Analysis of a real Drupal Compromise

Ryan Barnett, Senior Lead Security Researcher, Trustwave has analysed a real-world web compromise exploiting a Drupal SQL injection vulnerability (a.k.a. Drupalgeddon) that enables criminals to take control of websites. In this blog post, he will take a step-by-step analysis of a real world compromise of a Drupal web application.

This is a bit different dataset vs. what we normally show on this blog of only Phase 1 initial exploit attempts from web honeypot deployments.  Web honeypots have many tangible benefits however the main limitation is that there is no real, vulnerable target for the attacker to try and exploit.  In these scenarios, we usually only get to see Phase 1 of a full attack sequence chain.  This means we only have visibility into the initial Method of Entry that the attackers are trying to exploit.

So, from a web threat intelligence research perspective the question then becomes, how can we get visibility into Phase 2 post-compromise methodologies?  We can’t answer that unless:

1. A real web application in place for the attacker to compromise, and
2. One of our Trustwave WAF products in place in a detection-only monitoring mode.

The Trustwave research team has what we call “research deployments” of the Trustwave WAF appliance where it is deployed out-of-line (sniffing) and in a monitoring only mode.  This allows us to see full inbound attacks and, more importantly, outbound web application responses.  In this blog post, we will provide an “incident response” example that will highlight some of the tools and processes Trustwave uses when investigating web application attacks by analyzing WAF event data.

Web Application Indicators of Compromise (IOCs)

Breach activity does not transpire in a vacuum. Interaction with the compromised system must take place, and this process frequently leaves behind footprints of the activity occurring. 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 timeframe and potential impact of a breach.

IOC #1: Anomalous “admin” account activity (Drupal) 

Normal Drupal Login

Here is an example of a normal Drupal login screen:

In a normal, non-malicious login 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 we will now show.

Drupalgeddon Attack – Adding an “admin” account

In the first step of this attack sequence, an attack was seen coming in from Freemont, CA.

Here is the RAW event that the TW WAF generated:

Notice the highlighted section of the POST request body.  The attacker has successfully exploited the Drupalgeddon 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 a new admin account called “Rummykhan” 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 has 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.

IOC #2: Unexplained or suspicious outbound data (PHP/SQL Error Messages)

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 TW WAF, we can see that this attack was indeed successful based on the following SQL error message data:

IOC #3: Geographic anomalies in logins

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 “rummykhan” admin account and log into the Drupal site.

One method that can be used to identify this type of activity would be to define Restricted GeoLocations (Country Codes) that either have a known high fraud rate or where you know that you do not conduct any legitimate online business with.  Here is a screen shot of this capability within the TW WAF product:

IOC #4: New and/or suspicious files dropped (webshells)

After logging into Drupal as an “admin” user, the game is essentially over as they do anything they want.  Still, we were able to identify the next steps in this specific attack sequence.  Within two minutes, the attacker then initiated a series of PHP file upload attempts.  The attacker was looking to abuse the following “Create Book” functionality in Drupal:

The key way in which the attacker abused this functionality was related to 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 TW WAF:

Similar to the Drupalgeddon SQL Injection attack from IOC #1 above, the TW WAF again generates an alert identifying this as a PHP file upload attempt:

Since the TW WAF was in a monitoring-only mode, the upload attempt was successful and the attacker was then able to have access to their custom PHP webshell:

Once attackers are able to compromise a web site, they want to be able to keep 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 many webshells and/or modify legitimate PHP files so that attackers can later regain access.  In this attack sequence, the attacker uploaded the following files:

• up.php – an extremely small html uploader.
• 404.php –  WSO webshell
• priv8.php – boffmax v1.0 web shell by the-c0de team
• r00t.php –
• b374k.php – a copy of the original webshell that was uploaded

IOC 5: Unexplained or suspicious file changes

The final step in this attack sequence was a web page defacement of the main index.php webpage:

This resulted in the following defacement:

The TW WAF generated alerts on the inbound upload of the bogus “index.php” file so it would have been blocked in a normal scenario.  The final IOC here would be identifying that your legitimate main “index.php” file has been overwritten by a defacement page.  Another valuable feature that the TW WAF has is that it is able to learn a response page fingerprint for each resource so we can track changes found within the following elements:

With this type of fingerprint tracking, it is possible to identify if there is a significant deviation from normal (like when a page is completely overwritten with a defacement).  The TW WAF would then generate alerts similar to this:

Apparently this defacement crew (AnonGhost) has been quite active based on data from Zone-H web defacement mirror:

Conclusion

There are many takeaways that organizations can learn from this example compromise.

Stay current on software patches and upgrades 

This target website was not update to date on Drupal software patches even though the public announcement of the vulnerability back 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 can be another application.  The key is to make sure that your organization does a comprehensive software inventory and that you have processes in place to be notified of new versions and to deploy fixes as soon as possible.

WAFs need to be in blocking mode 

WAFs have two main functions: 1) Detection, and 2) Response.  If you are using a WAF in monitoring only mode, then you are not maximizing the benefit it can provide.  The WAF detected each of these different exploit steps however, based on the policy, did not block them.  This raises a larger question related to why many WAF users don’t configure them in a blocking mode.  The recent Trustwave “Security on the Shelf” report finds that:

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 MSS WAF services, so that they can get the most out of their WAF deployments.

Continuous Monitoring

Regardless of the WAF policy response actions, this example compromise also demonstrates how important it is to have constant, 24×7 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.

By Ryan Barnett, Senior Lead Security Researcher, Trustwave

About Trustwave

Trustwave helps businesses fight cybercrime, protect data and reduce security risk. With cloud and managed security services, integrated technologies and a team of security experts, ethical hackers and researchers, Trustwave enables businesses to transform the way they manage their information security and compliance programs. More than 2.7 million businesses are enrolled in the Trustwave TrustKeeper® cloud platform, through which Trustwave delivers automated, efficient and cost-effective data protection, risk management and threat intelligence. Trustwave is a privately held company, headquartered in Chicago, with customers in 96 countries. For more information about Trustwave, visit www.trustwave.com.