Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Files injected into images directory


adninja

Recommended Posts

Kalan,

 

 

CLEAN and SECURE your website. The hacker is gaining access to your /images directory through one of the known vulnerabilities and/or a backdoor he/she has installed.

 

You can't just protect the /images directory, you also have to locate and remove all malicious code and anomalous files.

 

 

Chris

Link to comment
Share on other sites

Running 2.2. I was running 2.3, but that destroyed my layout, and during the time I had it running there was a hacker that injected a spam email sending script into the image directory. That happened twice during the time I was upgraded, but not since I switched back to my old version. Now I just have simpler scripts getting placed there.

 

I have done a few mods (specifically the ones that are listed to increase security). Unfortunately the buggers are still getting through.

Link to comment
Share on other sites

I found a file called Thumbs.db that did not appear in the 2.2 install that I downloaded to use as a reference. I deleted it, so we will see what happens. I am also going through the site with a fine toothed comb.

Link to comment
Share on other sites

After combing through my shop I found a couple of other files that I ended up deleting. Unfortunately this seems to no be the backdoor that was being used, since it happened again not long after they were deleted. I did, however, find a .htaccess file in the root directory of my site that pointed straight to my images folder in my shop. I think that might have been it. Now we wait and see.

Link to comment
Share on other sites

Kalan,

 

 

Also check for unknown administrator accounts, change your FTP password, Admin Password, Database Password and install the '5 must have' security contributions.

 

 

 

Chris

Link to comment
Share on other sites

I spent the day yesterday installing all of that, and everything has been changed multiple times over. Of course, there was still a new php file installed in the images folder not long ago. The good news is that they only got a simple one in, and none of the malicious code that they have been planting recently.

 

I am going to do a full wipe of the software and plop on a clean install. Since my webhost did the install for me, what files would I need to edit to make it work with my current databases? Also, what file stores my layout?

Link to comment
Share on other sites

Kalan,

 

Keep your /images directory, your TWO configure.php files and your stylesheet.css so you can maintain 'most' of the layout changes. Any changes coded into the other files will be lost.

 

Also, use your existing database. However, I must warn that it too may be hacked.

 

 

Chris

Link to comment
Share on other sites

I am having the same issue though i know nothing about code so I do not know how to look for backdoors. I do have all the '5 must have' installed. i keep getting email.php, tmp.php and another one i cannot remember what it is. Any help is greatly appreciated.

Link to comment
Share on other sites

Rosa

 

If your site is infected the 5 must haves will not disinfect it.

 

VTS, Virus Threat Scanner, and Site monitor will indicate file that have suspicious code in them. You then have to remove it.

 

Also if there are any files that are not in OSC or are in the wrong place they probably need to be deleted.

 

HTH

 

G

Need help installing add ons/contributions, cleaning a hacked site or a bespoke development, check my profile

 

Virus Threat Scanner

My Contributions

Basic install answers.

Click here for Contributions / Add Ons.

UK your site.

Site Move.

Basic design info.

 

For links mentioned in old answers that are no longer here follow this link Useful Threads.

 

If this post was useful, click the Like This button over there ======>>>>>.

Link to comment
Share on other sites

  • 1 month later...

I too am have a hacker problem and know very little about coding so, like risela above I do not know how to look for backdoors. I started yesterday to do the '5 must haves' installed. Site Monitor threw up a few files for me to check although I can't get that contrib to send mail to me for some reason?

 

So, I logged on to my websites admin today but, like the other day I am completely shut out ... was greeted with the error message

 

Parse error: syntax error, unexpected T_VAR in D:\virtualservers\mystore\mystore.com\wwwroot\admin\includes\functions\html_output.php on line 32

 

My host got me back into the admin site yesterday but I think they have washed there hands of the situation now!

 

I looked this morning in my image folder via ftp and noticed a few more files I am unsure of including the 3 from yesterday that Site Monitor showed? They are:

 

data.dat

foot.dat

google3f12dbc72bc7a422.php

html.dat

Index.php

stats.txt

template.tpl

 

Should any of these be cause for concern? I am unsure of what to look at ... this has been going on since january when I was out of the country so, unfortunately I don't have a backup of the site thats recent, only a Dec 5th backup which should be okay but, I have done several contribs since then and added hundreds of products!! Is there a way of keeping all my current products if I use that backup?

 

Thanks for any help

Danny

Link to comment
Share on other sites

Delete anything in your images folder that is not an image.

 

There will probably be some added javascript in the html_output.php as well. If you have a backup of that file then upload the backup.

 

If you haven't already done so you need to protect your admin folder.

 

Then continue with the security advice that has been offered by others concerning cleaning your site up.

 

In your includes folder it will pay to have a file called .htaccess if there isnt one already there, with this code in it.

 

Options All -Indexes

<Files *.php>
Order Deny,Allow
Deny from all
</Files>

 

And in the images directory add a file called .htaccess with the following content:

Options All -Indexes

<FilesMatch "\.(php([0-9]|s)?|s?p?html|cgi|pl|exe){:content:}quot;>
  Order Deny,Allow
  Deny from all
</FilesMatch>

 

Those two will 'put a dent' in attackers accessing any backdoor code they have installed around your site. But unless you have a backup of your site prehack, you will have to go through your files looking for additional code, as well as additional files that may have been added.

 

Sometimes looking at the "Last Modified" date and time in your FTP client can help you narrow which files have been edited recently....as in by an attacker.

 

But 'in general' there are 3 types of code to look for.

 

1/ Upload code: (see: this link) code that allows an attacker to upload files, some you have already found in the images folder.

2/ Javascript (see: this link) appended into files.

3/ Base64 strings: Incredibly long strings like CCQYC28qUUllwKcVWx4twGDQCs+Tr0b/FiKnKHbnQQDFz7S0Bjh0FBfiX9LAy9yYHLpyu6PDOBMKs8..... that have been added into either the head or footer of main files like includes/application_top.php, includes/header.php, includes/languages/english/index.php etc

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

Delete anything in your images folder that is not an image.

 

There will probably be some added javascript in the html_output.php as well. If you have a backup of that file then upload the backup.

 

If you haven't already done so you need to protect your admin folder.

 

Then continue with the security advice that has been offered by others concerning cleaning your site up.

 

In your includes folder it will pay to have a file called .htaccess if there isnt one already there, with this code in it.

 

Options All -Indexes

<Files *.php>
Order Deny,Allow
Deny from all
</Files>

 

And in the images directory add a file called .htaccess with the following content:

Options All -Indexes

<FilesMatch "\.(php([0-9]|s)?|s?p?html|cgi|pl|exe){:content:}quot;>
  Order Deny,Allow
  Deny from all
</FilesMatch>

 

Those two will 'put a dent' in attackers accessing any backdoor code they have installed around your site. But unless you have a backup of your site prehack, you will have to go through your files looking for additional code, as well as additional files that may have been added.

 

Sometimes looking at the "Last Modified" date and time in your FTP client can help you narrow which files have been edited recently....as in by an attacker.

 

But 'in general' there are 3 types of code to look for.

 

1/ Upload code: (see: this link) code that allows an attacker to upload files, some you have already found in the images folder.

2/ Javascript (see: this link) appended into files.

3/ Base64 strings: Incredibly long strings like CCQYC28qUUllwKcVWx4twGDQCs+Tr0b/FiKnKHbnQQDFz7S0Bjh0FBfiX9LAy9yYHLpyu6PDOBMKs8..... that have been added into either the head or footer of main files like includes/application_top.php, includes/header.php, includes/languages/english/index.php etc

 

 

Have you tried the following code for .htaccess:

 

Options +FollowSymLinks
RewriteEngine On  
RewriteBase /


########## Begin - Rewrite rules to block out some common exploits
## If you experience problems on your site block out the operations listed below
## This attempts to block the most common type of exploit `attempts`
# Block out any script trying to base64_encode crap to send via URL

RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
########### End - Rewrite rules to block out some common exploits

########## Block bad user agents
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:[email protected] [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus

ServerSignature Off
RewriteCond %{REQUEST_METHOD}  ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]
RewriteCond %{THE_REQUEST} 	^.*(\\r|\\n|%0A|%0D).* [NC,OR]

RewriteCond %{HTTP_REFERER}	^(.*)(<|>|’|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{HTTP_COOKIE} 	^.*(<|>|’|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{REQUEST_URI} 	^/(,|;|:|<|>|”>|”<|/|\\\.\.\\).{0,9999}.* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww-perl|curl|wget|python|nikto|scan).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|’|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

#Block mySQL injects
RewriteCond %{QUERY_STRING}	^.*(;|<|>|’|”|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC,OR]

RewriteCond %{QUERY_STRING}	^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]
RewriteCond %{QUERY_STRING}	^.*\.[A-Za-z0-9].* [NC,OR]
RewriteCond %{QUERY_STRING}	^.*(<|>|’|%0A|%0D|%27|%3C|%3E|%00).* [NC]
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]

 

any attempts of hacking should show 403 Forbidden error

Please read this line: Do you want to find all the answers to your questions? click here. As for contribution database it's located here!

8 people out of 10 don't bother to read installation manuals. I can recommend: if you can't read the installation manual, don't bother to install any contribution yourself.

Before installing contribution or editing/updating/deleting any files, do the full backup, it will save to you & everyone here on the forum time to fix your issues.

Any issues with oscommerce, I am here to help you.

Link to comment
Share on other sites

any attempts of hacking should show 403 Forbidden error

 

The admin bypass exploit would not be caught in the above htaccess code, and that is the basis of 99% of oscommerce problems.

 

RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]

# Block out any script that includes a <script> tag in URL

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]

# Block out any script trying to set a PHP GLOBALS variable via URL

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

# Block out any script trying to modify a _REQUEST variable via URL

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

# Send all blocked request to homepage with 403 Forbidden error!

RewriteRule ^(.*)$ index.php [F,L]

########### End - Rewrite rules to block out some common exploits

 

There are a number of problems with this.

 

1/ Most of the eval() base64 code that has been injected into files, contains the function base64_decode not encode and almost never in a query string, but rather in either POST variable data or in a file being uploaded.

2/ Via the cookie_usage.php type exploit code, all malicious javascript will be uploaded in a file rather than injected via a query string. If javascript is appended into files it can also be done via fwrite(). So it will not be caught in the Query_String blacklist trap.

 

RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]

RewriteCond %{THE_REQUEST} ^.*(\\r|\\n|%0A|%0D).* [NC,OR]

 

RewriteCond %{HTTP_REFERER} ^(.*)(<|>|’|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

RewriteCond %{HTTP_COOKIE} ^.*(<|>|’|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

RewriteCond %{REQUEST_URI} ^/(,|;|:|<|>|”>|”<|/|\\\.\.\\).{0,9999}.* [NC,OR]

 

RewriteCond %{HTTP_USER_AGENT} ^$ [OR]

RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*(libwww-perl|curl|wget|python|nikto|scan).* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|’|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

 

3/ Its probably ok to allow a HEAD request since most legitimate search spiders still send requests using HEAD, banning it 'may' affect your sites Google ranking for example.

4/ Referers, cookies and user-agents can be spoofed in an HTTP Header request, so this may catch them the first time around, but HTTP Header packets could just be amended and bypass this filter. The point is though that the attacks so far have not been via these HTTP Headers but via a two tiered attack method that firstly used the admin bypass exploit to load sites with file upload code, then attempts to exploit that code at a later date when sites were patched.

 

The message needs to be clear. Hacked websites need to be cleaned out of all malicious code. See: http://www.oscommerce.com/forums/topic/372970-malware-cookie-usagephp-explained/

 

If this type of malicious code is still resident then there is not much any security measures can do to prevent exploitation including most of what is in that htaccess file.

 

Once the site has been properly secured, then yes it is a matter of adding a good black and white list HTACCESS file, similar to the one above, also there are other contribs with similar ideas in them as above. Also you will need some security code as well as a fallback, like Security Pro and Osc_Sec.php (see link in my signature) and IP Trap if you want the attacker to see a message of why they were banned.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

Taipo,

 

Thanks for fighting the good fight. But, please also mention that exploited site owners should dump their 'configuration' table to see if any php code was injected onto it. The data from this table is constantly added to osC webpages, which is why even after cleaning the code, they keep getting reinfected.

 

If they are php coders, here's an extract that will show all data on the 'configuration' table:

 

$config_query = osc_db_query("select * from configuration");

while ($config_ar = osc_db_fetch_array($config_query)) {

foreach($config_ar as $curFld => $curVal) {

print(preg_quote($curFld, '/')." = ");

print(preg_quote($curVal, '/')."<br>");

}

}

 

 

HTH,

Jim

Link to comment
Share on other sites

Yeah that is some nasty stuff. My advice generally for most Oscommerce users is to build a completely new site with the new 2.3.1 version released over a year ago, and also to install the security code. For those though that just believe that this is too much work, the next level of advice is as above.

 

Hacked websites need to be cleaned out of all malicious code.

 

The types of code that can be injected via these upload type files are too numerous to list. In fact on many shared server configurations, ANY code the attacker wishes can be added to files, any files they wish can be added to a server via these backdoor files and file additions.

 

The example you gave above is a good example of why securing the admin folder is just not enough. If an attacker has the ability to upload and append to current site files they can upload code that one would assume can only be executed with access to the admin directory. But lets not forget that the admin directory is just a set of files that have php code level permission to access the database.

 

Any files uploaded to anyone on a website can also access the same database, print out database variables, emulated the mass emailer that is in admin, back up the database, etc. Think of those files as admin files without admin permissions attached. Many of those shell codes we often refer to that are found in the image directory, are in actuality, just file managers with added benefits for the attacker.

 

So when a user uses a file manager like the one in admin, or a web host provided file manager in a control, they will be experiencing the same level access the attacker will have via these malicious files uploaded to various directories.

 

The best advice again is to build a new website with the latest oscommerce code rather than try to upgrade over the current site (which for many this often means uploading the new code over top of the old which does not rid them of rogue files), failing that, you need to go through every file in your backup if you have one before restoring it to check for rogue code and files, if no backup and you do not intend to build a new site then you hav eno choice but to go through every file in your site and replace anything that has had code added to it, or delete any file that is not a part of the oscommerce file list.

 

Some of the other types of advice that have been offered in the past have lead hacked users to believe that if they renamed the admin directory, deleted the files from images directory and input some nice htaccess they would be fine. The attack strategy on Oscommerce already planned for this, and now that many of the older version sites have been patched, they are moving to the second phase which is to exploit the trojaned files to further add not just spam to your site, but other install and upload codes.

 

This could go on indefinately unless site users make the hard decision to open a new site and import the database over and the images from the images directory. For others on the standard web permissions configuration where a directory is write protected at 755 and a file is write protected at 644, this is less of an issue because the damage is usually only restricted to those writable files and writable directories.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

Taipo,

 

All valid points. In my case, I was able to dump every table to see if any other injected code exists, plus compare a safe backup byte-by-byte with the latest site code. This quickly highlighted all my issues. (My original issue was that my FTP password got compromised at a public WiFi site, which definitely won't happen again!)

 

I'm even thinking of extending the osCommerce (or PHP MySql) code to disable any injected code. At each Sql pass, scan the result for '<?' and put a space between those 2 characters. This should get rid of any future PHP injection issues.

 

Thanks,

Jim

Link to comment
Share on other sites

There are a number of addons that already cover injections if you want to look at them. Security Pro, PHPIDS and Osc_Sec.php (there may be more). It best caught before it enters the database. In fact its best the hole that allows for manual injection is patched in the first place.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

  • 2 weeks later...

Taipo: That's why we always get a clean version of oscommerce and compare with the hacked one (diff -r). That tells us what "core" files were modified, what else was added ,etc.

 

After that, protecting (and renaming) the admin directory, patching everything, scanning for backdoors, is the thing to do...

 

Why is that? For most users it is not simple to wipe everything out an start again... But when possible upgrading is the best option.

 

Thanks,

Link to comment
Share on other sites

It all depends on the level of damage. For example I cleaned out a couple of sites recently, one was a Tomatocart variant of Oscommerce. Every php file, html file and js file had appended code, some 5000+ files including JSON and PHPIDS, and the template files as well. It seemed they had originally been using 2.2.1 and had upgraded to Tomatocart which is fairly secure, but missed just one rogue file that had been inserted into the 2.2.1 directory somewhere, which gave the attackers unlimited access to do as they wished to site files due to the fact the site was hosted on the type of configuration where the user and script have owner privaleges.

 

At some point the call has to be made to start again, and in that I mean, delete the entire web folder (not database) and reinstall a fresh version and template with addons. The time factor can be a red herring when it comes down to the amount of sites that are being repeatedly reinfected because they missed something, the loss of income, the loss of trust by users etc.

 

Restoring from backups, how do you know the backups are not also affected? Thats a valid question to ask.

 

The main thing for 2.2.1 users is to patch that faulty PHP_SELF code in the application_top.php files. A cleaned out site with the PHP_SELF code patched does not need any other additional things like changing admin directory names, but it doesnt hurt to do so as a general principle.

 

It reminds me of back in the day with those XMB forums when the patch had come out yet most users opted to tough it out with vulnerable versions of XMB until the attack vectors got leaked and in the end it was the defacements that drove people past the rhetoric of the vanguards of the old system who had been telling them it was safer to add this and that addon to their forums to protect them, when the upgrade was the real solution albeit not a straight forward proceedure for heavily modded sites.

 

But most forums lost the majority of their members before they caved and upgraded, most never returned to their former glory. The ones that did were those that made the hard call and upgraded to the patched version which often meant starting again and manually porting the DB or getting someone to do that for them.

 

Many of those that chose to tough it out eventually completely lost confidence in XMB altogether and moved to other scripts like phpBB and vbulletin to never return to XMB because of the total experience had been so bad but most also never were able to return their sites to their former greatness.

 

Its all those other psychological and social factors that need to be added into the equation than just an issue of difficulty in upgrading a heavily modded site to the secure version.

 

The less a user knows about php and how to clean their site out, the better it is for them to find someone capable to upgrade the site for them, because in the long run, repeated hacks are fatal to the longevity of a retail site and the total energy spent trying to prop up an insecure version can be more than the total energy spent to clean the slate and start again with the latest, which guarantees that none of the old bugs will survive the site change.

 

However if you know your stuff, by all means patch your 2.2.1 sites with cleaned up file headers and footers, cleaned out directories, protected admins, htaccess protection, user input filtering, and patch the $PHP_SELF code.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

When trying to find out how a website was infected, scan through the access logs.

 

Some strings to look for are:

 

../../../

base64_decode

<script

any http:// after a ?

 

Often times we find one line of code injected into a valid .php file that when sent the proper string, will automatically infect certain files in the website. We've been seeing more and more of this.

 

Also, you have to check all the payment modules as we've been seeing more code injected there that actually steals the credit card information and emails it to the hackers right before or right after it's sent to the credit card processing servers.

 

Some other issues we've been seeing is where the file is created, run then deleted. This leaves the file running even though it's not there.

 

Sometimes hackers will try to upload C code (C programming lanugage) and compile it. This often times doesn't work if the gcc compiler isn't available. Perl scripts are also sometimes used to launch their own webserver inside a website.

 

Just my two cents...

We Watch Your Website - so you don't have to!

no outside links allowed in signature!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...