Technical Insight

Open Source Applications and XSS Attacks

Our static code analysis colleagues over at RIPS Technology have a good write-up about a recent chain of vulnerabilities they discovered in an open-source application named LimeSurvey.  Combined with recent flaws in Browsealoud and other plug-in technologies, I thought I’d add to the illustrated landscape with a few points about what we see with our customers.

Don’t yawn you AppSec old-timers reading this, but the LimeSurvey hack started with XSS. 38%(!) of the applications we assess dynamically at WhiteHat have at least one XSS vulnerability, and most of those are production applications exposed to the internet.  XSS as a vulnerability is alive and kicking.

But then things got worse.  Functionality which was restricted to admins had code injection vulnerabilities.  A pet peeve of mine is a practice of dismissing the risk of a vulnerability based on permission restrictions, because it’s too easy to write “only the admin account is exposed” on the internal security risk register. This hack demonstrates perfectly why such limited scope when looking at vulnerabilities is a bad idea.

Functionally, it’s known that only certain users can write or modify templates, so at first blush you might think it’s not so bad if one or two of your admins have access to functionality with a high-impact (aka high-risk) vulnerability like Code Injection or SQLi.  However, in this instance there was a chain of events where an attacker using this chain of vulnerabilities ran an XSS script against the administrator account to get their session, then use their permission to exploit code injection to get a shell on the system.

The Moral of this Story: Trusting your internal users or specific admins not to abuse your system means also trusting that no one can drive their actions or impersonate them.  If you know you have other vulnerabilities that are available to “Low Privilege” users, then you already know that permission restrictions are not a mitigating factor against your “admin-only” vulnerabilities. Think like a hacker – if they can execute an Elevation of Privilege attack then the original level of control means little.