Forge certificate for man in the middle attack

Question

I'm trying to analyze a SSLv3 connection. The certificate of the server has a "MD5 with RSA" signature. So I was setting up a local man in the middle attack by setting up a local DNS server that would return a local IP address to the client. That local server would pipe the connection to the real server. However, the client immediately drops the connection, because it verifies the certificate, this suggests the binary is using certificate pinning. I don't have write access to the calling binary, therefore I can't just patch the cert-verification.

Is it possible to forge a certificate so the MD5 signatures collide, preventing the client from dropping the connection? I already read about HashClash, that it is indeed possible to create two certificates that have a colliding MD5 signature. But is it possible to do the same with a given certificate? If yes, is it possible in a reasonable amount of time?

Answer 1

Is it possible to forge a certificate so the MD5 signatures collide

Technically it is possible, but it will take a significant amount of work, this is exactly what hashclash discusses.

Generically, you can clone all aspects of the original certificate (CN, OU, expiry dates, etc) except its signature which depends on the original key pair and the private counter-part of the signing cert. Once you can produce a verifiable signature against parameters you've chosen, you've successfully fully forged a certificate.

Although... this may not be the most efficient use of your time... see below.

However, the client immediately drops the connection, because it verifies the certificate, this suggests the binary is using certificate pinning.

That is a reasonable assumption and may in fact be true. But it's not the only explanation to the client's behaviour. Some of the reasons that have a client reject a TLS connection can be influenced:

• The code could be checking certificate parameters but not its actual signature - which you can, for the most part, duplicate in a fake cert;
• The code could simply be checking whether the certificate is valid against a root CA, which you can also influence, by importing your own root CA, having used it to sign the fake cert;
• The code could be implementing cert pinning. On a rooted android or JB iDevice you can use objection to bypass some of the cert pinning routines;

Answer 2

Manipulating a SSL certificate in this manner would be very similar to what the authors of the Flame malware did in 2012, where they carefully crafted the malware so that it appeared to signed using a valid code-signing certificate that chained-up to a Microsoft Root authority.

At the heart of the attack was a chosen-prefix collision. This is an attack where the attacker can choose two arbitrary files, then append different calculated bytes to each, so that both files produce the same md5 hash.

In the case of the Flame attack, the attackers started with a valid certificate that chained-up to a Microsoft root, and had been used to sign a legitimate file. The signature in that certificate was done over the (weaK) md5 hash of the file. The authors of the Flame malware used a chosen-prefix attack to make their malware file produce the same md5 hash as the legitimate file, thus making it appear as if the malware file was signed by the certificate. For more info, see https://en.wikipedia.org/wiki/Flame_%28malware%29#Operation and https://msrc-blog.microsoft.com/2012/06/06/flame-malware-collision-attack-explained/.