Home > Security > Update on priemIframe hacks

Update on priemIframe hacks


From all the feedback I receive, it seems like the attack is focused on german websites. I drew a flow explaining how the circle of death & destruction works:

Roland Bollmann from www.robodurden.com wrote a php script to cleanup hacked servers. Thanks for the submission:


<?php
// hacked.php version 1.01 2011/01/24
// upload this script somewhere onto your server
// call "find -name php" to get the path to php (like /usr/lib/cgi-bin/php)
// and then call "/usr/lib/cgi-bin/php /home/www/web6/hacked.php path=/"
// to scan and repair the entire server ;-)
//
// www.robodurden.com usage at your own risk :-)

$hC = array(
'filereg'    => '/^.+index\.[^.]+$/i',
'hackmatch'    => '<iframe.+?priemIframe\.php.+?<\/iframe>',
'path'        => '.',
'test'    => 0
);

$sHtml = $_SERVER['PHP_SELF'] ? '<br/>' : '';

if ($sHtml)
{
print "run from http$sHtml\n";
foreach($hC AS $name => $var)
{
if (isset($_GET[$name]))    $hC[$name] = $_GET[$name];
}
}
else
{
print "run from console. usage: hacked.php [option1=value1] [option2=value2] ..\n";
for ($i=1; $i<count($argv); $i++)
{
list($name,$var) = explode('=',$argv[$i]);
if (isset($hC[$name]))
{
$hC[$name] = $var;
}
else    die("unkown command '$name'. possible commands:
'filereg'    = '/^.+index\.[^.]+\$/i'
'hackmatch'    = '<iframe.+?priemIframe\.php.+?<\/iframe>'
'path'        = '.'
'test'        = 0
");
}
}

foreach($hC AS $name => $var)
{
if ($sHtml)    print "$name = ".htmlspecialchars($var)."$sHtml\n";
else    print "$name = $var $sHtml\n";
}

$Directory = new RecursiveDirectoryIterator($hC['path']);
$Iterator = new RecursiveIteratorIterator($Directory);
$Regex = new RegexIterator($Iterator, $hC['filereg'], RecursiveRegexIterator::GET_MATCH);

$iTotal = 0;
$iTotalHits = 0;
foreach($Regex AS $a)
{
foreach($a AS $sPath)
{
$iTotal++;
if ($hC['test'])    print "$sPath$sHtml\n";

if (Load($sPath,$s))
{
$iHits = 0;
while(preg_match('/^(.*)'.$hC['hackmatch'].'(.*)$/s',$s,$aM))
{
$iHits++;
$s = $aM[1].$aM[2];
}
if ($iHits)
{
print "$sPath hits: $iHits$sHtml\n";
if (!$hC['test'])    Save($sPath,$s);

$iTotalHits += $iHits;
}
}
}
}

print "total matches: $iTotal$sHtml\ntotal hits: $iTotalHits$sHtml\n";

function Load($sPath,&$sData)
{
error_reporting(E_ERROR | E_PARSE);
$sData = file_get_contents($sPath);
error_reporting(E_ERROR | E_WARNING | E_PARSE);

if ($sData === FALSE)
{
return 0;
}
return 1;
}

function Save($sPath,$sData)
{
$hfile = fopen($sPath, "w");
if (!$hfile)
{
print("the file $sPath could not be opened for writing :-($sHtml\n");
return 0;
}
fwrite($hfile, $sData);
fclose($hfile);
return 1;
}

?>

 

I just got feedback from german abuse department of 1&1 Server Provider, they will check for these links in their access filters. So the world is a little bit safer now. 🙂

Advertisements
  1. Tobias
    2011/01/26 at 6:46 am

    Do you have any information about which security hole the trojan exploited to get access to the client computers?

    • 2011/01/26 at 12:27 pm

      With a simple visit of a website that already has been compromised. They use the Phoenix Exploit Kit to drop a small Trojan exe which looks for credentials and uploads them. Antivirus may detect it when heuristic is activated. Otherwise it will be silently executed. So the hole is one of the 12 mentioned exploits.

  2. Vince
    2011/05/26 at 11:50 am

    I was taking a look at this post and was curious how it was determined that FileZilla had something to do with this security issue.?

    I’ve been using this app for several years but have just recently been hit by a wave of sql injections.

    It wasn’t anything harmful, just annoying.

    The target was index files. A small code was injected into them and I was able to find the script that was the culprit. The only real damage was either getting a blank page (php) because the script was injected right before the <?php tag which rendered the php useless.

    As for the .html pages, it was injected right after the opening body tag so in essence it was invisible to the eye.

    The real pain was having to go through each index page and locate the script and delete it and then upload it again. If you don't get the following files removed, you end up having the same headache started all over again.

    There were 3 files to be exact.

    counter.js
    js.php
    confdb.php

    They were found in the root directory as well as my .htpassword folder.

    Could these be the same attack that you're referring to?

    If so, how would I create the file mentioned above so that I can clean up my server?

    Would I create a "hacked.php" file and upload it to the server?

    If this is the case, wouldn't it become another risk because all someone would have to do is search for that file.?

    Any help you can offer would be greatly appreciated because I'm getting fed up with this attack.

    Oh… would this also create a downloadable trojan when someone enters an infected site if they have java enable in their browser?

    Sorry for all of the questions, but I want to make sure that I'm running clean sites. I'm making a living using them and if they are a risk, I don't want to create problems for my clients.

    Thanks in advance.

    Vince

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: