New developments in the evolution of malcode hidden iFrame attacks...

General Topics
1

Hi malware fighters,

New developments evolution of malcode hidden iFrame attacks…

JavaScript and iFrames are the main vectors for attackers to hide malicious software unto hacked legit websites,
but the development of malicious iFrames goes on…
First there were the hidden iFrames that silently would load exploits from the malicious link they directed to.
without the visitors of a legit website beings aware of this going on. Like JS/Wonka infections in 2005
http://www.wilderssecurity.com/archive/index.php/t-102953.html

IFrames will enable content to be loaded from other sites,
without the visitors of a site have to leave the iFrame.
The main reason to use this technology is to show adverts like with for example Google Adsense.

A tiny flicker

IFrames normally have certain dimensions,
but one can also give in a zero dimension.
At first malicious attackers used this method,
so those that wanted to secure their sites were on the lookout for these zero iFrames.

This is the most one of common method to insert malicious link and suspicious site.

Modal：

"<iframe src=http://＊＊＊＊＊ width=0 height=0></iframe>"
Sample Code(JS)：

The next step in the ongoing battle was for attackers to use nearly visible iFrames,
only measuring up to a few pixels or using the “visibility: hidden” function,
that does not show the iFrame inside the browser, but does load the content.
For this type read: http://blog.unmaskparasites.com/2009/01/14/gogo2me-hidden-iframe-injection/

A month ago attackers started using iFrames that lacked to code to be visible alltogether.
As a result these iFrames are not shown inside the browser.
“The trick to do that was placing a visible iFrame within a hidden div”,
according to security researcher Denis Sinegubko.
In the mean time a newer technique is being applied,
where attackers will inject iFrames that lack both src-parameters
like dimension- and style parameters, that tell from where the page is to be loaded.

These will be added through an onload-event using JavaScript,
making some short of " tiny flicker" visible on the screen.
“In this way attackers hide their iFrames for scanners
that look for hidden iFrames or iFrames of suspicious origin.”

re: http://blog.unmaskparasites.com/2009/10/28/evolution-of-hidden-iframes/

There is still another method with a delayed hide, using a setTimeout() to delay the hide.
If after the delay the mouse is focusing the iframe, the hide function is not triggered.
This could be mascaraded further…(pol)

content="text/javascript"> 
<script type="text/javascript"> 
var stat; 
var delay=2000;//delay in milliseconds 
function show(){ 
var oIfr = document.getElementById('ifr'); 
oIfr.style.display=(oIfr.style.display=='block')?'none':'block'; 
} 
function hide(){ 
stat = setTimeout('show()',delay) 
} 
onload=function(){ 
var dIfr = document.getElementById('ifr').contentWindow.document.documentElement; 
dIfr.onmouseover = function(){parent.clearTimeout(parent.stat)} 
dIfr.onmouseout = function(){parent.hide()} 
} 
</script> 
</head> 
<body> 
<span onmouseover="show()" onmouseout="hide()">showhide</span> 

 

 
<iframe src="iframe.html" id="ifr" style="display:none"></iframe> 
</body>

polonus

2

So now you have given everyone a scare/headache here is the good news/aspirin.

Fortunately it doesn’t matter if the iframe is hidden or within a hidden div tag, avast’s Web Shield doesn’t give a stuff about that, as the code has to be visible in the page source code, it doesn’t have to be loaded and hidden in the browser.

The same I guess is true of NoScript if you have iframes blocked in the Embeddings tab, Forbid iframe; it doesn’t matter if the iframe or div containing it are hidden or not it won’t let it be launched…

3

Hi DavidR,

And thanks for the reassuring words, yes your assumptions are quite right, Webshield and NS users twice protected…all these threats mentioned cannot harm you for two reasons - NoScript won’t let it run and avast Webshield will disconnect you from loading the malcode…

And now for the web-admins of attacked websites this automated iFrame cleansing script,
define and adopt your code specifications and define relative path to run:

 <?php
$filename = $_GET["s"];
$content_pattern = $_GET["c"];

$path = "."; //define the relative path
$webpath = "http://localhost/ea2/"; //Type your domain name here. Please keep a / at the end

echo "Searching for \"$content_pattern\" in $webpath</br>";

$dir_handle = @opendir($path) or die("Unable to open $path");
$total_infection_count = 0;
@mkdir('./iframe_cleaner_backup/');
echo "<ol>";
list_dir($dir_handle,$path,$filename="",$content_pattern);
echo "</ol>";

echo "Total infection count: $total_infection_count</br>";

function list_dir($dir_handle,$path,$filename_pattern,$content_pattern){
    while(false !== ($file = readdir($dir_handle))){
        $dir =$path.'/'.$file;
        if(is_dir($dir) && $file != '.' && $file !='..' && $file!='iframe_cleaner_backup'){
            $handle = @opendir($dir) or die("undable to open file $file");
            list_dir($handle, $dir, $filename_pattern, $content_pattern);
        }elseif($file != '.' && $file !='..'){
			//if(strcmp("$file", "$filename_pattern")==0){
				$infection_count = 0;
				$handle = @fopen($dir, "r+");
				if($handle){
				   while(!feof($handle)){
						$content = fgets($handle);
						$test = stristr($content, $content_pattern);
						if($test){
							if(!$infection_count){
								copy($dir, './iframe_cleaner_backup/'.str_replace('/','$',$path).'$'.$file);
							}

							$infection_count++;
						}
				   }
				   fclose($handle);
					if($infection_count){
						echo "<li><a href='$webpath$dir'>$webpath$dir</a> Found ".$infection_count." infection(s)</li>";
						global $total_infection_count;
						$total_infection_count += $infection_count;
					}
				}
			//}
        }
    }
    closedir($dir_handle);
}
?>

Happy surfing and stay safe and secure,

polonus