route.php.jpg.* in download/

MarketInSG wrote:something to add on....I manage to found 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

Great post. It looks like the attackers are finally starting to step up their game.

Do you know how the breach occurred? It seems like the number of stores which would be vulnerable is small (old version of OpenCart, default security key, IIS) but I'm concerned maybe there's something that's been missed.

my client was on v1.5.3.1 or v1.5.4.1. But her store was upgraded from a previous version, hence the encryption key was still 12345.

They used eval to run their php codes and added those listener to the customer.php file. From there, they captured data and encrypted the data and store it into their own cache file which is spelled as cacne.language. Who would have thought of storing values in the cache folder where we rarely look into it. The data they stored are encrypted and since part of their codes are stored in their cookie on their computer, I couldn't go further.

From my understanding, they are just stealing credit card information, along with the addresses! Smart guys though.

There are several ways in. Idiosyncrasies of OC (e.g., unrenamed default "download/" or "admin/" as a dir name) offer places to guess, but scripts buried in other software (including blogs) can provide easily hooked entries. The attackers who have already stepped up their game are in the minority, but can sooner or later arrive. Finding a complete hacker console laden with pregnant commands is certainly enlightening, since it's brazen but for being cleverly hidden. (That's one of a couple of incidents that stand out among the several that I've resolved through the past few weeks, and that I'll shortly summarize, even with pictures, in posts.)

MarketInSG wrote:They used eval to run their php codes and added those listener to the customer.php file.

How were they able to execute the code?

the route.php.jpg.* and other funky files led to them writing to system/library/customer.php with their custom codes. The encryption key wasn't changed so they can easily find out the name of the actual files. Can't be 100% sure on that, but there's where it seems to come from. I found a whole chunk of CC information encrypted when I found all these codes around her server. So I guess we roughly know what's their aim of all these now

I did a bunch of research the first time around and just couldn't find a feasible way to execute an image or a PHP file renamed as an image. Everything I found required long-patched software versions or the user doing something very stupid to their server setup. Obviously there's some way to do this as sites are getting hacked but I'm not sure how and that's the troubling part. Is it Apache? IIS? PHP? Directory permissions? OpenCart itself? The only silver lining is the hack seems to fail far more than it succeeds (if reports on the thread are anything to go by).

Remaining alert to exact names and extensions will be important for all of us to look for. The "cacne.language" (MarketInSG) calls to mind customary attacks in Windows using "explore" and even "explorer" for commonly expected "explorer" plus an extension that is .exe, .dll, etc., in the wrong directory setting.

For what it's worth, the code (over there) may be relatively impotent, cached or not (http://forum.opencart.com/viewtopic.php ... 62#p411723).

I am satisfied that OC itself and properly set up Apache (not necessarily IIS), php, mysql, supportive Linux (even Windows), etc., are secure in their own right (per rph's short list). There are still ways in, and ways to find those, even if we change default encryption keys and default dir names (even without converting admin/ or download/ to gibberish).

A long known avenue in is whereami.cgi, which allows throughput commands, and which if found should be expunged on the spot (some blogs still use it, for example). With an installed hacker console (a sight to behold), manipulating filespecs to lop .trailers in order to launch an executable extension is easy, along with playing havoc with dir and file permissions by resetting them to favor the malicious access; all via http, and all within literally two seconds per connection. Those are both part of a now aborted globally operated instance I'll shortly summarize in a post. It's one of two noted at (3) and (4) at http://forum.opencart.com/viewtopic.php ... 95#p408895.

rph wrote:I did a bunch of research the first time around and just couldn't find a feasible way to execute an image or a PHP file renamed as an image. Everything I found required long-patched software versions or the user doing something very stupid to their server setup. Obviously there's some way to do this as sites are getting hacked but I'm not sure how and that's the troubling part. Is it Apache? IIS? PHP? Directory permissions? OpenCart itself? The only silver lining is the hack seems to fail far more than it succeeds (if reports on the thread are anything to go by).

That's where we might have to look into. The folders have access permissions, so they are surely able to access those files. It will be just how do they run it. Apache might have a vulnerability which they are making use of to run those files. Perhaps..we won't know till we get more information. Maybe someone would love to set up some honey servers for them to play with

In the worst instance that I recovered I set a trap. They have continued coming back; their toys were seriously modified, but their two-second visits (probably robotic) haven't figured that out. The Linux position that actually seems to matter is Group. They would like to have Owner (root), but with Group they can operate as part of the machine (Apache included). World can be set to 0 and they get in and around (for example, as in 750/640). We just don't have enough Navy Seals, yet, to dispense with them all on one day.

MarketInSG wrote:Perhaps..we won't know till we get more information.

Are there any logs from the person who was hacked, by chance?

MarketInSG, you've undoubtedly already checked, but the server may well have both ftp logs and Apache logs (both specifically so-named), which will show IPs and timestamps in and out. The logs can be edited a trifle into .csv and sorted by IPs and durations as well as times in a spreadsheet program. If they aren't available pro forma, then support should be willing to provide them. And rph's "by chance" anticipates a possibility that to say the least isn't welcome. The last time I wanted the (available) ftp and Apache logs for the same sort of purpose, there was a "mysterious gap" several months long, which told me something by itself. I had already sorted out from timestamps a master calendar, and with full root access in the account, some not all of the logs had evidently been compromised by the forces of evil themselves. I ordinarily set up my own code and logs, both well buried, for the sake of recapping traffic as well as potential traffic mishaps. In the two server logs and mine I can see the forces of evil revisiting the trap, evidently completely unaware at two seconds per visit that the website is locked down and their now specially modified implanted toys are impotent except for sandbagging them.

rph wrote:

MarketInSG wrote:Perhaps..we won't know till we get more information.

Are there any logs from the person who was hacked, by chance?

I will go dig around for the FTP and server logs if possible. But for OpenCart error logs, it only showed signs of the software running and there was some undefined index xxxxx in customer.php file which kind of led me there too.

Yeah, generally the OC and vqmod logs are helpful in these situations mainly by way of showing timestamped bouts and spurts of code blunders.

I was thinking more the server logs but anything would be helpful.

The ftp logs and the Apache logs will hopefully be complete and revealing, the OC and vqmod logs will hopefully augment those with corresponding entries and not have been rezeroed too recently to show any. He'll see when he looks. I think that your comment above will bring the former to to mind right away, and he'll know about all four anyway.

Hey I also Found this code on my download File there are 4 files
one is aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.jpg.33f34fa4f5e8b0a8f84115f8676e4967
2nd one route.php.jpg.54112ba671695dea6a7eec1851ac4645
3rd one route.php.jpg.e0d4df2d72874492016c004fdb0bf24d
4th is index.html

and for few hour i am unable to access my opencart http://www.lensbazaar.com/admin
admin panel and also my add to cart button not working and cart also

any one please tell me what is this?

is this hacking ? Please tell me

Thanks

It's possible. Everything seems to be working fine now, though. At the very least you should delete

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.jpg.33f34fa4f5e8b0a8f84115f8676e4967
route.php.jpg.54112ba671695dea6a7eec1851ac4645
route.php.jpg.e0d4df2d72874492016c004fdb0bf24d

And follow the instructions for securing your site in this thread. You may also want to hire a developer to look over your site/server logs and make sure there weren't any breaches.

Unless your download/ directory is otherwise blocked by .htaccess or similar .ht* files, the very presence of an index file, such as your index.html (index.php, etc., also qualify) invites a browser to land there without knowing any file names in the directory. Browsers look first at .htaccess files, then for a sequence of landing index.* files, while they seek, reach, and then try to land in a directory. (Under certain circumstances the host will insert index.*, mainly when you add a domain or a subdomain to your account and the server then makes and minimally populates the directory for it.)

If you did not put index.html there, then it could well have been put there along with the oddball "jpg" text files. Now about four hours later in current Firefox, for admin/ I am seeing a normal Version 1.5.2 log-in screen, for download/ I am seeing Forbidden plus 404 unfound, and for download/index.html I am seeing a double 404 unfound. That under the circumstances bodes well.

There's enough reading above to keep you attentive to your directories for a little while. Thanks, urace, for bringing it up, a sense of numbers and of variants is helpful.

A 0 byte index.html file is normal.

Re:

A 0 byte index.html file is normal.

I had those route.php.jpg etc. a while ago and deleted them but my index.html is containing this:
Should I delete that?

Tks
Cleo