By cnelsonakgov on
I recently had a Drupal site defaced. A little bit of carlessness on my part but I noticed that they seemed to have a script specifically designed to deface drupal installations. First the server was compromised with an upload script, then they upload a file called drupal_view.php, from there it looks like they deface the site. Unfortunately I have to say I'm running and older version of Drupal, but I've kept up with the advisories and gone so far as to remove or hand edit files (like xmlrpc) when they come under question. Anyone out there run across this type of attack?
Comments
Contents
What are the contents of the file uploaded? Without executable privileges I’m curious as to how they would do have the power.
Cheers
uploaded file
Well, they actually got in from another site on the server (an old drupal installation that should have een removed). Got into it and the upload area and were able to put a small upload script in a "files" area.
From there they uploaded a phpinfo.php file, something called i.php which they used to grab some config files and traverse the directory structure and then finally a drupal_view.php file, which I suspect they used to replace the front article on the website with a defacement notice -- it was actually pretty slick.
The files are removed as far as I can tell and the only one I see is the originall upload script, htaccess.php.
Site permissions
This is a good reason to have different sites owned by different users and to not allow your sites to be world writable. It pays to remove world readable permissions too - especially for files like settings.php.
Even though I'm the only person with access to our server, I've started using different user account for all our sites on it for this reason.
There is really no Drupal defence for these kinds of attacks - if someone can put a file in your web directory or edit existing ones, you're hosed if someone breaks into one of the other sites on the server. It comes down to the way the server is set up and maintained.
You have my sympathy. And do let the security know about the script these kiddies used.
First, my sympathy. This is
First, my sympathy. This is never pleasant.
How did they upload a PHP file and scripts? The default upload set is "jpg jpeg gif png txt html doc xls pdf ppt pps".
If you mean they fist gained entry to the server (through FTP, telnet or SSH, password guess/crack, etc.), then copied the files over, then yes, once they gain entry they can replace their own scripts over any existing application, including Drupal. All they really need to overwrite is index.php
I hope you saved all those scripts, they might be of use to Drupal dev, for assessment.
the files
The only port open to the public on this machine is 80 -- I'm pretty sure they came in on a php script vulnerability. Pretty sure its xmlrpc.php.
It looks like on Sep 4-11, a separate IP address (66.98.248.100) started coursing through the server and found some xmplrc.php files -- and specifically one with an old drupal installation (4.5.0 i think). Immediately after in the files subfolder of that installtion appears htaccess.php which is a simple upload script which is subsequently accessed by another IP (201.146.170.244) and then they're gone.
On Sep 25, the another IP from the 201.146 subnet same in and accessed the htacess.php script and uploaded a few files which they used as I mentioned in the first post.
Besides logs, mysql binary logs, some odd watchdog files I only have an actual file called htacess.php -- the others, thought accessed during the exploit, are no longer visible.
Files for security team
If you saved the files, then please go to http://drupal.org/contact
And select "Security Issue", then send a note referecing this topic. Mention the version of Drupal that was compromised.
Someone from the security team will contact you for a copy of the scripts where they can be analysed.
To make sure they are the security team, enter some garbled string and ask that it be included in your reply.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
we had the same
Just replying to say we had a similar deface recently.
Unfortunately I didn't notice any of what you have indicated above.
We were running 4.5.0 and twice our index.php was removed/written over and replaced with something like:
"this site has been defaced by SLaMMER"
First time I thought it was due to lax file permissions. So tightened these up - but still got done a second time! The only way they could have done this as far as we could tell is to have user permissions. Somehow. Our web host is pretty good - so don't think the vulnerability was there (but could be wrong). The logs tell us nothing - nice and cleaned up! So don't know how they did it.
Upgraded to 4.6.3 - about a month now. Have taken the tips on Best practice file permissions and really lock up when I leave. No defacing. Which is really handy.
The xmlrpc library that
The xmlrpc library that Drupal had been using was replaced in 4.6.3 do to this issue.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Follow-Up
Well I'm still investigating this little incident -- one of the things I was able to figure out was that they used the old drupal site+xmlrpc+the permissions on the upload directory, to get a file call phpshell.php on the server. I don't actually have this script in hand, but from reading through the snort files I was able to craft enough of it to return a google result. Essentially is a small web console that runs as the apache user and has a tiny file browser. Ouch.
Thanks for your words of encouragement. I'll try to post a final report when I feel comfortable I have the complete picture. As a reminder to all I encourage everyone to stay up-to-date with their Drupal installations. I thought I was being pretty good about it, but the small test installation I'd fogotten about got me in the end -- thank you google. Anyway, back to the logs.
Cheers