Case Study of a Cracked Drupal Website

We recently examined a website built using Drupal CMS. Somehow it was hacked into and all PDF files in the website were replaced with the ones carrying viruses.

After some probing around, we found that it wasn't caused by any vulnerability inside the Drupal code. The hackers stole an admin account and changed the configuration, and then further altered the content.

The website had upload module (in core) enabled.

Here is what happened:

  1. One of the admin accounts was leaked. This admin account has the right to modify "Access Control" in the Drupal website.
  2. The hacker got into the website using the admin account.
  3. We can see many rounds of attempts to upload executibles into the website, using either the upload module or a 3rd party image upload module. And also they tried to upload an image, and then rename the image into a .php file. None of these got them what they wanted.
  4. The hacker opened the configuration of upload module and edited the setting. We can asure that it added .php, .php3, or something like that into the allowed extension list.
  5. The hacker created a new node and uploaded a file, which is named 'p.php3'. Since .php3 is now an allowed extension, the 'p.php3' was uploaded successfully into /files.
  6. The hacker successfully executed the file http://website/files/p.php3. This file can take either GET or POST requests.
  7. Via p.php3, it further downloaded more php files into /files and /files/images. The most malicious one is a hidden file named /files/images/.php.php.

No need to say more, the hacker has gained enough control to damage the website.

After that, the hacker still wanted to further gain access to root. It droped some scripts into /tmp. One of the scripts we found is used to open sockets and transmit system variables to outside.

In the meanwhile, the hacker started SQL injection scanning.

Lessons learned through this case:

  • Protect your user accounts and admin accounts. Periodically check the access control settings to make sure the permissions are set right.
  • Harden your file systems. Mount /tmp and /var/tmp and other world writable directories as noexec and nosuid.
  • Remove php3 and php4 support from your web server. After all, Drupal-5.x requires a minimum php 5.1.6.
  • Install web server's application layer firewall, such as mod_security for apache.