29 replies to this topic

[adninja]

I keep having hackers inject files into my image directory. I have tried using an .htaccess file to protect the directory, but then none of my images show up. Is there a way to keep this from happening?

[DunWeb]

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

[website-security]

Which is the version you use and are there any reasons to avoid updates (customizations for example)?

[adninja]

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.

[DunWeb]

Kalan,


Look for anomalous files on your server. There is obviously a back door.



Chris

[adninja]

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.

[adninja]

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.

[DunWeb]

Kalan,


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



Chris

[adninja]

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?

[DunWeb]

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

[adninja]

I have looked through the database and I have not seen any evidence of hacking. Of course, I may not be looking for everything. What would be something that would throw up a red flag?

[adninja]

So I found a line of Base64 code in my shop. Just about every php file was hit. I am lobbing it out right now. This may take some time.

[risela]

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.

[geoffreywalton]

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

[Backcountry_Surfer]

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

[Taipo]

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

[web-project]

Taipo, on 25 March 2011, 12:29, said:

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:craftbot@yahoo.com [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

[Taipo]

Quote

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.

Quote

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.

Quote

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://forums.oscommerce.com/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.

Edited by Taipo, 26 March 2011, 22:01.

[jmose]

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

[Taipo]

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.

Quote

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.