Allow us to leave!
Here's one yardstick that I use before signing up for any new online service: I first search the Interwebs for stories from users who tried to close their account and to leave same service, and were given a hard time. I understand that commercially it is "rewarding" to show 300 million subscribers, even if 90% of them are stale accounts. But from a privacy and data security point of view, it does NOT make any sense for a user to leave an account behind that he/she knows for sure will never be used again. Some services, also larger ones, are handling this issue professionally, and have a decently findable link on their home page that allows the closing of an account and deletion of stored data. Others .. give you the run-around via six levels of customer "service", and in the end, they basically change your username to username.inactive, but leave everything else as-is. And keep spamming you, too.
If you have stories to share about online services that don't let you leave, please do so below. Keep it PG-13 and factual, please, but if a little ire shines through, we understand ...
Finding the bleeders
Now that the frantic frenzy around "Heartbleed" has calmed, and most sites are patched, it is time to circle back. For a server at a community college that I knew had been affected, I wanted to see if someone had pulled any data via Heartbleed during the roughly 36 hours between when the vulnerability became widely known, and when IDS signatures and patches were deployed to protect the site.
Problem is, Heartbleed leaves basically no traces in the httpd server log, so checking there for attacks didn't help. After a bit of pondering, we came up with the idea to correlate the firewall log with the web server log. If the firewall had seen a number of tcp/443 (HTTPS) connections to the web server from a certain IP, but these same connections were not in the web server log, chances were that we had found ourselves a bleeder.
The first IP that the correlation script identified as potentially fishy turned out to be owned by SSLlabs, and likely belongs to their public SSL scanner that everyone was using at the height of the panic. So .. the script seemed to be working well, and was pulling out the "right" types of connections.
A bit later, we found another IP, registered to an ISP in Malaysia. Twenty minutes of hits only on the firewall, at a rate of about one every 5 seconds, followed by a 5 minute pause, followed by hits both on the firewall and on the web server. Hmm, peculiar :). Chances are high this was in fact someone who tried to steal cookies of active sessions first, and then tried to re-use the cookies to break in. For the second part of the attack, the web server log shows GET requests to the application, followed by a 302 redirect to the "login" page, so "something" must have gone wrong on the attacker's side in either stealing the cookies, or in splicing them back into his fake requests. After another 20 minutes and about 60 requests which all were answered with a redirect, the attacker gave up.
Which tools or methods did you use to identify "heartbleed" leaks that occurred in the time span where your site was vulnerable, but IDS instrumentation and patching wasn't really available yet? Feel free to let us know via the contact form, or share in the comments below!
OpenSSL Rampage
OpenSSL, in spite of its name, isn't really a part of the OpenBSD project. But as one of the more positive results of the recent Heartbleed fiasco, the OpenBSD developers, who are known for their focus on readable and secure code, have now started a full-scale review and cleanup of the OpenSSL codebase.
If you are interested in writing secure code in C (not necessarily a contradiction in terms), I recommend you take a look at http://opensslrampage.org/archive/2014/4, where the OpenBSD-OpenSSL diffs and code changes are coming in fast, and are often accompanied by cynical but instructive comments. As one poster put it, "I don't know if I should laugh or cry". The good news though definitely is that the OpenSSL code is being looked at, carefully and expertly, and everyone will be better off for it.
Heartbleed hunting
Yes, I know that by now you are really tired of hear and read about Heartbleed. You probably already got all testing scripts and tools and are looking on your network for vulnerable servers.
I was just playing with the Shodan transformer for Maltego and looking for some specific versions of OpenSSL. The results are not good...
Somethings to keep in mind when checking your network is that the tools may not detect all vulnerable hosts since they may be buggy themselves :)
According some research, one of the first scripts released to test the vulnerability, and that most of people still use to identify vulnerable servers contains some bugs that may not detect correctly the vulnerable servers.
The heartbeat request generated on the proof of concept script is:
18 03 02 00 03 01 40 00 <-- the bold bytes basically tell the server to use TLS 1.1, so if the server only supports TLS 1.0 or TLS 1.2 it won't work. Of course that 1.0 and 1.2 are not widely used, so the chance of you having it on your network is small, but still, there is a chance.
Early last week, while testing different online and offline tools, I also came across different results, so you may want to use different tools on your check.
Network signatures may also provide additional check to help you identify vulnerable hosts. Again there is a chance of False Positives, but it is worth to provide you with more info on your checks.
Snort signatures and network parses for products like Netwitness can also be very effective to detect not only when an exploit was used against your hosts, but most importantly, when your vulnerable host provided information back (the leaked info).
Happy hunting to you because the bad guys are already hunting!
--------------------
Pedro Bueno (pbueno /%%/ isc. sans. org)
Twitter: http://twitter.com/besecure
Comments