[support] Drupal site hacked - new php files injected

Alexander Arul alexander.arul at gmail.com
Wed Oct 29 10:00:31 UTC 2014


Looks like they were able to break into the web server layer at least and
inject server executable files. It was probably an automated script. So
maybe they did not get hold of server level access or database access.
However still, the break-in could have happened from many angles, not just
Drupal (web application).

1. You need to secure your entire server stack:
- Operating system (did you update for the shellshock bug?)
  - What's your OS? You should ask this in that OS's security forum also..
  - How strong is your password? Do you allow remote root access?

- Web server
 - Subdomains, ports .. do you have any "private testing" subdomains that
might have lower security? Exposed buggy code?

- Database
 - Do you allow remote access?
 - Password strength?
 - How many human users have access?

- Do all applications share the same credentials to the database?
-- If there's an sql injection hole in one web app, the attacker might have
used the shared password to gain access into Drupal. So you have to isolate
all apps to individual restricted credentials.
-- Is there any db user credentials with global privileges? Apps using that
kind of privileges are suspect ..

- What other non-standard server applications did you install?

- What other web applications did you install?
-- Use strong httpwd password screens to restrict access to every web
facing application. Things like phpmyadmin can have vulnerabilities that
haven't even been published. Even without password, some applications can
grant access to data & database credentials.

- How about file permissions? Did you ever do chmod 777 anywhere
(especially web folders)? That would allow write access to anyone to that
file/folder, so they can inject a shell script and run commands.

- Drupal itself:
-- Did you write any custom code?
-- Did you install any 3rd party modules / themes etc?

- PHP
-- You need to secure your php by disabling dangerous functions etc.

2. Above are all considerations for just your machine. The attack could
have come from another machine that has privileged access to your server
also.

- Do an nmap. See what ports are available to internet. Remove everything
that's not essential, secure everything else.

3. If your server was used for spamming, it's probably blacklisted - check
with senderscore, spamhaus etc. Use emailsecuritygrader.com etc to check
all your domains.

4. You need to trace back to when the files were modified, and when the
attacker gained access. Check ssh logs, httpd logs, mail logs, git logs
etc. Maybe your server host can help to pinpoint suspicious traffic.

So I'd first trace back to the first scanning attempts by the attacker.
That might give you a clue as to how he eventually succeeded. Perhaps he
used a consistent group of IPs that you can pull out from your logs..

Best Regards
Alex


On 29 October 2014 17:12, Naveen Valecha <er.naveenvalecha at gmail.com> wrote:

> For more about securing file permissions
> https://www.drupal.org/node/244924
>
> On Wed, Oct 29, 2014 at 1:25 PM, Don <donald at fane.com> wrote:
>
>>  In addition to updating core and and contributed modules, I'd look at
>> how permissions are set up too.
>> Since i don't update from the admin panel, the only files that can be
>> added or changed are in /sites/default/files. You could probably make this
>> harder to figure out by changing the names a bit.
>>
>> I run apache webserver under user 'apache2' and giving write permissions
>> only in those directories. The other files are owned by a user and a team
>> group account.
>>
>> I wonder if you could do some more magic by not letting *.php files in
>> /sites/default/files be run but downloaded only?
>>
>> --
>> -Don Pickerel-
>> Fane Software
>>
>>
>> On 10/29/2014 3:17 AM, Ahilan Rajan wrote:
>>
>>  Hi,
>>
>> I had installed drupal 7.21 to run a simple website on my server. All
>> seemed well till one day last week I started getting huge amount of
>> spam emails from the server which was hosting the website.
>>
>> On further analysis of the postfix mail queue on the server, I found
>> all the emails were generated by TWO php files (css76.php in the
>> modules/panels/js directory and session.php in the
>> sites/all/libraries/jquery.cycle directory) . These two files were
>> NEWLY created/injected files and seemed bogus containing a number of
>> symbols along with a base64_decode return statement.
>>
>> Clearly my drupal setup had been hacked and someone had successfully
>> injected these files to send spam email (amongst other things I
>> presume)
>>
>> I shutdown the site, installed Security Review and Hacked modules and
>> carried out their recommendations and also checked my file permissions
>> via recommended scripts.
>>
>> However I am still not sure what the entry point for this hack was in
>> my setup and whether I am fully secure yet in this setup. Any
>> suggestions or points in this regard would be highly appreciated.
>>
>> thanks
>> Drupal Newbie
>>
>>
>>
>>
>>
>> --
>>
>> --
>> -Don Pickerel-
>> Fane Software
>>
>>
>> --
>> [ Drupal support list | http://lists.drupal.org/ ]
>>
>
>
>
> --
> Naveen valecha
> Web : http://valechatech.com
> Twitter: http://twitter.com/NaveenValechaNV
>
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20141029/ee9afa0d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fane-th.png
Type: image/png
Size: 18361 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/support/attachments/20141029/ee9afa0d/attachment-0001.png 


More information about the support mailing list