Argus detecting historical APT1 activity #3 cont

[Carter Bullard]

Hey Craig,
Seems that half the time I'm responding to your email, I feel like I need to beat you up.
Before I do that in this email, I'll apologize from the beginning, so sorry.  I'm going to
be somewhat forceful to emphasis some extremely important issues in Cyber
Situational Awareness, to point out the biggest problem out there, which is the
issue of human awareness in Cyber Security. But then I'll let you off the hook,
so hopefully this isn't going to be brutal.

Why on earth would you want to reassemble every executable file from HTTP
connections, generate an MD5 checksum and then go look the MD5 up
in someone else's database ?   Is this going to be helpful ???   Really ????
MD5 checksums, easy to change those ?  Adding an additional space to 
the executable, kinda makes this method pretty useless ?  And the better
question, are you authorized to capture this type of data ?  Really ??  Are
you sure ???

Pattern recognition has proven to be the WORST strategy for detecting Cyber
Security related events.  They cost an amazing amount of money, they don't
scale, they are remarkably unreliable, use an amazing amount of electricity,
don't do anything else for you other than look for small byte segments,
and generate so much heat and wasted time.   So much wasted time,....,
chasing down the amazing amount of false positives.  But even worse,
the false negatives are completely un-calculable.  This is just not a good
thing to evolve toward, in so many dimensions.

Some large users use argus just to do false positive rejection of Snort and
Suricata alarms.  And its not surprising.  You had in your example, a
" Heap spray " Snort signature, looking for " |5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c| ".
Do you know if that is a good signature?  It is now an old signature,
I believe that Microsoft has a fix in and the current pattern should be
' unescape("%u4141%u4141") '.    i'm sure in another 5 weeks, there
will be another string, then another ......  Looking for the string " unescape "
is probably a strategy that is bit more sustainable, than the actual bit pattern
test, and maybe a bit more reliable.  Who uploads " unescape " to a
browser?

Isn't it more important to see what it is that the Browser does once its been
corrupted by something like a Heap Spray technique than to simply set off a
" bell " every time you see " x0c|5C|x0c|5C " on the wire ??????

The point is that Cyber Security SHOULD NOT be a pattern recognition
discipline. 

Our imaginations are great, and the attackers imagination is probably better,
since he/she is motivated in a different way than we are.  However, only
a small number of attack ideas are actually useful, and the number of
attack defenses is even smaller.   We should be designing protection
strategies and mechanisms that are based on the actual theories of 
Cyber Security.  Bell-LaPadula, now there is a starting point.

OK, to let you off the hook, argus is designed as a data reduction audit engine.
The idea is we don't capture everything, we capture a minimum to enable
a large number of forensics capabilities.  We capture controlled samples of
transport data to enable content type identification / recognition.   In many cases,
our controlled sample strategy does capture enough payload to do all that
Snort, Suricata and Bro are designed to do, but in some cases we don't
grab enough to do complete Deep Packet Inspection, which I believe is a
forensics rat hole.    So, ..., if you want to grab all the packet contents with
argus, we provide all the bells and whistles to do so.  You can do packet capture,
and you can extend the amount of user data sampling to get almost all of it.

But I'd recommend that you just run Snort or Suricata along side argus.
Most vendors are supporting that type of multi-product strategy.

But to put the argus angle on this, more interestingly, the total number
of app bytes uploaded to a browser to perform a " heap spray " is as
sensitive an indicator of an exploit as the MD5 checksum over the contents.
And much more resilient to genetic mutation of the code.

Behavioral analytics, I believe are going to be more useful than pattern
recognition for Computer Network Defense, and that historical audit data
is the best data to base such systems.

Sorry if I was a bit too negative, hopefully this has been helpful.

Carter



On Apr 12, 2013, at 5:56 PM, Craig Merchant <cmerchant at responsys.com> wrote:

> Carter, thank you very much for writing such thorough and thoughtful emails on this subject.  I’ve shared them with the entire security team at work.
>  
> I’ve been thinking a bit on how Argus could be used to do more proactive alerting of these kinds of threats.  As you know, I’m not a programmer *at all*.  I had a couple of ideas and was wondering what it would take to implement them.
>  
> How difficult is it to reassemble a file from payload data?  I’m imagining being able to reassemble executable files from HTTP connections to external hosts, generating an MD5 of that file, and then use dig to query the malware database from:
>  
> http://www.team-cymru.org/Services/MHR/#dns
>  
> For APT threats that don’t drop a file and write directly to some vulnerable part of memory, what kind of payload data would be indicative of that kind of attack?  Looking through some of our Snort rules, I see patterns that look like:
>  
> Heapspray example:
> |5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|
>  
> Shellcode examples:
> |90 90 90 E8 C0 FF FF FF|/bin/sh
> |6a 43 59 e8 ff ff ff ff c1 5e 30 4c 0e 07 e2 fa 6b 63 5b 9d|
> \x00\x00\x00[\x00\x01].{4}\x00\x01\x00\x01lanattacks_(start_dhcp|reset_dhcp|set_dhcp_option|stop_dhcp|dhcp_log|start_tftp|reset_tftp|add_tftp_file|stop_tftp)
>  
> How would you use Argus to detect those types of attacks without generating a ton of false positives?  It doesn’t seem like the types of patterns above should be all that common in normal HTTP traffic. 
>  
> How much of the payload would Argus need to look at to reliably identify those types of attacks? 
>  
> Thanks.
> 
> Craig
>  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2589 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130413/a1d2639c/attachment.bin>