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:

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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

-HD

On Wednesday 22 January 2003 17:52, xss-is-lame@hushmail.com wrote:
> The real heart of this exploit is the ability to (ab)use ActiveX (the
Received on Thu Jan 23 10:23:17 2003