
From XSS to Reverse PHP Shell - ssclafani
http://www.exploit-db.com/vbseo-from-xss-to-reverse-php-shell/
======
Udo
Contrary to what the article claims, no one in their right mind thinks XSS is
not a threat.

The exploit here is, in a tl;dr nutshell, using a vulnerability in vBSEO to
upload executable code to the webserver - code that can be used to change the
content other users can see. It can also be used to inject further malicious
code onto the server (duh!), for example the misleadingly-named skript known
as "Reverse PHP Shell" that opens a port on the server to channel a shell
session through, using the privileges of the webserver's user account. There
is a lot of self-congratulating and back-padding going on, but that's about
the gist of it.

First of all, let me repeat a big _DUH!_ here, the only piece of actual work
and resourcefulness is the vBSEO exploit itself. The lesson, as always, is
simple at least at first glance: secure the data boundaries of your web
applications. Most such exploits work either through malicious file uploads or
unsanitized user input. I assert that file upload vulnerabilities like the one
in the article are actually easier to tackle, if only because a web app
typically has not very many places where these could occur.

~~~
nbpoole
That's actually not quite what's happening.

The vulnerability in vBSEO does not allow users to upload files. By all
indications, it's a relatively normal persistent XSS vulnerability. However,
because of the nature of XSS and the functionality built into vBulletin, it's
possible to add executable code to the filesystem.

It's always good to remind people that building functionality like that has
unintended consequences.

~~~
Udo
After re-reading the description I have to say that you're technically right.
The exploit itself seems to come from the output of unsanitized data that
originated from an "uploaded" page's code.

------
EGreg
While XSS can be a real problem for the users of your site (viral effects like
the samy worm, phishing, session hijacking, session fixation, and more) what
you've been able to do there is basically take advantage of another
vulnerability -- namely an open vector of attack which allows people to upload
executable PHP scripts to the server. Technically, you didn't have to do much
scripting, you simply had to upload a file to the server, taking advantage of
the vulnerability.

That said, how do you protect against XSS? The simple way is to only include
your own .js files, and only print json-encoded data in the page. In PHP, it
would look something like:

    
    
      <script type="text/javascript"><!--
      var MyAppData = <?php echo htmlentities(json_encode($app_data), 'utf-8'); ?>
      //--></script>
    

But what if you want to go further and actually allow the server to echo
scripts? How do you make sure several scripts from various "modules" can
coexist on one page?

Facebook did it by parsing and sanitizing javascript into FBJS, however in the
process they made it incompatible with the usual DOM methods, etc. Google
released CAJA, which is cooler IMHO since it jives better with Javascript.
Finally, you can disallow scripting completely and use iframes -- however, the
iframes are dangerous in one way: they may "bust out" of your page by changing
top.location . Does anyone know how to prevent this?

------
nbpoole
This is a problem for any application that has a web interface for writing to
the filesystem. You can perform a similar attack against Wordpress through the
template and plugin editors, for example.

Does anyone know if VB enables the plugin editor functionality by default / if
there's a way to disable it other than chmodding the files on the filesystem
(ie: by defining a constant)?

