Re: [WEB SECURITY] JavaScript Malware, port scanning, and beyond

[Jeremiah Grossman <jeremiah@xxxxxxxxxxxxxxx>]

On Jul 31, 2006, at 12:44 PM, Billy Hoffman wrote:

> Props to Jeremiah and RSnake for their research. I know SPI Labs spent
> quite some time working on this.  It will be interesting to contrast
> what you release at BH with our research to see how two groups
> independently approached this problem.

Yah, its going to take some time sorting out what new techniques now  
exist. When you get the BH, our code in on the conference CD's and  
fairly well documented. Feel free to dig in and see what overlaps.

> > > > >
> Style Sheets (CSS) and JavaScript includes. Such as <link src=....,
> <script src=... Many times these files are just as unique as an
> image. The technique is to simply use object or class detection.
> <<<<
> This is a really good idea!

Thank you. :) Especially helpful when no image file exists on the web  
device.

> Are you able to detect that the <link src>
> failed to load because of an event or do you associate the style style
> using the LINK tag and then investigate the DOM to see if the proper
> elements have the correct style?

Typo in my previous example, I meant this style of syntax:

<link rel="stylesheet" type="text/css" href="/unqiue_style_sheet.css">

or

<style type="text/css">
@import "/unqiue_style_sheet.css";
</style>

The technique does not use a timing check, but style object  
detection. This syntax might be off a bit depending on the browser (I  
don't have a better example handy), but you'll get the idea.

if (document.styleSheets['object']) {
	// the platform exists
}

or

if (document.styleSheets['object'].cssRules[0]) {
	// the platform exists
}


For JS includes, nearly identical. Lets say the third-party JS  
created a foo() constructor. To do fingerprinting, much like you  
would do for cross-browser JS programming.

if (foo) {
	// the platform exists
}



> > > > >
> Brute Forcing Basic HTTP Auth:
> Mozilla, your gold. Firefox/Mozilla support the url notation (http://
> user:pass@host/), while Internet Explorer (IE) does not. So forcing
> <<<<
>
> SPI also ran into this problem. We didn't look at it all that much
> beyond the classic "http://:admin@xxxxxxxxxxx/"; for Linksys  
> routers. We
> instead figured that if user has cached their credentials, you win
> regardless of IE , Mozilla/Firefox, Safari, etc!

Yep thats pretty much the case. The problem is the odds of being able  
to capture a user while they logged into their DSL router is rare, so  
we pushed harder to find another way.

> This means I can place
> code to interact with web interfaces on IT infrastructure (routers,
> switches, etc) and then find an XSS vuln in an IT admin related site.
> Cached credentials = very bad news. The browser is so helpful in  
> adding
> the necessary HTTP headers for outgoing requests made by JavaScript...

Yes, authenticated CSRF is very powerful. Even more so when you know  
where the user been (browser history theft during BH preso) during  
their session. Enables the attacks to more targeted.

> > > > >
> XSS Chaining:
> <<<<
> Was someone else was inspired by Anton's XSS-proxy at Shmoocon last
> year?
> :-)


Yah, Anton really woke everyone up and point the way to what was  
possible. The last several months I'm personally going to blame  
RSnake for filling my head with craziness.


Jeremiah-


----------------------------------------------------------------------------
The Web Security Mailing List: 
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]