5 ms·

From XSS to Reverse PHP Shell

14 points by ssclafani 16y ago

nbpoole 16y ago
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)?
Udo 16y ago
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 16y ago
  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 16y ago
    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 16y ago
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"></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?

14 points by ssclafani 16y ago

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

Udo 16y ago

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 16y ago
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 16y ago
  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 16y ago

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"></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?