Another day, another high profile “bleed” incident has hit the headlines. Following shortly behind recently discovered F5 bug “Ticketbleed” (CVE-2016-9244), Cloudflare, a popular internet services company best known for their CDN (content delivery network), announced last week (on 2/19) a bug that leaked memory contents all over the internet. Cloudflare quickly rectified the issue hours after it was discovered, and then posted a detailed technical explanation on their blog about the root cause
https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/).
Never heard of Cloudflare? They’re the front-end for popular websites such as OKCupid, Uber, FitBit, and many others. Over 2 million websites use its platform and it handles 10% of the world’s web traffic.
Even though traffic to the major websites affected encrypted via HTTPS theoretically making it secure and safe from eavesdropping, any “bleed” incident allows attackers to extract contents from memory, which is not encrypted. Therefore, passwords, private messages, photos, credit card and social security numbers, anything and everything can be scraped and recovered. Website cookie data was also exposed and leaked. This is particularly concerning due to many websites significantly lowering security barriers when cookie data is detected. A cookie identifies you to the website as a person who has previously authenticated and therefore, is more likely to be legitimate, thereby bypassing security questions or even skipping login pages altogether.
In the case of a bleed incident, it is ironic that the “bad actors” were the search engines themselves – Google, Yahoo, and Bing – as they automatically and continuously scan and cache websites, inadvertently storing compromised memory contents and allowing anyone to access them. This was the precise mechanism by which this bug was discovered; a security researcher at Google discovered Cloudflare’s RAM contents cached by Google. Fortunately, since the website leak, Google and most major US-based search engine are now cleaning caches containing leaked data. However, users are still advised to change passwords on websites hosted by Cloudflare because private data may have been captured by third parties that have weaker ethics than the likes of Google.
As a user, what should you do as a response? Incidents like this stress the importance of using unique, randomly generated passwords for every site (stored by password managers). Therefore, if an attacker were to acquire your Uber credentials, they can’t use the same password to login to your back account. Secondly, adopt MFA (multi-factor authentication) wherever possible. Even if your password is compromised, unless attackers physically steal your phone (or whatever secondary authentication device is required), sensitive data remains secure.
As a society, breaches like this highlight several interesting facts. Firstly, it brings to light just how few people understand the underpinnings of the internet. Most people have no idea what a memory leak is (and how dangerous they are), or have even heard of firms such as Cloudflare, which just happens to be an internet behemoth.
Secondly, it demonstrates the fragility of an Internet reliant on a very small number of major companies to maintain its smooth operation. Humans aren’t infallible, and when coding under strict project deadlines, mistakes are bound to happen. It’s unfortunate if there’s a bug in your code and your website is compromised; it’s a major ordeal when a single bug causes over two million websites to be exploited.
Lastly, how many compromises or outages like this need to happen for businesses to realize that they should heavily consider the potential ramifications of hyper-centralization of vital online infrastructure?
Ironically, there is really no incentive for anyone to do anything about this, because it provides a kind of perverted safety in numbers: “It’s not just our website that had this issue, it’s everyone’s shared problem.” The same principle applies to large scale IaaS providers such as AWS and Azure. Two recent examples of this include the large Amazon S3 issue which affected a significant portion of websites and web-based applications on Tuesday and the Dyn DDoS attacks a few months prior. So, what do you do you might ask.
One step is to better understand the risks of using a specific provider, have a contingency plan when service interruptions, data breaches, bugs do occur, and have the resources and partners that you trust to have your back. To protect yourself in today’s environment knowledge and prevention is the first step to truly living with confidence in your business.
