If you are currently running any Drupal 7 web applications, there is a very critical SQL Injection vulnerability affecting Drupal Core. This was publicly released on Wednesday, 10/15/14 along with an exploit. The proof of concept simply modifies the administrator’s username and password, allowing an attacker to gain administrative access to the Drupal application.
“Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks.
A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks.
This vulnerability can be exploited by anonymous users.”
The vulnerability is ranked as Highly Critical, a 5 out of 5 on the Drupal Security Team’s risk scale… A patch has been released and upgrading to Drupal Core version 7.32 will remediate this vulnerability. If you host Drupal sites, it is imperative that you patch soon. One quick way to test and see what sites have yet to be patched would be to make a simple bash loop to check all the known Drupal sites in your environment and see if any of them are still vulnerable.
Be very careful doing this, it will modify the admin’s password on every vulnerable site!
Even though this was only publicly released just a couple days ago, there is a chance that this vulnerability has been known for quite some time as it affects every Drupal 7 web application running version 7.31 or older. Luckily there are log traces of this attack that can be used to ascertain whether or not the vulnerability has been exploited.
The evidence in question lies within the Drupal Watchdog logs. Ideally this information should be extracted and stored in a SIEM or similar central logging solution. However, if you are only moving server logs off of the host then you are missing a good portion of the actionable evidence. Not to mention that once an attacker has gained access they can simply clear out the logs, erasing all remnants of the attack within the application.
If you are not offloading these logs to a SIEM and are lucky enough to still have Watchdog logs available following a breach, then you should search through these for the following four events in succession. Sometimes there will only be the first three (from bottom to top) as the attacker may wait to actually log in.
The details of the three messages to look for are:
- Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 478 of /var/www/redman/includes/unicode.inc).
- Warning: addcslashes() expects parameter 1 to be string, array given in DatabaseConnection->escapeLike() (line 981 of /var/www/redman/includes/database/database.inc).
- Login attempt failed for .
The nice thing about this attack is that the logs consistently provide us with valuable data, making it very easy to create a correlated events on a successful attack. So, if you are unsure of whether or not all of the Drupal 7 sites have been adequately patched, it’s a good idea to alert the SOC to successful attacks against any Drupal applications in the environment. Using LogRhythm this can be done with a simple correlated event rule block that looks for these messages in quick succession. I’ve included an example rule below that simply looks for this activity within the Watchdog logs. The first of which alerts on the message data from the first portion of the attack within Drupal 7 UDLA logs…
The second rule block looks for the next error message in the Watchdog database table…
And the third rule block looks for a failed login with a [ blank username ].
All of which is grouped by the same Impacted Host.
You could also add a rule looking for a successful login using the admin account. However they could change the admin’s username and may not even log in for quite some time following a successful attack. For this reason I did not include the fourth potential log message in the rule.
If you have a WAF that is tuned properly, this attack should be blocked. The LogRhythm Web Application Defense Module can assist with detecting this attack as well. Due to the popularity of this CMS, many organizations currently have a very large number of Drupal applications and often have little control over when they get patched. For this reason, it is beneficial to now when these applications are successfully compromised at the very least. Alerting on this activity will allow the security team to make a business case to get the sites patched in a reasonable amount of time as the only true way to fix this issue is to upgrade to Drupal 7.32 as soon as possible.