Cross-Site Scripting isn’t new, but there is generally a large belief among vendors, corporations and even some hackers that XSS can only be used to conduct client-side attacks such as session hijacking and similar attacks, or with tools such as BeEF.
A while back I discovered a 0day in vBSEO, that enabled an attacker to inject a payload into the administration control panel, and when this was viewed, the administrator would automatically and unknowingly create a new plugin enabling the attacker to execute arbitrary code on the server. During the early research a simple document.write() was used to write the payload into the administrator’s browser, but as this was visible it was likely that the attack would not go unnoticed and thus an asynchronous payload was developed instead.
The re-developed payload creates a hidden iframe outside the visible frameset, loads the plugin page, and reads the “anti-csrf token” and “administrator hash”, and finally submits a prepopulated form, with the stolen tokens used to authenticate the request. After the weaponized payload was released to the public, more and more independent researchers began to submit their proof of concept’s as weaponized payloads that would grant the attacker arbitrary code execution on the target servers.
Not long ago, the Ubuntu forums were compromised and a study of how it happened began. It was discovered that Canonical’s findings were inaccurate, as the session cookie in vBulletin have had “httpOnly” set for several years, meaning it could not have been session hijacked under normal circumstances. Instead, the attackers used most likely the same or a very similar payload as described above, which brings up the question whether we (the independent researchers) should still release highly weaponized payloads, even if a patch has been issued by the vendor.
Location: Thursday 29th May 2014 - 12:15 @ Beurs van Berlage - Amsterdam - Netherlands.