Defeat SSL Using Null Prefix Attack

balaji
By balaji

February 17, 2010

This article is about defeating SSL using Man in the Middle (MITM) attacks against SSL/TSL emulating certificates due to flaws in the operating mode of the Network Security Services (NSS). NSS is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. The possible targets for MITM tools are like Firefox, Internet Explorer, Chrome, Outlook, Evolution and any other tool that makes use of the libraries / API's listed above.

null-prefix-attack.jpg

This article is about defeating SSL using Man in the Middle (MITM) attacks against SSL / TSL emulating certificates due to flaws in the operating mode of the Network Security Services (NSS). NSS is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. The possible targets for MITM tools are like Firefox, Internet Explorer, Chrome, Outlook, Evolution and any other tool that makes use of the libraries / API's listed above.

Man in the Middle (MITM) Attack

When we access the URL www.paypal.com from a web browser, the server responds by sending the SSL certificate. Firstly, the SSL implementation at the client checks is the Subject field in the certificate it received, against the domain URL which it is trying to connect to, and to provide authenticity.

mitm_001.jpg

An attacker can perform MITM attack and respond to the client when www.paypal.com is requested. But attacker cannot send a certificate for www.paypal.com, still he can send the actual PayPal certificate to client with public key embedded in it. He cannot decrypt the traffic because he doesn’t know the corresponding private key for that certificate. To gain profit, he needs to own a certificate for www.paypal.com.

Obtaining a Certificate

One can obtain certificates for his/her domain from Certificate Authority (CA) like Thawte or VeriSign. If the domain is to be signed, he has to submit the Certificate Signing Request (CSR). Certificate Signing is a simple structure defined in PKS#10 as shown.

certificate_verification.jpg

At Thawte or VeriSign, the CA would check for the Subject, which is the exact entity for which the certificate is issued. Let's say that we submit CSR for www.site.bankofameica.com where the Common Name is www.site.bankofamerica.com. The CA would look at the root domain (bankofamerica.com) and ignore the subdomain (www.site). Then the CA will do whois lookup for the root domain and contact the administrator of that domain to verify whether he is authorized to get signed to the domain or not. Since the subdomain is ignored by CA, we can request for signing a certificate with Common Name: xxxxxxxx.attackersite.com, xxxxxxxx could be anything. Still the CA checks for attackersite.com and signs the certificate.

For carrying out a MITM attack, we need a certificate for paypal.com but we don’t own paypal.com to get a certificate. However, we can obtain a certificate for paypal.com.attackersite.com. The CA will look only at the root domain attackersite.com, do a whois lookup and contact the administrator of attackersite and finally sign the certificate.

mitm_002.jpg

Now the attacker, being MITM, can forward the Hello from the client to the server and send the client the certificate of www.paypal.com.attackersite.com. Since the certificate has been issued by a trusted CA, the client accepts it and the attacker can sniff the whole traffic successfully.

How does it work?

When the client requests for www.paypal.com, the attacker, as MITM between the client and the server, will respond to the client by sending the certificate of www.paypal.com.attackersite.com. The browser compares the destination URL and Subject field of the Certificate to authenticate.

The code at the client browser would look like:

char *destination = getDomainWeAreConnectingTo();
char *commonName = getCommonNameFromCertificte();
bool everythingIsOk = (strcmp(destination, commonName) == 0);
null-prefix.jpg

The destination would be destination URL typed in the URL bar and commonName would be the Subject value of the certificate. A pointer will check both destination and commoName. The strcmp function will check every character of these values till it reaches the end of the string denoted by nocharecter "". Hence the browser accepts the certificate and authenticates the server.

SSL Implementations Affected

The certificate obtained by this technique is valid for most of the SSL implementations, such as

  • Web Browsers: Firefox, IE, Chrome, Lynx, Curl
  • Mail Clients: Thunderbird, Outlook, Evolution
  • Chat Clients: Pidgin, AIM, irssi, centericq
  • SSL VPNs: AEP, Citrix, etc

Further Attack Deployment

Suppose an attacker wants to get the entire confidential data of all domains from the network. For this, the attacker will have to perform a MITM attack for each of the domains. It would seem that the attacker has to obtain certificates for all the domains. Instead he can obtain a single certificate and still be the man in the middle and sniff all the SSL traffic. This is possible by getting a certificate for *.attackersite.com. This certificate will match any domain the client is trying to connect to. The attack even works for *~.attackersite.com. Similarly the attack can be carried out for selective domains by grouping the domains and obtain a certificate for something like (www.paypal.com|www.etrade.com|www.bankofamerica.com|...).attackersite.com.

Patches and Updates

Thousands of products are still vulnerable to this Null Prefix attack. More information about the patches to this attack can be found at:

Good Reads


Tags: Technical

About

balaji

SUBSCRIBE TO OUR BLOG

Buyers-Guide-Collateral

WHITEPAPER

Buyer’s Guide to Managed Detection and Response

Download
MDR

Get AI Powered

Managed Detection and Response

MDR-learmore-btn

 

MDR-Guide-Collateral

REPORT

AI-Driven Managed Detection and Response

Download Report
Episode

EPISODE-25

Red-LineAsset-6

Why Your ‘Likes’ on Facebook May Be Revealing Far More than You Thought

Click URL in the Post for the Full Podacst
  • FacebookAsset
  • LinkedinAsset
  • TwitterAsset