Re: Obfuscated web pages

[Ivan Arce <ivan.arce () coresecurity com>]

Hm I wasn't planning to follow up on this topic (its old and tiresome) but
after reading your comments I figured that a follow up post may not be
entirely worthless.

Mike Barkett wrote:
 > To answer your question about JS in N-code, no, it is not a plausible
> solution at this time to do full DOM/JS inspection, and I hope I did not
> imply that.  As mentioned on another branch of this thread, if you wanted to
> simply deny JS then you could do that very easily with IPS-1.  I hadn't even

Excuse my skepticism but "simply denying" JS may or may not be done "very
easily" with IPS-1 or any other network IPS. In any case I will argue that
effectively denying passage of JavaScript content in any of its possible
forms and encodings is a task that cannot be accomplished very easily.

Furthermore I would argue that doing so in a manner that does not break
most of current web applications is even harder since almost all them use 
"good-intended" JS for legitimate purposes in ways that maybe hardly
distinguishable from "malicious" JavaScript.

What the hypothetical filtering device would need to do is to deny 
*potentially malicious* JavaScript  because blocking all JavaScript is not 
an option unless you decide that it is acceptable to disrupt the operation 
of almost all modern web sites and the omnipresent set of googlish scripts.

> In response to your other submission to this thread, quoted above, I was not
> positing a theory for critical review; I was just making a prediction based
> on personal experience.  If you really think a proof is necessary in this
> case, then you should be prepared to demonstrate that the desired result
> cannot be sufficiently approximated in polynomial time.  However, that's

Last time I checked, you were the one that brought in the "theoretical"
discussion to the list:

> Regarding inline JS inspection, I've said it before and I still believe that
> one day there will be a full DOM proxy product that is capable of running
> inline.  Yes, its speeds will lag other network devices, and yes, browser
> attacks will probably be yesterday's news by then anyway, but it would be
> foolish to suggest that it is theoretically impossible to do.  In the
> meantime, if you have embraced defense-in-depth and gotten yourself a
> trustworthy network IPS, a thorough endpoint solution, and you use only
> locked down browsers, then you'll be ok.

You attributed foolishness to the suggestion that it is theoretically
impossible to do inline analysis of JavaScript, I simply indicated exactly 
the opposite: It is foolish to suggest that it is theoretically possible 
to do it.

Anyway, I was just trying to point out that if the intent was to discuss 
"theory" then the discussion should be framed in the proper theoretical 
context. Should that discussion occur I really doubt that the lack of a
demonstration showing that inline dynamic analysis of JavaScript cannot be
"sufficiently approximated in polynomial time" will not suffice to 
invalidate your theory.

However, I am more interested in discussing the practicality of doing full
DOM parsing and inspection and dynamic JavaScript analysis inline on a
network device.

In my opinion it is not only "imperfect" but also impractical and highly
ineffective. The "Perfect Solution Fallacy" that you attributed to my
comment isn't an accurate interpretation of my post. I did not state that
I consider dynamic inspection at the endpoint to be perfect, I simply
consider it more suitable than doing it inline.

I believe that anybody with an engineering viewpoint seeking to address
this issue would not be looking for a perfect solution because there is
none but trying to figure out which is the most promising one in terms of 
effectiveness and efficiency and in my opinion that is to be found at the 
endpoint for this particular problem. for the record: I am not implying 
that that is the case for everything security-related.

> generally not the tone of this list, and I doubt either of us has the time.
> In my opinion, it would be a mistake to flout the continued maturation of
> analysis technology, much as was done by the many people who a decade ago
> thought that IPS was infeasible.  Ptacek and Newsham's paper was seminal,
> and defense against those principles is a must-have in the IPS world today,
> but let's not forget that 10 years ago many were citing that paper as a
> harbinger of doom for IDS, not to mention IPS.  Yet, within a couple years,
> the better IDS products had accounted for all the methods.  

You seem to mix different layers of abstraction in the manner that best
serves to support your opinion, which is completely fair game but not 
necessarily accurate.

it may be a fact that most of today's IDSes/IPSes account for the 28 
specific techniques described by Tim Newsham and Tom Ptacek in their paper 
and a handful of others disclosed since then, but real value of that paper 
was in the underlying concepts that provided the conceptual framework to 
understand those techniques:

A network device cannot possibly cope with providing  a defensive layer 
for a multitude of broadly or subtly different sets of other network 
devices if the defensive mechanism relies on maintaining and analyzing in 
runtime an accurate model of partially documented complex state machines 
that are being modified dynamically. At least it can't be done effectively 
if the aim is to detect and prevent incidents in the presence of purposely 
malicious adversaries (attacks rather than accidental events).

The problem is magnified if the model must include higher network-layer 
protocol logic and even more if it needs to include several -subtly 
different- Turing Complete machines.

Such is the fallacious reasoning that led me to think that the endpoint 
approach is better fit to address the issue... but then again, we're all 
entitled to opinion and in the real world the definitive judge will have 
to be The Code (or in your case the N-code).  So I guess we will all have 
to wait for The Code to run and see for ourselves...

Until then I'll remain respectfully,

-ivan

--
"Buy the ticket, take the ride" -HST

Ivan Arce
CTO

CORE SECURITY TECHNOLOGIES
http://www.coresecurity.com

PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836  B25D 207B E78E 2AD1 F65A



------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it 
with real-world attacks from CORE IMPACT.
Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw 
to learn more.
------------------------------------------------------------------------