heartbleed patterns ?
Carter Bullard
carter at qosient.com
Wed Apr 9 17:57:45 EDT 2014
Hey Mike,
I was going to do something about that today, since its a hot topic.
I’m thinking that there are a number of strategies for mining server
memory using TLS heartbeat attacks, and using argus to discover them
should be pretty successful. I haven’t found any incidents of this in
any of my data, so these strategies need to be tested to be real.
The big give away is that the TLS heartbeats are unencrypted (?), so
if you are collecting user data, you will see strings in your TLS
buffers. If the attackers are aggressive, you should see long lived
TLS connections, that started with the HELLO exchange to negotiate the
heartbeat extension, but not proceeding with any other part of the TLS
handshake. This is valid TLS protocol and attackers will be pretty
efficient, so as not to identify themselves for the system logs.
The memory miner, I suspect, would connect, and then just sit there
asking for large heartbeat responses, to farm as many server memory
buffers as they are willing to grab. All of which which should be
unencrypted on the wire.
This scenario would be the most zero false positive zero false
negative case to detect, that I can think of. Unambiguous intent,
not even trying to negotiate a full TLS, and getting the goods.
The heartbeat request can be pretty small, 20 bytes ?? And the response
would be very large, so the PCR for a buffer miner, connecting
to a vulnerable server, would be approaching -1.0. (I’ll have to fix
the filter to find some of these).
So, long lived connections, low source load values, after the
TLS handshake, and large dst byte counts for the memory dumps,
all in the clear.
If that jives with your understanding, we can come up with a
decent set of filters to find those types of connections.
There are others that are not so obvious. Lets continue this.
Gotta run, but will be back later tonight.
Carter
On Apr 9, 2014, at 5:02 PM, mike tancsa <mike at sentex.ca> wrote:
> Has anyone come up with or seen any flow patterns indicative of someone trying to exploit the OpenSSL heartbleed vulnerability ? I would like to go through my old logs to see if anyone was poking about prior to the general announcement.
>
> ---Mike
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20140409/e48a2d00/attachment.sig>
More information about the argus
mailing list