14

I have been asked to fix a hacked site that was built using osCommerce on a production server.

The site has always existed on the remote host. There is no offline clean version. Let's forget how stupid this is for a moment and deal with what it is.

It has been hacked multiple times and another person fixed it by removing the web shell files/upload scripts.

It is continually hacked often.

What can I do?

Charles
  • 50,943
  • 13
  • 104
  • 142
alex
  • 479,566
  • 201
  • 878
  • 984
  • 2
    If it's hacked that often, odds are (1) it's automated, and (2) it's an old version of osCommerce. UPGRADE. – Chris Eberle Jun 14 '11 at 00:49
  • @Chris (1) It's automated, fine, but what has that got to do with stopping the hacks and (2) this osCommerce is ancient and is sitting on an old PHP4 host. I also don't know what core files were upgraded and in my experience osCommerce is not an easy or painless upgrade process. – alex Jun 14 '11 at 00:54
  • I can see from the close votes the community believes this question shouldn't be asked here. I'm not 100% sure why, so would you mind letting me know? Thanks. – alex Jun 14 '11 at 00:59
  • 1
    @alex: it means that it's a very well-known vulnerability that has clearly been scripted, and to avoid being hacked further you need to upgrade to a version that isn't vulnerable. – Chris Eberle Jun 14 '11 at 01:05
  • Is Sony operating any osCommerce sites? ;) – Brian Jun 14 '11 at 01:14
  • @Brian, no I heard the IMF is. – Vineet Reynolds Jun 14 '11 at 03:22
  • This isn't really acceptable for Stack Overflow by today's standard. Similar questions might be acceptable at https://serverfault.com/ where they have an excellent canonical question: http://serverfault.com/questions/218005/how-do-i-deal-with-a-compromised-server – tripleee Jan 05 '16 at 10:03
  • This was topical at the time (I believe) and has some merit as a possible canonical question. I have flagged for "historical lock" but it has not (yet?) been granted. See also now http://meta.stackoverflow.com/questions/314002/how-to-cope-with-help-ive-been-hacked-questions – tripleee Jan 05 '16 at 12:37

3 Answers3

28

Because you cannot trust anything on the web host (it might have had a rootkit installed), the safest approach is to rebuild a new web server from scratch; don't forget to update all the external-facing software before bringing it online. Do all the updating on the happy side of a draconian firewall.

When you rebuild the system, be sure to pay special attention to proper configuration. If the web content is owned by a different Unix user than the web server's userid and the permissions on the files are set to forbid writing, then the web server cannot modify the program files.

Configure your web server's Unix user account so it has write access to only its log files and database sockets, if they are in the filesystem. A hacked web server could still serve hacked pages to clients, but a restart would 'undo' the 'live hack'. Of course, your database contents could be sent to the Yakuza or corrupted by people who think your data should include pictures of unicorns. The Principle of Least Privilege will be a good guideline -- what, exactly, does your web server need to access in order to do its job? Grant only that.

Also consider deploying a mandatory access control system such as AppArmor, SELinux, TOMOYO, or SMACK. Any of these systems, properly configured, can control the scope of what can be damaged or leaked when a system is hacked. (I've worked on AppArmor for ten years, and I'm confident most system administrators can learn how to deploy a workable security policy on their systems in a day or two of study. No tool is applicable to all situations, so be sure to read about all of your choices.)

The second time around, be sure to keep your configuration managed through tools such as as puppet, chef, or at the very least in a revision control system.

Update

Something else, a little unrelated to coming back online, but potentially educational all the same: save the hard drive from the compromised system, so you can mount it and inspect its contents from another system. Maybe there's something that can be learned by doing forensics on the compromised data: you might find that the compromise happened months earlier and had been stealing passwords or ssh keys. You might find a rootkit or further exploit tools. You might find information to show the source of the attack -- perhaps the admin of that site doesn't yet realize they've been hacked.

Be careful when inspecting hacked data -- that .jpg you don't recognize might very well be the exploit that cracked the system in the first place, and viewing it on a 'known good' system might crack it, too. Do the work with a hard drive you can format when you're done. (Virtualized or with a mandatory access control system might be sufficient to confine "passive" data-based hacks, but there's nothing quite like throwaway systems for peace of mind.)

sarnold
  • 102,305
  • 22
  • 181
  • 238
  • I'd give you +2 if possible. Excellent very helpful answer! – Brian Jun 14 '11 at 01:15
  • @Alex, thanks for the Accepted, but you might wish to hold off for a day or two -- questions with an accepted answer are less likely to get _new_ answers -- and there are doubtless still more things to consider in this situation. – sarnold Jun 14 '11 at 01:23
  • @sarnold That is very noble of you. I shall do that, but rest assured I'll be back to accept the best answer in a few days :) – alex Jun 14 '11 at 01:24
  • 2
    Another idea for examination might be to do it with a system that runs a different OS than the server's. That will reduce but not eliminate the danger. – David Thornley Jun 15 '11 at 19:10
  • 1
    As a side note, I like to keep a very basic, and incredibly cheap, Unix box for looking through hacked drives. It has no WiFi card, I permanently disabled the Ethernet port, I don't think it's ever so much as heard of Bluetooth, and I keep a clean install disc on hand so I can nuke it quickly and easily. It's great for peeking at compromised systems without worrying about my own getting wrecked. – Nic Jan 05 '16 at 17:25
9

Obtain a fresh copy of the osCommerce version the site was built with, and do a diff between the new fresh osCommerce and the hacked site. Also check for files which exist on the server but not in the osCommerce package.

By manually comparing the differences, you can track down all possible places the hack may have created or modified scripts.

alex
  • 479,566
  • 201
  • 878
  • 984
  • 4
    You should search for additional files uploaded that do not have a counterpart in the package. Next to that, check the database data for payloads. – hakre Jun 14 '11 at 01:00
  • This does nothing to prevent the intruder from repeating the intrusion, repeatedly. – tripleee Jan 05 '16 at 06:58
  • @tripleee It can give you the insight to fix it though. – alex Jan 05 '16 at 12:30
  • In my (limited) experience, hackers will edit web pages in order to manipulate SEO or drive spam, not to facilitate (further) break-ins. If the original page had a vulnerability which allowed them to pwn the box, why would they want to edit it at all? – tripleee Jan 05 '16 at 12:39
0

I know this is a little late in the day to be offering this solution but the official fix from osCommerce developement is here: http://library.oscommerce.com/confluence/display/OSCOM23/(A)+(SEC)+Administration+Tool+Log-In+Update

Once those code changes are applied then most of the actual work is in cleaning up the website. The admin login bypass exploit will be the cause that has allowed attackers to upload files via the file manager (usually) into directories that are writable, often the images directory.

There are other files that are often writable too which can have malicious code appended in them. cookie_usage.php and includes/languages/english/cookie_usage.php are the usual files that are affected, however on some server configurations, all site files can be susceptible.

Even though the official osCommerce fix is linked to above, I would also suggest to make this change as well: In the page above, scroll down till you see the link that says "Update PHP_SELF Value". Make those changes as well.

This will correct the way $PHP_SELF reports and prevent attackers from using malformed URLs in attempts to bypass the admin login.

I also suggest that you add htaccess basic authentication login to the admin directory.

Also check out an addon I authored called osC_Sec which is an all in one security fix, which while works on most php backed websystems, it is specifically designed to deal to the issues that exist in the older versions of osCommerce. http://addons.oscommerce.com/info/8283

Mark Davidson
  • 5,503
  • 5
  • 35
  • 54
Taipo
  • 76
  • 2
  • @MarkDavidson Was it really worth editing a four-year-old answer just to expand a shortened link and _nothing else_? – Nic Jan 05 '16 at 17:27
  • 1
    Probably not got to here via a meta post and I don't like clicking on shortened links. Maybe its just me I don't trust them. – Mark Davidson Jan 05 '16 at 17:28
  • 1
    [Blacklist the use of common link shorteneres in posts (on meta)](http://meta.stackoverflow.com/questions/313621/blacklist-the-use-of-common-link-shorteners-in-posts) – Tas Jan 06 '16 at 03:19