heartbleed patterns ?

Reynolds, Jeffrey JReynolds at utdallas.edu
Mon Apr 14 10:41:43 EDT 2014


>From what I¹ve seen with the code at mentioned at filippo.io/Heartbleed/,
this is what happens.  The the TLS session seems to complete and the
heartbeat packets are encrypted.  I could be wrong though, and I haven¹t
found any definitive sources that state as much.

Jeff

On 4/14/14, 9:27 AM, "Terry Burton" <tez at terryburton.co.uk> wrote:

>On 14 April 2014 15:13, Carter Bullard <carter at qosient.com> wrote:
>> 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.
>
>Reading RFC6520 it is my understanding that a heartbeat volley may
>occur after TLS handshake in which case the traffic will be encrypted.
>
>
>> 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/hea
>>>rtbleed.normal.and.attack.1.pcap
>>> 
>>>https://mcfp.felk.cvut.cz/publicDatasets/CTU-Manual-Capture-Attack-2/hea
>>>rtbleed.normal.and.attack.1.biargus
>>> 
>>>https://mcfp.felk.cvut.cz/publicDatasets/CTU-Manual-Capture-Attack-2/hea
>>>rtbleed.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




More information about the argus mailing list