Drupal Vulnerability: Mass Scans & Targeted Exploitation
October 16, 2014
Yesterday (October 15, 2014), a critical SQL injection vulnerability in version 7 of the popular open source content management system (CMS) Drupal was disclosed by Stefan Horst and detailed in SA-CORE-2014-005. The description of the vulnerability is rather harrowing:
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.
If you think this sounds pretty bad, you are spot on. Along with the advisory, a patch was released to fix the security issue. Unfortunately, patches are also often leveraged to identify exactly how to exploit such vulnerabilities. In this case, it was only hours later that PoC code on how to exploit the security issue was posted online. From that point it, has been off to the races by attackers. The first such instance of the code appearing that we have seen was on Reddit by the user fyukyuk. Not long after, someone further weaponized the code into a Python script and posted it to Pastebin here.
The following is the excerpt of the code that would need to be sent in a POST request to facilitate the SQL injection from fyukyuk's example on Reddit:
name[0%20;update+users+set+name%3d'owned'+,+pass+%3d+'$S$DkIkdKLIvRK0iVHm99X7B/M8QC17E1Tp/kMOd1Ie8V/PgWjtAZld'+where+uid+%3d+'1';;#%20%20]=test3&name[0]=test&pass=shit2&test2=test&form_build_id=&form_id=user_login_block&op=Log+in
If this code is executed properly on Drupal, it effectively updates the the account with the uid of 1 (admin) and sets the new username to "owned". The password is then set to "thanks" and those credentials could then potentially be used to access Drupal as an administrator. We say potentially because there are other mitigating steps one could enact to prevent access, such as ACLs and two-factor authentication. However, given the scope of the vulnerability includes remote code execution, restricting access to the Drupal admin interface may be the least of one's worries.
Targeted Attacks and Mass Scans in the Wild
Now, here is the bad news. Not only has the PoC code been online since October 15, attackers have also been mass scanning for this issue since then as well. We are aware of multiple confirmed breaches at various organizations as a result. Volexity has observed attacks against several of its customers in both indiscriminate and targeted capacities. Wide spread scanning has been observed against websites that are not even hosting Drupal. However, Volexity has also observed IP addresses associated with APT attackers specifically targeting websites of our customers.
In the cases where we have had packet capture to fully analyze the contents of the attacks, we have observed the attackers using the exact PoC code that has been posted online without changing it. The following HTTP Request was captured late last night from an attack on a patched Drupal server:
POST /?q=node&destination=node HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
Content-Type: application/x-www-form-urlencoded
Content-Length: 253
Host: <removed>
Connection: keep-alivename[0%20;update%2Busers%2Bset%2Bname%3d'owned'%2B,%2Bpass%2B%3d%2B'$S$DkIkdKLIvRK0iVHm99X7B/M8QC17E1Tp/kMOd1Ie8V/PgWjtAZld'%2Bwhere%2Buid%2B%3d%2B'1';;#%20%20]=test3&name[0]=test&pass=shit2&test2=test&form_build_id=&form_id=user_login_block&op=Log%2Bin
In this case, the attack appears to have been manual. Further examination of other log data available to Volexity has shown mass scanning with a variety of User-Agents being leveraged as well. So far, scans with the following User-Agents have been observed:
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Mozilla/5.0 (Windows NT 5.2; rv:25.0) Gecko/20100101 Firefox/25.0
Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:18.0) Gecko/20100101
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:28.0) Gecko/20100101
Python-urllib/2.6
Python-urllib/2.7
Version Reconnaissance - CHANGELOG.txt
In some of the targeted cases Volexity has observed thus far, the attackers requested a file that is often a remnant from Drupal installs and upgrades called CHANGELOG.txt. This file details the changes that have been made to Drupal with each release. More importantly is that above each set of changes is the version number in which they were made. If the file is left behind, the very first line will reveal what version of Drupal the server is running. In two cases Volexity observed the attackers requesting this file from the target server. In one case, the attackers did it prior to attempting their exploit. In the other they did it post exploit attempt. In both cases, the exploit failed as the server was patched yesterday afternoon. Volexity would recommend removing this file. The text below contains partial content from CHANGELOG.txt showing the patches and version number as observed on a Drupal 7 server:
Drupal 7.31, 2014-08-06
---------------------- -
Fixed security issues (denial of service). See SA-CORE-2014-004.Drupal 7.30, 2014-07-24
-----------------------
- Fixed a regression introduced in Drupal 7.29 that caused files or images attached to taxonomy terms to be deleted when the taxonomy term was edited and resaved (and other related bugs with contributed and custom modules).- Added a warning on the permissions page to recommend restricting access to the "View site reports" permission to trusted administrators. See DRUPAL-PSA-2014-002. - Numerous API documentation improvements.
- Additional automated test coverage.
Detection
Depending on what type of data you have to work with, there are various means to detect attacks. If you have access to web logs, you can grep them for the following text:
?q=node&destination=node
Results similar to the following may represent exploitation attempts:
119.57.189.115, 119.57.189.115 - - [16/Oct/2014:04:15:15 -0500] "POST //?q=node&destination=node HTTP/1.1" 200 "-" "Python-urllib/2.7"
This isn't to say there aren't other ways to encode the URLs and URI data, but it is what is currently prevalent.
Additionally, the following Suricata and Snort rules can be leveraged to detect the current round of attacks:
Suricata Format
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"Volexity - Possible Drupal SA-CORE-2014-005 Exploit Attempt"; flow:established,to_server; content:"POST"; http_method; content:"?q=node&destination=node"; http_uri; content:"name[0%20|3b|update"; http_client_body; threshold:type limit, track by_src, count 1, seconds 120; sid:2014101601;)
Snort Format
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTT_PORTS (msg:"Volexity - Possible Drupal SA-CORE-2014-005 Exploit Attempt"; flow:established,to_server; content:"POST"; http_method; content:"?q=node&destination=node"; http_uri; content:"name[0%20|3b|update"; http_client_body; threshold:type limit, track by_src, count 1, seconds 120; sid:2014101601;)
These signatures are specific to what is being seen in the wild and will not detect all possible cases of such an attack. A more loose version of these rules could involve only examining the http_uri and removing the following content match.
Conclusion
The most important thing to do, if you haven't already, is to patch immediately. Then examine your system, database, and logs to see if you have already been impacted. If you can't log into your admin account any longer and see the account name is now 'owned', then you have already been compromised. However, this is just the cookie cutter in the wild exploit being used. Attackers can perform any number of other functions with this exploit and are not limited to what we have described thus far. If you have been breached or have major concerns that you have been, it may be time to build a new server and start with a fresh system build and the latest version of Drupal. Consider restricting access to your user and administrative interfaces and consider two-factor authentication integration from providers like Duo Security. Also, while you are at it, go ahead and delete CHANGELOG.txt.