heartbleed patterns ?
Terry Burton
tez at terryburton.co.uk
Mon Apr 14 10:44:22 EDT 2014
On 14 April 2014 15:41, Reynolds, Jeffrey <JReynolds at utdallas.edu> wrote:
> 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.
May be of interest:
http://vrt-blog.snort.org/2014/04/performing-heartbleed-attack-after-tls.html
> 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