heartbleed patterns ?
el draco
eldraco at gmail.com
Sat Apr 12 10:00:32 EDT 2014
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