Drupal Sites Used in Cryptojacking

[engine]

Over 300 Drupal sites are being used in the Drupalgeddon2 RCE flaws.
Update your Drupal CMS now!

...hundreds of compromised Drupal sites being used to host "cryptojacking" malware that uses the CPUs of visitors to mine cryptocurrency via CoinHive.

[theregister.co.uk...]

Earlier story
Important Drupal Release on March 28 [webmasterworld.com]

[TorontoBoy]

Old versions of any software would eventually have vulnerabilities, no fixes and probably get repeatedly hacked. Vulnerabilities go into a vulnerability database. The hacking tool targets a specific site with known software, the vulnerability will automatically come up. Easy peasy to match the vulnerability to the site and you get hacked.

Wordpress took a different route and has always upgraded from the previous version. Drupal took the "clean slate" approach to a new version, which has always bothered me.

Here are the two vulnerability database entries for this cryptojacking: CVE-2018-7600 and CVE-2018-7602. Software cannot stand still.

[explorador]

ergophone: PS - you could run Drupal 7 indefinitely. If your backup and system audit tools are good enough, so what if you get hacked? If you don't have PCI or HIPPA considerations, restore from backup :-)

That's exactly what someone is doing on a project. I built that site (never hacked), left the company 5 years ago, long story short they keep it on Drupal, never got someone skilled on Drupal to perform updates, yes it lacks updates specially on security. I only used basic modules, nothing weird.

- The website was hacked quite often by diff people.
- They never fixed the site security hole(s).
- I suspect lazy admin security, new (unneeded editor/admin) profiles were added.
- 2 years ago only the same type of hacking has been performed (posting tv shows and links).
- It comes obvious to me its the same guy/team always finding the same flaw... they do the same.

The guys admin the site just restore the backup and add content. Always wondered what would happen if I got a site with some old CMS that was forgotten with no security updates, I thought on that: backup and restore. I couldn't keep my head straight on that concern so I took another path.

What to do with some old forgotten CMS? I never did this with Drupal, it's just that I moved to another job. But I did this with Wordpress. Drupal and Wordpress are diff animals but I think I have a point here. This old website WP based got some updates, it's a small website, actually abandoned by the client who refuses to close it but also doesn't post updates. WP moved on so fast I can't update the site to the latest version (it breaks the site) similar to what's happening with Drupal, it demands a total rewrite.

But PHP has changed, and many things started to fail on this site. The result by living with such an old website with dead CMS version has been issues and more issues. The solution has been easy: choosing specific version of PHP for the site. I know I will have to work on it eventually, it's a never ending work.

[ergophobe]

I had a Drupal 6 site that stayed on Drupal 6 well past the security releases. I wasn't happy about the situation, but it just was a fact of life. Much to my surprise, it plugged along for quite some time without getting hacked. Over a year I think.

On a couple of hobby sites that I wasn't quite ready to delete and was definitely not going to upgrade, I just ran some wget archiving scripts and put up a static version. If you don't need user comments and such, you can have a walled off version where you have additional authentication for all contributors (if possible, a whitelist of IPs) and you have an "editing" version and then periodically export to the live version.

I suppose if you wanted to get fancy with cron and rsync, you could even automate it.

I'm not saying any of this is a good idea. Don't get me wrong. Generally, these are kludgy, problematic, constant headache, terrible ideas.

But if you have to get by until you can migrate, it's a possibility.

[TorontoBoy]

Yes, a static site generator from a Drupal site might work pretty well, and would be difficult to hack. They are a bit cludgy, but you can always refresh the static site.

[LifeinAsia]

restore from backup

That advice works okay for general sites, but not so much for sites with a lot of UGC. Especially if it's been multiple backups since the hack.

Well, if the hack is in the file system, then yes- pretty easy to recover with a backup of the file system. But if the hack is in the DB, then it's a new order of complication.

[ergophobe]

Yes, it definitely will not work for your sites. It would be a short-term stopgap for you at best.

I should have been more careful in what I was saying. In my experience, which is just a couple of sites, catastrophe did NOT hit the day Drupal 6 hit EOL. It took me considerably past Drupal 6 EOL to get sites migrated - some to Drupal 7, some to Wordpress, one to Shopify.

But in the meantime, the D6 sites plugged along and were not immediately hacked and thrashed. The situation made me nervous the whole time, BUT with regular code and DB backups that truly got moved to another server on sites a low volume of UGC, I limped through, depending on my backups to save me if I got hacked before I got migrated.

[TorontoBoy]

msf > search drupal

Matching Modules
================
-Name -Disclosure Date -Rank -Description
---- --------------- ---- -----------
auxiliary/gather/drupal_openid_xxe 2012-10-17 normal Drupal OpenID External Entity Injection
auxiliary/scanner/http/drupal_views_user_enum 2010-07-02 normal Drupal Views Module Users Enumeration
exploit/multi/http/drupal_drupageddon 2014-10-15 excellent Drupal HTTP Parameter Key/Value SQL Injection
exploit/unix/webapp/drupal_coder_exec 2016-07-13 excellent Drupal CODER Module Remote Command Execution
exploit/unix/webapp/drupal_drupalgeddon2 2018-03-28 excellent Drupal Drupalgeddon 2 Forms API Property Injection
exploit/unix/webapp/drupal_restws_exec 2016-07-13 excellent Drupal RESTWS Module Remote PHP Code Execution
exploit/unix/webapp/php_xmlrpc_eval 2005-06-29 excellent PHP XML-RPC Arbitrary Code Execution

Just for fun, looked up the current Drupal exploits in the exploit db. There are only a few. I did not search for the required hack, but it should be easily found. These exploits are open source.

While there are only 7 Drupal exploits, in sharp contrast there are 73 for Wordpress. I advise to plug all security holes, stat. My bet is still on Drupal for security.

Vulnerabilities search: There are 293 Drupal vulnerabilities [rapid7.com...]

[ergophobe]

And look at the exploits
- one is for the Coder module, which you shouldn't really have on a production site anyway
- one is for XML RPC, which most people have turned off and in any case, that's from 2005. If you haven't updated since 2005, you've got all kinds of trouble (for one, you're probably stuck on versions of PHP that have unpatched exploits even if you patch Drupal)
- one is for OpenID, which most people have turned off

Beyond that, you would have to look at the details. Views exploit would depend on what component of Views and whether or not you need elevated privileges.

I wonder, though, how many of the WP exploits are for old versions. Early Wordpress was so bad, but I think it's a lot better now.

[TorontoBoy]

It would be easy for me to research the Drupalgeddon 2 exploit to see how to set it up. Then I could run it against any number of Drupal sites.

The vulnerabilities are all dated with the year. I did not notice the WP dates as there were 2-3 screens worth.