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.


[You must be registered and logged in to see this link.]

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.

[You must be registered and logged in to see this link.]

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?



After discovering and researching this
vulnerability, I realised 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 could’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 would eventually inject a PHP
payload via the nice plugin feature in vBulletin.

[You must be registered and logged in to see this link.]

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.

[You must be registered and logged in to see this link.]

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.

[You must be registered and logged in to see this image.]

Most administrators, would notice the
broken lock icon in case they use HTTPS / SSL, and then they would 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.

[You must be registered and logged in to see this image.]

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.

[You must be registered and logged in to see this image.]

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.
References:
Advisory: [You must be registered and logged in to see this link.]
Advisory #2: [You must be registered and logged in to see this link.]
EvilWebTool: [You must be registered and logged in to see this link.]
YT Video: [You must be registered and logged in to see this link.]
HQ Video: [You must be registered and logged in to see this link.]