vbSEO – From XSS to Reverse PHP Shell
XSS is not a big deal, or is it? On many 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 performing 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 malicious 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?
Initially, the XSS trojan I wrote should 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 would 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.
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 would 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.
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.
Advisory: vBSEO 3.5.2 & 3.2.2 – Persistent XSS via LinkBacks
Advisory #2: vbSEO Multiple Vulnerabilities
YT Video: http://www.youtube.com/watch?v=B6QAjB3kYec