Be careful with transitive trust

I just got through reading about another hugely popular, legitimate Web site hosting malicious code that redirects visitors to a malicious Web site. Once redirected, the new Web site runs a fake virus scanner and -- surprise, surprise -- finds multiple malware programs on the user's computer as it offers to install new "anti-virus" software to the end-user. Of course, users foolish enough to install the software

I just got through reading about another hugely popular, legitimate Web site hosting malicious code that redirects visitors to a malicious Web site. Once redirected, the new Web site runs a fake virus scanner and -- surprise, surprise -- finds multiple malware programs on the user's computer as it offers to install new "anti-virus" software to the end-user. Of course, users foolish enough to install the software end up installing what is likely to be the only malicious program on their computer.

Gone are the days when you could tell your end-users not to visit "untrusted" Web sites to minimize their exposure to malware. Actually, I gave up on that advice during the Nimda worm attack of September 2001. That was the first time a legitimate Web site tried to infect my computer. These days it is plausible to say that a fairly large percentage of malware is launched against us from innocent, victimized Web sites.

In the latest attack I'm referencing, the malicious attacker placed a malicious Macromedia Flash object on the vendor's Web page. (I also remember the days when media content couldn't hurt you.) How it got there I don't know, but it likely was placed using a Web site vulnerability or malicious ad placement. It might well have been one of the many cases in which you'll find a case of inappropriate transitive trust.

In the computer security world, transitive trust refers to how much implied security trust Party A gives to Party B when acting on behalf of Party A to Party C. Party A expects Parties B and C to use the same security policies and effort as it would use itself in all instances, or perhaps even more. In reality, Party A often assumes too much and fails to impress on the subsequent parties its expected security requirements. And when the compromise or vulnerability hits the news headlines, Party A is left swinging alone in the wind to face the music.

A common transitive trust scenario happening over and over today involves the placement of malicious banner ads on legitimate Web sites. The original Web site owner has a popular Web site and wants to maximize revenue. Often this is accomplished using revolving banner ads. On a big site, it is rare that the Web site administrators actually post or sell the majority of the banner ads themselves. Instead, they contact a trusted, accomplished, often traditional advertising firm to handle request (that is, the first transitive trust baton passing). This first-line trusted firm, not specializing in Internet media, contacts a medium-sized firm specializing in Internet advertising (the second baton pass). This midsize firm then contacts an even smaller firm that specializes in selling banner advertisement (the third baton pass), who promises top-dollar banner ads. The smaller ad firm ends up getting a top-dollar bid for the ad space, not realizing that the top bidder is a front company for a crimeware syndicate.

The crimeware organization could even initially offer up a legitimate ad, which contains a link back to its malicious servers. When go-live time happens, the crimeware company simply updates the content being referenced by the now well-placed banner ad. The smart crime company is clever enough to include blacklisted IP addresses in its code so that all the participating entities are redirected only to legitimate content. When the involved companies are finally notified, how long do you think it takes to locate the offending code?

Several recent studies have revealed that outsourcing development to third parties is responsible for the majority of Web site vulnerabilities of this sort. We've always known that contractors don't have the same intense commitment to a company as the company's own employees, and now we are seeing the results. When I was working for a well-known penetration testing company, I remember finding common Web site programming errors over and over on well-known client Web sites. I found some of these basic errors so often that I began to chide these vendors, unnamed, in my classes on computer security. "How could these companies miss these basic mistakes that are 10 years old?" I would ask with a chuckle.

Then, one day I found out that our company's own Web site had the same basic problem. We had outsourced the Web site's new look to a cheaper vendor. See, our company's own secure programmers and computer security experts were making too much money for the company to use them on the company's own internal projects. Boy, did I change my tune when the pain was ours.

Another example of inappropriate transitive trust involves identity theft. Many of the identity theft incidents over the last few years have occurred because the original company or entity trusted another third party to safeguard its data information assets with the same zeal as it would. It could be a servicing bureau that didn't protect its networks and computers well enough or data tapes that simply disappear in transit.

Every time we allow consultants, b-to-b partners, and remote networks to access our own networks, we are giving transitive trust, whether we know it or not. Their network becomes our network. Every piece of software you install is essentially extending trust to the publisher. If their code fails, so does your data and networks.

You should strive to measure transitive trust in every extending operation you're involved with. You must define the value and criticality of the data or services being entrusted, and require that those operating on your behalf use the same appropriate precaution (called due care in legal circles) as you yourself would provide for the circumstances. How do you do it?

For one, create a security policy, if one doesn't already exist) that covers these sorts of third-party interactions. Make sure your critical data is always encrypted in transit and require that your vendors do the same. Hard-code into contracts the policy and expectations of the third party, and require that vendors and their employees document their understanding. Always reserve the right to audit, and do audit, and provide for penalties for noncompliance. It's amazing what a little policy and awareness can do to improve the transitive trust given to others.

Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Join the discussion
Be the first to comment on this article. Our Commenting Policies