That’s what.

The story is that someone stole digital certificates for some big sites on March 15th using a username and password they obtained, the sites included Hotmail, Gmail, Yahoo and Skype.  On a scale of one to ten of a sites security issues this is more like an eleven.  The certificate is what proves you are you, if a clone of one of these sites was setup with the stolen certificate you could not prove it was a clone.  Now there is a system to deal with this in the CA system, there is something called a certificate revocation list, these certs are what the list sounds like, revoked.  But you need to keep them up to date, and yet still you need to have your browser actually tell you when you are at a site that has a revoked certificate.

Chrome had it’s updated in a couple of days, but FireFox and IE took seven and eight days.  The involved vendors were worried about responsible disclosure, really the only personal that benefited from the delay was the one who had the certs in their hands.

The basic premise of the attack is a man in the middle attack using SSL renegotiation.  Here is what a basic attack would look like.

When Jimmy connected to the wireless network Sam (the attacker) poisoned his ARP cache and now all of Jimmy’s traffic is flowing through Sam’s laptop and then out to the internet.

When the connection to https://e-banking.com came through Sam’s laptop he held back those packets (Session #1) and opened a new connection to https://e-banking.com (Session #2).  Sam then completes a full TLS handshake and triggers a renegotiation of the tunnel (This is a standard function of the protocol).

Then Session #1 that was held back is released to https://e-banking.com, this is done over the encrypted Session #2 tunnel.  The server receives the Session #1 connection and associates the session with Sam (attacker) and not Jimmy (again this is expected behavior of the protocol, the server was expecting a renegotiation and a new connection looks exactly the same).

At this point Jimmy has no idea what has happened his browser still says he is connected to the site and that the SSL certificate is trusted.

This is overly simplified example of what could be done in a case like this.

Jimmy sends a get command to do a fund transfer.

GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=1234567 HTTP/1.1

Cookie: victimscookie

Sam gets this or any other packet with the cookie in it and adds the following.

GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=9876543 HTTP/1.1

X-Ignore-This:

After the X-Ignore-This Sam adds the information from Jimmy’s packet, and ends up with this when it arrives at the server.

GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=9876543 HTTP/1.1

X-Ignore-This: GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=1234567 HTTP/1.1

Cookie: victimscookie

The web server ignores the legitimate request because of the X-Ignore-This but processes the other GET request and uses the Cookie for authentication.

This exact setup was just proven using twitter by a researcher and they were able to get twitter to ‘tweet’ back the usernames and passwords from the high jacked sessions.  

Here is a link to the story about the Twitter attack, http://www.theregister.co.uk/2009/11/14/ssl_renegotiation_bug_exploited/

Enjoy,