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@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@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/ ]



--

--
[ Drupal support list | http://lists.drupal.org/ ]