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