Security

All the malware that's fit to print

Some readers of the New York Times (NYT) web site were recently surprised to "learn" that their computers were infected with viruses. As it turns out, a rogue ad was responsible for the warning, and, as one would guess, anyone who downloaded the suggested fix for the virus problems was, instead, infected with malware. While the problem was fairly short-lived—and targeted Windows, not Linux or Mac OS X—it does point to a general problem for those who run web sites: how can one ensure that the ads running on the site don't contain anything objectionable, either because of the actual ad content, or because it contains malware?

Ad content is typically served by ad networks, and a web site operator includes a little blob of Javascript into the proper place in a web page. That Javascript is responsible for retrieving the ad content and adding it into the page. But there is nothing stopping it from doing other things, such as downloading Javascript from other sites. Because the script code was served with the page, it has all the rights that any other Javascript has in the context of that page. Essentially, the site owner has given their ad network a "free pass" to do whatever is needed to put up the ad.

In general, ad networks are careful to screen the ads they send to their partners—at least for malicious content—otherwise, those partners would switch to a different network. But, it is certainly possible, and has probably happened in the past, that a dodgy ad gets put into an ad network's rotation. That was the first guess for where the NYT problem was. But, as the paper itself reported, the ad actually came from elsewhere.

In addition to running ads from ad networks, web sites often directly sell ads to customers. In this case, the NYT believed it was selling an ad to VoIP provider Vonage. When the ads were placed, they at first displayed normal Vonage ads. At some point, though, whoever placed the ads (and provided the Javascript to the NYT) switched to serving virus warnings.

Obviously, in retrospect, the NYT should have been more careful to ensure that whoever they were dealing with was, in fact, representing Vonage. The ad content was not being served by vonage.com, but that's hardly surprising as many advertisers use other sites to serve their ads. Vetting advertisers can be rather difficult, though. There are multiple levels of both technical and administrative verification that need to be done, some of which is likely beyond the abilities of ad salespeople.

It is, in some ways, like the kind of vetting that needs to be—and often isn't—done for SSL certificates. There needs to be a real organization behind the ad, though what constitutes "real" is an open question. The code to be inserted needs to be inspected as well. An excellent dissection of the NYT malware gives a good view of just how the attack worked. Without somehow figuring out that tradenton.com was not a legitimate ad serving network, there is nothing particularly suspicious about the top-level code.

This is a problem we are likely to see more of over time. Because the ad networks want to be able to run code on the client, for geotargeting and other information gathering, sites must generally be willing to insert fairly opaque Javascript into their site. As the dissection shows, that can lead to bouncing around to multiple sites, grabbing code from each—even legitimate ad serving networks often have their own partners to whom the redirect requests. There is a sort of implicit web of trust that exists, but one that has the potential to be subverted.

Another aspect of the problem is that site owners often cannot see all of the ads that are currently being displayed on their site. If some small percentage of the ads—or those targeted at a different region—contain objectionable content of any sort, the site owner may very well be completely unaware of it until users complain. It's not just malware ads that are a problem, here, but any kind of ad that the owner might prefer not to run.

The NYT article mentions other similar incidents that have occurred in the past, but this attack, on a high-profile site, has, at least, served to raise the profile of the problem. Other than eliminating ad networks and customer-supplied Javascript from a site, there is very little defense against this type of subversion. By running other people's code in a site, one has, for all intents and purposes, turned over control of the site's content to third parties. It shouldn't be too surprising that attackers are taking advantage of that.

Comments (15 posted)

firefox: web content processing vulnerabilities

Comments (none posted)

firefox: use-after-free flaw

Comments (none posted)

firefox: URL concealment

Comments (none posted)

firefox: JavaScript execution

Comments (none posted)

firefox: multiple vulnerabilities

Comments (none posted)

firefox: certificate vulnerability

Comments (none posted)

freeradius: denial of service

Comments (none posted)

horde: cross-site scripting

Comments (none posted)

htmldoc: buffer overflow

Comments (none posted)

kde: man-in-the-middle attack

Comments (none posted)

kernel: missing capability check

Comments (none posted)

libsamplerate: denial of service

Comments (none posted)

nginx: arbitrary code execution

Comments (none posted)

planet: missing input sanitizing

Comments (1 posted)

puppet: multiple vulnerabilities

Comments (none posted)

rails: missing input sanitizing

Comments (none posted)

silc-toolkit: format string vulnerabilities

Comments (none posted)

wireshark: multiple vulnerabilities

Comments (none posted)

xapian-omega: missing input sanitising

Comments (none posted)

znc: arbitrary file overwrite

Comments (none posted)