Practical demonstration of the MSIE6 certificate path vulnerability

The vulnerability is described in details in Mike Benham’s post to Bugtraq mailing list. Simply, MSIE fails to detect a inconsistency in certification chain of X509 certificates. This allows the attacker to “inject” his own certificate into the chain and perform a successful man-in-the-middle attack on anyone using MSIE to connect to a SSL server.

I used the following open-source and freely available tools;

• dsniff
• OpenSSL </ul>

  Certificate setup

  The following certificates are needed:
  1. Fake certificate signing request (CSR) for the site you want to masquerade as, which you can make yourself.
  2. Any legitimate website certificate and corresponding private key from any CA known by MSIE (e.g. Thawte or VeriSign). I used Thawte.
  3. Signing CA (Thawte) certificate, to make the certification path complete.</ol> I've then signed the fake CSR using the real private key and certificate, as CA would do. OpenSSL doesn't mind that, even though the website certificate has the "CA: FALSE" constraint.

     Network setup

     I used dsniff's dnsspoof to redirect my MSIE browser to my IP address when it asked for secure.inteligo.com.pl SSL server. On my IP there was modified dsniff's webmitm working, which performed actual man-in-the-middle attack. The program listens on port 443 (HTTP/SSL) and accepts connections from the misguided clients. The webmitm program uses OpenSSL library and I needed to modify it to support certification paths (trivial patch). It needs to see the fake site certificate, signing website certificate and certificate of the CA who signed the latter. The webmitm then presents fake certificate of the banking server to clients together with prepared certification chain, to make the certificate authentic. So the session from client to webmitm is encrypted and trusted by the client and webmitm is free to look at its plaintext contents. The client's data is then sent over SSL to the server, who thinks that its speaking to the client.

     Results

     On the following pictures you can see results of the attack. The first screenshot shows what MSIE thinks about this site. Everything seems to be OK - URL (https), the hostname in URL (secure.inteligo.com.pl) and the page contents. Except for the signer of the website's certificate, which is a security company from my city who was kind enough to sign my fake certificate with their website's cert. Yet on higher level there's well-known certifying authority Thawte, who MSIE trusts and who validates the whole chain. The second screenshot shows what the attacker (me) sees in his webmitm output. The most interesting parts (secret login and passwords) are highlighted.

     Conclusion

     This MSIE vulnerability completely breaks SSL security against man-in-the-middle attacks, based on the Public Key Infrastructure. To perform this attack you need to be able to intercept victim's encrypted session at some point, e.g. in his LAN and there are many ways to do that (DNS spoofing, ARP spoofing, transparent proxy). In my oppinion this attack could be easily used for real money theft. Fixes Fixing this vulnerability is not easy in global scale, as it requires upgrading all MSIE copies. A solution also would be introducing client certificates, but this creates many organizational problems. Tokens Keying tokens or one-time passwords used by most banks don't give any protection againsta this attack, because they are only useful against passive wiretapping, when attacker would try to reuse the key. In this case the attacker is performing active man-in-the-middle attack and he can for example change the destination account number in money transfer just before sending data you submitted to the bank. Disclaimer: this demo was performed on a real banking service, though no their security systems were broken, we actually not even tried. The vulnerability was exploited on the client's side. This article doesn't contain technical details or recipe on how to perform the attack.