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
adding it into the page. But there is nothing stopping it from doing other
script code was served with the page, it has all the rights that any other
has given their ad network a "free pass" to do whatever is needed to put up
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
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
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
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.
to post comments)