[Discussion] new thread: biggest threats

Wed Oct 22 15:49:53 UTC 2008

Excellent post. I've been using the concept of generic signature to
supply weight for higher-lever logic for a while now, be it in
research environments only, - including such features inside a more
low-level engine would be incredible.

By using a variant of a hidden markov model (HMM), one could calculate
probabilities of a certain process (represented by that model), states
within that process and state transitions occurring.

I have no clue if such a HMM could be used to create advanced
signatures in a Bro-like infrastructure, but the possibilities if it
would are fantastic. In risk management, the probability of a certain
thing occurring are as, if not more, valuable as knowing for certain
it is. The 'problem' with the more binary-output (hit/no hit)
signatures is that correlated over space and time, probability as
compared to 'still no hit' could again create valuable intelligence.
And with the possibility of probabilities of things occurring, the
possibilities for more elaborate signature increase as well. It's a
kind of never ending cycle too because the concept of reporting on
probabilities involves the same kind of hit/no hit signature - being
it on a higher level. The trick for us INFOSEC people is to ever
increase our capability of dealing in probabilities rather then 1/0
hits as long as possible.

Just some 0.3$.

Joep

Martin Holste wrote:
> All good points, and conclusions I had arrived at as well.  Then I saw
> the Bro XML validator plugin
> <http://bro-ids.org/wiki/index.php/XML_Analyzer> which showed that it is
> possible to do extremely intensive, app layer inspection if you can do
> it in a clustered, asynchronous way.  The other thought I had was that
> you wouldn't have to have the horsepower to actually render to memory
> what the browser would see.  You could get 80-90% of the value through
> JS profiling, as in, how many eval calls does the code make?  What is
> the entropy like?  If we could "score" JS, it would really open the door
> to a lot of possibilities, but we wouldn't necessarily have to create
> the entire DOM on the fly, just get a feel for the style.  Since Mozilla
> already provides the spidermonkey command line JS engine/API, the heavy
> lifting is already done.
> 
> Here's an example of how I see this working:  A sig detects that a user
> agent on a host changes and makes a note of it in a global array.  (The
> UA changing is obviously not malicious in its own right).  Another sig
> tracks which HTTP referrers were sent via iframe and keeps a short (by
> time) list of those in a global array.  A third sig tries to decode JS a
> bit to see how many evals are in the code.  A final sig looks for any
> executable downloads.  If all four hit on the same client in quick
> succession, you've got "probable cause."
> 
> Sounds like a lot of work, but I don't think it's as bad as the first
> impression makes it seem because instead of writing thousands of
> signatures for very specific occurrences like we do currently, you write
> a few hundred sigs for generic events, and then a few more hundred sigs
> for the matching up the combination of generic events which equals
> "badness."
> 
> This is where Bro would make a lot of this easy.  For instance, Bro
> allows for truly global lists to be shared between nodes, as in, the
> list of clients which have recently switched their user agent.  So every
> node is aware of this stuff.  Have you guys seen how cheap quad cores
> have become?  Run 4 processes on the same box and you get some easy load
> balancing.  Then you have enough horsepower to do this app layer
> inspection without packet drops.  I suspect you could even implement
> load shedding if they get in trouble.
> 
> I admit that this all sounds rather complicated, but there don't seem to
> be any simple exploits out there anymore in today's commoditized
> malware.  I don't think we can continue to depend on single-event
> signatures.
> 
> --Martin
> 
> On Wed, Oct 22, 2008 at 9:19 AM, Andre Ludwig <aludwig at packetspy.com
> <mailto:aludwig at packetspy.com>> wrote:
> 
> Correct, but the problem with JS is that it is an extremely expressive
> language.  One that in conjunction with the DOM provides a nearly
> infinite number of ways to shovel an exploit to vulnerable browser,
> kernel, or third party code.  That is the fundamental problem with IDS
> when attempting to detect/block these sorts of exploits at this layer.
> While I agree that your suggestion would be helpful it IMHO has no place
> on the network for sheer performance reasons alone (can you imagine
> trying to emulate a full DOM/JS engine at wire speed).   Browsers can
> barely keep up with the onslaught of horribly written JS code, much less
> purposefully obfuscated or obtuse JS that hides an exploit.   This is a
> topic that I have dedicated some thought to over the last three years so
> I would love to hear everyones ideas on the subject.
> 
> Andre Ludwig
> 
> Martin Holste wrote:
>> Right, just like a network is a means, not an end.  You inspect
> the network because you know the threats have to traverse it, and I
> would argue that similarly, there is value in inspecting Javascript
> because like the network, it is ubiquitously involved in malicious
> activity.  I'm suggesting a JIDS as a plugin to a NIDS.
>>   On Wed, Oct 22, 2008 at 8:59 AM, Andre Ludwig  <
> aludwig at packetspy.com <mailto:aludwig at packetspy.com>> wrote:
> 
>> * PGP Bad Signature, Signed by an unverified key: 10/22/08 at 09:59:22
> 
>> JS is a means, not an end.
> 
>> Andre
> 
> 
> 
> 

> ------------------------------------------------------------------------

> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion

-- 
Best regards,
Joep Gommers

+1 (571) 451-2007
+1 (703) 879-1681
Skype: jgommers