Twice this past week we've been alerted to a foreign PHP file added to one of the subfolders under the /sites folder. Shared hosting situation with a knowledgeable company. Came to our attention from Spamhaus DBL listing, which identified the file. First time was Monday.

Ok, Monday, apply all core updates, all module updates, change passwords. Website should be secure.

But same kind of attack happened late yesterday or early today (Wed) (tho different file name into different subfolder location).

The Monday insertion was to a subfolder in our subtheme folder (Genesis), and today's insertion was into a subfolder under the Ctools module.

The logs show a POST entry with the IP address of the offender and the file path to the injected file.

Folder permissions are 755 (rwx r-x r-x) up and down the tree, which is how that hosting company has to do things for Drupal to work (Lightsppd webserver) in that environment.

We do use Webform (latest version) for a short "contact us" form, with a message area. In the Webform configuration page, I did see that the global setting default that allows file uploads "of configurable type" [whatever that means]. So I have disabled that item (we don't need it). The support tech at the hosting company mentioned that some attacks come thru a form submission. But I rather doubt that the Webform module has that kind of security gap.

I deleted the inserted file. The Drupal logs shows four or five IP addresses submitting the file request (now showing in the logs as file not found). Which I'm guessing are mostly other infected computers.

The user logs don't show any unexpected log-ins. Either at the Drupal level or the hosting level. So it doesn't look like a hack of that sort. But I can't figure out how the system allows the file to be written to the locations they have been written to.

The hosting error logs do show attempts to access the .htaccess file, but with an "access denied" result, which is what I would expect. I mention this because this kind of log entry shows in proximity to the POST attacks.

Not sure where to start the troubleshooting or what more to do.

Comments

Stefan Lehmann’s picture

Sounds like your website is another victim of the Drupageddon last year.

There is probably an entry in the menu router table of your website which allows the attacker to deploy arbitrary code on your website.

You basically have to assume, that your whole website / webserver has been compromised from the day this issue was released.

I like cookies!

donm’s picture

Drupageddon: yes, we got hit back in the fall of 2014, and I spent some long hours in December cleaning up from that.

Which I thought had all been done. We did check the menu router table at that time per the recommendations, and found nothing along those lines (or earlier this week, when I checked it again per your suggestion).

However, this Saturday morning, checking the server logs again, there was another insertion attack. Deleted that file, so OK. But what on earth.

Had occasion to download the /sites folder from the server (to check out some new theming ideas). By fluke, decided to first scan the thing with my antivirus checker (Avast), which identified 14 infected files (with PHP BackDoor trojan). Dated back in October and some in November. So obviously left-overs from what must have been two attacks re Drupageddon.

Most were in various module folders, and with various file names. The different date stood out.

But one infected file was for our node.tpl file in our subtheme -- a few lines had been added right at the top of that file. Interesting. Scary.

Hopefully, that got everything now.