heartbleed patterns ?

Carter Bullard carter at qosient.com
Mon Apr 14 10:13:33 EDT 2014


Hey Sebas,
The key to this type of analytic is to realize that
much of the variances drop out, as the protocol is
dominated by a different but deterministic behavior.

Still, it is the realization of unencrypted traffic
on the TLS channel that is the real key to detecting
the problem.  The PCR does help for the aggressive
case, where the buffer mining behavior dominates
all other behavior on the TLS.

Carter


On Apr 13, 2014, at 7:06 AM, el draco <eldraco at gmail.com> wrote:

> After looking at the traffic I sent I realized that it was not the
> best dataset, for once there was no easy way of differentiate the
> attack and the normal traffic. So I created another one. I hope it is
> better.
> 
> Now I used 3 hosts: the victim, the attacker and the normal.
> 
> The timeline is like this (the dates are synchronized with the pcap file):
> Sat Feb 15 15:37:57 UTC 2014
> I started the capture
> -Dradis server: 10.0.0.40
> -Normal access: 10.0.0.43
> -Attacker: 10.0.0.42
> 
> Sat Feb 15 15:38:11 UTC 2014
> Access to dradis with the normal computer. IP 10.0.0.43
> I created some notes and work a little bit without any attack. Normal actions.
> Even I upload a small file to dradis.
> 
> Sat Feb 15 15:43:56 UTC 2014
> I started the attack from 10.0.0.42 with an infinite loop using the
> public python heartbleed exploit.
> 
> Sat Feb 15 15:44:46 UTC 2014
> In the normal computer I logged out from dradis.
> 
> Sat Feb 15 15:45:11 UTC 2014
> i login again
> 
> Sat Feb 15 15:45:48 UTC 2014
> I created some notes and info on the dradis
> 
> I tried to upload a file, reload the page. Then succedded in uploading
> the file. Work a little bit.
> 
> Sat Feb 15 15:48:38 UTC 2014
> i logged out as admin. I try to login with baduser1 and badpass1.
> 
> Sat Feb 15 15:49:35 UTC 2014
> Then with baduser2 and badpass2.
> 
> Sat Feb 15 15:50:12 UTC 2014
> I stopped the attack, but continue with the normal computer.
> 
> Sat Feb 15 15:50:32 UTC 2014
> I use the system a little longer normaly.
> 
> Sat Feb 15 15:51:58 UTC 2014
> I logged off from the normal computer.
> 
> Sat Feb 15 15:52:18 UTC 2014
> I stopped the capture.
> 
> This capture can be found in the malware capture facility project web
> page again https://mcfp.felk.cvut.cz. Direct links are:
> https://mcfp.felk.cvut.cz/publicDatasets/CTU-Manual-Capture-Attack-2/
> https://mcfp.felk.cvut.cz/publicDatasets/CTU-Manual-Capture-Attack-2/heartbleed.normal.and.attack.1.pcap
> https://mcfp.felk.cvut.cz/publicDatasets/CTU-Manual-Capture-Attack-2/heartbleed.normal.and.attack.1.biargus
> https://mcfp.felk.cvut.cz/publicDatasets/CTU-Manual-Capture-Attack-2/heartbleed.normal.and.attack.1.timeline
> But there are more files there for the analysis. For example, in the
> tcpflow pdf report, you can see exactly when the attack started and
> ended.
> 
> A quick analysis of only the PCR of this capture shows this:
> The histogram data for the attacker is small:
>     Amount PCR
>     63 -0.985890
>     62 -0.000000
> 
> But the histogram data for the normal computer is longer and have more
> values in the middle. I'm sending you the histograms plots and raw
> data so you can see.
> 
> I know that this analysis is quick and really biased because the
> normal access is focused and small. But maybe we can extract some
> clues from here.
> 
> Based on Carter's and John's presentation "PCR - A New Flow Metric", I
> can see that a lot of traffic has these peaks near -1 and 0 values, so
> maybe it is not easy to differentiate the attack.
> And of course, this data was obtained by looping the attack for
> several minutes. If there are only few requests, they may no easy to
> detect.
> 
> Hope this helps.
> sebas
> 
> 
> 
> On Sat, Apr 12, 2014 at 4:00 PM, el draco <eldraco at gmail.com> wrote:
>> Hi list.
>> Just a contribution for this heartbleed analysis. I'm sending you a
>> real capture of a heartbleed attack I made with my servers. I'm not
>> sure if you already made your captures, but my capture files can be
>> published.
>> 
>> The server is a virtualized Kali running a vulnerable Dradis web
>> server. The client is a linux maxhine (macs and ips are only for this
>> experiment)
>> The attack is using the public pyhton exploit in an infinite loop.
>> Every time it gets different information.
>> 
>> Timeline is like this:
>> 1- I started the capture
>> 2- I started the infinite attack
>> 3- I accessed the dradis framework web page
>> 4- I login with valid credentials
>> 5- I create notes and use the system a while
>> 6- I logout
>> 7- I left some seconds without doing nothing.
>> 8- I try to login with non valid credentials. Twice.
>> 9- I left some seconds without doing nothing.
>> 10- i stop everthing.
>> 
>> I'm posting the pcap file and the bidirectional argus file (with
>> ARGUS_CAPTURE_DATA_LEN=120).
>> 
>> The data is available in our Malware Capture Facility Project,
>> http://mcfp.felk.cvut.cz, where you can also find more long-lived,
>> real and labeled botnet captures.
>> 
>> You can download them from here:
>> https://mcfp.felk.cvut.cz/publicDatasets/CTU-Manual-Capture-Attack-1/10.0.0.40.dradis.heartbleed.pcap
>>  (~2.4MB)
>> https://mcfp.felk.cvut.cz/publicDatasets/CTU-Manual-Capture-Attack-1/10.0.0.40.dradis.heartbleed.biargus
>> (~150KB)
>> 
>> You can play with it and test the detection methods. Hope it helps.
>> btw: The server is running only this dradis server, so the attack
>> downloaded almost every data I sent. Even the fake logins and
>> passwords. See for yourselves.
>> 
>> Have fun
>> sebas
>> 
>> On Fri, Apr 11, 2014 at 6:21 PM, Carter Bullard <carter at qosient.com> wrote:
>>> Hey Mike et. al.,
>>> I realized that I may have bashed Apple in my last email,
>>> so to be fair and to give a good analysis, I want to clarify.
>>> 
>>> When looking for strings in TLS, in the handshake there is
>>> some ascii, especially in the first 128 bytes from the
>>> client, as you'll see the hostname of where you're going.
>>> 
>>> But in the server side of the TLS connection, rarely do you
>>> see strings, except possibly in the certificate exchange.
>>> 
>>> So, looking at this in depth, it is weird about the
>>> Apple string captures that I am seeing using the simple
>>> method that I sent earlier.  It could be that my argus is
>>> capturing some of the apple server certificate exchange, but
>>> its the only server out of 1000's of https servers that I
>>> have data for, that exposes any information that looks like
>>> a certificate, which led me to say that apple is using
>>> TLS heartbeats, and that its leaking information.
>>> 
>>> I do see strings from specific apple TLS connections, through
>>> out early 2013, that revealed "Entrust.net" strings, but they
>>> could be embedded in the public server certificate, and so not
>>> necessarily a problem.  But if they are instead, embedded
>>> in the private certificate, then that should be a big problem,
>>> at least for Apple.  (I thought Apple used their own CA to
>>> do certificates).
>>> 
>>> Sorry, if my earlier email was misleading.
>>> 
>>> Using the earlier method of just looking for strings, if I
>>> reject the apple sites that have "entrust.net" embedded, I did
>>> find 2 sites that leaked data through TLS heartbeats, as I
>>> found URLs in the encrypted stream.  This covered all of 2013
>>> for my sites.  No significant unencrypted memory leaks from my
>>> site out through TLS.
>>> 
>>> 
>>> Carter
>>> 
>>> On Apr 11, 2014, at 10:43 AM, Carter Bullard <carter at qosient.com> wrote:
>>> 
>>>> Hey Mike,
>>>> The unambiguous test is clear text exchanges on TLS flows, and user data capture, even as little as 32 bytes does reveal some exploits, such as bad actor servers mining buffers from client machines, say during long video downloads, especially from some porn sites.
>>>> 
>>>> With the PCR your looking for changes in the balance of data exchange, and so it will be useful for a class of TLS based connections where the heartbeat becomes the predominate contributor to the total demand of the connection.  So this works in the case where the attack is very aggressive.
>>>> 
>>>> For many exploits that are trying to be stealthy, such as in some video streaming cases,  the memory minor is not trying to maximize the collection of buffers.  Here the heartbeat will not move the PCR so much, but the probability of unencrypted traffic being collected by argus goes wayyyy up.
>>>> 
>>>> I know you don't have user data, but if you did, something as simple  as a regex like " [A-z]{5}" should work ???
>>>> 
>>>>  ra -R whole.archive -e "[\x00-x7F]{7}" - port https
>>>> 
>>>> should find any flow where argus sees 5 ascii chars in a row, unencrypted buffers ,in an https based TLS connection ???
>>>> 
>>>> What this showed me, is that Apple uses TLS heartbeats, and so some of my Macs leak some memory chunks back to Apple.  Apple generally leaks strings like "www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)1%0#".  I'm capturing 128 bytes as the rule, and that shows me an interested trend.
>>>> 
>>>> Carter
>>>> 
>>>> 
>>>>> On Apr 10, 2014, at 9:11 PM, mike tancsa <mike at sentex.ca> wrote:
>>>>> 
>>>>> 
>>>>> These options look better
>>>>> 
>>>>> # ra -L0 -N 30 -nr radium.2014.04.03.16.00 -spcr,sbytes,dbytes,sappbytes,dappbytes - tcp and port 993 and pkts gt 10 and srcid <host I am interested in>
>>>>> 
>>>>> PCRatio     SrcBytes     DstBytes    SAppBytes    DAppBytes
>>>>> -0.564713         8200        17427         3718        13365
>>>>> -0.323127         2438         3154         1238         2420
>>>>> 0.081633         6384         4596         2226         1890
>>>>> 0.748789         5352         2984         4692          674
>>>>> -0.627924         7774        16846         2974        13012
>>>>> -0.610738         2744         5972         1218         5040
>>>>> -0.550795         4315         7347         1667         5755
>>>>> -0.323609         3426         3939         1368         2677
>>>>> -0.566158         4551         7813         1705         6155
>>>>> 0.073302         6215         4662         2189         1890
>>>>> -0.510569         3463         5341         1343         4145
>>>>> -0.745797         2412         5459          688         4725
>>>>> -0.775878         2724         4648          472         3740
>>>>> 0.237192         1048         1128          652          402
>>>>> -0.440237         2002         3094          946         2434
>>>>> 0.990593       355233        13419       337929         1597
>>>>> 0.090220         6183         4506         2157         1800
>>>>> -0.229565         3090         3093         1230         1963
>>>>> 0.235040         6457         3760         5005         3100
>>>>> -0.025942         3442         3086         1990         2096
>>>>> -0.634990         5796        10204         1836         8224
>>>>> 0.081633         6384         4662         2226         1890
>>>>> -0.392833         1888         2786          898         2060
>>>>> -0.217314         3378         3381         1320         2053
>>>>> -0.592405         4221         8511         1771         6919
>>>>> -0.546398         2225         3225          699         2383
>>>>> 0.081633         6384         4596         2226         1890
>>>>> -0.342771         2687         3029         1091         2229
>>>>> -0.527645         3189         3232          739         2390
>>>>> 0.934990        28527         2300        26431          888On 4/10/2014 9:04 PM, mike tancsa wrote:
>>>>>>> On 4/10/2014 8:47 PM, Jesse Bowling wrote:
>>>>>>> Hi Mike,
>>>>>>> 
>>>>>>> You would need to have this section in your argus.conf/command line in
>>>>>>> order to be generating application byte metrics (which pcr is based on):
>>>>>>> 
>>>>>>> # Argus can be configured to generate metrics that include
>>>>>>> # the application byte counts as well as the packet count
>>>>>>> # and byte counters.
>>>>>>> #
>>>>>>> # Commandline equivalent   -A
>>>>>>> #
>>>>>>> 
>>>>>>> ARGUS_GENERATE_APPBYTE_METRIC=yes
>>>>>> 
>>>>>> Thanks, I do have that on the particular server I am interested in.  I
>>>>>> collect it via radium, so hopefully that did not mess up the old
>>>>>> historical records.
>>>>>> 
>>>>>> ra -L0 -N 30 -nr radium.2014.04.03.16.00
>>>>>> -spcr,spkts,dpkts,dbytes,sbytes,srcappbyte - tcp and port 993 and pkts
>>>>>> gt 10 and host xxxx
>>>>>>  PCRatio  SrcPkts  DstPkts     DstBytes     SrcBytes
>>>>>> -0.564713       82       75        17427         8200
>>>>>> -0.323127       18       11         3154         2438
>>>>>> 0.081633       63       41         4596         6384
>>>>>> 0.748789       10       35         2984         5352
>>>>>> -0.627924       87       71        16846         7774
>>>>>> -0.610738       23       14         5972         2744
>>>>>> -0.550795       40       24         7347         4315
>>>>>> -0.323609       31       19         3939         3426
>>>>>> -0.566158       43       25         7813         4551
>>>>>> 0.073302       61       42         4662         6215
>>>>>> -0.510569       32       18         5341         3463
>>>>>> -0.745797       26       11         5459         2412
>>>>>> -0.775878       34       14         4648         2724
>>>>>> 0.237192        6       11         1128         1048
>>>>>> -0.440237       16       10         3094         2002
>>>>>> 0.990593      262      179        13419       355233
>>>>>> 0.090220       61       41         4506         6183
>>>>>> -0.229565       28       17         3093         3090
>>>>>> 0.235040       22       10         3760         6457
>>>>>> -0.025942       22       15         3086         3442
>>>>>> -0.634990       60       30        10204         5796
>>>>>> 0.081633       63       42         4662         6384
>>>>>> -0.392833       15       11         2786         1888
>>>>>> -0.217314       31       20         3381         3378
>>>>>> -0.592405       37       24         8511         4221
>>>>>> -0.546398       23       13         3225         2225
>>>>>> 0.081633       63       41         4596         6384
>>>>>> -0.342771       24       12         3029         2687
>>>>>> -0.527645       37       13         3232         3189
>>>>>> 0.934990       38       26         2300        28527
>>>>> 
>>>>> 
>>>> 
>>> 
> <attack.computer.hist.data><normal.computer.hist.data><normal.hist.png><attack.hist.png>

-------------- 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/20140414/1e0bc697/attachment.sig>


More information about the argus mailing list