Drupal - How to tell if my Drupal site is comprised from the SA-CORE-2018-002 -- 2018 March exploit?
How can I tell if someone used this exploit to hack my site?
Your Drupal 7 or 8 site can experience loss or theft of data, data can be removed, deleted or changed, wreaking havoc on the site in many different ways.
See this Stack Exchange post for general information on checking to see if your website has been hacked.
What can they do with this exploit if executed properly?
The exploit is a remote code execution vulnerability, which means any data has the potential of being affected.
This exploit has been given a risk score of 21/25, which is almost the highest that it gets. This risk score also defines the following vulnerabilities, among others:
- AC (Access complexity): easy (no skill) to access and exploit
- A (Authentication): no special authentication needed
- Cl (Confidentiality impact): all non-public data is accessible
- II (Integrity impact): All data can be modified or deleted
Read more about risk scoring and definitions here.
I can't update my Drupal sites now, what is a good alternative to patch up this hole easily?
There is a patch available if you are unable to update core right away. From Drupal.org:
If you are running 7.x, upgrade to Drupal 7.58. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)
If you are running 8.5.x, upgrade to Drupal 8.5.1. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)
To read more, here is an FAQ about the exploit
What could happen
I had a personal Drupal site hacked during Drupalgeddon, an exploit of similar severity (though of a different type). In terms of "what could happen," in that case the hacker put several "back door" files into my codebase (I knew very little about development at the time, and had no Git repository), from which he could send out spam email. The domain involved was blacklisted in spam filters, and it was a huge mess to be able to send email from that domain for the several months I had kept it afterward.
Since this vulnerability permits remote code execution, the attacker could presumably install modules to carry out phishing attacks, carry out commands on the command line with php exec(), steal passwords, and thereby compromise much of your server. The damage could range from something as simple as your machine being recruited as a spam engine or botnet node, or if you have sensitive information, the attacker might steal it and either resell it or blackmail you, depending on the information and the attacker's motives.
How to tell if you've been hacked
Most of the time, your site will not be defaced. When two groups of 14 year old script kiddies go at each other you might see a site defaced with Goatse images (NSFW), but unless the hacker has something against you personally he isn't going to do this. The goal for the hacker is either money or the ability to commit crimes with someone else's computer.
Now with that in mind, common things you will see are new users being created (especially admin users), and in the logs you may see a particular IP sending only one type of (abnormal) request. In the Drupalgeddon case, I was able to figure it out by seeing POST requests to a php file in my access log.
If you cannot patch your site right away
If you cannot patch the site now, I would recommend cutting the apache/nginx server so no one can get to your site. Or, have the server direct all traffic to an HTML page explaining you are down for maintenance, aka "hard maintenance mode." In all cases, you do not want to allow a visitor to have any shot at bootstrapping Drupal, until you can get an upgrade or patch in place.
And thinking back to my site getting hacked, remember that the first Drupalgeddon attacks started 7 hours after the release, and it was in the form of a script that auto-hacked thousands of sites. Move quickly!
If you are hacked
Hopefully you have a backup, in which case the best bet is to "nuke the whole site from orbit" and start over with a new server. I did a manual DB and file audit once because I didn't have Git and regular backups in place - it takes a very long time, but if it does happen, take a deep breath, and learn Git and learn how to set up a proper backup environment. If you have a business and its a customer site, tell them the truth up front. You will probably lose them, but better to lose a customer (you can get new ones) than your reputation.