This time, we would like to share with you a few bugs ZeroDayScan found in default Drupal installation (Drupal 6.16). Both of these bugs lead to full path directory disclosure in the default Drupal installation.
Why it is important?
Full path directory disclosure bugs allow the attacker to study the internal structure of your website. It is very helpful in case SQL injection is found on the same box (and it also does not have to be on the same website that runs Drupal as most of the web servers host a bunch of websites). It happens because using SQL injection you can write files, and if you know the location of default Drupal installation, you can easily find the "files" Drupal directory. This directory is fully writeable as it is used as a temporary directory. As a result, an attacker can create a web shell on that box. For more information please check this article: Backdoor webserver using MySQL SQL Injection.
How to reproduce these bugs?
It is very easy. If the destination Drupal parameter is send not in a proper format, an error message is printed. To reproduce this bug, you just need to add the following path to your website's name: /node?destination=node . In our tests we use www.drupal-site.com website. So we used the following URL: http://www.drupal-site.com/node?destination=node
Here is a an error message as we got it:
The following error is printed: warning: urlencode() expects parameter 1 to be string, array given in /var/www/drupal-6.16/includes/common.inc on line 258. The bold text basically specifies where the Drupal files are located on the remote host.
Another bug is in the Drupal built-in login parameters validation mechanism. In order to reproduce it, specially crafted data must be sent to remote site. In our test we used the curl tool to do it for us. Here is a screenshot:
The following string is POSTed: name=aaaa&pass=Q1s2x3w4d&op=Log+in&form_id=user_login_block
The following error is printed: warning: mb_strlen() expects parameter 1 to be string, array given in /var/www/drupal-6.16/includes/unicode.inc on line 404.
After contacting the Drupal security team, we learned that there is a workaround for this bug. It is recommended to configure Drupal to disable printing of errors to the screen (it is ON by default). You can do it by clicking on "Administer" >> "Error Reporting". Then select "Write errors to the log" instead of "Write errors to the log and to the screen". Here is a screenshot of this window:
We suppose that these bugs will be fixed in the next Drupal release. But we are not totally sure as the Drupal security team does not consider these bugs as high priority. No security alert is going to be released covering this issue.
Always update your software. Another recommendation, is to host each of your sites in a distinct virtual environment, so if one of the sites is vulnerable, it will not effect the other websites. Also consider installing the GreenSQL database firewall.
Finally, you should use the ZeroDayScan web security scanner to check your website and find Zero Day Bugs. It is a free tool and it really works and finds a lot of bugs including SQL injections. The ZeroDayScan security scanner found the bugs covered here. If you use custom modules in you Drupal installation, ZeroDayScan can check it and detect bugs.