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.

Resources
Drupal Security Advisory
Drupal Public Service Annoucement
Drupal Documentation on “Your Drupal Site Got Hacked. Now What?”
Drupal Site Audit
Volexity Blog
Sururi Blog

What follows is a brief walk-through of evidence found on a couple of compromised hosts. YMMV.

Incident Response
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.

2014-11-02_01

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.

2014-11-02_02

Here’s info on this IP address:

2014-11-02_03

The firewall logs showed activity over port 8888. If you visit the IP:port, you get this site:

2014-11-02_04

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.

2014-11-02_05

Going back to phpMyAdmin, a quick search for “.php” was done across all of the tables.

2014-11-02_06

There was an entry found in the “menu_router” table which seems to be a very common indicator.

2014-11-02_07

Clicking on the link, you can download the blob.

2014-11-02_08

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. “Kcqf1” contains the command. I imagine the attackers might send commands along the lines of uname, wget, curl, etc.

2014-11-02_09

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.

2014-11-02_10

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.

Good luck!

This entry was posted in Malscript and tagged , , , . Bookmark the permalink.