|
12 Jun iFrames = Apple too? Michael 20 Mar New Brazilian banking Trojans recycle old URL obfuscation tricks Josh 30 Apr More thoughts on drawing the line VitalyK 29 Apr Drawing the line Eugene Join our blog You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings. |
Looking up definitions for 'iframe' does indeed give results about "... a constraint of the H.264 codec specified by Apple to ensure ease of consumer video editing.". Such iframes do contain all necessary rendering information and serve as reference to construct other frames. But here we discuss the other kind of iframes - HTML tags. Iframes can have several attributes and we often encounter them when analysing malicious sites. They are often used in a hidden way to construct drive-by downloads of malware. To hide even more, simple encryption (also called 'obfuscation') is often used, web browsers decrypt that on the fly. Knowing that, we can search for interesting websites. For example doing a web search for "#64#6f#63#75#6d#65#6e#74#2e#77#72#69#74#65" (which decodes to 'document.write'), we instantly get 10,000+ results.

The first entry in our search results is a link to a torrent site where users discuss a malicious package. Ironically in between these search results we also noticed what seems to be an 'infected podcast' hosted at itunes.apple.com - which brings us back to the initial talk about iframes. The injected code contains an iframe redirecting to moshonken(dot)com, a host known for having spread exploits in the past. Currently that host appears to be not operational but malicious code trying to access it is still injected in many legitimate sites, as our search results showed. We detect this code as 'HEUR:Trojan.Script.Iframer' and have reported the problem via Apple's feedback form.
Analysis
Weblog
Fabio, our researcher in Brazil, has noticed malware authors using an old trick to mask URLs. The trick involves specifying an IP address such as say, 66.102.13.19 (the IP address of google.com, borrowed from my colleague, Costin) in a numerical base other than base 10. The supported bases are octal (8) and hexadecimal (16), and even a single 32bit number work, thus the following are all valid, and each will take you to google.com:
Now, by itself, this isn’t terribly interesting from a technical perspective; this ‘feature’ of IP specification has been around for quite a while.
However…what is interesting though is that due to the relative obscurity of using such methods to denote an IP or URL, it is quite feasible that existing security products do not correctly identify the URLs as valid or flag them as malicious when they point to existing known bad websites.
In my testing, Firefox on Windows supports all of the above addresses, under Linux however, Marco from our German office says some are unsupported. Based on poor browser support for such features, it’s possible to imagine URL filtering tools having the same lack of support.
In addition to potential weak tool support for such URLs, it is likely that unsuspecting users may be more easily convinced that a particular URL is legitimate, which I think is the obvious goal of using such URL obfuscation techniques.
Analysis
Weblog
Following on from Eugene's post, I'd like to chip in with my thoughts on what's happening at Defcon this year. I spoke at Defcon last year, and I'd say that the event is something unique – an opportunity for smart people with unconventional minds to meet and share their knowledge. Defcon not only gives you access to new ideas, but you also get to encounter the spirit of modern cyberculture.
It seems to me that the emergence of contests like Race to Zero was always simply a matter of time. And now that such a contest has appeared we'll see similar ones in the future, whether we like it or not. Of course breaking the law is wrong - I think the exact form of the contest will be modified before Defcon starts in order to meet legal restrictions.
However, I think the Race to Zero contest organizers could change the rules of the game in other ways, to make it beneficial to all participants. Let me explain...
Let's take a look at what the participants are going to manipulate: they will have the code of existing applications and probably some prepared sets of nop code. Nop code ("no operation" code) is special software code that neither affects the state of the machine nor alters the system. There are many approaches to obfuscation techniques but almost all of them have the same basic principle: the affected code is restructured and mixed with nop code. Depending on the algorithm used to mix the two sets of code, either it will be more difficult to read/re-engineer the code or the code will be able to evade detection by signature-based AV software engines.
Weblog
The so-called 'malware obfuscation contest' proposed by the folks at Race to Zero is already generating contradictory discussions.
IMHO - either something is ethical or not...and I firmly hold that creating new malware to bypass security products 'for fun' is not!
We anti-virus researchers have always opposed the creation of new malware under any circumstances. The only excuse for creating malware in test environments that ever sounded vaguely reasonable was the old "we need to create new samples in order to study attack methods in detail".
Let's get real folks - we are seeing new samples by the thousands today - we have more than enough 'live' malware to study in order to improve our technologies. So even if this excuse was "sort-of-maybe one-time-only almost-acceptable" once upon a time, it is NOT acceptable in 2008.
Weblog