Malware on D7 website - Blacklisted by Google

Question

I want to tell you about the malware attack to my Drupal website. Not just for your suggestions but also to create something helpful to anybody tha could suffer for the same problems. Well...

---

INITIAL SETUP

• Drupal 7.9
• Activated modules:
  • CORE: Block, Contextual links, Database logging, Field, Field SQL storage, Field UI, File, Filter, Image, List, Locale, Menu, Node, Number, Options, Overlay, Path, PHP Filter, RDF, System, Taxonomy, Text, Toolbar, User
  • CCK: Multiselectd
  • CHAOS TOOL SUITE: Chaos tools
  • DATA/ORA: Calendar, Date, Date API, Date Popup, Date views
  • FIELDS: Email, Field permission, Link
  • OTHER: Google Plus One +1, Pathauto, Token, Weight
  • SHARING: Share this, Share this block
  • TAXONOMY MENU: Taxonomy menu
  • VIEWS: Views, Views PDF Display, Views PHP, Views UI
  • OTHER MODULES THAT I REMOVED: CKEDITOR, VIEWS_SLIDESHOW, IMCE, DOMPDF, PRINT, WYSIWIG

---

MY SETUP ERRORS

• In order to satisfy the custome, I modified some of the modules and I've never update them (AUCH!)
• The customer was in posses of the login data, and maybe his computer wasn't safe (MMM...)
• I didn't have a copy of the webiste, because I trusted on the provider weekly backup (DOH!)

---

ATTACK EXTERNAL SYMPTOMS

• All the link of the homepage redirected to a malware website
• Google blacklisted the website
• Critical alert on the Google Webmaster Tools panel

---

FTP SYMPTOMS

• Lots of "strange" files: mainma3.php (I found this one in every folder!), functoins.php, sum75.html, wlc.html, aol.zip, chase.zip, chaseverification.zip, 501830549263.php, wp-conf.php and a dozen of wtmXXXXn.php (dove X = numero) in the root folder. All these files was plenty of malicious functions (unescape, base64_decode, eval, etc.)
• Install.php was modified with a long line of malicious code
• To EVERY javascript files was appended this line of code: ;document.write('');
• The weekly backup was also infeceted
• Dozen of repeated "strange" request, found on the Drupal log panel (my domain is obscured with the string "-----"):
  • index.php?q=ckeditor/xss > Notice: Undefined offset: 5 in eval() (linea 29 di /web/htdocs/-----/home/modules/php/php.module(74) : eval()'d code(1) : eval()'d code).
  • -----/user?destination=node/add > Failed login by shadowke
  • calendar/week/2012-W19?year=2011&mini=2012-12 > page not found
  • misc/]};P.optgroup=P.option;P.tbody=P.tfoot=P.colgroup=P.caption=P.thead;P.th=P.td;if(!c.support.htmlSerialize)P._default=[1, > page not found
  • misc/)h.html(f?c( > page not found
  • mail.htm > page not found

---

RECOVER [Thank to this article: http://25yearsofprogramming.com/blog/20070705.htm]

1. I've put the website on Maintanance mode (error503.php + .htaccess). Traffic open just for my IP Address [see this useful guide: http://25yearsofprogramming.com/blog/20070704.htm]
2. I've downloaded the whole website in local
3. I've searched and removed the strange files > I found forty of them
4. I've searched the files for these worlds [with the freeware AGENT RANSACK]: eval(base64_decode($POST["php"])), eval(, eval (, base64, document.write, iframe, unescape, var div_colors, var _0x, CoreLibrariesHandler, pingnow, serchbot, km0ae9gr6m, c3284d, upd.php, timthumb. > I've acted in one of the follow ways: a) I've replaced eval with php_eval() (the eval safe version of drupal); b) I've wrote down the suspected modules; c) I've compared the code with the fresh downloaded module; d) I've removed all the malicious code (see the javascript mentioned above)
5. I've searched for mohanges in the file system [with the freeware WINMERGE]
6. I've identifyed some suspected modules, thank to the list written at the point 4 above, and thank to some researches on Google (name_of_the_module security issue, name_of_the_module hacked, etc...) and on Secunia [http://secunia.com/community/advisories/search]
7. I've scan my computer (Avast, Search&Destroy, Malwarebytes Antimalware) > I didn't found any virus or spyware
8. I've changed all the logins (ftp, cpanel, drupal admin panel)
9. I've reloaded the whole website
10. I've removed all the suspected modules: CKEDITOR, VIEWS_SLIDEWHOW, PRINT, DOMPDF, IMCE, CAPTCHA, WYSIWIG, WEBFORM.
11. I've tell the whole story to the provider assistance
12. I request Google for a revision (they did it in 12 hours)

---

DRUPAL LOG NOW

dozen of these messages - wtm4698n.php?showimg=1&cookies=1 > page not found - fhd42i3d.html > page not found - wp-conf.php?t2471n=1 > page not found - -----/user?destination=node/add > Failed login by Elovogue

---

LESSONS LEARNED

• Never touch the modules, so you can update them
• Keep all the login in a safe computer / Use a safe computer to work on the FTP
• Search for any security issue before installing a module
• Keep a clean copy of the website somewhere

---

MY QUESTIONS:

• What kind of attack I've received?
• There are other unsure module in my installation?
• What can I do yet?

Thanks to everybody for your patience!

Answer 1

What kind of attack I've received?

It's really hard to say. It could be a desktop virus, or a php execution via one of the modules (or insecure configuration). It's good that you seem to have blocked it.

There are other unsure module in my installation?

You should download a "good" copy of each module from drupal.org and compare them. If you haven't yet, put the whole site in revision control (git) and make the live site a checkout from git so you can quickly see "git status" if anything is changed and then "git reset --hard origin/master" to undo the changes.

What can I do yet?

In addition to the git idea, I suggest installing and running http://drupal.org/project/security_review which may have some suggetsions. Another potential helper is: http://drupal.org/project/paranoia

Answer 2

"Never touch the modules, so you can update them" There are often situation where you have to patch modules to fix bugs or add features that aren't in the latest stable release. This practice is generally ok as long as you are careful.

Always use version control as it helps you keep track of changes you have made, as well as changes someone else might have sneakily made.

I also recommend including a patch file of the changes in the module directory, which allows you to see at a glance if a module has been modified and what the changes were.

Also commit the patch file to version control. The patch file also makes things easier when updating the module as it can often be reapplied after the update (sometimes if it doesn't apply to the new version you have to manually apply and re-create the patch).

Make sure the patch file name includes the drupal.org issue node id and comment id, so that you can easily check the progress of the issue that the patch addresses, so you can see if the new version of the module already includes the patch or not and you can get a newer version of the patch if there is one.

Keep all the login in a safe computer / Use a safe computer to work on the FTP

Yes. Also, use SFTP or SSH to connect to the server.

Search for any security issue before installing a module

This is generally not something you can do. If you have the latest stable release of a module you should have the most secure. There is no way to see security issues for a module that have not been fixed yet (or it would be easier for people to exploit them). The exception to this are modules without a full release, like dev versions and betas, etc. These modules don't go through the same security processes so they can have security issues posted in the public issue queue. However, even in this case if you have the latest version you should have the most secure version.

Keep a clean copy of the website somewhere

Yes. This comes down to version control again. If you have the code in a version control repository you have a clean version of the code. You should also keep offsite backups of the database and non-version-controlled files. The idea is you can fully restore a site in the case of emergency and hopefully never lose more than 24 hours of data (or less if you run backups more often).

Also, don't rely on general webhost backups. Do your own backups to a different server where possible. I recently had an incident where the hosting provider had a server issue that took down MySQL, corrupting databases on a bunch of servers. The nightly backups then happened after that, so the nightly backups were also corrupted. So the data restored was in some cases a week old.

This kind of thing can happen with any hosting, however in theory should happen less with more high end hosting. In this case if you take your own offsite backups you can avoid troubles.

It is possible for your backups to have problems too but if you have 2 lots of backups in different places you are much safer.

What kind of attack I've received?

As greggles says, there are so many possibilities that we can't know the answer to this. Your hosting provider may be able to find out though.

There are other unsure module in my installation?

As mentioned, version control can easily allow you to see what has been hacked. Aside from that, you could download all the same versions of the modules and drupal core and compare them to yours using diff or a similar command. Then you can review all the differences and see if they are your customisations or something a hacker has done.

It could be a long process but it's good to be absolutely sure.

As for potentially dangerous modules, all you can do is use the latest version of all modules, as they will generally be the safest. There are still always more security issues found though so you must keep them up to date. The security team sends out notices about security updates.

You can also check out https://drupal.org/security, which has 3 tabs of security related information for contrib and drupal core.

What can I do yet?

Here are some things (there are plenty more):

• Make sure you always keep your drupal modules up to date.
• If you are doing custom development make sure to get up to speed with secure coding practices for drupal & PHP and other related web technologies. A good place to start is Writing secure code.
• Keep your server software up to date (if you have control over that).
• Always use secure connections like SFTP to access the server.
• Always use strong passwords and don't reuse passwords.
• Give user 1 a unique username, not "admin" or similar.
• Don't give the user 1 drupal account out to others, if admins need a higher level of access set up a role for them and give them only what they need.
• If there are other user admins use the userprotect module to keep user 1 safe.
• There are a bunch of other modules for better passwords and roles/access control management that might be useful depending on the website.

Answer 3

I'd add: 1) don't use FTP. 2) use version control on the server so you know what code you put there. 3) don't hack core or contributed modules and make sure to subscribe to security updates. 4) ensure you have set your file permissions on your server correctly so that Apache is limited to what files it can write to.

Answer 4

What kind of attack I've received?

If your server was not exposed, most likely it was some remote injection exploit which worked over a network which exploits the security vulnerability without any prior access to the vulnerable system (e.g. SQL injection, XSS, etc.).

Example scenario:

1. Your hosting provider sends you the message that your site has been blocked, because it found a lot of IP addresses are visiting some particular file (e.g. /en/printmail/123).
2. You identified that this may be caused by Print module, so you've to check which version currently you've.

3. This helped you to find the right security advisory, e.g. SA-CONTRIB-2012-057 which says:

   • Security risk: Moderately critical
   • Exploitable from: Remote
   • Vulnerability: Cross Site Scripting

4. Then you know what kind of attack you had and you can start from there knowing the risk by knowing what happened and address the problem.

See also: How to remove malicious scripts from admin pages after being hacked?

There are other unsure module in my installation?

Try to not installing modules which are less popular therefore not tested properly. Especially when they're executing some dynamic code or they've their own custom code instead of using Drupal API properly or using custom SQL queries instead of using proper API and PDO.

What can I do yet?

Once you've removed malware, you should:

• keep your Drupal core and all modules up-to-date,
• keep up-to-date with Drupal Security Advisories & related news (Twitter),
• keep up-to-date with your system packages (e.g. apt-get update),
• make sure your PHP and web server is up-to-date and configured properly,

• make sure your file permissions are correct,

  See: What are the recommended directory permissions?,

• monitor Drupal watchdog and system logs for any suspicious behaviour,

• install Hacked module to monitor integrity of modules,
• use some security monitoring tool (like Nagios) to monitor your website,
• avoid using Drupal PHP filters/modules and similar (which allows injection of dynamic code),
• never keep PHP code in your database (like in blocks or views),
• disable development modules (like Devel),
• keep learning about recent vulnerabilities to be up-to-date with technology,
• and so on.