Client Site Hacked - And Hacked When Taken Off Line

[dgswilson]

At some point - - - /public_html/php.ini

allow_url_fopen = Off
display_errors = Off
display_startup_errors = Off
log_errors = On
error_reporting = E_ALL
error_log = /home/yourUserID/public_html/phperr.txt ( create this .txt file )
expose_php = Off
magic_quotes_gpc = On
magic_quotes_sybase = Off
register_globals = Off

[Yafolio]

I have had this happen before when using a previous host. They had this long pre-written script regarding this matter and made sure they let us know it was a vulnrability on a script we were using. The honestly spent more time writing the letter that fixing the issue. This ended up being found on over 80 domains of our clients as well. At least half of them were static html pages with no scripting. This originated server side and would place a script in the CGI file (this can run on and offline) per the hosts. The script queried the filelist and inseted some javascript or Iframes.

Before I found the CGI script I wrote a script that on load would rewrite the code and comment it out. The fix if I remember correctly was to block CGI. This has been a couple years ago and dumped them some time ago. This was from an infected host server and spread through the others. I hope this helps!

[South River Design]

Also want to make sure the path to the admin. directory is "non standard".
Why give hackers an easy target?

These solutions will not deter very sophticated hackers, but will do in most.

Note: Sophicated hackers can also hack what ever cart you choose to use.

Also remember to add the "don't save credit card numbers in the database" contribution for the protection of your customers.

JOC

[Refiner]

I've dealt with a number of clients who have been hacked over the years. It is not likely to be the database, but the php script used for the site. I see a few areas you may want to address (some may have been addressed already, but worth repeating):


1 - PHP site copied over....

solution:
Backup the database, backup any of your known files which you have for download or images and themes.
Do not backup the php scripts as you will reinstall these. Be sure you have the latest builds.
Wipe all folders and do fresh install of the software, then restore the database.

Also, rather than uploading via an FTP client, open cPanel and use the Folder view to upload the compressed script, unpack and install.
If your client's database is not compatible with the most recent build of the script, there are ways to convert it or have a trusted database expert make the conversion.

This will resolve any unknown folders that may have been added inadvertently by the hacker to reaccess the site.

Also check all your folders to make sure the proper permissions are given for each folder.
Make .htaccess for secure folders
Make all passwords meet the highest level of settings.
Make sure that users are not able to create or upload to new directories they have created.



2 - database users:
Ensure that your database users are the users you want to have access to your site.
Your database should be tracking all user IPs and the server should also be logging IPs for the hacker.
A direct IP match between a database user and the hacker's IP means you will want to put a user'sIP on server ban as well as database ban.

Removal of their account will not be sufficient unless they are completely banned from the site.
Keep in mind that hackers tend to use proxies to get around IP bans to you may end up banning a number of IPs in the process.

As any server, VPS can be set to trip the server access on 5 failed login attempts within a set time frame. If your client removes suspect users from the databse, the csf (or whatever firewall is installed on the server) will automatically ban the IPs the hacker attempts to log in from if it is set up properly.


3 - PHP scripts...

Find out all the php scripts your client is using and research them for vulnerabilities. The latest version of a php script is not necessarily the most secure but there is a very good chance that the developers of the script have patched known loopholes which allow hackers access to a website.

It may be advisable to switch to a more highly rated and secure php script if the current one has too many hackable access points. Be sure to check over reviews from users of any scripts which will be used on the site.

As for OSC, it is very important to have the latest build, fully patched, if possible.

4 - Webmail and pop3 access

Secure passwords are a must for these. You may need to make new e-mail accounts if a particular account seems to be creating a flood of unauthorized phishing/scam/spam emails.


Lastly, as kyanwan stated

5 - Server logs!!!

These are the keys to locating the culprit's access points and IP.

[Refiner]

One other thing and I think someone else may have mentioned this. When I say "wipe all files/folders for clean reinstall" this includes the CGI folder and scripts. Your reinstall will add only the parts you will need.

As far as phishing/scam hackings, I dealt with a client 2 years ago who had a major issue with his site going down with hacking attempts on another host. Once moving him to my server, he has not have any hacking attempts. He and I cleared all the culprit folders (yes it was an unauthorized folder added to his php) and cleaned up everything. Since I am a database wiz, I looked his databases over with a fine tooth comb for any potential issues. His former hosting provided server log details needed to locate both the IP and the culprit folders.

I have had other clients who have experienced hackings, but usually due to using a php script that is free and easily hacked.

And just because a site is "down" does not mean it cannot be hacked. The folder configurations of specific php scripts are known to hackers and they will access directly (reason for .htaccess and CHMOD settings).

A website which has had the domain expire and has not been removed from any server is also VERY VERY vulnerable. As a host, it is important to regularly clean up servers and remove dead domains/dead accounts. This also applies to ADDON DOMAINS which have expired. It may be advisable to run a complete backup of an expired domain or dead account for the client should they request it in the future. Do not store it on the server, but on a local or portable device (CD/DVD prefered).

[erima]

One problem with OSCommerce and other open source software is that they are prone to attacks because the code can be so easily studied. OSCommerce, Joomla and other open source projects do a fantastic job updating their software once an exploit has been found but it does not good if you aren't checking for updates at least once a month.

When you take the site offline, you are simply disabling the cart functions - but the underlying database is still there. Unfortunately, all of the identified vulnerabilities are still there so if the are doing a MySQL injection attack where they hack the database - it doesn't matter if all ports are blocked

While it is a great idea to have either a software or hardware based firewall, in most cases the attackers are exploiting vulnerabilities in the code, not the server. Like several of the previous posts, I strongly recommend renaming the admin folder and setting up an ip trap in the now empty admin section. Use htaccess for password authentication.

Good luck, I think the next 18 months are going to be very difficult for Open Source.

[nolan shipman]

There are a lot of great suggestions here.

There a quite a few possibilities. If you are finding that your index.php is being modified (appended), ensure that your last line of code is "return 0;" thereby preventing the execution of any code which is appended after yours. This may help with the symptoms.

As far as the illness, I'd suspect you either have a security hole (there are some solid suggestions above) or (most likely) you have a trojan or compromised application or module. It sounds like a full scan has been done on the client side and is highly suggested on the server side. Additionally, add ons and applications on the server can be compromised. Disable or preferably delete anything that is not being used.

I'm curious to see the ultimate solution to your issue. Good luck with everything.

[SnerdeyWebs]

One of our data centers that we used to use actually denies the use of Oscommerce websites on their servers. They claimed that the OSC sites are the #1 hacked stores they host for clients. Causing much grief for everyone involved. When we heard this announcement it was decided to switched to Magneto for any new or site overhauls that we perform for clients.

The results have been happier clients, increased sales as the designs are fantastic!

If you continue to use oscommerce once you have the site fixed. I'd consider creating cron jobs to backup the site on a regular basis.

Best of luck with this and as for being attacked when offline. Well, the website might be offline but the database is still open for hackers as they can continue to create mysql dumps into the hosted account.

[MrGamm]

One of our data centers that we used to use actually denies the use of Oscommerce websites on their servers. They claimed that the OSC sites are the #1 hacked stores they host for clients. Causing much grief for everyone involved. When we heard this announcement it was decided to switched to Magneto for any new or site overhauls that we perform for clients.

Isn't that like 20x more complicated? I think you are right in a sense that OSC is much more widely used and perhaps more popular.

I have run neither, but both get hacked right?

-------------------------

In any event, if the store keeps getting hacked hours after launch it could be the database like others have said, in which case, maybe installing the website, then running a web crawler, or link checker over it to see if it speeds the rate at which the infection occurs will help.

If it is inside the database, then it has to be triggered by a user event to cause infection, right? Just make sure no crons are running.

Also, and I think it is more likely that someone is attacking the website over HTTP. Have you turned your server log files on to see if any strange requests are coming in over HTTP? But if you said it was infected before it went live, then it is probably the database, unless there is a script that is injecting cron scheduled tasks into operating system. Or just a script that is doing it on it's own.

Maybe installing a clean verison of OSC and then swapping the database for use with the clean installation will help.

If the attack is iframe injection, copying the code which shows up (the IFRAME HTML and addresses) and then doing a text search on the installation and back up will be the fastest way to find where it is originating if it is originating within the store itself and not over http.

I am not very familiar with OS Commerce so I am unaware as to where it the problem truly is, but if it were anything related to the server or the server company, they would probably fix it or risk compromising the rest of thier client base.

Why not choose a host which hardens their servers for protection against known exploits that attack popular open source distribution? Some attacks are well known, and to protect people the exploits can be stopped at the server level bypassing the need for users, using popular and highly exploited open source software to upgrade and protect it themselves.

I mean if the host is going to host a popular open source distribution, maybe in some cases they should be prepared to bail it out when it gets hacked on their servers. Jmo.

That being said, make sure OSC is the most recent version.

Hope that helps.

[Martinscholes]

I have been hacked myself a few times. I suspected a host employee. They were able to change anything on the site. I did track the hackers location, using the log files, blocking their IP from access and changed my IP address. The fact that the site can be changed after shutdown would indicate an employee that has access.

Yes, that was the first thing I thought of. Unless someone has managed to hack into her wireless network?