route.php.jpg.* in download/

yes, rename download folder will help too.

Anything.

After reading this thread, I checked my sites and found 3 sites were infected with the same files mentioned here. I did some research and examination of the files - what damage they could do (and how they could do it) and also how the files arrive there.

The files are actually plain text php scripts. But they have an extension of .jpg added. This will not allow the hacker to actually exectute the php script, any attempt to access the files will just display a red-x (a broken image file) because of the .jpg entension.
An earlier post in this thread shows the hacker uploading the files, then accessing the same files. This was assumed to be an attempt to "run" the files, but could just as easily be an attempt to rename the files. This then makes sense and we can see the hacker's plan:
1. Upload the file with a temporary extension that is ALLOWED.
2. Attempt to rename the file to take off the .jpg, so route.php.jpg is renamed to route.php which can then be executed by the hacker and do its nasty damage.

In checking around the internet I found many infections of this, but no reports of any damage done. This is probably due to the fact that in most cases the second step (rename) fails. It fails because the proper safe permissions have been set by default in that folder (i.e. no permission for visitors to rename or execute files in that folder).
But not all web providers set the proper permissions by default. The hacker is looking for unsafe systems where the file can be renamed and then executed.

Also, not all infections seem to be in Opencart. But other infected systems seem to have one thing in common: a folder named "download". If this hack is scanning sites for a "download" folder it then makes sense to re-name that folder. This isn't foolproof but is certainly going to help. BUT you cannot just re-name the folder - you will cause your Admin to malfunction unless you take extra steps.

But why does the hacker choose jpg as the file extension? Looking into my own sites I spotted in the store settings the field "allowed uploads" which still has a list of file extensions in it. The first of those extensions happens to be jpg.

From all this (and other points mentioned) I have devised a plan to clean my sites up and set up some protection in future.

1. Delete the actual offending files using FTP.

2. Block the IP (31.44.188.140). The hacker can easily switch in future to a different IP but that's no reason not to block this one right now. If you have CPanel there should be a simple IP blocker in it. If not, you can use the htaccess method mentioned in this thread.

3. Make sure files created/uploaded to your site have safe permissions. Test this by uploading a small file yourself, then check its properties using FTP. The settings should be either 644 or 444 (644 is fine). If the file is not 644/444 you'll need to contact your web provider to fix this.

4. Go into your Admin>settings and clear out all the extensions listed in "allowed uploads".

5. Rename the Download folder to something else. Earlier in this thread "MyDownloads" was suggested, but I recommend something more abstract - a word that doesn't even contain "download" in it. Just make up a word.
Then edit both config.php files (the one in the root and the one in the admin folder). Find the line that defines the download folder path and edit it to the new folder name. Then upload these two config files. Your admin screens will then work okay.

6. In notepad, create a file called .htaccess containing the following four lines, then upload the file into your newly renamed download folder:

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

This will simply prevent any access to any file in this folder. Even if the hacker succeeds in uploading a file, he then cannot get any access to it - and more importantly neither can any other unsuspecting visitor.

Of course, this plan only applies if you are NEVER going to allow visitors to upload files in the product options. If you do plan to use uploads you'll have to look elsewhere for solutions.

I hope this can be of help to others, but be aware this is NOT necessarily a complete lst - other secure actions can be done aswell. But my list here simply handles the most obvious things you should do right now.

Very useful post.
I had a few errors in the log after changing the download folder name so will edit the config files - thanks.

Hopefully this thread will be read by many who run OC stores.

gjanezic wrote:I had 6 effected stores, all version 1.5.1.3.
All of them used different 36 char long strings for encryption keys (generated with uuid()),
I really doubt anyone could guess the key.

However I also have a store version 1.5.4, which did have the same files,
but access.log said the 'hacked' could not access them:

Code: Select all

access_smartclick.log.5:31.44.188.140 - - [25/Mar/2013:20:01:05 +0000] "POST /index.php?route=product/product/upload HTTP/1.1" 200 196 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1"
access_smartclick.log.5:31.44.188.140 - - [25/Mar/2013:20:01:05 +0000] "GET /download/route.php.jpg.4d0a6ff31f71cc20ab9d572bdfcdb7a0 HTTP/1.1" 404 13398 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1"
access_smartclick_php.log.5:31.44.188.140 - - [25/Mar/2013:20:01:05 +0000] "POST /index.php?route=product/product/upload HTTP/1.0" 200 160 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1"
access_smartclick_php.log.5:31.44.188.140 - - [25/Mar/2013:20:01:05 +0000] "GET /download/route.php.jpg.4d0a6ff31f71cc20ab9d572bdfcdb7a0 HTTP/1.0" 404 13385 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1"

Probably due to .htaccess roule:
RewriteRule ^download/(.*) /index.php?route=error/not_found [L]

Hope it helps.

Can you confirm that the file name was actually "route.php.jpg.4d0a6ff31f71cc20ab9d572bdfcdb7a0" in the 1.5.4 store? The encryption library was changed so the hacker shouldn't have been able to figure out the file mask, which is probably the reason they couldn't access it (they're looking for 1.5.3.x and earlier stores).

I'm not sure by what process the hacker could actually use the file though. The normal way is to try sticking a null-byte in the file name (which isn't possible in current versions of OpenCart and PHP) but the hacker isn't using that.

I can confirm the filename was route.php.jpg.4d0a6ff31f71cc20ab9d572bdfcdb7a0, I am using 1.5.4.1 and encryption key is a random string.

(1) Attacking an uploader is often probably just fundamentally analogous to port-snooping using the machines' game of "knock, knock, who's there?" via the network ping command (the target machine without ping on poses an increased obstacle). If the hacker looks for OC with usable upload capability, and can slip in file(s), then he knows something about (dis)allowed extensions as well as sizes. If he can moreover see it or access it, then he knows something about the server, ranging from .ht*, php version and php,ini, to OC settings. Barring directory listings in *.ht is one defense, along with giving directories names that won't matter to people. Unfortunately, most of the time (across the board) file extensions are "believed" rather than looking at file content.

(2) When uploads are allowed and expected, then in the same frame of mind that registrants and whatnot must be approved administratively before they are active on-line, uploading can be to a virtual vault and files can be reviewed, then be moved to wherever they might be intended to be downloadable. If there are too many of those to review manually, then vulnerability accordingly increases. One plain tipoff is plainly file names (the example *.jpg has a name and name length that would not occur to most benign uploaders). Upload maxima (file numbers, sizes) can be constrained to lesser values than are allowed by php.ini for other purposes. Separate scripts can be called into play via "include" if appropriate. Approval or manual preregistration of registrants can offset many problems, with full attention to the sorts of subtle hints that can be perused and if need be tracked down (again, depending upon numbers of folks to process).

gjanezic wrote:I can confirm the filename was route.php.jpg.4d0a6ff31f71cc20ab9d572bdfcdb7a0, I am using 1.5.4.1 and encryption key is a random string.

Are you sure you're looking at the right store? I'm not really sure how that could happen with the new encryption class in 1.5.4.1 with a unique key. I've updated Secure Random Password Reset on the off chance it's the mt_rand() issue.

I found these files in my 1.5.2 installation too when I was doing general cleanups for the issue I discussed in another thread about resource limits reached. Could this have caused that? It seems like all the little things I did including cleaning those files out of the download folder (which I didn't mention in that thread) have solved the issue, so now I'm wondering if this might have been the reason all along?

I have followed all the security steps listed in this thread so it should happen again.

as long as your encryption keys are changed, they can still upload the files, but they shouldn't be able to find the files and run it. Best bet, change your download folder to another name and update in your config.php files.

As to attacks, see also:

http://forum.opencart.com/viewtopic.php ... 22#p402816 and posts following it
http://forum.opencart.com/viewtopic.php ... 19#p402919
http://forum.opencart.com/viewtopic.php ... 27#p403027

if you guys won't be using the file uploader for options, you might want to just stop the files from being moved to your download folder. Attached is a vqmod to do that.

Consider downloading what he just offered . . .

Here are two concurrently hacked websites on the same host, at least one of them is OC, and at the moment we don't yet know whether the download directory was involved, but browsers offer to download the file that leads to discovering that there are plural domains affected on that host:
http://forum.opencart.com/viewtopic.php ... 43#p403443

We now have these additional files,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.jpg.3b11866ae29410f515f60ebc43e657d6 (6 kb) 2013 Feb.
route.php.jpg.a209aabd9fb26ee8f671753a198526b0 (1 kb) 2013 Mar.

which I just found in a download/ directory (which I abruptly renamed to gibberish/) and safely brought down for a looksee and then deleted from the server. Those happen not to have caused the problems that were being remedied meanwhile.

Gaining familiarity with the directories and looking for such out of place files, as well as security measures, go a long way toward stopping problems in advance. In no small measure we ourselves are our often most effective anti-malice scanners on our severs.

I just can't seem to find a vector of attack on this. Does route.php.jpg contain code in the EXIF data or is it just a renamed PHP file? Is your .htaccess file normal?

all these files contain the following:
There is no meta/exif data.

they can't run it. It should be safe

It's relying on cookie poisoning for the rest of whatever it's trying to do which is really weird when they're (presumably) already executing remote code. The only way I could find to make this work is:

1) Putting a null-byte in the file name so the ".jpg" is dropped, but that only works on old versions of PHP you can't even run OpenCart on and isn't what the hackers are doing with the given file names and GET requests.
2) Run include() on uploaded files, which OpenCart doesn't do.
3) Modify or add an .htaccess file so JPG files are run as PHP, which there hasn't been any evidence for yet.

But it seems really weird that hackers would spend all this time targeting sites with a hack that doesn't work.

The text does vary but they're text files along those lines nonetheless, with unexecutable self-abortions. However, that they've taken the tack they have is instructive, as to how OC is safeguarded, and as to how "current" thinking such as it is aims and how to deal with it in order to see how it might be made to work or to defeat it (as just above). A danger lurks in NOT going manually through the directories (including but not exclusively download/ or its gibberish/ equivalent) from time to time to look for such oddments, since sooner or later one of these lunacies will be armed and destructive.

something to add on....I manage to find one of my client with such malicious files. Somehow the attack got further into system/library/customer.php and they inserted codes to listen for credit card information and they store it in your cache folder. Here's some extra details: http://forum.opencart.com/viewtopic.php?f=10&t=102456

* Edit: had a typo....