3 ms·
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
by 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 agoThat'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 agoAfter 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.