[Discussion] new thread: biggest threats
Andre Ludwig
aludwig at packetspy.com
Wed Oct 22 15:31:37 UTC 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Profiling works, but I doubt it can get you 80-90% accuracy no matter
how well the system works. The problem again is that JS is an extremely
expressive language, and who is to say that you are even going to use JS
to actually interact with the dom? Why not use ActionScript, VBS, or
next weeks latest and greatest RIA scripting language?
I agree on the distributed approach 100%, it is the only real way to
scale and easily provide a modular approach to features and capabilities.
Andre
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:
>
> -----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 <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
> >
> >
>
>
> -----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-----
>
>
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.9.0 (Build 397)
Charset: ISO-8859-1
wsBVAwUBSP9HXMjAfVnRK9hXAQgyawgA2ME0jiz4L9+cOk0xTX5GTCPRu2YoLC4E
fCxcL+e+AoQ3GuPKZwpf6oDvFWeq41pfLOyC4gBHn6EWgqzK6/LQCl+52dfY9cPN
qqm+RsarWv8ErwKCzapb5+PhxwYWF31JNOp4U3UK/dg6Ow6MihLkjLVRrgXYSQW4
aXp2lMji4kksb6jVC5OIih/ZWooC0Wkb8h412H8BE6rT9LEyg/T1Y65Kzl57aIH7
smyLeoOGhgRjsNp3JfCqpLn59BdBqnXQteno+VsRE3fa296cdiDHQR5xd4sPYAbf
3mEfuFrTxaX+qtMWNLmXrkzqT4vlbvGw9OZtjFp953K6UOHGA7w6QA==
=wTIM
-----END PGP SIGNATURE-----
More information about the Discussion
mailing list