April 25, 2008 | Comments: (0)
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 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.
Posted by Roger Grimes on April 25, 2008 03:00 AM
January 11, 2008 | Comments: (0)
Security design: Why UAC will not work
Pinning all your end-point security hopes on UAC assumes that criminals are not as smart as they really are
It's security's dirty little secret: Not having your users logged in as root or administrator will not stop malware.
There is a huge public security thrust to ensure that users are not constantly logged on with highly privileged access. In Microsoft Windows, this means not being logged in as a member of the administrators group or any of the other 17 groups with admin-like privileges (for example, Power Users). In Unix/Linux/BSD, this means not being logged in as root or bin or whatever else is close. In the AS/400, it means not being logged in as Qsysop or Qsecofr. For mainframes, it might mean superuser, terminal 0, or another user label indicating special privileges.
Unfortunately, the concept of least privilege is more a popular mantra than a rule in most environments. This is especially true at home, but it's nearly as bad at work. If you want to find someone logged in as administrator or root all the time, point your finger in the general direction of network security folks: "Do as I say, not as I do."
Microsoft is trying to encourage users and developers to go least privilege by introducing UAC (User Account Control) in Windows Vista, and the Unix/Linux/BSD folks have being trying for a decade longer with Switch User (SU).
No panacea
The problem is that even if no one ever logged in as a superuser, it wouldn't make a dent in the ability of malware writers to do bad things to us and our computers.
It would stop a lot of the current malware, but only because they are designed (like a lot of today's legitimate software) to expect the user running it to be logged on as privileged. And in most cases, this is a good assumption. Most users are logged in using privileged accounts, but malware doesn't need privileged access to do bad things.
Even today, there are hundreds of malware programs that can do all the nasty things they want: modify your computer, steal your identity, whatever, without ever needing admin or root access.
Forget for the moment remote buffer overflows, social engineering, phishing, and all the other sorts of maliciousness that don't care about your logon credentials; malware doesn't need to modify your system files to cause problems.
On location
It's always been a mystery to me why Windows malware tries so hard to modify files or place itself in the System32 directory. Most people say it's because the malware wants to modify the Windows OS, and that's true. But the System32 directory location isn't needed. I've been keeping a table of all the ways and places that Windows malware can locate itself to cause damage, and I have more than 130 entries. My Linux/Unix/BSD list is much smaller, but contains a few dozen locations. Many of the listings on both documents do not require admin or root access to manipulate.
For example, most Windows malware modifies the HKey\Local_Machine\Software\Microsoft\Windows\Run registry key, but I have dozens of other keys that can be modified to launch just as easily. For instance, malware can use the user's own registry profile keys instead. Users always have Full Control to their own profile's auto-run registry keys, and they are checked (and the listed programs launched) by the computer after executing code in the machine's startup areas.
Let me be more explicit: There is nothing that malware can do today that can't be done without privileged access. I'm not talking about the way they can modify the system, but the intended result of the modification. Malicious hackers may not be able to modify System32 or sbin, but they can still intercept your identity and steal all your money, without modifying your operating system or (in the case of memory-resident-only malware) a single file.
Next steps
Just to be clear: Not having admin or root access does limit the possibilities for malware writers. They can't take their pick of all the current low-hanging fruit, but there are still plenty of ways to hack a user's computer without privileged access, and that's the pity. For years and years, we've been saying that users need nonprivileged accounts to do most of their work. We say this as if it is the Holy Grail of computer security -- as if it will end all malware as we know it today. But ultimately, this one change won't amount to a hill of beans. Malware writers will learn what it takes to do all the things they need to do without requiring admin access. They have many malware programs they can study today, and certainly, they will develop many new methods in the future.
Stopping malware isn't as easy as not being logged in as a nonadmin. For a real, long-term solution, see next week's column.
Posted by Roger Grimes on January 11, 2008 03:41 PM
