Website Hacked

[jim_bob45506]

One of my client's websites was hacked over night. There is no obvious file vandalism, though I am doing a review now.

 

I am wondering how to best find out the IP of the hackers (if that is even possbile) and is there any way to prevent this in the future besides periodically changing the master password?

 

Thanks!

Jim

[TCH-Bruce]

You can go through the access logs. That should provide some information.

 

And yes, periodically changing the password is always a good idea. When choosing a new password make sure that it includes letters and numbers and isn't something that can easily be guessed.

[jim_bob45506]

Thanks for the reply. Based upon the web logs, seems there are several nasty people trying to get into private areas of the website.

 

I am adding 34 IP's to the denied access list in hopes it makes them leave the site alone. Plus I will be keeping a closer eye on the server logs.

 

Admin password has been changed with numbers and letters.

 

I am always appreciative of the prompt support from TCH.

 

Jim

 

PS - They left a website URL in the logs, with their latest hacks posted. It can be found at:

 

http://www.zone-h.org/defacements/onhold

[MikeJ]

I am wondering how to best find out the IP of the hackers (if that is even possbile) and is there any way to prevent this in the future besides periodically changing the master password?

Worry less about the IP the hacker came from (it was probably another compromised host anyway), and more about how they got in.

 

Look for abnormal activity in your web logs for possible attempts (and successes) at abusing vulnerable scripts/packages. Searching for "wget" might show you where they got in. An example of a vulnerable PHP script would be one that does an include() or require() of a variable that is not initialized in the page (so that it could be defined in the URL) allowing people to inject foriegn code in your page to get shell access. They often use this to "wget" other files to your account. One of the more commonly exploited methods I normally see.

 

If the site uses any packages (like PHP-Nuke, Gallery, Advanced Guestbook, etc....) they should check for updates and security notices on the ones they are running. It's possible they have vulnerabilities (like all the ones I mentioned do for non-current versions).

 

If the site has a vulnerability that has already been exploited, blocking IP's alone will likely not prevent it from happening again.

[jim_bob45506]

Mike

 

The site uses no php, but lots of cgi, including database programs, csv writing cgi programs, etc. In some cases I found attempts at accessing formmail, in all its variances (formmail is not used on the site) and attempts at entering the cgi calendar program login.

 

I saw no instances of wget, though I may be missing them from viewing the logs.

 

What they did was installed another index page in the main public directory. They could have done more if they could have.

 

I am not fully knowledgeable in protecting against this stuff. Any additional comments would be appreciated as it is a school website, loaded with informational data.

 

Thanks!

Jim

[MikeJ]

The formmail accesses you can pretty much ignore unless you have formmail installed. People scan for vulnerable formmail scripts on a regular basis to spam with and it's likely unrelated to the people who defaced the website.

 

It would be difficult to explain all the things to look for in a forum post (I've been working with websites for over 10 years). But a good start would be if you know exactly when the defacement happened (such as the defaced file's timestamp), then you can look at the web accesses in the minutes leading up to that time to see if anything looks unusual. This is more difficult if the site gets a lot of traffic.

 

Btw, I was using PHP as an example since it's most commonly used. Any dynamic script has the potential of being vulnerable to abuse.

Edited August 12, 2004 by TCH-MikeJ

[TCH-Rick]

This was another case of a site being defaced due to an exploit in a script called CalendarScript 3.2. There is an update that corrects the problem and I posted more on this in this thread. It was a different IP from a different part of the world but used the same method as in the other site I mentioned in the other thread.

 

They found the site using a Google search, probed it to discover the script was vunerable, and defaced the site. Total time on the site according to the logs was just under 2 minutes.