Two weeks ago, Microsoft fixed (Ref Lexsi 12420) a flaw disclosed at the Black Hat by Moxie MarlinSpike in late July regarding X.509 certificates which did not get a big attention.

The flaw itself is simple: most libraries handling X.509 certificates, such as NSS libraries used by Firefox or CryptoAPI in Windows, do not take into account the possibility to insert a null character (\0) in the CN (Common Name) field of an X.509 certificate. Thus, the display stops at this null character when handling a certificate.

As an example, the CN field « lexsi.com\0maliciousdomain.com » is seen as « lexsi.com » by vulnerable software.

Valid certificates using this vulnerability have been published, one for www.paypal.com and the other for * (!).

However, Microsoft has given an exploitability index of 3 (= functional exploits are unlikely).

In order to understand why this index is so low although the exploitability has been proved at Black Hat, let's see what are the requirements to take advantage of this vulnerability.

Let's imagine the case of an attacker who wants to decipher the data exchanged with the website https://www.benevolent.fr which is authenticated and ciphered by SSL protocol.

In the client side, the web browser checks 3 elements to authenticate a website using SSL:

1. The certificate has not expired
2. The certificate is signed by a certification authority present in the trusted authorities list embedded in the browser
3. The domain name is identical to the CN field of the certificate

So, the attacker must own a valid certificate for the www.benevolent.fr domain. It can not be self-signed (condition 2) and therefore it must be obtained from a certification authority. But this is not possible because when buying such a certificate, the certification authority will check that the domain belongs to the attacker.

This is where the vulnerability enters the game, because it is possible to buy a certificate for www.benevolent.fr\0malicious.fr (supposing the attacker owns the domain malicious.fr).

Once in possession of this valid certificate, the attacker can set a page (redir.malicious.fr) which acts as a gateway to the legacy www.benevolent.fr website, with the purpose of silently decipher the victim's packets without raising his suspicion.

This leaves us with our third condition, which prompts a warning when the CN content (considered here as being www.benevolent.fr) is different from the URL set by the user.

The attacker has to manage a way (DNS Cache or ARP Poisoning for example) to get the user forwarded to the IP address of redir.malicious.fr when it types www.benevolent.fr in the address bar.

This step is the one which explains that a massive exploitation did not happen despite the 2 months and a half that Microsoft took to fix it. This also explains the exploitability index of 3.

It is required to forge a specific certificate for each target, and also to be in a man-in-the-middle scenario.

Furthermore, Microsoft states that it ensured the certification authorities listed in its browser do not accept anymore a null character in the certificates they deliver.

But what about the valid wildcard « * » certificate ?

In fact, Internet Explorer do not consider this domain as valid, and a warning is displayed (hoping to increase victim's alertness).

However, the Mozilla foundation browser do not reacts to this wildcard and versions prior to 3.0.13 are vulnerable to this attack without the need for an attacker to forge a specific certificate for each victim.

The flaw has been fixed two days after the conference in the Firefox browser (version 3.0.13, the 3.5 is not affected), in early September by Opera (release of the version 10) and in mid-October by Microsoft in the MS09-056 bulletin. Regarding Safari, the Windows version relies on the Microsoft's CryptoAPI library and therefore is not vulnerable if the MS09-056 fix is applied. Several tools handling certificates have been fixed (thunderbird, mutt, openldap, proftpd, wget, curl, fetchmail, neon, kdelibs, qt ...), and some mobile browsers (BlackBerry).

However, as it is explained by Moxie MarlinSpike, Firefox embeds an automatic update mechanism in which all the protection relies on the website from where the updates are retrieved. And this site is authenticated ... via SSL. If the exploitation requirements are met, an attacker is able not only to decipher SSL data, but also to install whatever he wants to on the victim's computer! The exploitation of a vulnerability in the OCSP protocol in order to prevent the revocation of the certificate is also worth noting.

Let's finish with the Mac version of Safari. In its actual version (4.0.3), its behaviour is different from other browsers (even those which are not patched). Indeed, the null character is ignored. Our certificate "www.benevolent.fr\0malicious.fr" is seen by Safari as being for the domain www.benevolent.frmalicious.fr. However, the example of a certificate with the CN field "sitekey.ba\0nkofamerica.com" given during the presentation shows that exploitation is still feasible, just adding more constraints.

This flaw allows to decrypt SSL traffic (obviously, as we own the certificate offered to the victim), and without him being aware of it as all of the usual signs (lock, green address bar...) are the same. The title of this blog entry is not to take too seriously, as the finding (done concurrently by Dan Kaminsky) is great.

Yet the need to perform a man-in-the-middle attack is a major hindrance for a massive exploitation. Thus, the certificate issued for paypal is not enough to perform a large scale phising. Still, targeted attacks in a corporate network are possible ...

Details of the vulnerability are available in the slides.