I got this picture from a reader of the site. Apparently the reader was simply viewing Yahoo mail and poof, RogueIframe trojan. We are starting to see a lot more of this kind of stuff, but it’s really disappointing that third party ads are being displayed on otherwise sensitive apps (or at least I think most people feel they are sensitive). Here’s the picture:

Click to enlarge

We’ve seen this exact hack hit before, against Facebook. But I think this kind of thing may be the beginning of a epidemic. As long as you can end up with your advertisements on any site that is even vaguely sensitive, you can start either taking over the site, or delivering malware. Whatever best suits the attacker’s needs. I think this all goes back Tom Stripling’s speech at OWASP where he in painstaking detail explained why you cannot trust third party JavaScript on your site, and yes, that definitely includes advertisements. Anyway, I hope this gets cleaned up quickly.

There’s an interesting article over at ZDNet that explained that Google’s text ads are getting subverted by trojans on people’s machines to get them to click on other people’s ads. It wasn’t clear what those ads were, exactly, but there you have it. I see this kind of thing as a clear path for future monetization - similar to how bad guys are adding extra form fields into forms via malware to gain more information about your identity. Very clever, and easy to do.

This is different from when Google’s ads were spreading malware but has the same basic purpose. Ultimately getting code on people’s machines is the best way to get control of the machine and ultimately make money off of it via spam, clicks, or whatever else they come up with.

Similar to Mr T, Łukasz Pilorz sent me a link to some malware that is actually doing browser sniffing. This was something we had thought was probably going on, but it was more of a theoretical attack. Now it’s clear it is actually being used in the wild. The interesting part of the code reads as follows:

if (win && ie) {
xd = _hwaPlugIE("SWCtl.SWCtl.1") ? "1" : "0";
sf = _hwaPlugIE("ShockwaveFlash.ShockwaveFlash.1") ? "1" : "0";

if (_hwaPlugIE("PDF.PdfCtrl.1")) pdf = "1";
if (_hwaPlugIE('PDF.PdfCtrl.5')) pdf = "1";
if (_hwaPlugIE('PDF.PdfCtrl.6')) pdf = "1";

qt = _hwaPlugIE("QuickTimeCheckObject.QuickTimeCheck.1") ? "1" : "0";
rp = _hwaPlugIE("rmocx.RealPlayer G2 Control.1") ? "1" : "0";
wm = _hwaPlugIE("MediaPlayer.MediaPlayer.1") ? "1" : "0";
} else if (!win || moz) {
for (var i=0; i < n.mimeTypes.length; i++)
_hmime += n.mimeTypes[i].type.toLowerCase();

xd = _hwaPlugMoz("application/x-director") ? "1" : "0";
sf = _hwaPlugMoz("application/x-shockwave-flash") ? "1" : "0";
pdf = _hwaPlugMoz("application/pdf") ? "1" : "0";
qt = _hwaPlugMoz("video/quicktime") ? "1" : "0";
rp = _hwaPlugMoz("audio/x-pn-realaudio-plugin") ? "1" : "0";
wm = _hwaPlugMoz("application/x-mplayer2") ? "1" : "0";
}

You can download the entire source here. It’s pretty interesting code, if you haven’t seen it before. Clearly it’s malicious so be careful about executing it, since it does use full paths. Interesting though. Thanks to Łukasz!

I found an interesting link after visiting Zeno’s post on a Malware paper produced by Google to document malware on the internet. Firstly, let me start by saying, this is a really good paper, as it discusses the ways in which malware propagates. Not that it’ll be news to anyone who reads this site religiously, but it’s still interesting to see all our theories validated.

Secondly, be wary of the statistic 1 out of 10 websites have malware. Google hand selected 17 million and only did a deep dive into 4.5 million sites out of their own repository. It’s well known that Google does not spider the entire internet (it’s a very small portion in reality) and also, they picked those URLs because they were likely conduits. They weren’t arbitrary. So let’s just take that statistic off the table. Yes, the Internet is a scary place, but not 1 out of 10 sites actively trying to screw you scary.

But back to the interesting stuff for a minute. They point to a large number of the exploits found having to do with website vulnerabilities, including those found within ASP and PHP and additionally a big chunk was delivered through holes in the site that allowed XSS. That XSS may have been intentional in the case of widgets or advertising or not, but in the end, it’s bad.

I should also point out that this doesn’t say anything about sites that attempt to do things like CSRF, or servers that have been compromised in other ways that allow the attacker to quietly steal user data. For instance, SQL injection or server vulnerabilities that just allow a back door into the system to pull confidential info out of the database.

One point that I’d like to make on top of this, is that the two things that were able to cause most of these problems were remote JavaScript and iframes. I just don’t see many applications for those technologies that, as a user, I care about (ads and widgets are pretty low on the list of what I care about seeing on my browser as a consumer). I am an edge case as a user, I’ll admit. But as nice as Web2.0 is, not getting malware is even nicer.

I’ve been auditing a website over the last few days that has been seriously compromised. The good news is that they are prepared and determined to fix the problem, the bad news is that they have so many potential holes it would take a small army to fix them all in a reasonable amount of time. I found myself saying something I really thought I’d never say - “What about a WAF?” There are two special circumstances that struck me about this situation that made me have a bit of a change of heart.

First of all, anyone who has read this site long enough knows that I’m pretty critical of WAFs in general, so I’m not here selling them or anything. They can represent a single point of failure in many applications, add additional complexity, have false positives and false negatives and require administrative overhead - not to mention the cost. But here is where I changed my mind. In this case the client had between 1,000-5,000 customer facing attack points to secure. There is no possible way they could fix that by hand in any reasonable timeframe.

Secondly, the attacker left malware on the system that was intended to infect the users of it (a la the superbowl hack). Like firewalls, WAFs could theoretically be used for egress filtering. Even during a complete compromise the system could prevent consumers from getting infected with any future malware that the system leaves for them. This assumes that it is not re-assembled via JavaScript (or other client side code), but in most cases it would at least slow down the rate of infection. So yah, I had a moment of weakness and let the three letters out of my mouth, but in this case, I think it’s justified.

This is actually a really serious issue that was sent to me. The funny part is that I’ve known this was possible for years now and even already put it into a presentation I’m doing in a few weeks, but anyway Google’s ads have been spreading malware. A few people with Google accounts have been buying sponsored ads (no doubt with stolen credit cards/identities). It’s sure easier than getting to the top of the search results page!

Although I don’t think this signals the end of text ads, I think it’s a wise choice to consider any paid links to be just as untrustworthy as anything on the SERPs. Google, nor any search engine have been particularly good about vetting how good or bad a domain is before linking to it. Hey, money is money right? Although, I believe they will probably do a cursory scan of the domain to make sure it isn’t spreading malware in the future given the bad PR, it’s pretty easy to fool spiders into not seeing malware. So I’m not sure what actual protection this will provide.

My next thought was CSRF - if you buy a search term and include a few images to remote domains you can pretty easily get them to do things on your behalf, and it’s extremely targeted at the same time. Yah, that’s bad. Don’t trust those paid ads - it doesn’t matter if they are “sponsored” or not. As a side note, I was a little annoyed to read that Matt Cutts wants people to snitch out paid links. I think Google should look at it’s own problems before trying to hurt people’s revenue streams. At least with my paid links, I wouldn’t be risking people’s identity to click on them!

There’s an interesting article about some research that Finjan did regarding their findings that 80% of Malware is served by ads. Taking aside the statistic itself, which you can either agree with or not (maybe it’s 80% that Finjan detected), it’s still an interesting trend. However, one thing struck me in the article that they almost glossed over. They mentioned that one trend is that they are embedding the code so that it executes when seen through translation services. Interesting.

There’s a few reasons this is interesting. Firstly, it’s kind of a slap in the face to people who think that using translation services somehow makes you safer or more private (I’ve never understood why people think that since it still downloads all the embedded content directly from your server), and secondly it really opens up a new way to target your attack. It’s easy to tell when a user is using a translation service (referring URL and/or lack of referring URL but preceded by a pull from a translation service - this could be aided by unique IDs on images to track them back to specific pages).

Now using the translation service to know that your target is located in some area that speaks whatever language they are using, you can be sure that they are in an area that has no extradition treaties with wherever you are hosting. That can greatly reduce the liklihood of getting caught, while still maintaining some good number of malware infections. Kinda nasty. I might be reading a little too far into Finjan’s findings, but still, it’s interesting to think about.

digi7al64 and Rahul both alerted me to a really good writeup on the Gozi trojan written by Don Jackson. Not only is is a good writeup but it’s extremely thorough on all the details from the transmission to how the code operates, to what it does once installed, etc… etc… Very good writeup indeed. The major scary part about this trojan is that it is specifically designed to steal information that would otherwise be invisible to an attacker due to SSL.

I think my only beef with the writeup (and this is a nit pick, really) is that the example output is from Wireshark instead of a HTTP proxy, so it’s difficult to read what’s going on, and parts of the header are cut off. Wireshark is a great program, it’s just really not ideal for looking at HTTP traffic in an intelligible way (although that could be a nice feature enhancement to it - or even turning it into a HTTP MITM itself). Again, that’s a nit-pick, because this is a great writeup.

Zach sent me a link to a hackin the box article about how Windows Live is being used by blackhat SEO (search engine optimization) to bring malware links to the top of the search results. This marriage between blackhat SEO and hacking is starting to take off. It’s unclear what tactic they used to get to the top of the search results, but clearly, it worked, as they ended up taking over quite a bit of Live’s Italian site.

Once the users were on the Live.com site apparently they were served up links to malware sites. The search engine itself was used as a conduit for sending people to the malicious search pages. This is yet another reason why search engines shouldn’t index XSS. Even if the site is benign, they would be indexing links to malicious pages on benign sites. Anyway, interesting read, and it’s scary that the SEO community is now dabbling in hacking as well. It was only a matter of time.

I know this sort of attack has been around for a while, but perhaps not quite in this way and not quite as many servers were affected, but there is a report over at SANS talking about an XSS VBScript malware that injects malware. Ben Heinkel alerted me to it and actually put up two screenshots here and here showing how the code actually worked. Pretty nasty stuff, especially as it appears there is no virus definition for this particular variant yet.

However, there are two things about this that are more interesting from an attack perspective. The first is that this was not calling malware that was uploaded to the site that had been compromised. Why bother? Since the sites themselves had XSS holes on them (I’m assuming persistent) the only requirement was that the executable and VBScript was housed somewhere on the Internet. No longer do you have to upload your malware to the machine you want to infect people from. Who needs all that hassle when all you really want to do is link to it?

The second thing that’s interesting is that this uses VBScript. Firefox users might be cheering since they wouldn’t be vulnerable to this without a plugin, but really it’s a pretty interesting thing that it is easier to write Malware that installs executables in VBScript than JavaScript. Although JavaScript is still the favorite for port scanning and controlling the page it was VBScript used in the attack. I think people tend to forget about VBScript, but it’s potentially just as nasty considering the wide userbase that supports it.