Hacked osCommerce? Here’s some essential reading…

Having your site hacked is a PITA. It can be far worse if you weren’t prepared…

Step One: preparing to recover from an attack

First off, store an entire set of working files locally. This should be a set of files that has never been off your computer so that you know that they have not been tampered with. Edit them locally, when you need to, and then upload them to your webspace, either through the file manager in your cpanel or with ftp, sftp, ssh, or something similar. You don’t have to upload the entire set each time, just the modified files.

Some people edit their files live on the server. If you do this you will not have a current local copy. If you download the file(s) from your server, you do not know for certain that they have not been modified by a hacker. ALWAYS edit your local files and upload them to the server, not the other way around.

It wouldn’t be a bad idea to get XAMPP (from Apache Friends) and develop locally, or use the osCBooks “localhost” package which can be found here.

Before installing a new contribution, make a copy of the entire local directory and datestamp it (rename the directory copy to indicate the date). That way if anything goes wrong, you can revert to the old copy. It is a good idea to keep a couple of these snapshots (backups taken at different times) around just to be safe.

Now, if your site ever gets hacked it is easy to fix. Go to your webspace and delete all the files associated with your site. Use some common sense though. There may be other folders such as for cgi, logs, statistics, etc that you might want to keep. (They should not be in a web accessible location anyway but that’s another issue).

Once you have deleted your website from the server, upload the entire fileset from your local computer. Now, your website should be back to where it was before you got hacked. That should be a fairly quick and painless recovery process – certainly this can be done in minutes if done correctly.

Do not upload your files over the existing files. You must delete everything first. Otherwise you will not remove any new files or folders that were added by the hacker.

Step Two: protecting against an attack in the first place

Most important…set the permissions correctly! The documentation states that you should set the permissions on a few folders to 777. That is fine if you want to be hacked. If you follow those instructions, you WILL be hacked, it’s just a matter of time.

Set the permissions on ALL folders to 755. If your host has PHP installed as CGI through suExec (the proper method), then your site will run fine this way. If they have PHP installed as a module, you will get a warning from oscommerce saying that it is unable to write to the images folder. Setting permissions back to 777 will make the message go away but it will leave you open to an attack. Contact your host and ask them if they could change the way in which they install PHP. If they will not, you should immediately get a new host. This isn’t an arbitrary statement. By installing PHP the wrong way, they have created a security vulnerability that you will not be unable to resolve. A partial work-around is to upload images via file manager in cpanel or through ftp. A less secure method is to set the permissions on the images folder to 777 just long enough to add your new products and then set it back to 755. This work-around does not, however, deal with the permissions issues on a couple of other folders. Loading PHP in the correct manner is the only fix.

Set the permissions on all files to 644, with two exceptions. There are two configure.php files. One is located in /catalog/includes/ the other is in /catalog/admin/includes/. The permissions on these two files should be 400, 444, or 644 dependent on your server configuration. Use the lowest setting that will still allow your store to function and that your host’s setup allows you to set.

If you have trouble setting permissions on files or folders through ftp, try the file manager in cpanel instead. Some hosts don’t allow ftp to change permissions.

The admin folder requires a password (in the latest version of osc). This method of password protection is not secure. A hacker could run a password cracker program against it and try thousands of passwords a second until they get in. Use the feature in cpanel to ALSO password protect your admin directory. When a hacker runs a password cracker program against this, the system will be notified after a set number of attempts and the hacker’s IP will be automatically banned from the system (on a properly configured server. It wouldn’t hurt to check this with your host).

Renaming your admin folder to something obscure (a 12+ character long string of random letters and numbers would be best) makes it even more difficult for hackers since they won’t even know where your admin folder is now. You will have to modify your configure.php files to point to the newly renamed admin directory. Be sure that you do not list the new name in any other files (like robots.txt) as this will give the name away.#

Step Three: further securing your shop

Install the following security mods:

Security Pro
IP Trap
.htaccess Protection

With all of those changes made, it is unlikely that you will be hacked. There are always other methods of attack and some can only be prevented by making changes to the server configuration (which is out of your control). Keep in mind that shared-host accounts have more security issues than dedicated accounts and that “cheap” accounts are just that; don’t expect that a cheap account is managed by competent or conscientious people.

Lastly, make sure that your admin settings for file-based sessions and cache (if you use either), do not use the /tmp folder if you are on a shared-host account. On most systems, the /tmp folder is a symlink to a shared system folder that all the other accounts on that shared-host also use. Not only can this potentially cause problems but it can be a security leak, sharing customer data through this shared folder

This post was taken from the osCommerce forum – and was made by php_Guy. There aren’t many posts that I would take from there and post here as much of the official forum is “noise”. Nice work php_Guy.

9 Replies to “Hacked osCommerce? Here’s some essential reading…”

  1. THANKYOU! I saw a reference to changing the name of the admin file elsewhere online, but I couldn’t find the php files that contained the paths, so it didn’t seem like it was going to work – until I saw the throwaway comment in the middle of this post about changing the configure.php files. So casually mentioned – could have saved me hours, had I found it first!

    Thankyou, thankyou, thankyou!

  2. “Be sure that you do not list the new name in any other files (like robots.txt) as this will give the name away.#”

    Would you like to do an enlightenment of how to stop robots accessing and listing your admin without using robots.txt?

    It would seem we are on a lose-lose situation here if we list in robot.txt the hackers will find our admin, if we don’t list in robots.txt Google et.al will list our admin pages on the web for all to see…

  3. Named randomly and secured via htaccess, there is absolutely no way that Google can list it, and if it didi (though I see no reason how/why), you go to webmaster central and remove it.

  4. @Xpajun

    Don’t put your new admin name in your main robots.txt file but create a new one in your admin folder and place the following lines in it;

    User-agent: *
    Disallow: /

    It can be found in this contribution http://addons.oscommerce.com/info/2162

    @Gary Would you recommend the 5 security mods for all versions of osC shops including the 2.3 series?

  5. “Would you recommend the 5 security mods for all versions of osC shops including the 2.3 series?”

    What 5 security mods are you talking of? The chosen few might be ones that I never use anyway lol Let me know and I’ll advise what I use.

  6. These five mods;

    Step Three: further securing your shop

    Install the following security mods:

    Security Pro
    IP Trap
    .htaccess Protection

  7. My opinion only;;;

    Security Pro – Use the very latest one (r7).

    Sitemonitor – rubbish coded piece of crap, but somewhat useful. Suggest FWR Filesafe instead.

    IP Trap – pointless

    .htaccess Protection – inbuilt one is fine

    Anti-XSS – pointless as SPr7 takes care of it.

    So, yes to Security Pro and protecting admin via inbuilt htaccess. Maybe to Site Monitor. No to IP Trap and AntiXSS – based on securing 2.3.1.

    Would say yes to it all, other than IP trap, for securing 2.2

Leave a Reply

Your email address will not be published. Required fields are marked *