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-lameat_private 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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
This archive was generated by hypermail 2b30 : Thu Jan 23 2003 - 05:57:11 PST