Message-ID: <200301230536.38717.sflist@digitaloffense.net>
From: sflist at digitaloffense.net (H D Moore)
Subject: Re: New Web Vulnerability - Cross-Site Tracing

Although its definately an interesting way to compromise client-side 
headers, the root is the vulnerability is the XMLHTTP component's ability 
to act like a HTTP proxy. Client-side scripting components should only be 
allowed to interact with the site which served them up, otherwise you 
open a huge can of worms, where XSS and user-credential theft are only 
the squishy little ones on top.

The developers of various other client-side technologies (Java, Flash MX, 
etc) realized this and placed at least a some minimal controls over where 
connections could be made. The fact that Microsoft created yet another 
bloated piece of client-side code that can be abused remotely shouldn't 
suprise anyone. 

It seems like everyone is missing the point... Why bother going through 
the trouble setting up a page to steal someone's cookies when you can 
relay web-based attacks directly through their browser. Think of all the 
interesting web services that people run which use host-based access 
control. In the case of systems running IIS, you already have a couple 
easy ones through RDS and the IIS Web Admin component. Since you aren't 
restricted to just GET requests, it rips open a whole new world of 
attacks against a user's internal network. While some these could be 
carried out through plain old HTML redirection[1], many of the more 
security-concious services use POST requests to submit configuration 
changes or confirm actions. 

Giving a system cracker the ability to use your browser to connect to a 
system, send a request, read it, and send another one is his wet dream 
come true. It would be trivial for a malicious person to setup a web site 
that scanned and exploited other web servers jsut using the browsers of 
the visiting users. A prototype[2] of this was built a while back using a 
different client-side technology and it proved just how it easy it was to 
setup and manage. A little backend scripting goes a long way to creating 
a fully-automated attack system composed using your site's visitors as 
unwitting carriers. Pathetic little components like the XMLHTTP control 
make the difficulty of doing this go from mediocre to trivial. 

For even more fun, take a look at the default authentication method used 
to publish pages to various Microsoft web services. It might be possible 
to relay PUT requests to a FrontPage-enabled server using the Windows 
authentication credentials of the browser. 

[1] Send the the user to a url which exploits the unicode bug on an 
internal system, supplying a command to add a user account. For 
applications which use GET requests to pass variables (PHP, ASP), this is 
all you need to carry out some interesting attacks, such adding a user 
through a webmail admin interface or disabling the firewall rules on a 
web-enabled router device (with a static known ip no less).

[2] The prototype was never made public, it was created due to a debate 
between friends on how feasible such a system would be. For an overview 
of some of the truly sick capabilties of Flash MX, check out this PDF: 

http://www.macromedia.com/desdev/mx/flash/whitepapers/richclient.pdf

-HD

On Wednesday 22 January 2003 17:52, xss-is-lame@...hmail.com wrote:
> The real heart of this exploit is the ability to (ab)use ActiveX (the
> only actual example provided) and reportedly JavaScript, Flash, etc. to
> create raw HTTP requests.  That is far more serious than XSS using
> TRACE.  The four above quotes from the press release are all sorry
> attempts to frame this as a "real" server vulnerability.  The fact of
> the matter is that it's not so simple or serious.  There is *nothing*
> in the press release that indicates that the issue is 100% reliant upon
> a vulnerability in the web client and has other mitigating factors,
> such as having to find someone that actually has credentials for the
> site you want to gain access to.

Powered by blists - more mailing lists