Drupal 7 SQL Injection Info
There's a lot of sites covering this vulnerability but I wanted to document some indicators for anyone who might need it.
Drupal Security Advisory - https://www.drupal.org/SA-CORE-2014-005
Drupal Public Service Annoucement - https://www.drupal.org/PSA-2014-003
Drupal Documentation on "Your Drupal Site Got Hacked. Now What?" - https://www.drupal.org/node/2365547
Drupal Site Audit - https://www.drupal.org/project/drupalgeddon
Volexity Blog - http://www.volexity.com/blog/?p=83
Sururi Blog - http://blog.sucuri.net/2014/10/drupal-sql-injection-attempts-in-the-wild.html
What follows is a brief walk-through of evidence found on a couple of compromised hosts. YMMV.
Logging into phpMyAdmin and checking out the "users" table. Two accounts were created. The "drupaldev" account seems to have been found on many compromised hosts.
There was one host that had hundreds of accounts. What made the malicious accounts stand out was the missing mail field. This would occur if the user could get past the requirement on the registration page or if the account was added directly to the table.
Going to the "sessions" table, there's one entry with the "uid" that matches the account created by the attacker. You can find out the attacker's IP address this way.
Here's info on this IP address:
The firewall logs showed activity over port 8888. If you visit the IP:port, you get this site:
Looking at the webserver logs, we can see POSTs hitting the user/login file on the host. The server 500 errors probably indicate a failed first attempt.
Going back to phpMyAdmin, a quick search for ".php" was done across all of the tables.
There was an entry found in the "menu_router" table which seems to be a very common indicator.
Clicking on the link, you can download the blob.
Going to the file system, there is a directory called "README.txt" with a php file inside. The folder and file names appear to be random but the script itself is the same as what others have reported.
This PHP script is particularly interesting, it's a simple backdoor that's triggered by a cookie. Sucuri covered this awhile ago.
Here's a cleaned up version. If you hit the script straightaway, you will get the results of phpinfo(). If you wish to send your own commands, you need to pass three variables. The "Kcqf3" variable contains a value that triggers the script. The second variable "Kcqf2" will be preg_replace. The "Kcqf1" contains the command. I imagine the attackers might send commands along the lines of uname, wget, curl, etc.
I wrote a program to craft HTTP requests and can include my own cookie values into the header. Here, I'm sending the phpinfo command and you can see the result in the background. What stands out is its simplicity and cleverness.
You could create an IDS rule to look for HTTP requests that contain a cookie with the value "preg_replace" and detect/block those coming in. You can then follow up on the targeted host to see if the backdoor is there.