Best methods to clean up a hacked site with no clean version available?Wordpress Trojan issueWhat is the purpose of this JavaScript hack?PHP regex to fix hacked Wordpress siteWebsite hacked, how to remove malicious code with SED / GREPWordpress site backdoor - hackMy site is loading some other site, causing it to redirect to itHow can I search and replace all files recursively to remove some rogue code injected into php files on a wordpress installation?Why regex pattern works with html comments but doesn't work with php and js comments?Joomla Site is hacked?My website is defaced — how do I fix it?What's the best method for sanitizing user input with PHP?Best practices to test protected methods with PHPUnitWhat is the most secure method for uploading a file?What is the best way to get the errors from a production site in PHP?Integrating Magento with a simple static websiteSetting up a deployment / build / CI cycle for PHP projectsWhere to store users' content? (SVN and PHP)PHP best way to send post requests to hundreds of sites?register_globals fixImagick convert vs imagick PHP
Is it damaging to turn off a small fridge for two days every week?
How does DC work with natural 20?
If I wouldn't want to read the story, is writing it still a good idea?
What could exist inside and between the walls of a Dyson Sphere?
Is a single radon-daughter atom in air a solid?
Methodology: Writing unit tests for another developer
Why does Linux list NVMe drives as /dev/nvme0 instead of /dev/sda?
Can there be an UN resolution to remove a country from the UNSC?
What is the legal status of travelling with methadone in your carry-on?
What exactly is the 'online' in OLAP and OLTP?
When to remove insignificant variables?
Is this proposal by U.S. presidential candidate Pete Buttigieg to change the composition of the Supreme Court constitutional?
How does the spell Remove Curse interact with a Sword of Vengeance?
What's the difference between a deep fryer and a chip pan?
Find the C-factor of a vote
"How can you guarantee that you won't change/quit job after just couple of months?" How to respond?
Explain why a line can never intersect a plane in exactly two points.
What does "play with your toy’s toys" mean?
Why don't countries like Japan just print more money?
Why are < or > required to use /dev/tcp
What is "industrial ethernet"?
Do I need a shock-proof watch for cycling?
Why did pressing the joystick button spit out keypresses?
Is "Busen" just the area between the breasts?
Best methods to clean up a hacked site with no clean version available?
Wordpress Trojan issueWhat is the purpose of this JavaScript hack?PHP regex to fix hacked Wordpress siteWebsite hacked, how to remove malicious code with SED / GREPWordpress site backdoor - hackMy site is loading some other site, causing it to redirect to itHow can I search and replace all files recursively to remove some rogue code injected into php files on a wordpress installation?Why regex pattern works with html comments but doesn't work with php and js comments?Joomla Site is hacked?My website is defaced — how do I fix it?What's the best method for sanitizing user input with PHP?Best practices to test protected methods with PHPUnitWhat is the most secure method for uploading a file?What is the best way to get the errors from a production site in PHP?Integrating Magento with a simple static websiteSetting up a deployment / build / CI cycle for PHP projectsWhere to store users' content? (SVN and PHP)PHP best way to send post requests to hundreds of sites?register_globals fixImagick convert vs imagick PHP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
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?
php oscommerce
edited Mar 26 '12 at 0:02
Charles
46.2k1288125
asked Jun 14 '11 at 0:46
alexalex
351k174786920
|
show 3 more comments
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?
php oscommerce
edited Mar 26 '12 at 0:02
Charles
46.2k1288125
asked Jun 14 '11 at 0:46
alexalex
351k174786920
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 0: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 0: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 0: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 1:05
Is Sony operating any osCommerce sites? ;)
– Brian
Jun 14 '11 at 1:14
|
show 3 more comments
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?
php oscommerce
edited Mar 26 '12 at 0:02
Charles
46.2k1288125
asked Jun 14 '11 at 0:46
alexalex
351k174786920
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?
php oscommerce
php oscommerce
edited Mar 26 '12 at 0:02
Charles
46.2k1288125
asked Jun 14 '11 at 0:46
alexalex
351k174786920
edited Mar 26 '12 at 0:02
Charles
46.2k1288125
asked Jun 14 '11 at 0:46
alexalex
351k174786920
edited Mar 26 '12 at 0:02
Charles
46.2k1288125
edited Mar 26 '12 at 0:02
Charles
46.2k1288125
edited Mar 26 '12 at 0:02
Charles
46.2k1288125
46.2k1288125
asked Jun 14 '11 at 0:46
alexalex
351k174786920
asked Jun 14 '11 at 0:46
alexalex
351k174786920
asked Jun 14 '11 at 0:46
alexalex
351k174786920
351k174786920
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 0: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 0: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 0: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 1:05
Is Sony operating any osCommerce sites? ;)
– Brian
Jun 14 '11 at 1:14
|
show 3 more comments
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 0: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 0: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 0: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 1:05
Is Sony operating any osCommerce sites? ;)
– Brian
Jun 14 '11 at 1:14
2
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 0:49
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 0: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 0:54
@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 0: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 0:59
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 0:59
1
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 1:05
@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 1:05
Is Sony operating any osCommerce sites? ;)
– Brian
Jun 14 '11 at 1:14
Is Sony operating any osCommerce sites? ;)
– Brian
Jun 14 '11 at 1:14
|
show 3 more comments
3 Answers
3
active
oldest
votes
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.)
answered Jun 14 '11 at 1:04
sarnoldsarnold
90k16143199
1
+1 thanks, very useful information.
– alex
Jun 14 '11 at 1:06
I'd give you +2 if possible. Excellent very helpful answer!
– Brian
Jun 14 '11 at 1: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 1:23
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 Hartley
Jan 5 '16 at 17:25
|
show 2 more comments
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.
answered Jun 14 '11 at 0:47
alexalex
351k174786920
mark your answer ? :P
– afarazit
Jun 14 '11 at 0:48
@atno I can't for 2 days :)
– alex
Jun 14 '11 at 0:51
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 1:00
This does nothing to prevent the intruder from repeating the intrusion, repeatedly.
– tripleee
Jan 5 '16 at 6:58
@tripleee It can give you the insight to fix it though.
– alex
Jan 5 '16 at 12:30
|
show 1 more comment
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
edited Jan 5 '16 at 17:24
Mark Davidson
4,92352953
answered Jan 27 '12 at 21:21
TaipoTaipo
762
@MarkDavidson Was it really worth editing a four-year-old answer just to expand a shortened link and nothing else?
– Nic Hartley
Jan 5 '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 5 '16 at 17:28
1
Blacklist the use of common link shorteneres in posts (on meta)
– Tas
Jan 6 '16 at 3:19
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f6337976%2fbest-methods-to-clean-up-a-hacked-site-with-no-clean-version-available%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.)
answered Jun 14 '11 at 1:04
sarnoldsarnold
90k16143199
1
+1 thanks, very useful information.
– alex
Jun 14 '11 at 1:06
I'd give you +2 if possible. Excellent very helpful answer!
– Brian
Jun 14 '11 at 1: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 1:23
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 Hartley
Jan 5 '16 at 17:25
|
show 2 more comments
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.)
answered Jun 14 '11 at 1:04
sarnoldsarnold
90k16143199
1
+1 thanks, very useful information.
– alex
Jun 14 '11 at 1:06
I'd give you +2 if possible. Excellent very helpful answer!
– Brian
Jun 14 '11 at 1: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 1:23
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 Hartley
Jan 5 '16 at 17:25
|
show 2 more comments
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.)
answered Jun 14 '11 at 1:04
sarnoldsarnold
90k16143199
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.)
answered Jun 14 '11 at 1:04
sarnoldsarnold
90k16143199
edited Jun 14 '11 at 23:52
answered Jun 14 '11 at 1:04
sarnoldsarnold
90k16143199
answered Jun 14 '11 at 1:04
sarnoldsarnold
90k16143199
answered Jun 14 '11 at 1:04
sarnoldsarnold
90k16143199
90k16143199
1
+1 thanks, very useful information.
– alex
Jun 14 '11 at 1:06
I'd give you +2 if possible. Excellent very helpful answer!
– Brian
Jun 14 '11 at 1: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 1:23
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 Hartley
Jan 5 '16 at 17:25
|
show 2 more comments
1
+1 thanks, very useful information.
– alex
Jun 14 '11 at 1:06
I'd give you +2 if possible. Excellent very helpful answer!
– Brian
Jun 14 '11 at 1: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 1:23
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 Hartley
Jan 5 '16 at 17:25
1
1
+1 thanks, very useful information.
– alex
Jun 14 '11 at 1:06
+1 thanks, very useful information.
– alex
Jun 14 '11 at 1:06
I'd give you +2 if possible. Excellent very helpful answer!
– Brian
Jun 14 '11 at 1:15
I'd give you +2 if possible. Excellent very helpful answer!
– Brian
Jun 14 '11 at 1: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 1:23
@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 1:23
2
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
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
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 Hartley
Jan 5 '16 at 17:25
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 Hartley
Jan 5 '16 at 17:25
|
show 2 more comments
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.
answered Jun 14 '11 at 0:47
alexalex
351k174786920
mark your answer ? :P
– afarazit
Jun 14 '11 at 0:48
@atno I can't for 2 days :)
– alex
Jun 14 '11 at 0:51
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 1:00
This does nothing to prevent the intruder from repeating the intrusion, repeatedly.
– tripleee
Jan 5 '16 at 6:58
@tripleee It can give you the insight to fix it though.
– alex
Jan 5 '16 at 12:30
|
show 1 more comment
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.
answered Jun 14 '11 at 0:47
alexalex
351k174786920
mark your answer ? :P
– afarazit
Jun 14 '11 at 0:48
@atno I can't for 2 days :)
– alex
Jun 14 '11 at 0:51
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 1:00
This does nothing to prevent the intruder from repeating the intrusion, repeatedly.
– tripleee
Jan 5 '16 at 6:58
@tripleee It can give you the insight to fix it though.
– alex
Jan 5 '16 at 12:30
|
show 1 more comment
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.
answered Jun 14 '11 at 0:47
alexalex
351k174786920
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.
answered Jun 14 '11 at 0:47
alexalex
351k174786920
edited Apr 12 '12 at 6:29
answered Jun 14 '11 at 0:47
alexalex
351k174786920
answered Jun 14 '11 at 0:47
alexalex
351k174786920
answered Jun 14 '11 at 0:47
alexalex
351k174786920
351k174786920
mark your answer ? :P
– afarazit
Jun 14 '11 at 0:48
@atno I can't for 2 days :)
– alex
Jun 14 '11 at 0:51
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 1:00
This does nothing to prevent the intruder from repeating the intrusion, repeatedly.
– tripleee
Jan 5 '16 at 6:58
@tripleee It can give you the insight to fix it though.
– alex
Jan 5 '16 at 12:30
|
show 1 more comment
mark your answer ? :P
– afarazit
Jun 14 '11 at 0:48
@atno I can't for 2 days :)
– alex
Jun 14 '11 at 0:51
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 1:00
This does nothing to prevent the intruder from repeating the intrusion, repeatedly.
– tripleee
Jan 5 '16 at 6:58
@tripleee It can give you the insight to fix it though.
– alex
Jan 5 '16 at 12:30
mark your answer ? :P
– afarazit
Jun 14 '11 at 0:48
mark your answer ? :P
– afarazit
Jun 14 '11 at 0:48
@atno I can't for 2 days :)
– alex
Jun 14 '11 at 0:51
@atno I can't for 2 days :)
– alex
Jun 14 '11 at 0:51
4
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 1:00
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 1:00
This does nothing to prevent the intruder from repeating the intrusion, repeatedly.
– tripleee
Jan 5 '16 at 6:58
This does nothing to prevent the intruder from repeating the intrusion, repeatedly.
– tripleee
Jan 5 '16 at 6:58
@tripleee It can give you the insight to fix it though.
– alex
Jan 5 '16 at 12:30
@tripleee It can give you the insight to fix it though.
– alex
Jan 5 '16 at 12:30
|
show 1 more comment
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
edited Jan 5 '16 at 17:24
Mark Davidson
4,92352953
answered Jan 27 '12 at 21:21
TaipoTaipo
762
@MarkDavidson Was it really worth editing a four-year-old answer just to expand a shortened link and nothing else?
– Nic Hartley
Jan 5 '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 5 '16 at 17:28
1
Blacklist the use of common link shorteneres in posts (on meta)
– Tas
Jan 6 '16 at 3:19
add a comment |
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
edited Jan 5 '16 at 17:24
Mark Davidson
4,92352953
answered Jan 27 '12 at 21:21
TaipoTaipo
762
@MarkDavidson Was it really worth editing a four-year-old answer just to expand a shortened link and nothing else?
– Nic Hartley
Jan 5 '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 5 '16 at 17:28
1
Blacklist the use of common link shorteneres in posts (on meta)
– Tas
Jan 6 '16 at 3:19
add a comment |
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
edited Jan 5 '16 at 17:24
Mark Davidson
4,92352953
answered Jan 27 '12 at 21:21
TaipoTaipo
762
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
edited Jan 5 '16 at 17:24
Mark Davidson
4,92352953
answered Jan 27 '12 at 21:21
TaipoTaipo
762
edited Jan 5 '16 at 17:24
Mark Davidson
4,92352953
edited Jan 5 '16 at 17:24
Mark Davidson
4,92352953
edited Jan 5 '16 at 17:24
Mark Davidson
4,92352953
4,92352953
answered Jan 27 '12 at 21:21
TaipoTaipo
762
answered Jan 27 '12 at 21:21
TaipoTaipo
762
answered Jan 27 '12 at 21:21
TaipoTaipo
762
762
@MarkDavidson Was it really worth editing a four-year-old answer just to expand a shortened link and nothing else?
– Nic Hartley
Jan 5 '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 5 '16 at 17:28
1
Blacklist the use of common link shorteneres in posts (on meta)
– Tas
Jan 6 '16 at 3:19
add a comment |
@MarkDavidson Was it really worth editing a four-year-old answer just to expand a shortened link and nothing else?
– Nic Hartley
Jan 5 '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 5 '16 at 17:28
1
Blacklist the use of common link shorteneres in posts (on meta)
– Tas
Jan 6 '16 at 3:19
@MarkDavidson Was it really worth editing a four-year-old answer just to expand a shortened link and nothing else?
– Nic Hartley
Jan 5 '16 at 17:27
@MarkDavidson Was it really worth editing a four-year-old answer just to expand a shortened link and nothing else?
– Nic Hartley
Jan 5 '16 at 17:27
1
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 5 '16 at 17:28
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 5 '16 at 17:28
1
1
Blacklist the use of common link shorteneres in posts (on meta)
– Tas
Jan 6 '16 at 3:19
Blacklist the use of common link shorteneres in posts (on meta)
– Tas
Jan 6 '16 at 3:19
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f6337976%2fbest-methods-to-clean-up-a-hacked-site-with-no-clean-version-available%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 0: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 0: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 0: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 1:05
Is Sony operating any osCommerce sites? ;)
– Brian
Jun 14 '11 at 1:14