We recently discovered an easily exploitable, vertical privilege escalation vulnerability in every popular, off-the-shelf CMS that we tested.
The lesson: CMSes either need stronger security around user permission updates, or to backtrack away from the convenience afforded by allowing raw HTML editing and publication from non-admin users.
What is a privilege escalation attack?
A privilege escalation attack is the process of exploiting a bug, insecurity, or poor configuration to increase your level of access within a system. Through such an attack, a user who already has a limited degree of access to a CMS can assign themselves the unrestricted access.
Which CMSes are affected?
Just about every CMS that provides unfiltered HTML editing capabilities to non-admin users is vulnerable to XSS-based vertical privilege escalation attacks, even when CSRF protection is in place. We personally validated the attack against Craft , WordPress , and Drupal *.
The vulnerability was responsibly disclosed with exploit samples to each security team in April 2016. The Craft security team immediately responded by releasing a fix for the exploit as a critical update, and is no longer vulnerable in recent versions.
*Note that in its default configuration, Drupal is not vulnerable to this attack as the administrator user role is the only role able to author unfiltered HTML, however nearly all organizations we've seen use a more complex system of user roles and permissions which increase their susceptibility to this attack.
What is the outcome of the attack?
Non-admin CMS users can update their user account's role to admin status. This typically provides the attacker with a large number of new exploitable vectors. (e.g. download a database backup to crack contained hashed passwords, deploy a broader XSS attack within a CMS theme template file, deface the public website, etc.)
Technical Attack Summary
The attack is a straightforward XSS exploit.
I: The Exploit Script
It is a common misconception that CSRF-protection mechanisms are useful against these sorts of XSS attacks, however CSRF-protection merely adds one additional, trivial step to the attack process.
II: Exploit Deployment
With the exploit script in hand, an attacker can drop the script anywhere in the CMS where unescaped, unfiltered HTML is displayed. (This is almost everywhere in most popular CMS configurations.)
Some doubt that attackers would be so bold as to place obviously malicious code directly into their own blog posts or page updates. Keen attackers, however, will obfuscate the intention of the exploit script before deployment to avoid detection, perhaps through minification and encoding.