heartbleed patterns ?
Carter Bullard
carter at qosient.com
Fri Apr 11 12:21:57 EDT 2014
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
>>
>>
>
-------------- 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/20140411/6ec860d3/attachment.sig>
More information about the argus
mailing list