Cracking Drupal - XSS

Anything you can do XSS can do better

Ben Jeavons — Fri, 01 Oct 2010 05:25:55 +0000

Cross Site Scripting (XSS) is the number one vulnerability in Drupal code¹ and one of the scariest forms of exploits, because anything you can do XSS can do better².

More serious than <script>alert('xss')</script>

During XSS demos and vulnerability testing it's easy to use some code like <script>alert('xss')</script> to see Javascript executed where it shouldn't be. But an alert box isn't scary.

It's scary when Javascript can put your Drupal site offline. And it's even scarier when it locks you out of logging back in because it changed your administrator account username, password, and email address. Watch the short video below to see a demo of this.

The malicious Javascript entered by the attacker, when unknowingly executed by an administrator, does the following evil evil things:

Changes the site title and site email address
Changes the administrator's username, email, and password
Sets a site-offline message and puts the site in offline status
And finally, logs the current user out of the site³

How do you protect against this?

Against this exact demo? You disable the use of the Full HTML input format by anonymous users. In general you should understand how to configure your site securely and know what actions you allow untrusted users to perform.

The attack vector in the video is a comment that has Full HTML enabled for anonymous users. Note that Drupal does not come by default with Full HTML enabled for anonymous users.

Be mindful of contributed modules

It's also common that contributed modules print user-supplied data insecurely, opening up for an XSS attack. Popular modules are often more vetted and secure, and thus safer to use. Greg has written recently about some tools to use in picking modules. Also, if you're writing code, make sure you're correctly using the APIs and following best practices.

Stay safe, community!

¹XSS is the number one vulnerability in Drupal code based on times reported in Drupal core and contributed project Security Advisories as published by the Drupal Security Team. Read the report on Drupal Security for more information and stats.

²Javascript can't exactly change admin settings better than you can :). It can certainly change it "faster" than you can though.

³The final piece of the attack ran by the Javascript is actually a different class of attack known as Cross Site Request Forgery (CSRF).

Mitigation against CVE-2010-1584 Drupal Context Module XSS

greggles — Mon, 10 May 2010 18:04:36 +0000

Recently Justin Klein Keane posted information about a vulnerability in the Context Module for Drupal.

Justin included information about mitigating factors:

In order to execute arbitrary script injection malicious users must have 'Administer blocks' permission.

Here are some more concrete steps for mitigation of this particular vulnerability.

1. Ensure only trusted roles have the "Administer Blocks" permission

My coworker Ben Jeavons wrote previously in this blog about the importance of understanding trusted and untrusted users on your site and how roles play in. We also built a check for some important permissions into the Security Review module that Ben built as part of his work with GVS.

To put it simply, while it's not on the list of roles that the Drupal Security Team considers to be site owning permissions that mean there is no need for a Security Advisory, "Administer blocks" is an important permission and shouldn't be given out to untrusted people who might ~~inject XSS into a block title~~ reconfigure or disable all the blocks from the site.

Update: Heine Deelstra asked me to clarify that last line. In general, injecting XSS into a block title would merit an SA in the opinion of the Drupal Security Team. Granular permissions are a strength of Drupal and only permissions which allow for privilege escalation are included in the list we will not do an SA for.

2. Upgrade Context to the latest code from the repository

As often happens, the Drupal community can move quite quickly and in this case the issue has been fixed in the development version of code that exists in the source code repository. A big thanks goes to Steven Jones and to Young Hahn - two of the volunteer module maintainers - for helping out in this particular case . I say "volunteer" because Steven and Young are not paid by the Drupal Security Team to do this kind of work, though their employers may pay them for it, their employers are only one of many companies that benefit from the existence of the modules.

To get the code from CVS a site administrator could use this single command:

cvs -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d context-DRUPAL-6--2 -r DRUPAL-6--2 contributions/modules/context/

There is an issue to create a development snapshot release for this vulnerable branch so it would be easier to download the new code and that release will be created automatically by the Drupal packaging system within 12 hours.

Update: a new release has been created.

You should of course test an updated module in a test environment prior to releasing it onto a live site.

3. Disable the Context module

Only do this if you can't do steps 1 and 2. Really, both of those should be entirely possible and they are simpler.

The Context module provides a variety of features, but the most common one is a new way to show blocks on a site. So, if you can live without the features provided by context you can simply disable it.

Go to Administer > Site building > Modules and uncheck the checkbox next to the module and submit the form.

My personal commentary

My personal take on this is that it's been given a bit more hoopla than it deserves. The mitigation steps are simple and most sites would not be vulnerable in the first place. The Drupal Security Team has a policy of not creating "Security Advisories" in the case of Release Candidate (RC) software and, ideally, the broader world of "Security Researchers" would respect that.

Of course, it would also be ideal if site administrators respected the "developer" nature of these kinds of modules, but the project usage for Context shows that it is on well over 10,000 sites. Another solution to that would be for module developers to create official "1.0" releases of their modules if they are serious about letting them get used on lots of sites.

On a somewhat related note, the Verizon Security blog recently had a post about Security Researchers vs. Narcissistic Vulnerability Pimps.

Drupal text filtering decision cheat sheet

greggles — Thu, 08 Oct 2009 16:39:54 +0000

This flowchart is based on the one that Heine Deelstra presented at Drupalcon Paris.

I'm hopeful that the presentation will be helpful in eliminating Drupal's most common security issue!

Attachment	Size
filtering_text.pdf	55.82 KB

When a Security Vulnerability is Just a Bug - Drupal Content Access XSS

greggles — Wed, 27 May 2009 14:43:14 +0000

If you pay close attention you may have noticed a recent disclosure of an XSS vulnerability in the Content Access module.

This report comes from a system administrator and security researcher at a fine university and contains a section titled Vendor Response:

Drupal security [team] was notified of this vulnerability on 5/19/2009. Vendor
has declined to issue an official security announcement due to the
restricted access rights required to carry out the proof of concept
exploit. Vendor has filed a bug with the module maintainer at
http://drupal.org/node/472494.

XSS is a big deal! With XSS you can run any activity like change a user's password. A similar issue exists in Drupal core.

However, the only way to exploit this vulnerability is to edit a role or create a new role, which is only possible for people with the permission to do a lot of other really bad things on the site much more directly than XSS.

The Drupal Security team has to balance the desire to have vulnerability-free code with the desire to get every end-user updated to the most recent code. If there are dozens of new vulnerability reports and releases of core/modules all the time end users will start to ignore them - particularly when they are for things like this which aren't the most important concern within this scenario.

Is that logic sound? Do we really have a noise/upgrade/"useless release" problem? Let's look at the numbers.

How quickly do Drupal site maintainers upgrade?

So, are we doing a good job of supporting people and getting them to upgrade their site and modules?

Sadly people are still very slow to upgrade. Screaming louder about security holes isn't going to help.

There are lots of things we can do here. I've heard complaints that upgrading is too hard - it's too easy to break your site in the process. I've also heard complaints that "Well, I upgraded and then 2 weeks later a new release came out. So now I wait 2 weeks after every release to make sure I only have to do it once." I've also heard "there are so many releases and I don't understand them, so I just upgrade my sites periodically."

Dang.

So, as bullet points of what we can do

Make upgrading as easy as possible (without sacrificing security...)
Reduce unnecessary noise and confusion around SA
Only make an SA/Release when it's absolutely necessary

What else? Why don't you upgrade your sites? What could Drupal or the security team do to make you more likely to upgrade?