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