heartbleed patterns ?

[Carter Bullard]

Hey Mike,
Your argus can generate the metric.  The clients use the srcappbyte
and dstappbyte values that argus has always been able to generate.
You do have to turn those on though.  We can calculate an bad
approximation if the appbyte values aren’t there, but the theory
is based on application bytes.

Carter

On Apr 10, 2014, at 4:46 PM, mike tancsa <mike at sentex.ca> wrote:

> 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
>>> 
>> 
>> 
> 
> 

-------------- 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/20140410/a9796ebd/attachment.sig>