Hi All,
I recently received an email from my host (Arvixe) stating that they had disabled a script on one of my D7 sandbox sites due to large quantities of spam email emanating from there.
Upon investigation I found an encrypted PHP file called "sql91.php" in my modules/field/modules/options folder. I later discovered a second bogus file called "sraynr.php" in a different folder. Both of these files have been called from Russian IP addresses:
146.185.239.52
146.185.239.51
I'm curious as to what was most likely leveraged in order to create these files. I had a basic (but not ridiculous) password in place on Drupal, and an 8 character randomly generated password on the hosting/cpanel. So whilst I certainly wouldn't rule out password breach it seems unlikely.
As it's a sandbox site I've not bothered to do the usual safety checks, and am wondering what possible avenues could be exploited to get a custom PHP script embedded into the codebase.
I'm going to leave the site up as is (except I've changed the password) as bait to try and glean more info. Will report anything I find.
Any thoughts and comments would be much appreciated.
Cheers!
BC
| Attachment | Size |
|---|---|
| sraynr.txt | 3.43 KB |
| sql91.txt | 18.96 KB |
| sray.png | 19.34 KB |
Comments
Have you upgraded?
Have you upgraded your drupal core to 7.32 per https://www.drupal.org/SA-CORE-2014-005
This was released on October 15, 2014. There have been attacks on sites that were not updated and I would wonder if your site is one of the ones exploited. The attacks are silent and attackers don't need to log into your site to exploit it.
Good question! I've updated
Good question!
I've updated my productions sites but not this one. So it seems likely this was their 'in' given the nature of the breach.
In this case the attackers have (as far as I know) only leveraged the exploit for spamming purposes, but if they can get a custom PHP script in like this they could do anything.
Could be catastrophic for sites that store sensitive customer information.
Timely reminder to make sure your sites are up to date and that all security best practices have been followed!
I'm glad I keep all my sandbox sites and production sites isolated from each other, otherwise today could be a very long day :)
Thanks.
BC
I use an apache password as a
I use an apache password as a first line of defense on my development sites. That way I can focus on updates to live sites first.
Nice. I run my important
Nice.
I run my important sites from Pantheon and have password protection on the dev sites there - never bothered with the ones on my shared hosting though as they're just experimental. After this though it may be a good idea.
I'm also considering blocking IP ranges for geographical regions from which I wouldn't expect any traffic - i.e. most of my sites are local Australian ones so there's no reason why anyone from Russia or Nigeria would be visiting.
Sounds good in theory but I need to research the possible impact on SEO etc. Could be harmful if search spiders live in other countries.
Might also look at banning IPs that try to hit things like "/wp-admin" - no human user would do that.
BC
A practical guide to blocking
A practical guide to blocking IP ranges, dodgy urls such as wp-admin would be useful. A kind of cookbook how to get rid of some of the annoying entries you get in the logs with advice on any likely seo impact. Any one know if such a thing exists?
Blocking ranges in your firewall
I did a blog post on how to block ranges in the firewall.
But you need to install software.
For anyone who wants this here is the link: http://www.wiredpea.com/article/firewalling-everyone-china-and-ukraine
Look at this post on Drupal
Look at this post on Drupal Answers: http://drupal.stackexchange.com/questions/54159/how-to-deal-with-someone...
If you have access to install software on your server, you might consider ConfigServer Firewall (CSF) as well. There are plenty of guides on the web.
Clear signature of SA-CORE-2014-005
This looks a lot like a signature of SA-CORE-2014-005. Please assume your site and server has been compromised (and thus any site hosted on that server too). You should go through the usual process:
- https://www.drupal.org/node/2357241
- https://github.com/greggles/cracking-drupal/blob/master/after-an-exploit.md
- http://drupal.geek.nz/blog/your-drupal-websites-backdoor
EDIT: that also means your docroot was writable by the webserver, which is not recommended.
Permissions
See also Securing file permissions and ownership.
Thanks for useful link...
Thanks for useful link...
check permissions as mpdonadio mentioned
Check permissions as @mpdonadio mentioned.
Also remove read permissions from the CHANGELOG.txt
chmod a-r CHANGELOG.txt
sometimes we don't update our websites as the drupal update came.So spamers can check version of our drupal using changelog.txt and may try to attack on the website with the vulnerability in the drupal version. So remove read permissions from CHANGELOG.txt
Naveen Valecha
https://www.valechatech.net
This is actually bad advice.
This is actually bad advice. Leave the .txt files alone. Spammers and hackers will target your site with all known vulnerabilities regardless of whether this file is readable.
There are also several other ways to identify the Drupal version, typically.
Frankly, there is no good practice except keeping up to date. Trying to obscure the fact you are on a vulnerable version is not going to stop any attacks.
yeah keeping update is best practice
@pwolanin
From this file hackers easily get to know your drupal version of your site and hacker easily get to know which vulnerability is in your drupal version if you have not updated your site.
yes there may be other ways to find your drupal version but I don't know would you please share it here how hackers get to know which drupal version is installed http://stackoverflow.com/questions/2887282/how-to-find-version-of-drupal...
Yeah keeping drupal version update is best practice.
+1 to keep update your drupal site.
Naveen Valecha
https://www.valechatech.net
yeah keeping update is best practice
@pwolaninFrom this file hackers easily get to know your drupal version of your site and hacker easily get to know which vulnerability is in your drupal version if you have not updated your site.
yes there may be other ways to find your drupal version but I don't know would you please share it here how hackers get to know which drupal version is installed http://stackoverflow.com/questions/2887282/how-to-find-version-of-drupal...
Yeah keeping drupal version update is best practice.
+1 to keep update your drupal site.
Replied to the above comment.
Naveen Valecha
https://www.valechatech.net
Thanks for your input
Thanks for your input everyone ^_^
If you didn't update your site within three days, assume you've been compromised and there's a back door or two hidden about the codebase (or perhaps even in the database).
Best to restore everything if you can from a local backup.
Cheers,
BC
If you didn't update your
it's less than 3 days. We've seen the first attacks as early as 7 hours after the 12pm EST announcement on Oct 15th. See http://drupal.geek.nz/blog/your-drupal-websites-backdoor
Found this in my web
Found this in my web log:
118.192.48.6 - - [16/Oct/2014:10:32:58 +0100] "POST / HTTP/1.1" 200 20116 "-" "Python-urllib/2.7"
IP address is in China. Very suspicious. No signs of hack on site. Anyone got any knowledge of whether this is an attack?
I've seen SQL Injection
I've seen SQL Injection attacks with the user agent "Python-urllib/2.7", so the one you are seeing could well be a similar attack.
Any examples of what they do?
Any examples of what they do?
What I've seen in the week of
What I've seen in the week of analysis I did was in the users table, but it could well be more than that:
set @a=(SELECT MAX(uid) FROM users)+1;INSERT INTO users set uid=@a,status=1,name='phantom' , pass = 'HASH';INSERT INTO users_roles set uid=@a,rid=3;INSERT INTO users SET uid=77000 , name='ololo1' , pass='HASH' , status=1;Warning: they are likely other exploit touching other table from that user agents.
PCI compliance issues
We run a Drupal 7 website that accepts credit card details (doesn't store them) and instantly sends them on to our payment gateway for processing. Thus we need to be PCI compliant.
I haven't been able to find any info on this vulnerability and PCI compliance or credit card security. We couldn't find anything google searching for this today.
We looked at our installation and saw that anyone who could access our site could also access our SSL private key. And this seems to be a fairly normal configuration. Our site is in a linux account, our private key is in the same account.
So, what should we do now?
Obviously we should reset our site. It doesn't look like it was hacked, and was updated within a day and a half or so of the announcement. But since we can't be sure we'd better reset back to prior to Oct 15th.
But what else?
And will this apply to 10,000s of Drupal sites or more that accept credit cards, that need to be PCI compliant? If so, I'm surprised that we couldn't find anything on the web about this.
We also rang our payment processor and they didn't know what to tell us!
Thanks for your ideas
If you are taking the credit
If you are taking the credit card numbers directly on your site, that's not an easy situation to be PCI compliant.
See: http://drupalpcicompliance.org/
In particular, the new PCI compliance rules coming into force soon will make it very onerous if the card number ever reaches your sever, and you are basically not allowed to use shared hosting.
You should probably consider have the SSL key re-generated and the cert re-issued if you want to be cautious, and force all user passwords to be changed.