So…I’d like to be able to see if any heartbleed activity was happening before everyone knew about it. I’m thinking I’d see this in the conn.log with data leaving the server. Any thoughts or pointers we could use to check? Thanks all.
James
Heartbleed is extremely difficult to detect without doing an inspection of the TLS traffic. The biggest indicator is that a heartbeat message response is larger than the request. But with regular https traffic, as an example, you’ll see similar looking payloads, just as a matter of course. I.e., a GET request which is X kB will garner a response that is Y kB (where Y is greater than X).
If you take a look at the branch that the bro folks released to detect heartbleed, they specifically inspect the heartbeat message if a cipher spec hasn’t been chosen. And if a cipher has been chosen, compare the payload sizes of the heartbeat request/response (TLS Record information is in the clear, even if the actual record is encrypted).
I’m not sure you can come up with a reliable and simple means of finding it through the information in the connection log. But I’d like to be wrong in this instance. If anybody disagrees with me, I’d really really like to know as it’d would help me (and a bunch of folks) out.
You’re correct, I don’t believe that the attack is apparent in any Bro logs in our releases. The only way at the moment to detect heartbleed with Bro is to use Johanna’s branch (although I’d love to be proven wrong if someone figures out a way to catch it!)
.Seth
From using the proof-of-concept code on my servers to validate before/after patching the vulnerability, I found the following common criteria in the Bro conn log:
orig_bytes=241
protocol=tcp
resp_port=443
Using this criteria in a search, and grouping by orig_ip, I was able to find all of the known attempts in my log from April 8. When I searched through historical logs, I had one false positive using the search but I don't know how many false negatives this produced.
Whether or not this search would work is completely dependent on your standard SSL traffic. You could try searching for orig_bytes < 250 and resp_bytes > 30000 but I suspect that won't work if your organization is offering downloads or rich web content...
John Landers
Note that there is an almost 100% chance that this (and similar) approaches will not work on any attacks that might have happened before the bug was publicly released.
You basically just fingerprint one of the (more common) tools. There is next to no chance that an earlier attack (or even someone using a different tool) will exhibit the same characteristics. All of them will send the TLS records in a slightly different way, perhaps enable encryption before sending them, or — perhaps even send a https request before the heartbeat to make it less obvious in logs.
Johanna
Yep. It's pretty much an impossible task.
John Landers
Check this blog
http://blog.bro.org/2014/04/detecting-heartbleed-bug-using-bro.html
use this git
git clone --recursive git://git.bro.org/bro -b topic/johanna/heartbeat
As a data point, NERSC ran our timemachine data (goes back several months) thru Johanna’s code, and saw no SSL Heartbeat attempts until the morning of Apr 8.
Thanks for the feedback all..very helpful.
James
I’m attempting to add an email alert for these, but I’m getting an error. This is my first time attempting this, so I may have something wrong with syntax.
Here is what I’ve added to local.bro.
hook Notice::policy(n: Notice::Info)
{
if ( n$note == SSL::SSL_Heartbeat_Attack_Success )
add n$actions[Notice::ACTION_EMAIL];
}
Here is the error:
error in /bro/share/bro/site/local.bro, line 96: unknown identifier SSL::SSL_Heartbeat_Attack_Success, at or near “SSL::SSL_Heartbeat_Attack_Success”
-John
Heartbleed::SSL_Heartbeat_Attack_Success
Easy mistake. 
.Seth
The heartbleed module is in the Heartbleed namespace so the notice is
Heartbleed::SSL_Heartbeat_Attack_Success
Also, there is a helper for that sort of thing, you can simply:
redef Notice::emailed_types += {
Heartbleed::SSL_Heartbeat_Attack_Success,
};
Thanks Justin,
I changed it to what you listed, but I’m still getting the following error:
error in /bro/share/bro/site/local.bro, line 95: unknown identifier Heartbleed::SSL_Heartbeat_Attack_Success, at or near “Heartbleed::SSL_Heartbeat_Attack_Success”
Do you have
@load policy/protocols/ssl/heartbleed
at some point before that?
Did you add that after the line that @loads the heartbleed script?
That did it.
Thanks!
Just curious how the heartbleed Bro build is running for folks. Any problems?
After implementing it just a little while ago, I’ve had eight notifications. Half of which look to be vulnerable servers.
So, I’d say so far good.
-John
Do you have a github with this script in it? Thanks!
https://github.com/bro/bro/tree/topic/johanna/heartbeat - the script is in scripts/policy/protocols/ssl/heartbleed.bro
Make sure to use the linked branch (topic/johanna/heartbeat)
Johanna