Cloudbleed

It turns out that if you crawl enough of the Internet, pages start bleeding into one another. At least that’s the case for Google Security Researcher, Tavis Ormandy, who discovered a severe flaw in Cloudflare’s service. The flaw, eerily reminiscent of the infamous Heartbleed bug, resulted in revealing uninitialized memory containing sensitive information ranging from ‘encryption keys, cookies, passwords’, and even private messages on a dating website. Cloudflare’s post-mortem indicates that the flaw was introduced when ‘Automatic HTTP Rewrites’ was enabled in 2016-09-22.

The root cause of the flaw was a fragile pointer arithmetic check. The code was checking for strict equality (==) as opposed to greater than or equal to (>=) when determining if the pointer has reached the end of the buffer. In order to trigger this vulnerability, a request for an HTML page containing unbalanced HTML code would result in extraneous data being returned which contained internal Cloudflare headers, cookies, and authorization headers/tokens depending on what just happened to be in memory at the time. Since Cloudflare is a shared service, popular websites (Uber, FitBit, OKCupid, etc) are more likely to remain resident in memory and thus be leaked when the flaw was triggered.

Agilebits, the makers of 1Password, has responded with an overview of how their use of multiple encryption layers protect their users in cases where SSL/TLS fails.

In a follow-up post, Cloudflare did not find any evidence that the bug was actively exploited. However, it’s impossible to rule out given the large opportunity window, lack of logs, and Cloudflare’s large customer base. One of the biggest issues remaining are websites that have been scraped or cached by automated bots (other than well-known search engines such as Google which have purged affected page caches) that may have inadvertently saved the leaked information.

On the bright side, there is a ray of sunshine as the clouds recede: Cloudflare was able to deploy a mitigation within an hour and patch their services in seven hours.

For users, there are several things you can do to protect yourself:

•  Change your password on websites using the Cloudflare service

•  Use two-factor authentication (2FA) where available

For service providers, this is an excellent opportunity to re-evaluate your threat model and understand the risks of using shared cloud services.

•  If you rely on SSL/TLS to provide transport security, the SSL/TLS needs to be terminated inside your network and not at a third-party service provider

•  Employ defensive programming

Check out Ryan Lackey’s take and Ryan McGeehan’s take for more information on how to handle the fallout.

CloudPets: ‘Embearassingly’ bad security

If a bear spies on your child, does anyone hear it? If the bear is made by CloudPets, the answer is yes. This week’s chapter of the never ending compendium of ‘why you shouldn’t put a chip in it’ has a bluetooth-enabled teddy bear acting as a remote spying device and <sarcasm>in a plot twist no one has seen before, the manufacture doesn’t seem to care</sarcasm>.

The National Security Agency was ahead of the times when they banned Furbys in 1999. It took approximately two decades for consumer electronics to catch up to their fears of creating a child’s toy that could moonlight as a remote listening device.

SpiralToys, the maker behind CloudPets, left their MongoDB server open to the public, making it child’s play to steal the sensitive information. Additionally, an unsecured Amazon S3 bucket meant that attackers with knowledge of the voice recording filenames could trivially download the messages.

For all you parents out there, reconsider buying ‘smart’ or ‘cloud-enabled’ toys for your kids. This isn’t the first time toy manufacturers have compromised families privacies, and it’s not just toys that are vulnerable – even Internet-connected baby monitors are a bad idea. Germany has already taken steps to ban Internet-connected dolls out of fears that attackers could target children.

If you’re considering putting a service up in the cloud, be sure to lock it down properly.

•  Check out the flAWS challenge to learn more about common mistakes that lead to security vulnerabilities when operating in the cloud

•  Deploy your database servers in a private VLAN − far away from being publicly accessible from the Internet

•  Require authentication, authorization, and auditing (AAA) on sensitive datastores such as databases

• Engage with security professionals to design and secure your service

•  Use pre-signed URLs when using S3 to share files

.

By:
Cylance Research and Intelligence Team
Cylance
www.cylance.com

  • Twitter
  • Facebook
  • Google+
  • Digg
  • Gmail
  • LinkedIn
 
  • Twitter
  • Facebook
  • Google+
  • Digg
  • Gmail
  • LinkedIn

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

You have Successfully Subscribed!

Share This