RE: Obfuscated web pages

["Mike Barkett" <mbarkett () us checkpoint com>]

To be clear, I was making two separate sets of comments, to answer the two
unique questions that were raised:

- Is there an IPS whose signatures can operate in a sandbox? Yes. IPS-1
(NFR) has done it for a while.  While it does not currently offload
specifically JS code into a sandbox, a similar concept has been applied
before.  I attempted to make it clear that our product does NOT do what was
asked in the original thread.

- Does any product perform full DOM inspection inline?  Not that I know of.
I then expounded upon my personal thoughts on the feasibility of such a
technology, irrespective of IPS-1 or any other product.

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
thought of doing a DOM inspector in N-code until you asked.  However, your
question raises the interesting possibility that one could write an N-code
parser of simple JS that either allows or denies (user configurable option)
any JS that gets so complex that further analysis would disrupt the smooth
flow of traffic.  I doubt our N-coders would prioritize such a task any time
soon, but it could be done by anyone who knows both N-code and JS really
well.


> I believe that what would be foolish is to suggest that it is 
> theoretically possible to do effective (let alone efficient) inline JS 
> inspection and alerting/blocking, unless of course that suggestion comes 
> along with the theoretical support for such a theoretical hypothesis.
...
> My impression is that in such a scenario the odds are heavily biased 
> against the defensive network device. My admittedly simplistic rationale 
> for such a far fetched thought is that all the principles applicable to a 
> L-4 network IDS outlined by Ptacek & Newsham 10 years ago also apply to 
> this problem and are compounded by the fact that maintaining and 
> monitoring state of a DOM parser and a JavaScript engine is much more 
> difficult than doing it for an endpoint's TCP/IP stack

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
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.  

Yes, the complexities of DOM inspection are considerably more extensive than
those of the TCP/IP stack.  I think most of us agree that the best place to
do this type of inspection is at the host.  Likewise, it could be argued
that the best place to secure a web server is at the host, yet we still have
firewalls and IPS to: a) fortify and validate that protection in properly
designed/maintained environments, and b) attempt to mask the fact that there
is no protection in improperly designed/maintained environments.  The
Perfect Solution Fallacy strikes again.  Just because the network won't be
the best place to do the inspection, does not mean that some vendors won't
make a best effort, and that some administrators won't misconstrue it as a
silver bullet.  That's my opinion, and at least for now, I'm sticking to it.

-MAB


--
Michael A Barkett, CISSP
IPS Security Engineering Director
Check Point Software Technologies
+1.240.632.9000 Fax: +1.240.747.3512

> -----Original Message-----
> From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
> On Behalf Of Ivan Arce
> Sent: Wednesday, February 20, 2008 5:13 PM
> To: focus-ids () securityfocus com
> Subject: Re: Obfuscated web pages
>
> aha!
>
> Theoretical DOM inspectors may work in theory-land but it is unlikely
> they'd work in in real world.
>
> Besides that, let's focus back on the original question:
>
> If there anything that successfully detects/prevents *obfuscated*
> malicious web content from executing at the endpoint?
>
> Not as far as I know, although there are endpoint security product that
> address this issue I don't have an answer as to how accurate or effective
> they are.
>
> Regarding the hypothetical Checkpoint IPS-1 (formerly NFR) approach:
>
> Do you really think that writing a JavaScript interpreter in N-code and
> running it inline is a plausible solution?
>
> -ivan
>
> Mike Barkett wrote:
> > > -----Original Message-----
> > > From: listbounce () securityfocus com
> [mailto:listbounce () securityfocus com]
> > > On Behalf Of Gary Flynn
> > > Sent: Thursday, February 14, 2008 4:18 PM
> > >
> > > I suspect that no vendors support this feature ( actual code
> > > execution in some sort of sandbox ) and I was just trying to
> > > verify it.
> >
> > Gary - Actually, the Check Point IPS-1 (formerly NFR) sensor engine has,
> for
> > many years, executed protections in a "sandbox" so that no single
> protection
> > can dominate the processor(s).  So, if someone were to write N-code to
> try
> > to interpret generalized code, it would operate in that same sandbox,
> for
> > lack of a better term.  This even applies inline.  However, just to be
> > clear, off the shelf, IPS-1 does not do any of the theoretical DOM
> > validation stuff previously mentioned in this thread.
> >
> >
> > -MAB
> >
> > --
> > Michael A Barkett, CISSP
> > IPS Security Engineering Director
> > Check Point Software Technologies
> > +1.240.632.9000 Fax: +1.240.747.3512
> --
> "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.
> ------------------------------------------------------------------------


------------------------------------------------------------------------
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.
------------------------------------------------------------------------