Overview
Recently, I was playing around with the Drupal CMS application code. Drupal is an open source CMS application widely used for the purpose of blog posting. For further details, know more about Drupal here. Basically the open source application advantage here was that the source code was at my disposal.
While fiddling around with the core Drupal Vendor Package I stumbled upon a very interesting vulnerability of XSS. Basically, the idea here was to see how exactly an attacker can exploit this particular XSS to impact Drupal users at large.
So, let me walk you through the technical process of discovery and impact assessment for the Drupal source code audit which lead to the discovery of XSS. Eventually this XSS can be used to hijack drupal accounts or to perform other malicious activity by an attacker.
Post submission about the vulnerability details to Drupal, they added file .htaccess protection (so-called-fix) which has been added to the vendor’s directory that enables denying access to the following location,
Location of vulnerable file is : \core\vendor\behat\mink\driver-testsuite\web-fixtures\issue130.php
The above file contains a PHP Super GLOBAL variable : $_SERVER[‘HTTP_REFERER’] which fails to sanitize requested data, which is specifically vulnerable to reflected cross site scripting attack.
Reporting Date : 29th Aug, 2015 via BugCrowd
Vulnerability Details:
The source code audit started with the use of grep command.Initially, I was more inclined towards finding specific set of keywords like $_GET, $_POST, $_COOKIE, or $_REQUEST as well as other user provided inputs that can also be operated with $_FILES, $_SERVER one by one.
So, after a number of unsuccessful attempts of GREP command, finally grep -i -r “\$_SERVER” command did the thing for me!!
Figure 1 : grep command execution:Random output from the above code
Here, we can see a number of results as a result of our simple grep command execution. Lets try for some more combinations to get a precise result as compared to our earlier result.
Bingo!! here appears some interesting stuff, when I started digging deeper into the pages to look for an un-sanitized data inputs from users. After a while a specially crafted command, produced the desired valid result.
grep -i -r “\$_SERVER” * | grep “$_GET” | grep “echo” and here something is fishy!!!.
Figure 2 : Finally,found some suspicious files which may be vulnerable.
Giving my search a different angle I started looking for the following: /core/vendor/behat/mink/driver-testsuite/web-fixtures/issue130.php and guess what, we stumbled upon the following code.
<!DOCTYPE html>
<html>
<body>
<?php
if (‘1’ === $_GET[‘p’]) {
echo ‘<a href=”issue130.php?p=2″>Go to 2</a>’;
} else {
echo ‘<strong>’.$_SERVER[‘HTTP_REFERER’].'</strong>’;
}
?>
</body>
Figure 3 : At first glance this might look like a simple XSS to you.
However, a closer look reveals the true nature of the beast!! 😉
So, lets prepare a POC which will reveal the true nature of the beast ;).We only had to send a referer header to the issue130.php with a XSS payload, as shown in the following image.
Figure 4 : sending XSS payload using referer HTTP header
Once this referer header is sent via the URL : http://google.com<script>alert(1)</script> then it will pop out an alert JS code execution. So, you can see successful execution of the JS code in the image given below.
Figure 5 : Successful execution of the Javascript code
Conclusion
As can be seen, official Drupal update regarding the patch for this vulnerability seems unsatisfactory. Since they have decided to use “.htaccess” as patch, which is not a proper mechanism to patch away this XSS, no filter or encoders have been used. Nevertheless, several other mechanisms can be used for successful filtering & encoding such as HtmlEncode, HtmlAttributeEncode, JavaScriptEncode etc.
reference link: https://msdn.microsoft.com/en-us/library/hh567599%28v=cs.95%29.aspx
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
