[Discussion] new thread: biggest threats

[Martin Holste]

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> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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>
> wrote:
> >
> > * PGP Bad Signature, Signed by an unverified key: 10/22/08 at 09:59:22
> >
> > JS is a means, not an end.
> >
> > Andre
> >
> >
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop 9.9.0 (Build 397)
> Charset: ISO-8859-1
>
> wsBVAwUBSP82asjAfVnRK9hXAQgJmwf9Gl+a9xhnH/SOwphSa/3wNqWMhQ+Od+3S
> crAMZpO9XIiKuo4UdC+L13T2wQ38H5flnrq0bwQcQ8//AcZVeU6tSiy1xWR5chOd
> 36I9T675FrzdQtUWBp+lKsLiotubAcjgWvWVyw65tB27gUaIojzISMqm6XHVlfW3
> 2IDZZoo/mzPSkOnX44tO70i0kCKY5hBaJ9JlQfAW4giW7Q1Y+MTHUYm25npYrD8i
> mWgsEbTGUlBwM6JgNnDTFgRM6riOHw1GOdcZjm6/THSTjYz5IaItUyMD6SwEzOgE
> igxaOzT2V77zJKs4b9P8Xj1jCTZztkl45hbSFaOdYhB3rVTk0us73Q==
> =UtkX
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081022/7fbcf357/attachment-0002.html>