Bestehen Bedenken im Hinblick auf VPN-Sicherheitslücken? Erfahren Sie, wie Sie von unserem VPN-Migrationsangebot inklusive 60 Tagen kostenlosem Service profitieren können.

Zscaler Blog

Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang

Abonnieren
Security Research

Trust Two Times Removed

image
THREATLABZ
November 07, 2008 - 4 Lesezeit: Min

Hello everyone, Jeff Forristal here. I thought I'd take a moment to discuss a real-life security incident that I recently reviewed in post-mortem fashion. The plot is simple: while the person was surfing the web, their browser was exploited by a piece of malware targeting a popular browser plugin. However, it's the details that make this story a bit intriguing...and scary.

The person's surfing session was quite normal and not particularly careless. During the moments just before the incident, the person was using Google to find an answer to a technical question. One of the top search results was for a smaller site that hosted technical tidbits of information collected and donated from various information sources. The person clicked through to that site. Now, this site is not a site that would be considered to have a 'risky' reputation, nor does it harbor any direct malware. It's just a normal, basic site that looks to be someone's personal project (site was designed in FrontPage 6.0!) to better the world by collecting and publishing useful information. In fact, the only thing questionable about it is the number of syndicated ads on the page: 7, by our count, from multiple vendors (BidVertiser, Google, Clicksor, and FastClick). Of course, it makes sense that they would (over-)populate their page(s) with ads in an attempt to generate revenue from their content publishing efforts. But this turned out to be the problem.

See, once the person's browser landed on this ad-infested page, the browser started running around like mad to fetch all the syndicated ad content. Each ad syndication attempt usually results in multiple browser requests because the main requests to the ad syndicator often results in a chain of redirects eventually landing at the specific content of the "advertisee" utilizing the syndication service. As the term 'syndication' implies, the ad services are just the middle-man between the web site and the advertisee. And the website is just the middle-man between the ad service and the web surfer.

Anyways, what eventually happened is that one of the ad syndicators served up an advertisee's ad...and it just so happened that the ad was actually a piece of malware that could immediately compromise the vulnerable browser plugin. This is not necessarily new news; attackers have been known for quite a while to leverage advertising syndication as a way to spread their malware. But it's a bit scary to witness in action, and the growing amount of advertising syndication utilized by web sites is going to make it a more predominant malware delivery vector. The problem is exacerbated by the fact that the ads are no longer simple graphics; advertising syndicators usually allow their clients (the advertisees) to specify arbitrary HTML. This gives the advertisee cart blanche to use rich media ads that rely on multiple technologies such as DHTML, Javascript, Flash, etc. But this also gives an attacker full access to syndicate any arbitrary piece of malware that could be hosted/served via a normal web page. (Side note: maybe Google is onto something by only using pure text-based ads; the text is very easy to validate and stands practically no chance of harboring a piece of malware...)

What does this all mean? Well, there are a few things. First, all of those vendors who suggest an exploit is partially mitigated by the requirement that a "user must visit a malicious web page in order to be attacked" need to change their tune, because advertising syndication is essentially bringing the malicious web pages (via rich media ad capabilities) to the user. Second, the onus is on the advertising syndication services to ensure their clients aren't trying to deliver malware ads through the service. That's a tall order, and the ad vendors have not exactly been batting 1000. Third, in the age of mashups and syndication, we no longer have a situation where a user has to only decide whether they trust the destination web site or not; they must now trust all the components that are mashed and syndicated into that site, and in turn trust all the components those components use, etc. In the incident I just talked about, we have the person trusting the web site, the web site trusting the advertising services, and the advertising services trusting their clients. Thus we come to having trust two times removed. Worse, web browser do not equip people with the necessary tools to really help them manage this trust chain effectively; it's pretty much an all-or-nothing shot based upon the user's trust of the immediate target web site. In the meantime, maybe browser plugins like AdBlockPlus and NoScript could help, although that essentially robs legitimate sites of advertising revenue. However, if enough users start to use ad blocking software as a matter of security, perhaps the advertising services will become pickier about their clientele and better scrutinize what they are actually syndicating.

Only time will tell, I suppose.
- Jeff

ps. if you are interested in which advertising vendor was the 'enabler' for the mentioned incident, well, we can not say with 100% certainity. But there does seem to be a popular opinion against one of the vendors.

form submtited
Danke fürs Lesen

War dieser Beitrag nützlich?

dots pattern

Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang

Mit dem Absenden des Formulars stimmen Sie unserer Datenschutzrichtlinie zu.