Table of Contents [TOC]
So Your Drupal site got hacked and is infected with a malware. Now what? What to do when your Drupal website has been hacked? In this post, you will learn more about how to fix a hacked drupal site in and remove Drupal hacked redirect malware infection from the database.
With a dedicated security team, Drupal is considered one of the most secure CMS in the open-source world. The attacks, each more innovative than the other, make security a major issue for the community. However, there is no such thing as zero risks.
You have already faced attacks, crashes, performance issues… but what to do when your Drupal site is hacked? In this post, we summarize some best practices to maintain the security of your site. Since drupal is also iused for ecommerce sites. Check out our guide on ecommerce security threats & best practices.
Looking for a Drupal malware scanner? – we have got a list of website malware scanner tools here.
Usually, when a site has been hacked, elements of the interface or the back end have been modified, files are deleted, features are altered or unavailable. Suspicious content or links are now posted on the site.
At the slightest suspicion, it is preferable to analyze the site and the server for traces of hacking. The list of ways to check if a site has been hacked is not exhaustive, but here is a good start to start your investigation:
Analyze server logs – Abnormal error messages can indicate a malicious attack on the site. There are tools like Scalp that allow you to analyze logs. You can also run manual commands to retrieve the contents of the logs directory. For example, in Linux, the Last command displays the list of the last connected users as well as their respective IP addresses.
Identify unusual IP addresses that may be an intrusion on your site.
Scan Modified Files – There are several ways to check if certain files have been modified. For example with Linux, it is possible to use the command # ls -al –time-style=+%D | grep ‘date +%D’ | more to analyze the last modified files (the last 24 hours).
Analyze messages on search engines – in Google search results, Google may display below your site result “This site may damage your computer”. It is also possible to use an antivirus that can detect if the site is corrupted. These messages are indicators that your site appears to have been the victim of an attack.
If your Drupal site has been blacklisted by Google you can use their diagnostic tools to check the security status of your hacked Drupal website. An effective way to check if a Drupal site is hacked.
Worried about Drupal hacked site? Drop us a message on the chat widget and we’d be happy to help you fix it. Secure my Drupal website now.We can thoroughly scan your hacked Drupal site & cleanup any malicious code. CONTACT US HERE
For more information about these security warnings, read our guide explaining the Google blacklisting.
On March 22, the authors of CMS announced the release of a new version of Drupal 7 and 8 to address a critical vulnerability. The update was released on March 28, to correct (among others) the flaw referenced CVE-2018-7600 for the announced vulnerability. Nicknamed “Drupalgeddon 2”, this allows a remote attacker to execute an arbitrary code on the system (RCE) in order to gain control.
The DrupalGeddon2 vulnerability, referenced CVE-2018-7600 comes from a failure to process parameters submitted by the user through the account creation and password reset forms, accessible via the “ / user / register” URLs and ” / user / password “.
This lack of processing more specifically impacts the “call_user_func_array” and “call_user_func” functions defined in the “/core/lib/Drupal/Core/Render/Renderer.php” file in charge of generating HTML pages.
By sending a specially crafted HTTP request, an unauthenticated remote user is able to force the remote server to execute arbitrary system commands. Thus an attacker can take control of the underlying system.
Such an attack can be carried out in order to impact the image of a company (disfigurement ), or to compromise the server .
It was found that this vulnerability could be exploited in at least 2 different ways:
An attacker can inject PHP commands which will be interpreted by the “rendering” engine introduced in Drupal 7.
https://www.drupal.org/docs/7/api/render-arrays/render-arrays-overview
To inject the malicious code, the attacker uses the following native rendering functions:
For example, to inject code within the account creation page, the attacker uses the “rendering” function named lazy_builder through the timezone parameter. Two arguments are passed to this function:
” [#Lazy_builder] [] = ” allows injecting a PHP function of our choice, such as ” exec “, which allows executing system commands.
” [#Lazy_builder] [] [] = ” contains the possible parameter of the function injected previously.
Thus, sending the previous request to a vulnerable server will allow an attacker to force the server to execute the following command: exec (“echo PWNED> /Applications/MAMP/htdocs/drupal/index.html”);
This execution results in the creation of the page “index.html” containing simply the term “PWNED”.
Rather than creating an HTML page, it is quite possible to upload a web shell, open a backdoor on the server, etc.
A filtering feature has been created to correct the vulnerability. In the CMS source code, this takes the form of a class called ” RequestSanitizer” . The methods of this filtering class are used upstream of the vulnerable code, so their use mitigates the exploitability of the various attack vectors detailed above.
The purpose of the “stripDangerousValues” method is to filter out all parameters prefixed with ‘#’, such as ” # lazy_builder ” and ” # post_render ” used in this attack. This allows preventing an attacker from injecting
“rendering” functions.
This filtering thus makes it possible to avoid the injection of PHP code within these parameters.
Multiple vulnerabilities have been discovered in Drupal, a free content management system. A remote attacker can execute arbitrary queries on a user, as well as execute arbitrary PHP code.
CVE-2020-13663 [CVSS v3 score: being calculated]: A CSRF type vulnerability has been discovered in Drupal. A remote attacker exploiting this vulnerability can cause the browser of a user visiting the vulnerable page to execute arbitrary requests, by sending specially crafted form entries.
CVE-2020-13664 [CVSS v3 score: being calculated]: An arbitrary code execution vulnerability has been discovered in Drupal. A remote attacker exploiting this vulnerability can execute arbitrary PHP code.
The attack requires that a user visit a site controlled by the attacker, with a specially crafted name in the tree structure of the vulnerable website.
Let’s take a closer look at some of the most common causes of a compromised Drupal website due to the vulnerabilities exposed.
A Drupal Access Bypass can lead users to access resources that are not intended for them. The last such vulnerability was dubbed SA-CONTRIB-2018-081. The cause is a Drupal module named JSON: API 8.x-1.x module for Drupal 8.x. It is mainly used for:
In this case, it does not carefully check permissions while responding to some requests. This can allow malicious actors with insufficient authorization to obtain sensitive information. Therefore, only GET requests can be used for this type of attack.
Drupal SQLi vulnerabilities are often found in poorly coded modules. However, an SQLi in the kernel is quite rare and dangerous. One such dangerous flaw was “Drupalgeddon”, although Drupal used PDO (PHP Data Object) to separate a static SQL query and dynamic values.
$ query = $ db-> prepare ("SELECT * FROM users WHERE user =: user AND password =: password");
$ account = $ query-> execute (array (': user' => $ _POST ['user'], ': password' => $ _POST ['password'])); Everything looks fine because the entry is properly cleaned up before it reaches the database. The bone of contention, however, was in Drupal’s placeholder tables. They were aimed at giving flexibility to module developers, as they allowed dynamically changing the structure of database queries.
db_query ("SELECT * FROM {node} WHERE nid IN (: nids)", array (': nids' => array (13, 42, 144))); Thereafter, the placeholder: nests would correspond to the number of arguments provided. Like that:
SELECT * FROM {node} WHERE nid IN (: nids_0 ,: nids_1 ,: nids_2) This functionality combined with PHP indexed arrays could be used to pass parameters such as (GET, POST and cookies). Drupal placeholder arrays would by default assume that the $ _POST [‘user’] parameter is an array. Subsequently, it would use the raw array string indexes to generate the new placeholder names. As a result, the attacker can provide malicious values such as Parameter: user [0 #], Value: foo. The resulting query would be:
SELECT * FROM {users} WHERE user =: user_0 # Thus, the attacker successfully bypasses the login authentication. Moreover, the attacker can even create new users by editing the parameter as user [0; INSERT IN THE user VALUES “MalUser”, “Passw0rd!”, “Administrators”; #]. This was a very critical flaw as it affected the core of Drupal. What is more alarming is that a Metasploit module has also been released to exploit it!
Also Read – SQL injection – How to Fix & Prevent SQLi Hack
Drupal security has been haunted by a series of Drupalgeddon bugs. Drupalgeddon 3 is the last one found this year. This allows unauthenticated users to run code on Drupal sites. Although Drupalgeddon 2 also allows RCE. However, to exploit this, the attacker needed the ability to drop a node. The full URL looked like this:
PUBLISH /? Q = node / 99 / delete & destination = node? Q [% 2523] [] = passthru% 26q [% 2523type] = markup% 26q [% 2523markup] = whoami HTTP / 1.1 [...] form_id = node_delete_confirm & _triggering_element_name = form_id & form_token = [CSRF-TOKEN]
Here, under the pretext of deleting a node, the attacker injected the whoami command. The second line of code is to verify the CSRF token. Essentially, a CSRF token checks if the request was generated on the same server. Subsequently, the attacker gets the form_build_id of the response as shown in the code below:
POST / drupal /? Q = file / ajax / actions / cancel /% 23options / path / [FORM_BUILD_ID] HTTP / 1.1 [...] form_build_id = [FORM_BUILD_ID]
This finally triggers the exploit and the output of the Whoami command is displayed. Therefore, the attacker can execute all kinds of commands to manipulate the server. What makes this RCE bug more serious is that the exploit has already been released!
Also Read – Remote & Local File Inclusion Vulnerability
Vulnerabilities such as XSS and SQLi are quite common in Drupal modules. The last in this series is SA-CONTRIB-2018-080.
The E-Sign module has been found to be vulnerable to XSS. The E-Sign module essentially allows you to integrate Signature Pad into Drupal. As of this writing, approximately 875 sites are using this add-on.
The vulnerability is caused by the failure to clean up entries when a signature is displayed. Thus, the attacker can test XSS using the code <script> alert (‘XSS Found!’) </script>.
The vulnerable signature field would then spit out the message “XSS Found!”. This vulnerability can then be used by the attacker to:
Before we move onto fixing a hacked drupal site, you must have these tools in your toolbox.
Also Read – XSS Cros site scripting Attack – Exploit & Protection
Other tools to scan your hacked Drupal site website:
Drupal Backup Docs or look into free Drupal backup tools such as Backup and Migrate and a Node Squirrel.
Download the same version of known good core files from the version official Drupal repository.
manually updating core files, follow the official upgrade docs for Drupal 8 and Drupal 7.
We recommend reviewing the Drupal Security Docs to learn how.
Your site has been hacked, you are now sure! What to do?
The main goal is to clean up your site and prevent further hacks. For this, several methodologies are possible to manage this crisis, but you can start on the basis of this one:
This phase should allow all actions to be put in place so that none of them are forgotten. It is about documenting:
Before starting an analysis of how your site was hacked, it is imperative to make a copy of all files, the database and the system environment. You can use external storage media for these copies and store them offsite.
As you browse the files, be sure to check for viruses and malware that need to be cleaned. Feel free to create new backups and store them in a different directory. These backups will make it possible to have versions of the site before your cleaning intervention.
So, if you made something worse or broken by wanting to debug, you can go back and undo the changes.
The best is to notify your host as soon as possible. This will allow them to start scanning their own systems and help you in the process of recovering and securing the site.
Scan the servers and the PC to detect contaminated files
Before changing the password of your site, it is necessary to ascertain the origin of the hack. Did this infect the servers or the computer, or both? Several anti-malware and anti-virus tools exist to detect this, like AVG, BitDefender, Malwarebytes, etc.
Consider taking your site offline while the flaw is corrected.
It all depends on the type of site and the number of visitors to it. If it is an e-commerce site, it is imperative to take the site offline to prevent malware and spam from spreading & to safeguard sensitive user data ( payment methods, etc.) Be careful Drupal “Maintenance mode” is not the same as “Offline mode”, as long as your site is online, malware continues to spread.
Close all possible access for hackers
Just cleaning up programs, code, and malware isn’t enough. It is imperative to close all possible access doors to avoid new hacks. Where to look? Here are some elements that must be monitored to optimize security:
Passwords: it is imperative to verify/modify FTP passwords, administrator passwords, etc.
Investigate the attack and identify the source
Now you need to audit your site. You can perform the inspection directly on the infected site version if you do not have a recent backup. Otherwise, it is possible to do a comparative analysis with a test or pre-production environment.
That version is recent enough to compare the code with the version of the online site. In this way, you will be able to track down infected files, malware present on the site, and unauthorized settings. Where to look? Several places need to be carefully inspected:
Check Modifed Files
Often, the backdoors infecting your Drupal site may modify the Drupal core files. File modification of Drupal site can be checked by the following steps:
Connect to your Drupal site via SSH.
Create a new directory using this command:
mkdir drupal-y.x.
Replace ‘y’ with your Drupal series i.e. 7,8,9. and replace ‘x’ with your Drupal release i.e. 4.7.1, 2.1.3, etc.
Navigate to that directory using the command:
Now, extract the tar.gz file using the command:
This command will list all the files modified in the last 20 days. Check the modified dates of the files and if there is anything suspicious, scan that file for malware.
Remove Hidden Backdoors
You will find multiple backdoors of various types in hacked Drupal sites. Backdoors are injected into files like index.php and directories like /modules, /themes, /sites/all/modules, and /sites/all/themes.
Backdoors commonly include the following PHP functions:
Restore the Drupal site
Once you have detected and cleaned up all the malicious code, it is time to restore your Drupal site by repairing all the damage done! Three main options are possible:
Check User Logs
User logs can help you identify any suspicious logging into your site by the hackers. To do so:
Disable Drupal Backdoors
Drupal backdoors can be found hidden in folders like: /modules, /themes, /sites/all/modules, and /sites/all/themes. Detecting them is not easy as often the code may be obfuscated. To find such code, follow the steps mentioned above in “Clean Infected Files and Remove Obfuscated Code”. Also, these backdoors use certain PHP functions.
The Drupal database is often targeted by malware. To clean the database of your infected Drupal site, follow these steps:
Take extra precautions on user data management
It is about putting in place preventive security measures to minimize the risks of a new hack. Several means are possible:
One last check before uploading
Your site is now cleaned and restored, but a final audit is recommended before putting it online to be sure that no malicious code persists . Make sure that preventive security measures have been applied to avoid a new episode!
The process of recovering your site can be long and tedious. To avoid getting your drupal website hacked with malware in 2020-2021, one of the only ways is to take the security of your Drupal site seriously by providing preventive security measures.
You must Perform Drupal security updates, plan regular backups of your site, stay on top of alerts sent by the Drupal community, have a maintenance service center or get in touch with web security experts like WP Hacked Help, We take web security seriously. Apart from cleaning up hacked drupal site we fix hacked wordpress sites, hacked prestashop sites, hacked shopify sites & woocommerce hacked. Get in touch with us today. prevention is better than cure!