25C3: Severe Vulnerabilities in SSL and SSH

The presentation by Luciano Bello und Maximiliano Bertacchini covered the pseudorandom number generator (PRNG) vulnerability that had plagued Debian the middle of 2008. The two Argentineans once again worked the vulnerability and concluded emphatically that the problem affects not only Debian server admins, but all system admins whose hosts had at one time used Debian to create certificates. Furthermore, the problem affects not just SSH, but GnuPG-signed data and SSL certificates created with libssl.

The speakers ended with an arcane rundown on how theoretical weaknesses in the MD5 hash function could have serious practical consequences. An international team assembled by Hackerspace activist Jacob Appelbaum had identified how a complete root certificate can be generated that all web browsers would unfortunately accept.

The team was looking for an SSL found in current browsers that uses the MD5 hash function, even though MD5 (dating from 1991) "has been broken" since 2004 and caused further vulnerabilities in 2007. The rogue Certification Authority (CA) they could produce had the same hash fingerprint as its originator, which experts call a collision. The collision allows modification via a calculation of a limited number of bytes. The team used a cluster of 200 Playstation 3 machines outfitted with Cell processors and spent three days simulating the collisions. (The alternative would have been running on an Amazon EC2 at a cost of about $20,000.)

The researchers and developers registered a domain and allowed a CA to generate a legitimate SSL certificate by using the old MD5 hash. They then created a collision that produced a sub-certificate and by some scripting and good luck found a certificate with a requested serial number and a defined timestamp (both being required for the attack). Within four weekends they had the rogue SSL certificates they wanted, at a cost of under $1,000.

If a man-in-the-middle attacker could divert the SSL-secured connection and present his own certificate, signed by the falsified sub-certificate, instead of the one requested by the server, no browser would have a chance to recognize the manipulation. These kinds of attacks could pose a serious threat, for example, to e-banking applications with SSL-secured IMAP servers or that run over SSL VPNs. Because the discovers of the attacks don't want to reveal the certificates, there's only a brief window in which browser makers, CAs, and finally users can update their applications.