[WEB SECURITY] Exploiting User-Agent XSS

MustLive mustlive at websecurity.com.ua
Sun Jun 12 11:48:43 EDT 2011


Hello MaXe!

First, I know better when and where to refer in my letters. So as I'm not recommending you or anybody else what links to use, as I don't need any advises of this kind (so nobody need to recommend me anything about it).

Second, I've already provided relevant examples in my first answer to Atul in this list. Atul and Michal wanted more information about additional vectors and I'd give them more. Last week I've already wrote detailed article (it took me many hours during few days to write it), as I promised to Atul and Michal, and everybody who wanted could read it already. And on this week I'll present English version of the article to the list (translating took me twice more time, as it usually happens), so everyone, who've not read it yet for any reason, will be able to read it. And everyone will can use this article as anthology of XSS attacks via U-A header (plus attacks via other header are also mentioned in it).

> If you know a way, the amount of time it takes to write a reply as your previous to this mailing list

Yes it takes a lot of time for me to write on English :-) - as articles, as letters (on English I'm writing slower then on Ukrainian and Russian).

> but all I see is talk, and old irrelevant examples.

It's your vision. If Flash vector is already old and irrelevant (in 99% cases, only in 1% of users with old versions of flash plugin it'll be relevant), but it'll still be in handy for almost all (almost arbitrary) headers, then other attack methods are quite actual. 

I consider as relevant such attacks (which I've mentioned in my previous letter): via spoofing of User-Agent at persistent XSS vulnerabilities (which I've already described in my first letter to Atul), via JavaScript, via ActiveX (less usable then via Flash, but still possible attack vector), via spoofing User-Agent in browsers by viruses, via proxy which is spoofing User-Agent.

> 2. The target site, makes a request on behalf of the user with a modified user agent, conducting the XSS attack, and of course it returns the output.

How will you do it - request on behalf of the user with a modified user agent - without using Flash and other methods which I described in my article. I.e. you can't simply spoof U-A in cross-site requests (and in Flash it was fixed already and in XMLHttpRequest it's locked to the same domain by SOP).

> This kind of attack, looks similar to TRACE (XST) attacks

Yes, TRACE vector is considered as fixed for a long time, but in case of U-A vector, then I consider it as more actual and still exploitable.

> There is an impact of User Agent XSS, but I'd profile it as low, due to the requirements for a successful attack to work.



I'm agree with you - I also can mark it as low impact (but still possible attack vector). Only for attacks on persistent XSS via U-A header I'll mark its impact and risk as high. So I'm asking people to not call it impossible, but possible vector (hardly, but possible). And soon I'll write to the list my article with anthology of XSS attacks via U-A header.



Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
  ----- Original Message ----- 
  From: owasp at intern0t.net 
  To: Michal Zalewski ; MustLive 
  Cc: websecurity at lists.webappsec.org 
  Sent: Wednesday, June 08, 2011 12:09 PM
  Subject: Re: [WEB SECURITY] Exploiting User-Agent XSS


  Hello MustLive,





  Instead of just talking about how it may be possible to conduct XSS attacks vis User-Agents with current up to date technology and referring to your own website whenever possible, why don't you just provide this mailing list with relevant examples?



  If you know a way, the amount of time it takes to write a reply as your previous to this mailing list, is the same as it takes to provide a relevant example. I'm sorry, but all I see is talk, and old irrelevant examples.



  The only possible way I know, is to trick the user into a scheme that could look like this:

  1. User clicks a short URL link, which redirects the user to a spoofed website that looks like the target site.

  2. The target site, makes a request on behalf of the user with a modified user agent, conducting the XSS attack, and of course it returns the output.

  3. Cross-domain policy, will prevent most critical assets from being accessed, such as cookies. (If you use Firebug in FireFox, you'll get the usual access denied error.)



  This kind of attack, looks similar to TRACE (XST) attacks, because most if not all current attack vectors, has been patched a long time ago.



  As soon as it's another website, and not the user performing the request, cross-domain policy will intervene and as previously stated, make possible exploitation even harder.



  There is an impact of User Agent XSS, but I'd profile it as low, due to the requirements for a successful attack to work.





  If you should have a way, of conducting XSS attacks vis User Agents, without making any website or program (which is manually installed), perform the HTTP request, then I'd like to see it.







  Best regards,

  MaXe


  On June 7, 2011 at 4:50 PM MustLive <mustlive at websecurity.com.ua> wrote:

  > Hi Michal and guys!
  >
  > Last week I've already wrote two articles: 1st one - Sending server headers
  > in Flash (on which I'd be referencing in 2nd article) and 2nd one - XSS
  > attacks via User-Agent header (http://websecurity.com.ua/5195/). The topic
  > is large, so I was needed to split it into two articles. And in second
  > article (which I'll translate for you) I'm be talking about as XSS attacks
  > via User-Agent header, as (briefly) via other headers.
  >
  > So soon I'll translate this article for you (it's large enough, but I'm
  > planning to finish translation in the nearest days). In the article I've
  > described the next attack vectors with using UA header: via Flash, via
  > spoofing of User-Agent at persistent XSS vulnerabilities, via JavaScript,
  > via ActiveX, via spoofing User-Agent in browsers by viruses, via proxy which
  > is spoofing User-Agent.
  >
  > > There are many RCE and UXSS vulnerabilities in outdated Flash plugins;
  > > there is no way you can protect such users.
  >
  > It's true concerning other attacks (browser-based attacks) on such users.
  > But the things is different when we talk about XSS attacks via Flash on
  > these users. To protect them from such attacks (without asking them to
  > update their browser/plugin/brain/etc) it's possible by fixing these XSS
  > holes at vulnerable sites. If lame admins of these sites don't want to fix
  > these (as any other) holes, then other actions can be made. To make long
  > story short: XSS hole via User-Agent header it's a problem of the site, not
  > of flash plugin.
  >
  > > If you know a way to inject U-A headers into
  > > cross-domain requests, it would certainly be considered a browser bug
  >
  > Partly it is. But from other side, if some request is made by some browser
  > of some user with changed U-A from default, then it's not a big deal for
  > browser (and for plash plugin). Even if this header contain XSS payload :-),
  > as I wrote above - XSS hole via User-Agent header it's a problem of the
  > site, not of browser / flash plugin.
  >
  > But Adobe and browser developers are trying to fix such holes, and besides
  > doing good, also doing bad. Such examples concerns not only this case with
  > U-A, but many other cases. I'll not write further on this, because it's
  > other topic then "Exploiting User-Agent XSS" started by topic-starter. Just
  > note guys, that any moaning about "Adobe fixed this attack vector, so
  > it's not possible any more and don't care about XSS via U-A completely" is
  > incorrect and will lead to additional decrease of security of web sites. So
  > main leitmotif of my article is that there are many methods of conducting
  > XSS via User-Agent and developers need always to work to prevent such
  > vulnerabilities (and about that I wrote in article's conclusion).
  >
  > > - and would likely be addressed swiftly.
  >
  > Michal, such things not always happen :-). Like when in March I informed
  > Mozilla, Microsoft, Google and Opera about vulnerability which concerns many
  > browsers (as these one, as almost all others), then Google and Opera just
  > ignored. Microsoft asked for additional details and after that (when I gave
  > it for them) ignored. Only Mozilla not ignored and promised to fix (but it
  > can stretch on long time, even years like it was with css history hack).
  >
  > Best wishes & regards,
  > MustLive
  > Administrator of Websecurity web site
  > http://websecurity.com.ua
  >
  > ----- Original Message -----
  > From: "Michal Zalewski" <lcamtuf at coredump.cx>
  > To: "MustLive" <mustlive at websecurity.com.ua>
  > Cc: <atul at secfence.com>; <websecurity at lists.webappsec.org>
  > Sent: Tuesday, May 31, 2011 2:53 AM
  > Subject: Re: [WEB SECURITY] Exploiting User-Agent XSS
  >
  >
  > > It's not working in new versions of flash plugin, but it's working in
  > > older
  > > versions. So no need to fully forget about it.
  >
  > There are many RCE and UXSS vulnerabilities in outdated Flash plugins;
  > there is no way you can protect such users.
  >
  > > 3. Other advanced methods. Among them there is also such one as using of
  > > JS.
  > > Even if other guys told you, that there is no possibility via JS, it's not
  > > true - there is such way (which works in some browsers). I know about such
  > > method from 2004 and at that time I wrote about it at one my site
  > > (concerning not security purposes) and I tested this method in modern
  > > versions of those browsers.
  >
  > Please do share. If you know a way to inject U-A headers into
  > cross-domain requests, it would certainly be considered a browser bug
  > - and would likely be addressed swiftly.
  >
  > /mz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110612/610daa8a/attachment-0001.html>


More information about the websecurity mailing list