In Pwned @ hack.lu, Didier Stevens has a nice screenshot of what a lot of people saw at the conference yesterday. Not trusting the crowd in the room, I had configured my Web browser to go through an SSH tunnel elsewhere, so the software that was affected for me was fetchmail -- which I had fortunately configured paranoid enough that it noticed the wacky certificate that was "shown" by my personal server on port 995, pop3-s, and simply died with a nice error message.
So, what happened? As I said in a spontaneous lightning talk after that session, my diagnosis was that somebody was running a man-in-the-middle attack on a room full of security people. The tool they were using rewrote the TLS certificates that were shown by servers, but tried to keep the human-readable information in the certificate intact. (As Benny K notes in a comment, "the certificate seemed fine".)
The tool used was most likely ettercap.
Incidentally, I don't mind that this prank was played on all of us. Attending a hacking conference means you're fair game to some extent -- there will be packet sniffing, and there will be active attacks. As long as no lasting damage is caused, and as long as the attacks don't interfere with the conference talks, that's fine. What I found disappointing, though, is that the responsible party didn't have the stomach to give a lightning talk about the results gathered. For instance, I'd love to know how many of the (security-minded!) people in the room actually clicked past the errors that their browsers and mail clients showed. That would be first-class input for the Web Security Context Working Group. (Anecdotal evidence suggests that a few people got rather nervous after they heard the lightning talk...)
Now, for the details...
How do you diagnose something like this?
Fortunately, the attacker seemed to focus on several TLS-based protocols, and left SSH alone. So, when the errors started, my first step was to ssh out of the conference network, and get a dump of the certificate that the server really shows -- that's easy enough:
$ openssl s_client -host ... -port 995
Running the same thing locally yielded this certificate.
Loooking at these certificates is possible with standard tools:
$ openssl x509 -in ... -text
To compare things, there's of course nothing like the good old diff(1), so that's what came next (full diff here).
There were four significant changes:
- A little bit of mangling to the subject's distinguished name (you'll see that I use a home-grewn CA certificate that's mostly useful for myself); note the duplicate L attribute in the certificate:
Serial Number: 6 (0x6) - Signature Algorithm: md5WithRSAEncryption - Issuer: C=LU, ST=Luxembourg, L=Grevenmacher, O=does-not-exist.org, CN=Thomas Roessler -- CA Key 20060714/emailAddress=roessler@does-not-exist.org + Signature Algorithm: sha1WithRSAEncryption + Issuer: C=LU, ST=Luxembourg, L=Grevenmacher, O=does-not-exist.org, CN=Thomas Roessler -- CA Key 20060714/emailAddress=roessler@does-not-exist.org, L= ValidityThis actually suggests a bug in the tool that was used. -
A different public key:
- 00:bc:1e:0d:ab:8b:3e:c1:9a:b3:a8:ce:67:20:36: - b6:3c:d9:ad:0c:23:fa:e0:b4:7b:7b:a3:03:f2:22: - b2:94:0e:9c:c2:8f:c7:1f:82:ff:ae:6d:c5:dc:ef: - ec:b4:28:bc:76:59:8d:29:02:cc:e9:57:12:c7:ae: - d3:73:0c:95:b8:bf:f2:63:16:43:b6:7e:44:8c:a3: - 43:55:9a:bd:6a:ff:ff:b3:05:90:f7:9d:96:36:0a: - ec:99:41:12:3b:3d:c1:79:8d:3a:73:a5:7b:f0:7a: - 73:1b:e1:c3:cc:76:ce:af:cc:5b:c1:29:0a:fd:34: - e8:d2:5e:54:5b:cf:a2:a2:7b + 00:e8:fb:ae:62:f1:00:e4:2d:d4:59:d0:11:4f:45: + bf:9b:6f:62:3a:ae:81:59:ad:0f:18:5a:76:73:2f: + f4:f8:78:28:70:bb:7e:7c:cb:ac:ab:8d:d7:cf:9e: + 36:ea:4d:5f:1d:41:b7:a8:10:a2:77:56:1f:b2:33: + 6a:c7:53:5e:15:8f:6c:41:4c:54:62:11:3b:03:ec: + 10:08:78:be:bc:1c:87:47:44:53:20:dc:d0:37:f3: + 8d:0f:14:cb:bc:83:47:02:e3:87:d6:c2:0f:a5:02: + c6:30:fa:c4:da:81:66:88:a6:f7:b4:30:7e:81:c9: + c8:5a:3b:e0:18:a4:55:85:27
- Dropped X509v3 extensions; I'd count this as another bug, or would be curious what the attack tool's rationale is for changing this aspect.
- A change in signature algorithm and signature value. The latter is no surprise (after all, there's different key material now); I don't know why the signature algorithm is changed. (Though, yes, the sha1 chosen by the attacker is a better choice than the - cough - MD5 in my server's certificate. That's actually a bug in the certificate.)
So, we learn two characteristics about the attack tool:
- It aims to keep the human-readable information in the certificate intact.
- It changes the public key to one that we now know.
A bit of Google searching later, I knew that ettercap matches the first of these characteristics and, interestingly, has a default key pair.
Well, I can't say I was particularly surprised when that key pair's public modulus turned out to be the one that had been injected into my ongoing TLS transaction. (text dump here)
Of course, the use of that key pair is no proof that ettercap was the tool in question, but it makes it a very likely conclusion. I haven't bothered checking whether the "L=" glitch is typical for this particular tool, or not.
That's actually all.
Comments (2)
Posted by Didier Stevens | October 21, 2007 6:19 PM
Posted on October 21, 2007 18:19
Posted by Marco Ramilli | October 23, 2007 2:32 AM
Posted on October 23, 2007 02:32