In this blog post, we will walk you through a real-world compromise of a Drupal web application. This analysis will differ from our typical posts that only cover the initial phase of an exploit attempt based on data from our web honeypot deployments. Web honeypots provide a wealth of valuable information, but they do not include real, vulnerable targets for the attacker to actually exploit. In these scenarios, we usually only get to see the first phaseof an attack sequence meaning we can only observe the initial method of entry an attacker attempts to exploit.
So, from a threat intelligence research perspective the question then becomes, "How can we get visibility into the second phase of an attack beyond the initial intrusion?". We can't answer that unless:
The SpiderLabs Research team manages a number of out-of-line research deployments of the Trustwave Web Application Firewall (WAF) in monitoring only mode. These deployments allow us to see full inbound attacks and, more importantly, outbound web application responses. In this blog post, we will provide an analysis of an "incident" observed as the result of a research deployment to highlight some of the tools and processes SpiderLabs Research uses when investigating web application attacks.
Breach activity does not transpire in a vacuum. An attacker will interact with the compromised system and typically leave behind some sort of clues indicating some activity. These clues are commonly referred to as indicators of compromise (IOCs). Monitoring systems for indicators of compromise and responding appropriately is critical to reducing the duration and potential impact of a breach. Here is a Top 10 listing of IOCs from last year's Trustwave Global Security Report:
Keep in mind that this is only a top 10 list of IOCs, and there are many indicators to consider. With these IOCs as our guide, let's start searching for signs of successful web application compromises!
Here is an example of a normal Drupal log-in screen:
In a normal, non-malicious log-in request for Drupal, this is how the resulting raw HTTP request looks:
Notice the single "name" parameter in the POST payload? That is the parameter name that maps to the "Username" parameter data in the Login UI above. This "name" parameter is the target vulnerability injection point for the attacks explained below.
In the first step of this sequence, an attack was observed originating in California.
Here is the RAW event that the Trustwave WAF generated:
Notice the yellow highlighted section of the POST request body. The attacker has successfully exploited the Drupageddon vulnerability by placing an SQL Injection payload within the "name[]" array contents. If you look closely at this SQL Injection payload, you will notice that the desired goal is to add and activate (by setting the "status=1" setting) a new admin account ("uid = 1") with a preset password hash. In searching the web for this specific SQL Injection payload, we were able to find a Mass Drupal Exploit php program on PasteBin:
If we look at the source code, we can see the following data which matches up with the attack request from above:
This sets the password hash to match "admin". Meanwhile, the WAF generated an alert that lists many different detection mechanisms:
It is important to note that this event consists of both anomaly-based detections and negative security signatures.
Looking back at the Mass Drupal Exploit code from PasteBin, after sending the attack payload, the tool then checks the response body content to see if the SQL injection generated a specific error string:
If we inspect the HTML response data captured by the Trustwave WAF, we can see that this attack was indeed successful based on the following SQL error message data:
After the initial Drupalgeddon exploit, the attacker then pivoted to use a different IP address from the country of Morocco to then use the new admin account and log into the Drupal site.
Using multiple IP addresses during the course of an attack is a common technique used by attackers. One way to identify this type of activity is by defining Restricted GeoLocations (Country Codes) for locations you know are frequently the source of fraudulent activity or countries with which you don't typically do business. Here is a screen shot of this capability within the Trustwave WAF :
After logging into Drupal as an "admin" user, the game is essentially over as an attacker is capable of almost anything. Still, we were able to identify the next steps in this specific attack sequence. Within two minutes, the attacker initiated a series of PHP file uploads in an attempt to abuse the following "Create Book" functionality in Drupal:
The key way in which the attacker abused this functionality was via the enabled "Text Formats":
Notice the highlighted sections. This interface allows admin users to post PHP code to the site. The Drupal site even lists the following warning about this feature:
In this case, however, if the attacker is able to exploit a vulnerability and become an admin-level user, then it is game over. The attacker was able to place PHP code for a known webshell/backdoor into the body value parameter of the form:
This attack results in the following HTTP request as captured by the Trustwave WAF:
Similar to the Drupalgeddon SQL Injection attack from IOC #1 above, the Trustwave WAF again generates an alert identifying this as a PHP file upload attempt:
Since the Trustwave WAF was in a monitoring-only mode, the upload attempt was successful and the attacker could access their custom PHP webshell:
Upon compromising a website, attackers want to maintain access for future use. In case the web site owners happen to upgrade the system and patch the initial exploit vectors, attackers like to upload a number of webshells and/or modify legitimate PHP files to allow them to regain access. In this attack sequence, the attacker uploaded the following files:
The final step in this attack sequence was a web page defacement of the main index.php webpage:
The Trustwave WAF generated alerts on the inbound upload of the bogus index.php file so in a normal scenario it would have been blocked. The final IOC here would be identifying that your legitimate main "index.php" file has been overwritten with a defacement page. Another valuable feature of the Trustwave WAF is its ability to learn a response page fingerprint for each resource so that changes found within the following elements can be tracked:
With this type of fingerprint tracking, it is possible to identify significant deviations from the norm (like when a page is completely overwritten with a defacement). The Trustwave WAF would then generate alerts similar to this:
In this scenario, the target site was not up-to-date on Drupal software patches despite public announcement of the vulnerability in 2014. As this blog post shows, attackers are still searching for, and exploiting, vulnerable websites. In this case it was Drupal, but tomorrow it might be another application. The key is to make sure that your organization does a comprehensive software inventory, implements processes to take note of new versions and deploys patches as quickly as possible.
WAFs have two main functions: 1) Detection, and 2) Response. If you are using a WAF in monitoring-only mode, then you are not realizing the true value of the technology. The WAF detected each of these different exploit steps, but based on the policy did not block them. This raises a larger question of why many WAF users don't configure them in a blocking mode.
Twenty-eight percent of organizations are not getting the full value out of their security related software investments
Here is a breakdown of different reasons why:
Many of these challenges are what is driving more and more organizations to managed WAF services, so that they can get the most out of their WAF deployments.
Regardless of the WAF policy response actions, this example also demonstrates how important it is to have constant, 24x7 monitoring of your web applications. Keep in mind that this compromise (from the initial Drupalgeddon SQL Injection attack all the way through to the final web defacement) only took ~18 minutes. Do you have security personnel that are monitoring your web applications and WAF events at all times looking for these types of attacks?