Wednesday, November 21, 2007

Rootkitting Your Customers


I am a big fan of Dan Geer (image at left); he always has an interesting perspective on security issues, but that's not to say I agree with him.

Dan wrote a guest editorial that was published in Ryan Naraine's "Zero Day" blog, tackling the topic of trustworthy e-commerce when consumers' PCs are so likely to be infected with who-knows-what (there's even a Slashdot thread to go with it). Dan proposed:
"When the user connects [to your e-commerce site], ask whether they would like to use your extra special secure connection. If they say 'Yes,' then you presume that they always say Yes and thus they are so likely to be infected that you must not shake hands with them without some latex between you and them. In other words, you should immediately 0wn their machine for the duration of the transaction — by, say, stealing their keyboard away from their OS and attaching it to a special encrypting network stack all of which you make possible by sending a small, use-once rootkit down the wire at login time, just after they say 'Yes.'"
I see one major flaw with this: suppose we agree that a benevolent rootkit issued from the merchant is a good idea, how do we guarantee that the rootkit trumps any other malware (i.e. other rootkits) that are running on this presumed-infected consumer's PC? All it would take is a piece of malware that could get into the Trusted Path between the consumer's keyboard and the merchant's good-rootkit.

I understand that Dr. Geer is trying to tackle this infected/zombie problem from the merchant's perspective. And in the grand scheme of things, the merchant has very little control of the trust equation. There are some interesting security economics at play here.

What is needed here is Remote Attestation of the trustworthiness of the consumer's computer system. The problem is, we may never get to the point where remote attestation is possible, because of the socio-political aspects of trustworthy computing, not the technical aspects. It's the same reason why every year for the last decade has been the "year of the PKI", but in none of them have we seen widespread adoption of public key infrastructure to the point that it would be our saving grace or silver bullet like it has been heralded to become. Trustworthy computing, as simple as calculating trust relationships through public key cryptography (such as with the use of TPMs), requires an authority to oversee the whole process. The authority has to vouch for the principals within the authority's realm. The authority has to define what is "correct" and label everyone and everything within its domain as either "correct" or "incorrect", from a trustworthiness perspective. In this distributed e-commerce problem, there is no authority. And who would do it? The Government? The CAs (Verisign, et al)? And ... the more important question ... if one of these organizations did stand up as the authority, who would trust their assertions? Who would agree with their definitions of "correctness"?

Dr. Geer's suggestion will also work and fail like the many NAC/NAP vendors who truly believe they can remotely attest a computer system's trustworthiness by sending a piece of software to run in a CPU controlled by an OS they inherently cannot trust--yet they believe they have trustworthy output from the software. This method of establishing trust is opt-in security; NAC vendors have tried it and failed (and many of them keep trying in an arms race). And when organizations like, say, Citibank start using one-time-use rootkits, the economics for malware to tell the rootkit "these are not the droids you're looking for" become very favorable. At that point, we'll see just how bad opt-in security can be. The economics for attacking NAC implementations, by comparison, are only in the favor of college students who do not wish to run the school's flavor of AV. It's a chicken and egg problem, only we know without debate in this case. The software we send to the remote host may be different, but the principle is the same: Trust must come first before trustworthy actions or output.

But it would probably make for a great movie plot.

No comments: