Drupal Local File Inclusion Vulnerability

I was testing our scanner (with AcuSensor enabled) on Drupal (http://www.drupal.org) and the scanner found a possible File Inclusion vulnerability.

drupal_vulnerability

As you can see from the screenshot above, the GET variable q was set to start/../../xxx….end and it got partially sanitized. It reached the include function as /themes/garland/page-start-..-..-xxx….end.tpl.php. All the slashes were replaced with “-“.

Even more, we cannot fully control the include path, the user input is automatically prefixed with ./themes/garland/page-.  So, this vulnerability doesn’t look exploitable, right? Actually this is exploitable on Microsoft Windows systems.

On Unix systems, something like “cat /var/www/some_invalid_filename/../../../../../etc/passwd” doesn’t work because some_invalid_filename is not a directory and give the error that  some_invalid_filename doesn’t exist. It will not work even if you have a valid file name.That’s the expected behavior in my opinion, however, in Microsoft Windows things are different.

Executing the command “type c:windowssssssssssssss……….boot.ini” will return the contents of c:boot.ini even if sssssssssssss is not a directory and it doesn’t even exists as a file name. Check the screenshot below.

drupal_cmd

The vulnerability is located in the file “includestheme.inc” on line 1011. Vulnerable code:

drupal_vulnerable_code

PHP option magic_quotes_gpc is turned OFF in Drupal, so it’s possible to use %00 to terminate the string. Therefore, if you set q to something like q=……………………boot.ini%00 it is possible to include the contents of boot.ini on Windows systems, if the web server is installed on the C:  partition. Below are two more screenshots about the exploit.

drupal_exploit_1

drupal_exploit_2

Drupal versions 5.x and 6.x are vulnerable to this problem.

Drupal security team was notified about this vulnerability on 29 January 2009 and they’ve released a fix on 25 February 2009. The fix for Drupal version 5.x is available here. And for Drupal version 6.x can be found here.

Share this post
  • Once again, thank you for your report!

    Secunia seems convinced this is an information disclosure bug (“Exposure of sensitive information”), but we think it is much more serious:

    1 – if uploads are enabled, an attacker can upload evil_php_code.txt, then have it included and executed.

    2 – if an attacker succeeds to get a string such as <?php [code] ?> into the Apache logs (access, error or php log), he can then try to get the logfile included and the code executed.

  • Thanks Heine,
    Yes, there was a lot of research on LFI 2 RCE (local file inclusion to remote code execution) and it’s pretty easy to accomplish. Check this paper for more information http://www.ush.it/2008/08/18/lfi2rce-local-file-inclusion-to-remote-code-execution-advanced-exploitation-proc-shortcuts/.
    And I’ve recently tried to do the same on IIS (with PHP) and it’s working without problems.
    So, yes, this vulnerability is very serious for people running Drupal on Windows systems.

  • well i tested this on some own sites it seems not work. not sure how clear is this.

  • It works only on Windows systems (not on Unix). And the sample exploit I’ve provided in this article works only if the webserver root is located in the C: drive. Also the guys from Drupal already released a patch (http://drupal.org/node/383724). Your websites could be patched.

  • Leave a Reply

    Your email address will not be published.


    *