CloudBleed: Guess What? There was 0-day protection
If you aren’t familiar with CloudBleed, take a moment to read the following articles to get an understanding how it was found, what happened, and what PII/PCI data was (possibly) leaked:
- Vulnerability Disclosure from Tavis Ormandy (@taviso), a security researcher at Google
- Incident Response from CloudFlare
- 3rd party assessment from Ryan Lackey (@octal)
In some of the examples shown by Tavis, or by digging into cached sites on less popular search engines, you can see how usernames, passwords, sessions, credit card info, etc could be seen in clear text despite the use of HTTPS (TLS1.2). A simplification of the flow would look like this:
Request: Client >=====> CloudFlare >=====> Origin Web Server
Response: Client <=====< CloudFlare <=====< Origin Web Server
Despite the fact that the client is utilizing HTTPS, CloudFlare has the ability to terminate the secure connection since it has the private key. This is essentially the content (PII or PCI) that was being cached if certain conditions occurred on the CloudFlare reverse proxy.
0-day Protection Against CloudBleed
So, what is the 0-day protection and what is it all about? Application Layer Encryption is a feature from F5 that would have left researchers scratching their heads when looking at the cached content.
First things first, let’s dynamically encrypt sensitive parameter names using Application Layer Encryption. But really, what does that mean? Let’s take a deeper look.
In all examples I will be using Google Chrome.
Let’s say you have login page without Application Layer Encryption.
If I were to right click on the Password box and choose Inspect, I would see something like this:
As you can see from the red boxes, the parameters for my username and password are log and pwd. We can all agree that this is in human readable format (HRF).
If I were to do the exact same thing with Application Layer Encryption, I would see this:
In the screen shot above there are 3 things I would like to focus your attention on:
- Both name=log and name=pwd are no longer in HRF.
- Notice in the first red box that there is a slight purple hue over the value? That’s the dynamic part of Application Layer Encryption. Every few seconds the values will change. This is done on the client side, not the server side. That value will never repeat and is completely unique to the user’s session.
- We also removed the element IDs, id=”user_login” and id=”user_pass”.
With Application Layer Encryption turned on, every user will have a unique value for name=log and name=pwd moving forward.
We can also turn up the security a notch by inserting decoy fields to further confuse the bad guys.
Decoy fields are only seen in the raw code and do not change the end users experience. As you can see above, there are additional IDs which makes it very difficult to pull apart in a replay attack.
But Brian, what about the values being sent!?!!?
As you can see from the picture above, the username is briandeitch and the password is test. Although this is sent via HTTPS, CloudFlare has the private key and this is the type of data that could have been cached by search engines. Yikes!
Same exercise but this time with Application Layer Encryption:
Decoy fields turned off:
Decoy fields turned on:
As you can see from the form data, both the parameter names and values have been dynamically encrypted on the client side. Let’s say this data was leaked by CloudFlare and cached by a search engine. Couple of points:
- These substituted and encrypted values are single use, meaning a replay attack wouldn’t work.
- Good luck reverse engineering any of this. Application Layer Encryption uses private/public key technology and this key, unlike the private key for the SSL Certificate, isn’t hosted on CloudFlare. This means the payload (form data shown above, you know the values for the username and password) is completely encrypted to CloudFlare (or any other proxy for that matter).
- In addition, the decoy fields are sent as well. Good luck deciphering which fields are mapped to the actual application(s).