heartbleed patterns ?

Fri Apr 11 08:46:53 EDT 2014

Hey Jesse,
grepping the user buffer is available in all ra* progrmas !!!
and we have support for regex or pcre at compile time.
that was some real work !!!

Carter

Carter Bullard, QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax

> On Apr 10, 2014, at 8:45 PM, Jesse Bowling <jessebowling at gmail.com> wrote:
> 
> I wanted to also bring up the thread from 2012 with subject "[ARGUS] Feature request: grep hex strings with -e"; this option would seem to be especially apropos now but it doesn't seem to be available in the 3.0.7.23?
> 
> # ra --version|head -1
> Ra Version 3.0.7.23
> # ragrep --version|head -1
> Ragrep Version 3.0.7.23
> 
> # ra -M printer="hex" -r sample.heartbleed.argus -s suser -N 1
>                                                                 srcUdata                                                                  
> 
>       0x0000     1603 0200 dc01 0000 d803 0253 435b 909d        ...........SC[..
>       0x0010     9b72 0bbc 0cbc 2b92 a848 97cf bd39 04cc        .r....+..H...9..
>       0x0020     160a 8503 909f 7704 33d4 de00 0066 c014        ......w.3....f..
>       0x0030     c00a c022 c021 0039 0038 0088 0087 c00f        ...".!.9.8......
>       0x0040     c005 0035 0084 c012 c008 c01c c01b 0016        ...5............
>       0x0050     0013 c00d c003 000a c013 c009 c01f c01e        ................
>       0x0060     0033 0032 009a 0099 0045 0044 c00e c004        .3.2.....E.D....
>       0x0070     002f 0096 0041 c011 c007 c00c c002 0005        ./...A..........
> 
> # ra -M printer="hex" -r sample.heartbleed.argus -s suser -e '\x16\x03'
> # ragrep -M printer="hex" -r sample.heartbleed.argus -s suser -e '\x16\x03'
> #
> 
> Did I miss a compile option perhaps? 
> 
> # grep -i pcre config.log
> PCRE_CFLAGS=''
> PCRE_CONFIG=''
> V_PCRE=''
> 
> 
> Cheers,
> 
> Jesse
> 
> 
>> On Thu, Apr 10, 2014 at 6:29 PM, Carter Bullard <carter at qosient.com> wrote:
>> 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
>> >>>
>> >>
>> >>
>> >
>> >
> 
> 
> 
> -- 
> Jesse Bowling
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20140411/1eb02110/attachment.html>