DirtyCOW Bug Drives Attackers to A Backdoor in Vulnerable Drupal Web Servers

In this post we’ll unpack a short — but no less serious — attack that affected some Linux-based systems, on October 31. Throughout the campaign, the attacker used a chain of vulnerabilities including the infamous Drupalgeddon2 and DirtyCOW, and system misconfigurations to persistently infect vulnerable Drupal web servers and take over user machines.

In the past, remote code execution (RCE) attacks on web servers were usually once-off security events – attackers would run their malicious code, and that was it. If the process was detected and terminated, or if the administrator restarted the web servers, the attack would stop.

Increasingly, attackers are opting for persistent attacks. Persistency means that the attacker has a technique to easily re-infect a vulnerable server in case the process is terminated or after a server restart, or run an additional malicious code. Persistency is achieved through different techniques and usually depends on the type of operating system.

Exploiting SSH in Linux

In the case of Linux-based systems, one of the favorite techniques used by attackers is opening a communication channel through SSH and transmitting malicious commands. This technique assumes that an SSH service is installed in the target system. But what happens if it isn’t? Well, then the attacker would somehow need to install it themselves.

In our case, the attack surface was the web application. This means that the attacker’s code was running under the user and permissions of the web application. Usually, the web server user (e.g. nobody, www-data etc.) has minimal permissions and can’t install new services. What if the attacker could change its user context and get sufficient permissions? What if the attacker changed the user to ‘root’? This will certainly help…

First, the attacker builds a word list by locating all of Drupal’s settings files and extracting any line with the word “pass” in it.

This technique can be quite useful as many administrators leave ‘root’ as the default user to connect from the web application to the database.

Then, armed with a potential list of passwords, the attacker tries to use the operating system command ‘su root’ to change the user to root.

If the attacker succeeds in changing the user, they can proceed to download the secondary payload ‘sshdstuff’ and execute (more details below).

If the administrator was careful and didn’t leave root passwords in the configuration files, this technique fails, and the attacker tries to exploit the DirtyCOW bug to escalate their privileges to root. The attacker downloads three different implementations of DirtyCOW and runs them one after the other. One of the implementations is downloaded in its raw format (C source code file) and is compiled at runtime. Surprisingly, one of the implementations of this two-year-old bug has zero detection rate in VirusTotal.

Finally, when the attacker switches to the root user and has permissions to install new services, they install SSH, configure it and add their key to the list of authorized keys by the service. Now, as long as the machine is up and running, the attacker can remotely transmit any command as the user root – game over.

Mitigation suggestions

Administrators should make sure that their web application is fully patched as well as the operating system of the host. Alternately, it is possible to use external cybersecurity solution, like a WAF, to block the attack before it reaches the server. Imperva customers are protected out of the box.