Legal Disclaimer

"...For Dummies" is a registered trademark of Wiley Publishing, Inc. Wiley has not given authorization for this title, nor is it associated in any way with the Wiley (nee IDG Books, nee Hungry Minds) series "... for Dummies."

February 09, 2007

More Nefarious Chip-And-Pin Attacks

Ziff-Davis has a story detailing some vulnerabilities in the use of smartcards that borders on lame. I love smartcards. They're amazing little things. But they're also prone to some Bad Things.

The reason I call the recent attack announce, "lame" is because it's a simple exploitation of the trust boundary of smartcards. The trust boundary of a smartcard is really the computer and the machine. In certain situations, the trust boundary is the computer, the machine, and the remote server, as I'll outline in the 'more interesting' attack below.

A little while ago I started working on a "PKCS#11 proxy service." The idea is that some older SSL apps don't support PKCS#11. If a server sends a client certficate request, the client doesn't know what to do...it will probably ask you for a file certificate at best, or just fail to negotiate at worst. If you use a HTTP CONNECT proxy service, the service could silently strip out the client certificate request from the SSL handshake and sign the data the server sent by talking to your smartcard itself. This doesn't break the SSL handshake, only the TCP stream, but the CONNECT proxy is the endpoint for the TCP stream so no worries.

"That's kinda neat," I started thinking to myself, "I wonder what else you could do with that." Looking at the way the handshake works, you can do a lot of bad things with SSL the way it's defined. The client cert request that an SSL server sends to the client is random data. It's in no way attributable to the site that requests the signature. "So what?" you ask. Here's what: I set up a web site with a URL, say https://www.foo.com and tell you to click the link. You do so, with your smartcard inserted. You connect to my server. My server then opens up a connection to your bank. The bank asks my server to authenticate itself, and sends the random data to my server asking my server to sign it. My server in turn sends an SSL client cert request to you, with the same data that your bank wanted signed, and you sign the request ("What could go wrong?" after all). Now my server is logged into your bank account, and is transferring your funds into my bank account. Neat, huh?

I feel like SSL should change, and should be required to send client cert requests in the format of domainname+date or something. Signing that would be safe(r), because your client could at least check that the certificate request is valid and that you're signing for the site that you think you're signing for. I guess if this idea/attack hasn't been published before, it might be new/novel...

Post a comment










Please enter the number above into the box below.









Further back...

Archives