When CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) first came out I think we can all agree that it was a giant pain in the ass but some times it was comical.
About 9 years ago (who knew it was older than the original iPhone?), reCAPTCHA was released and got ride of the puzzle solving by simplifying the process to a check box.
Continue reading Bots and users beware, Google’s reCAPTCHA goes invisible
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:
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.
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 element, 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:
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!?!!?
Let’s look at a data submission without Application Layer Encryption from the browser via the network tools in Chrome:
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:
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:
Personally, my favorite part of Application Layer Encryption is that it requires no change to my back end applications. This solution requires no installation or modification to the end users web browser, 100% client-less, and transparent to the end user. At the end of the day, you can still rely on HTTPS for transport layer security however Application Layer Encryption steps up your overall security posture by using clever obfuscation and encryption to protect your data when there is a proxy between your customers and application.
Lastly, Application Layer Encryption is a feature with F5 WebSafe. F5 has taken a very complex solution and created a point and click solution to easily protect your application(s).
Step 1:By creating a profile, specify the URIs, you want protected.
Notice, you can also wildcard URIs too.
Step 2: Add the parameters you want protected.
The Encrypt check box is how we secure the username and password values that are being sent. That’s what prevents replay attacks.
The Substitute Value check box substitutes the parameter’s value with a random value in the web application while the form is being filled.
The Obfuscate check box encrypts the parameter’s name attribute.
Step 3: Associate the new profile to the application.
That’s it. Questions? Ping me on twitter @briandeitch
Best Regards,
BD
Special thanks to Brian McHenry, Todd Morton, Chad Fazio, Jeffery McFerson, Joe Martin, and Ted Byerly for their contributions on this article.
David Holmes from F5 is back with one bad-ass iRule to combat Mirai. After reviewing the source code for Mirai and a post by Scott Tenaglia David put together an iRule to cause Mirai to do a bad memory move and crash. Check out his post here:
Lastly, the iRule in question:
when RULE_INIT {
set static::mseconds 10000
set static::maxdupreq 10
}
when CLIENT_ACCEPTED {
set dup_req 0
set last_req ""
}
when HTTP_REQUEST {
if { $last_req equals "" } {
set last_req [HTTP::uri]
set dup_req 0
}
elseif { $last_req == [HTTP::uri] } {
incr dup_req
after $static::mseconds { if {$dup_req > 0} {incr dup_req -1} }
if { $dup_req > $static::maxdupreq } {
log "Killing suspected Mirai at [IP::client_addr]"
TCP::respond "HTTP/1.0\r\n200 OK\r\nLocation: http\r\n\r\n"
TCP::close
}
}
else {
set dup_req 0
}
}Best Regards,
BD