PHP based web site being hacked

[alique]

This is an annoying situation that we are in at the moment and we are in need of some quick help here please. We have a web site that uses PHP scripts in the shopping cart. There is also an installation of a blogging script (b2evolution) along with a links directory script as well. Lately we noticed that links on our web site were taking people away to a notorious web site where people could buy some crap. Upon investigation it was found that there was a PHP based file on our web server that didn't belong to us. When tried to download, our anti-virus caught it as a PHP based backdoor. OK now what it does is, it inserts a piece of javascript in a page that they want to hack. Javascript itself is nothing apart from a web site hosted in China.

Has somebody ever experienced this kind of situation and what could be the solution? We have taken security measures that you would expect someone to take but there has been a second attempt after that as well.

[Markus]

It sounds like you're allowing your website to run some arbitrary code, known as XSS (cross-site-scripting). You can google to find articles on the subject. Another possibility is that you're allowing visitors to upload files to your website without first sanitising the file. Without having access to your code, though, we can only provide vague answers.

[dgreenhouse]

I've had a few sites that got hacked because the client had weak passwords or "heaven forbid" I didn't write the code correctly! :-)

There are a tremendous number of automated "vulnerabil ity scans" and "password hacks" running on the Internet that insert code into sites. And yes your problem may have started with an uploaded file.

The last hack that hit a client, inserted a JavaScript script into every index.php, index.html, and index.htm that it found in the site's whole directory tree. Fortunately this particular hack was an obscure Joomla hack that just damaged the files and didn't cause too much havoc - other than lost money and time :-(. This site wasn't even based on Joomla!

Make sure any ftp & admin panel passwords are "STRONG" so at least your site isn't susceptible to these kind of hacks.

As far as XSS and CSRF go - see:

http://en.wikipedia.org/wiki/Cross-site_scripting

http://en.wikipedia.org/wiki/Cross-site_request_forgery

Also, review your raw log files and look for a series of request for files that returned 404 errors from the same IP address. You'll notice that there will be a bunch of requests returning 404's all throughout your raw logs that are in close proximity. This is an indication of an automated vulnerability scan, but sometimes it's just a determined "script kiddy."
Many times these scans are trying to access files such as: admin/index.php, phpMyAdmin/index.php, phpMyAdmin, etc. and as stated they're bunched together in a group.

Also, look at the modification time of the file(s) that that have been hacked to limit your log search to around that time (typically the damage doesn't start to show up until some time after the file changes). Also, look at the file time of the php script file that inserted the bad code. This is of course post-mortem, but it will help in protecting against the problem in the future. CHANGE YOUR PASSWORDS!

Finally, as Markus mentioned, it might just be an XSS attack based upon comments in the blog. Make sure that b2Evolution is properly cleansing any comments being posted by users and no b2evolution installation files are still on the server.
(This last one I'm just making an assumption as I've never installed or used b2evolution on a site.)

[kovik]

Sanitize ALL user input before using it.

User input includes, but is not limited to:

• The $_POST array,
• The $_GET array,
• The $_FILES array,
• The $_COOKIE array,
• The $_SERVER array in regards to client information and URL information,
• And the the non-recommended $_REQUEST array.

Sanitation is a case-by-case process. In other words, the same data can be filtered differently for MySQL queries (i.e. mysql_real_esca pe_string) and display on the website (i.e. htmlspecialchar s). Just note that whenever you have an occurrence of any elements from the arrays that I mentioned, you are NOT **EVER** taking the data at face value unless you want to run the risk of unwanted data.

[itsloop]

all advices are valuable but i want to add one more advice is... do you have any public area from where your visitors can post sum data which is not validated for the <HTML> and other scripting tags e.g

<script>document.location.href='whereever.com';</script>

this also can be a problem please also check this thing.

If this is the problem then you can use

strip_tags

function for it.

[kovik]

htmlspecialchar s is less invasive and preferred over strip_tags. This is due to the fact that strip_tags actually changes what the user inputs. So, lets say that a user is writing something like command-line arguments for an application that they use. The accepted format for doing this is "command <argument1> <...>".

See how that could be a problem?

[alique]

Further Information

After looking into logs, we have found some useful information on attack and the method used. I can post the log here if that is OK. During the research, found countless sites infected with this particular r57.php shell.

[kovik]

Then you need to find out where in your website you allowed this download and quarantine that section until you fix the problem.