heartbleed patterns ?

[mike tancsa]

Hi Jesse,
	I didnt know of this filter in Argus, nor this metric to analyze. Are 
there any good references you can point me to on this topic ?

I guess this is only available in the dev version of the clients ? If 
the data I have is saved from an older version of argus/radium, am I 
able to safely use the newer clients on older archives and get valid info ?

	---Mike

On 4/9/2014 6:24 PM, Jesse Bowling wrote:
> A friend of mine observed a pcr of -.99 in cases of known heartbleed attacks; hence my earlier question regarding filters. :)
>
> I'm also interested in seeing how this plays out!
>
> Cheers,
>
> Jesse
>
>> On Apr 9, 2014, at 5:57 PM, Carter Bullard <carter at qosient.com> wrote:
>>
>> 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
>>
>
>