8 Things to Know About the Drupal Security Issue

autoupdate or die

By now you’ve probably heard about the extremely serious Drupal security issue from mid-October.

The Drupal security team issued a new warning two weeks later that, if possible, escalated the severity of the issue.

Here’s an overview of the issue and its impact.

1) How serious was this?

As bad as it gets.

The Drupal team rated this security issue as 25/25. Most Drupal security issues have a rating of around 12 or 13 and only impact a limited number of sites and pose limited danger. This issue impacted every Drupal 7 site and could lead to sites being completely taken over.

It also proved to be a relatively easy bug to attack. Sometimes it takes days or weeks for hackers to find out how to exploit a new vulnerability. This time exploits were being used in less than 7 hours. According to the Drupal team, you needed to update between 4 pm and 11 pm UTC (London time) on October 15th.

My guess is anyone on a big name Drupal host (Acquia, Pantheon, BlackMesh etc) is safe because those companies rolled out fixes quickly. But if your site is on an average hosting service and you didn’t respond inside 7 hours, you may be in trouble.

2) When did all this happen?

  • November 2013: the issue was reported as a feature request, but not escalated to the Drupal security team.
  • September, 2014: the security team get a report of the bug from SektionEins, a German company who discovered it while auditing a client site.
  • October 15, 2014: the issue was officially announced.
  • October 29, 2014: there was a follow-up advisory. This didn’t reveal any new issues, but it did emphasize how dangerous the original issue was. This is the point where the internet had a collective freak-out.

3) Where was the security issue?

The problem was in this file: /includes/database/database.inc. Here’s the old, vulnerable code, starting at line 735:

media_1413467719444.png

Here’s the new, safer code, again starting about line 735:

media_1413467798927.png

So, fixing the issue was as simple as replacing this line in database.inc:

foreach ($data as $i => $value) {

with this line:

foreach (array_values($data) as $i => $value) {

4) Why was that one line of code so dangerous?

Anthony Ferrara has a detailed technical explanation.

The short version is that hackers were able to exploit that one line to access to the databases of vulnerable sites.

Once inside the database, the hackers had several techniques. One popular option involved creating administrator accounts. They then enabled the PHP module which allowed them to write code directly to the site’s files. The PHP module has been removed from Drupal 8 to prevent exactly this kind of attack.

5) Who is doing the hacking?

Acquia, Pantheon and RiskIQ all point the finger at Russian hackers. RiskIQ describes the origin as:

“a large Russian datacenter operator, and a common source of Eastern European cybercrime activity”.

A Reddit user also pinpoints Chinese and Tor sources.

These are your common, run-of-the-mill hackers who are infecting Drupal, WordPress, Joomla, phpBB3 and other software on a daily basis. This Drupal issue was just an unusually good opportunity for them.

6) What are the hackers doing with infected sites?

RiskIQ say that many of the infected sites are driving people to download malware and in particular an “RIG Exploit Kit”. This is a common attack that isn’t Drupal-specific:

“The same RIG infrastructure is also receiving traffic from sites running WordPress, with similar compromise patterns.”

What is an RIG Exploit Kit? According to Kahu Security, it contains a variety of malware that attacks old versions of Internet Explorer, Java, Flash and Silverlight.

However, Acquia say that some infected sites won’t be used by the hackers until later:

“We could not find any query intended to change the content or destroy sites: attackers were only interested in installing backdoors to take over the site or server at a later point in time, and make the intrusion unnoticeable.”

 

7) How many websites were hacked?

The BBC said, “Up to 12 million websites may have been compromised“. That number has now spread like wildfire around the web. Unfortunately, it’s an absurd statistic and never should have been published.

The BBC report relied on some really bad analysis from Sophos.com. Here’s how Sophos seems to have arrived at their estimate:

  • First, they said there are 1 billion websites in total, using Netcraft as a reference.
  • Next, they looked at W3Techs which shows Drupal powering between 1.9% of all websites. So they calculated 1.9% of 1 billion, which gives 19 million.
  • Finally, they used the W3Techs estimate that 65% of Drupal sites are using Drupal 7. Calculating 65% of 19 million produces the final estimate of 12 million.

Every stage in that calculation uses bad statistics that are contradicted by other sources. So, if we can’t trust the widely reported figure of 12 million, what can we know for sure about this size of this security issue?

Drupal.org reports that there are less than a million Drupal 7 websites in total. Yes, it’s true that those statistics come from Drupal sites using the Update module and some of the larger, more professionally sites disable Update when they go live. But despite that, it’s hard to imagine there are enough sites that disable the Update module to push the Drupal 7 total far beyond 1 million. BuiltWith.com puts the entire Drupal ecosystem at only 780,000 sites.

So, if there are around 1 million sites on Drupal 7, how many were hacked?

Bevan Rudge estimated “between ten and ninety percent of all Drupal websites” were hacked. That’s such a broad range that Beven is essentially saying, “we don’t know”, which is honest.

My conclusion: it’s hard to say anything more accurate than this problem extends to “10,000’s or possibly 100,000’s of sites”.

8) Were any famous sites hit?

RiskIQ has a rundown of some of the larger sites that were impacted:

  • Popsci.com
  • Homestead.com
  • Typepad.com
  • Spin.com
  • Advertise.com

I’ve seen a few people wondering if this incident was related to the WhiteHouse computers being hacked a few weeks ago. WhiteHouse.gov and related sites do run Drupal 7. Yes, some government sites including one from the state of Indiana. However, security experts in the Drupal community knew about this issue before it was released, and it’s hard to believe the White House team weren’t able to protect their sites in time.

Author

  • Steve Burge

    Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

0 0 votes
Article Rating
Subscribe
Notify of
11 Comments
Oldest
Newest
Inline Feedbacks
View all comments
hans
hans
9 years ago

“November 2013: the issue was reported as a bug”: should be “November 2013: the issue was reported as a feature request”.
It really makes a big difference because at that time there were no more feature requests accepted for Drupal 7 core.
Also it was not reported to the security team as a security bug.

steve
steve
9 years ago
Reply to  hans

Hi Hans. Yes, you probably described that better than me. I wasn’t 100% sure how to best describe how that report was handled.

Bevan Rudge
Bevan Rudge
9 years ago

“it’s hard to believe the White House team weren’t able to protect their sites in time.”
I agree. However I did see some tweets alluring to vulnerable .gov Drupal websites sometime after 15 October. I can’t find them now unfortunately, since [url=http://Twitter.com]Twitter.com[/url] no longer makes it easy to find archived tweets.

steve
steve
9 years ago
Reply to  Bevan Rudge

Yes, I suspect that’s something else to file under, “We’ll probably never know.”
It’s likely that quite a few .gov sites were vulnerable given the speed of the hack and the slow speed that many government IT departments move.

Paul Booker
Paul Booker
9 years ago

However, Acquia say that some infected sites won’t be used by the hackers until later:
“We could not find any query intended to change the content or destroy sites: attackers were only interested in installing backdoors to take over the site or server at a later point in time, and make the intrusion unnoticeable.”
This is probably the silver lining, if any, for the website owner who didn’t fix the vulnerability in time. However for the website user ..

steve
steve
9 years ago
Reply to  Paul Booker

Good point. We’ve seen reports of some hackers actually patching the security flaw after themselves so no-one else can get in.

kepford
kepford
9 years ago

Steve, you should be writing for the BBC. Excellent coverage of this topic in plain english.

steve
steve
9 years ago
Reply to  kepford

Thanks Bob, although I’m not sure that’s a compliment after their article here 🙂 Their Drupal coverage was extremely lazy.

Pete
Pete
9 years ago

Quick help for people without backups etc – quick typeup of what we did may need some fixing its just off the top of my head 🙂
#!/bin/sh

echo “Drupal Base:”

read base

echo “Day before day Patched (YYYY-MM-DD):”

read patched

#Remove php files in files folder – only good if you dont use your files folder for php files

find $base/sites/default/files/ -name “*.php” -exec rm -f {} \;

#find known backdoor

grep -r –include=*.php “PCT4BA6” $base | xargs rm

#find base64 used to hide backdoors – This should only return a small amount just check the files dont look like hack

grep -r –include=*.php “base64” $base

#find strtolower used to hide backdoors – This should only return a small amount just check the files dont look like hack

grep -r –include=*.php “strtolower” $base

#find eval used to hide backdoors – This should only return a small amount just check the files dont look like hack

grep -r –include=*.php “eval” $base

#find string in known backdoors – This should only return a small amount just check the files dont look like hack

grep -r –include=*.php “ncfe288” $base

#find strtoupper used to hide backdoors – This should only return a small amount just check the files dont look like hack

grep -r –include=*.php “strtoupper” $base

#find making backdoors – This should only return a small amount just check the files dont look like hack

grep -r –include=*.php “file_get_contents” $base

grep -r –include=*.php “file_put_contents” $base

#find files editited between launch of hack and your patch

find $base -type f -name “*.php” -newermt 2014-11-15 ! -newermt $patched
#Search Database for any of the above to make sure its not in the DB, also delete users with added perms and remove the added roles
#END no guarantees this has got it all but its a good start anyone who can add or improve please do

Casper Vanish
Casper Vanish
8 years ago

I am a victim of such attacks, now my site is completely offline, & Am also pointing my finger on Russian Hackers with evidence of incoming activity from that such location (my website is full of trackers that record data such as location, OS &Even The Browser Thier Using Also their IP Addresses From My Advanced Hosting Infrastructure) but not to worry my site is completely restore able (thank God my sql database was not compromised)

Bevan Rudge
Bevan Rudge
8 years ago
Reply to  Casper Vanish

If you think your database is safe then your audit failed. This is a SQL injection vulnerability/attack. By definition, the database is compromised.
Your only solutions are to rebuild from scratch or restore from a backup from before the vulnerability was announced.

11
0
Would love your thoughts, please comment.x
()
x