VbSEO-From XSS to Reverse PHP Shell

XSS is not a big deal, or is it? On your occasions, I 've seen this vulnerability being classified as useless, not serious, and being a low threat. what I 've always had in mind is that it's only the capabilities of the browser, and the hackers mind which sets the limit for a XSS attack.

 

It may seem impossible to do anything else other than stealing sessions, cookies and other Ming phishing, client side defacements etc. but take a look at the picture above, that is a reverse php shell automatically injected into the site, when a vBulletin administrator viewed a malicious linkback.

The vulnerability itself I'm referring to, is a 0day within vBSEO which exists within the administrator and moderator panel only. however, the attacker is able to inject persistent scripts via this linkback feature directly into the part of these panels handling these linkbacks.

In short, the attacker crafts a malicious HTML page as shown in the advisory. then, the attacker clicks a link to the target forum with vBSEO installed, and when the target is reached, vBSEO performs a GET-request to the attacker's malicous HTML page (if it's served online and if RefBacks are enabled ).

The title of this page is then loaded directly into the database, and an administrator can see it sanitized in the actual thread, but also in the admin and mod panel where the title is not sanitized at all, allowing the script to run.

What is actually possible?

After discovering and researching this vulnerability, I realized it was a fine case to do further studies on and then develop a XSS worm. fortunately I got away from that idea due to the fact it cold' ve been abused globally on forums with vBSEO installed. however, the idea itself was not bad so I began developing the payload aka the javascript, which wowould eventually inject a PHP payload via the nice plugin feature in vBulletin.

Initially, the XSS trojan I wrote shocould be able to do all of this silently without the user knowing, so instead of document. write being used, appendChild which uses DOM objects, was used instead. this took a bit more work in order to function better, but the result was that the visible window wocould not change to the affected user getting infected with this trojan.

When the user browses to, in this case "Moderate Linkbacks", the script is executing as soon as the user hits that page. when this happens, the trojan checks whether infection has already happened once and if not, continues. then an iframe is created outside the visible frames, where the adminhash and securitytoken (CSRF-token) is read and saved in a local variable in the browser.

Then a new form is injected into this iframe, which contains the adminhash and the securitytoken. the form itself contains the values needed to create a new and completely valid plugin which in this case, is PHP code. at this point, the script checks again if the user has already been infected and if not, the form is submitted, the plugin is created, and a cookie is set to prevent the script from going in loops.

Most administrators, wocould notice the broken lock icon in case they use HTTPS/SSL, and then they wocould view the source. the great thing about using javascript to create HTML objects, especially with "appendChild" etc. is that it is not visible. A debugger, such as Firebug shown in the picture above is needed, unless the admin finds the malicious javascript payload and reads what it does, but then it might be too late.

During the execution of the XSS trojan, a time-out is set. when time runs out, the XSS trojan will try to delete itself leaving almost no traces, besides the possible injected plugin, and the remains of the hidden iframe outside the frames which cannot be viewed due to the way HTML works in FireFox.

If the attacker was successful, and patient as well, he wowould eventually see that the target website had already connected back to retrieve the title, but also that another user had triggered the XSS Trojan which hopefully injected the PHP plugin specified by the attacker.

So what's this tool I 've been using during my presentation of this vulnerability? It's a recently developed tool written in Python, where the payload is written in Javascript, freely available to anyone in the bottom of this blog. I recommend however, that a user of this tool looks inside the source code.

Is XSS a serious threat then?

Yes, it definitely is.

For a demonstration of the tool and this vulnerability, check either the YouTube or RapidShare link below.