Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Finding the bleeders InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Finding the bleeders

Published: 2014-04-21
Last Updated: 2014-04-21 18:49:54 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)

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!

0 comment(s)
Diary Archives