My Drupal Site was hacked

kayblaino - October 21, 2007 - 18:29

I'm working on porting my current xoops site over to drupal....
I awoke this morning to log in and do some work on my dev site and come to find it was hacked! The Mafia Hacking Team seems to have taken over my page and posted up their own index.php It looks as if they have not hit the files themselves, just removed every file in my root directory.

I just upgraded to the new patch last night (5.3) to fix security problems. I'm not sure how these people got in but part of the reason I'm switching to Drupal from xoops is it is more secure and I wanted to avoid this problem!

What is a guy supposed to do? I'm going to be reloading all my work, but it still poses two questions:
How were they able to do this?
How can I prevent this, especially on my live site?

If anyone has tips or experience please let me know!

Blaine

=-=

VeryMisunderstood - October 21, 2007 - 18:35

you prevent this type of thing by updating immediatley after a new release is put out. In your profile on durpal.org subscribe to othe security newsletter and keep yourself up to date on security issues when they are announced and react accordingly.

All Open Source programs have secuirty issues that need to be patched now and again. After all the Source is Open. Thus people are more apt to hack at it, after reading the code and finding possible flaws.

The fact that someone had the ability to delete files from your server, may possibly point to a problem with your servers security and not Drupal. Have you checked your apache logs ? to find out when this deletion took place ? have you inspected your logs for how they may have gotten in ?

If the files were removed by the DB was intact, uploading new files should have gotten you back in.

did you export your watchdog table to inspect errors?
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )

Blaine. It's quite possible

Genbushi - October 21, 2007 - 18:38

Blaine.

It's quite possible that the exploit wasn't Drupal per se, or another vulnerable aspect of the server\host that was exploited.

Have you saved off all possible logs, etc. to be able to do a post-scenario forensics look?

Logs and such

kayblaino - October 21, 2007 - 19:06

I'm looking through the logs now, nothing I can tell as of yet except it happened really early this morning, 4ish I think. I called the host and they basically stated "its not their problem"
Which doesn't fully please me, however I just purchased a new host yesterday so I'm not too worried.

I looked at the most recent security posts and it seems that most of them were fixed by upgrading to 5.3, which I did. I'm going to go back over everything and I'm working on re-uploading my files now to get everything rolling again.

posted up their own

gpk - October 21, 2007 - 19:24

posted up their own index.php

My first thoughts would be that they hacked your account on the server, rather than Drupal, especially if you had already upgraded. If they hacked Drupal then unless they cleaned out the DB you should find evidence there. Often (e.g. when PHP running as Apache module) the webserver process doesn't have permissions to write to the top level drupal folder and hence you can't do this kind of damage using Drupal or PHP (unless perhaps there is a PHP/Apache vulnerability). If PHP is running as CGI with phpSuExec then it runs as your own user id, and while this makes shared hosting more secure in general it does mean that PHP scripts running in your account have greater privileges.

I trust you didn't have 777 permissions everywhere...?

gpk
----
www.alexoria.co.uk

No I didn't have 777 on

kayblaino - October 21, 2007 - 22:02

No I didn't have 777 on anything unless it needed it. I tend to pretty strict with how I set permissions on things, just enough to make everything work.
I was looking at some of the venerabilities and it seems that with certain things you can make your own code run on the remote server, which if they could do that then with simple commands it would be easy to clear some files and then load up their own index file. I'm still questioning how they got on the server. I think it has to be through the code somehow because the ftp logs show that no one got on, however yes I do know that logs can be modified...

I still haven't gotten the site back up... I'm thinking they may have screwed something in the database because I'm having a lot of strange errors, however I'm still looking into that possibility.

My next question becomes, is there any way to deal with these people? I know there are cyber crime laws enforced however I have no clue even on how they would find these guys...

=-=

VeryMisunderstood - October 21, 2007 - 22:04

My next question becomes, is there any way to deal with these people? I know there are cyber crime laws enforced however I have no clue even on how they would find these guys...

with you being able to pinpoint an IP or some such fingerprint, no there is nothing that can be done.
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )

pretty strict with how I

gpk - October 22, 2007 - 07:42

pretty strict with how I set permission

Good!

make your own code run on the remote server

I think it's important for various reasons to work out exactly when the hack took place to determine whether you had upgraded Drupal by then - i.e. to help understand how it happened and whether this might be an ongoing vulnerability?

Also, what user does PHP run under, and what are the permissions on your top level Drupal folder? Because in many cases it would not be possible to use PHP code to upload file here.

Your Apache logs should have quite a few clues re. timing of the attack.

******* something in the database

Again depending on the server setup/what user PHP runs under (typically when PHP runs as an Apache module under the webserver user id), on many shared hosting packages if you have an account on the server it is possible to identify other users' database connection details. This is not a Drupal fault but a basic security problem with these shared hosting setups. However in this situation you usually can't directly modify files in the top level folder(s), just content in the files folder. Thinking about it now I guess that depending on the server setup the attacker might then be able to get scripts in the files folder to run under the account holder's user id, in which case they could then change any files/folders in the account. If Drupal hadn't been upgraded at the time of the attack then it might be possible to achieve same using the the XSS security holes since closed, but I've not really thought about this.

If the attack was through Drupal then I really would expect to see evidence in the Apache log and possibly the Drupal log.

gpk
----
www.alexoria.co.uk

i am a newbie

socialtalker - October 23, 2007 - 05:43

or rather a arrested developed newbie, been one for over a year now...lol
no, i just wanted to say that make sure you have a complex password. a small pw of less than 8 digits of all numbers or letters can be hacked instantly, while a complex pw makes it much harder

Help users create complex passwords that are easy to remember

by Michael "Mullins CCNA, MCP" | Jan 19, 2006

Takeaway: Passwords are only as good as the policy that enforces their use. That's why it's imperative that organizations employ a written password policy—and that they take steps to enforce it. In this edition of Security Solutions, Mike Mullins discusses how to create an effective password policy, and he offers a trick to share with users for creating strong, complex passwords.

While most end users understand the importance of using passwords to secure corporate systems and data, they don't always know how to create a strong password. That's why it's just as important to create a strong password policy in your organization. Remember: Passwords are only as good as the policy that enforces their use.

By default, Windows disables the password filter in the Default Domain Group Policy Object (GPO) and in the local security policy of workstations and servers. That's one more reason why it's imperative that organizations employ a written password policy—and that they take steps to enforce it.

For example, if your company's password policy only requires a minimum of six characters and doesn't require complexity (i.e., a combination of uppercase and lowercase characters, digits, and/or nonalphanumeric characters), then you've got a pretty weak policy. That means most users will use passwords that are easy to crack through either brute force or social engineering.

How do you make sure your users create strong passwords that hackers can't easily guess? Your first step is to enable the password filter in the GPO or on local stand-alone workstations and servers. To find the password filter, go to Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy in the Group Policy MMC in the Default Domain policy. After enabling the password filter, you can start creating an effective password policy for your users.
Craft a strong password policy

Let's look at some best practices for effective password policies. Most organizations require users' passwords to have a minimum of eight characters. They also specify that passwords must meet at least three of the four complexity requirements—uppercase letters, lowercase letters, numbers, and nonalphanumeric characters.

Organizations should also configure the password history to remember the last 24 passwords, which is the maximum setting. This virtually ensures that users won't reuse passwords.

In addition, you should set the minimum and maximum age of the password to an appropriate level. I recommend setting a maximum age of 180 days and a minimum age of 90 days. This prevent users from cycling through passwords until they can return to the one they want.
Put your policy in action—and enforce it

It's smart to establish a good password policy in your organization, but it's even more important to actually enforce it. A strong policy that no one has to follow doesn't add any more security than no policy at all.

In addition, it's important to remember that a good password policy doesn't work if users have to write down their password because it's so complex. That only transfers the security risk instead of mitigating it.

So how can you make sure users' passwords are complicated enough to deter hackers and easier enough to remember? One of my colleagues offers the following trick for creating complex passwords that meet complexity requirements while still being possible to remember.

Step 1: Come up with a base word
Pick the name of a pet or any common thing that's easy to remember. For example, say you once lived in Louisville. You can use that to establish the base of your password and satisfy the required criteria for a strong password.

Remember: You need at least one capital letter and either a number or special character. So, using Louisville as your base word, you can substitute an ! or 1 for i and replace the s with $—e.g., Lou1$ville or L0u!$ville.

Step 2: Add more characters to the base word
Pick any four characters to add to the base word.

Step 3: Store your password without worry
Now, write down the added four characters, along with a clue for the base word. Using our previous example, you would write down city1xyza, where city1 signifies Louisville with a 1 and $ and xyza represents the four additional characters.

So, even written down, this password reference would serve as a reminder of your complete password while revealing nothing to any roaming eyes. (Keep in mind that this example is a 14-character password. While that may be longer than the actual requirement, it may be easier to remember.)
Final thoughts

Password policies only work if you turn them on. Make sure you've trained your users on how to create complex passwords that they can remember without leaving a paper trail that prying eyes can easily follow.
Miss a column?

Check out the Security Solutions Archive, and catch up on the most recent editions of Mike Mullins' column.

Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.

Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.

 
 

Drupal is a registered trademark of Dries Buytaert.