All good points, and conclusions I had arrived at as well.  Then I saw the Bro XML validator plugin <<a href="http://bro-ids.org/wiki/index.php/XML_Analyzer">http://bro-ids.org/wiki/index.php/XML_Analyzer</a>> 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.<br>
<br>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."<br>
<br>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."<br>
<br>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.<br>
<br>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.<br>
<br>--Martin<br><br><div class="gmail_quote">On Wed, Oct 22, 2008 at 9:19 AM, Andre Ludwig <span dir="ltr"><<a href="mailto:aludwig@packetspy.com">aludwig@packetspy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
</div>Correct, but the problem with JS is that it is an extremely expressive<br>
language.  One that in conjunction with the DOM provides a nearly<br>
infinite number of ways to shovel an exploit to vulnerable browser,<br>
kernel, or third party code.  That is the fundamental problem with IDS<br>
when attempting to detect/block these sorts of exploits at this layer.<br>
While I agree that your suggestion would be helpful it IMHO has no place<br>
on the network for sheer performance reasons alone (can you imagine<br>
trying to emulate a full DOM/JS engine at wire speed).   Browsers can<br>
barely keep up with the onslaught of horribly written JS code, much less<br>
purposefully obfuscated or obtuse JS that hides an exploit.   This is a<br>
topic that I have dedicated some thought to over the last three years so<br>
I would love to hear everyones ideas on the subject.<br>
<br>
Andre Ludwig<br>
<div class="Ih2E3d"><br>
Martin Holste wrote:<br>
> 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.<br>

>   On Wed, Oct 22, 2008 at 8:59 AM, Andre Ludwig  < <a href="mailto:aludwig@packetspy.com">aludwig@packetspy.com</a>> wrote:<br>
><br>
</div>> * PGP Bad Signature, Signed by an unverified key: 10/22/08 at 09:59:22<br>
<div class="Ih2E3d">><br>
> JS is a means, not an end.<br>
><br>
> Andre<br>
><br>
><br>
<br>
<br>
</div><div class="Ih2E3d">-----BEGIN PGP SIGNATURE-----<br>
Version: PGP Desktop 9.9.0 (Build 397)<br>
Charset: ISO-8859-1<br>
<br>
</div>wsBVAwUBSP82asjAfVnRK9hXAQgJmwf9Gl+a9xhnH/SOwphSa/3wNqWMhQ+Od+3S<br>
crAMZpO9XIiKuo4UdC+L13T2wQ38H5flnrq0bwQcQ8//AcZVeU6tSiy1xWR5chOd<br>
36I9T675FrzdQtUWBp+lKsLiotubAcjgWvWVyw65tB27gUaIojzISMqm6XHVlfW3<br>
2IDZZoo/mzPSkOnX44tO70i0kCKY5hBaJ9JlQfAW4giW7Q1Y+MTHUYm25npYrD8i<br>
mWgsEbTGUlBwM6JgNnDTFgRM6riOHw1GOdcZjm6/THSTjYz5IaItUyMD6SwEzOgE<br>
igxaOzT2V77zJKs4b9P8Xj1jCTZztkl45hbSFaOdYhB3rVTk0us73Q==<br>
=UtkX<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br>