Check the link with an online I-frame checker - Jutakys...

General Topics
1

Hi malware fighters,

In the last three months the number of new malicious sites they observe has increased from 100,000 to 200,000 per day to 200,000 to 300,000. Also there is shown a surprising velocity of change in the compromised sites. Part of the effect is that they are being cleaned up quickly, but the attacks are also changed frequently to redirect to different sites, Almost 60% of these sites are up for less than one day. The goal of these techniques seems to be to defeat blacklist-based protections. They calls them transient threats.

What are these web pages? Few are actually put up to serve malware. Some of them are blog comments, some are advertisements, many are legitimate web sites corrupted through HTML/script injection, and many have been corrupted through compromises of SQL servers through SQL injection. These compromised web sites are tricked into redirecting users to the few sites that directly serve the malware.

The combination of the Apache web server and PHP scripting engine are a favorite target of attackers. There are large numbers of vulnerabilities for attackers to exploit and no automated patch system to make sure servers are protected. AV vendors are observing some new attacks which help to obscure the attack; in some of them, the user is redirected from the compromised site to the malicious site only when they were referred through a major search engine.

The actual malware being served varies from fake codecs, game password-stealing attacks to fake anti-spyware. The fake codec sites are the most volatile, with 62% active for less than a day. The fake anti-=spyware sites are more stable, but 28% are active less than a day and the average is less than 2 weeks. (info provided by AVG survey).

Malicious Iframes are part of this scene: you can launch up a query for a particular link (site)
to look for info on Iframes there with jutakys Iframe-detektor:

http://jutaky.no-ip.org/index.php?option=com_content&task=view&id=19&Itemid=32

give in below where it says “Please enter URL etc”… enable JS and wait for the results…

The most effective and versatile browser for detecting iframes and for protecting you from the harmful effects that may result from them is Mozilla Firefox with some very easy to use extensions. NoScript will block malicious javascript which will stop a lot of frame triggers in their tracks. Remember to enable javascript for your PTR programs and forums or you will not be able to use them properly. GreaseMonkey will be necessary if you wish to use one of the iframe detectors. JSView will enable you to see the source of javascript on webpages, this is not an extension for beginners however, it takes a practiced eye to use it effectively. View Dependancies will add an extra tab to your PageInfo view which is useful if something is not showing in the source code, but you just know there is something there.

Are there legitimate uses for a 0 pixel or 5 pixel iframe? Yes, they are often used for traffic tracing, or to initiate a pop up. Just because there is a suspicious iframe, doesn’t necessarily mean that it is a form of cheating. Unfortunately, some forms of 0 iframe detection can give an alert when those legitimate frames are encountered. The amount of malicious Iframes makes out 7% of the total amount of malware found.

polonus

2

Hi malware fighters,

Javascript threats re: http://www.scribd.com/doc/194762/Javascript-malware

Sometimes the usefull scanning sites leave the web. So the link now points nowhere…
I found another script online that could be made to run with greasemonkey and that builds a yellow lining around iFrames that run outside the normal webdomain, I give it here:

// Remote IFrame Detector
// version 0.1 
// 2007-01-19
// Copyright (c) 2007, Rod Hilton
// Released under the GPL license
// http://www.gnu.org/copyleft/gpl.html
//
// --------------------------------------------------------------------
//
// This script will look at any iframe in a document and draw
// a border around it if its source is on a different host.
//
// This helps prevent javascript malware attacks that rely on wrapping
// a safe site in an iframe to prevent detection.
//
// --------------------------------------------------------------------
//
// ==UserScript==
// @name Remote IFrame Detector
// @description draw border around remote iframes
// @include *
// ==/UserScript==


var thishost = window.location.hostname;
var alliFrames = document.getElementsByTagName('iframe');
for (var i = 0; i < alliFrames.length; i++) {
	var thisiFrame = alliFrames[i];
	var src=thisiFrame.getAttribute("src");
	//Only bother if it's not a relative url, meaning it starts with http://
	if(src.search("^http://")==0) {
		var match=thisiFrame.getAttribute("src").search("http://"+thishost);
		//If the hosts don't match...
		if(match==-1) {
			thisiFrame.style.border="5px dashed red"
		}
	}
}

Enjoy,

polonus

3

I think this is closing the door after the horse has bolted, as the iframe would still have executed with all its potential. I don’t see anything in the script that blocks the execution of the iframe.

So I don’t see how it can live up to its statement:

// // This helps prevent javascript malware attacks that rely on wrapping // a safe site in an iframe to prevent detection. //

Whilst it might make a user aware of something strange,

However, iframes can be used for dynamic content and quite frequently might go off-site for the content.

4

Hi DavidR,

I know the only real protection against this lies with add-ons like NoScript (because the code is not being executed) that is one, and RequestPolicy because the code beyond the normal domain(s) is not being executed so the malware is not silentlty left to run.

Web browsers are not prepared for emerging threats. - Code (e.g. JavaScript, Java, Flash) is executed with the assumption of trust. - Forensic challenges • Resource links do not appear in the browser history. • No-Cache instructions might inhibit the browser from saving a copy of the malicious page. • Network devices might only record IP address and port for SSL requests – no idea if the request was safe. • Current security measures are inadequate or bypassed by certain attacks. - Same Origin Rule - Cookie attributes (secure, httponly)

What I miss here is a link scanner that would make these vulnerabilities visible before you would load the site into the browser. The only occasion I have seen a similar badd stuff iFrame online detektor, that was jutaky’s, not shortly afterwards it goes offline, very frustating while we have so little of these. Especially so while the other link scanner like DrWeb’s av link checker misses a lot. Another point for wanting this is that malcreants use the hidden iFrame technigue to infect an enormous amount of respectable sites (of which the server security is weak) to infect the browser user. We should not stay in the dark. Who is stepping in here: build a fashionable free online hidden iFrame scanner, put in the URL and hops…
Good we have the network shield but then again we already tried to make the connection, I want to know before going there that there are no hidden invisible iFrames luring inside that site’s webcode!

polonus

P.S. iFrames have better alternatives, and the technique is vulnerable, that has been proven.
So better not propagate the use of it, web developers should leave their hands off it, and use an alternative…

D.