Vulnerabilities Allow Attacker to Impersonate Any Website | Threat Level | Wired.com

Vulnerabilities Allow Attacker to Impersonate Any Website

• By Kim Zetter
• July 29, 2009  | 
• 7:37 pm  | 
• Categories: Black Hat Conference

LAS VEGAS — Two researchers examining the processes for issuing web certificates have uncovered vulnerabilities that would allow an attacker to masquerade as any website and trick a computer user into providing him with sensitive communications.

Normally when a user visits a secure website, such as Bank of America, PayPal or Ebay, the browser examines the website’s certificate to verify its authenticity.

However, IOActive researcher Dan Kaminsky and independent researcher Moxie Marlinspike, working separately, presented nearly identical findings in separate talks at the Black Hat security conference on Wednesday. Each showed how an attacker can legitimately obtain a certificate with a special character in the domain name that would fool nearly all popular browsers into believing an attacker is whichever site he wants to be.

The problem occurs in the way that browsers implement Secure Socket Layer communications.

“This is a vulnerability that would affect every SSL implementation,” Marlinspike told Threat Level, “because almost everybody who has ever tried to implement SSL has made the same mistake.”

Certificates for authenticating SSL communications are obtained through Certificate Authorities (CAs) such as VeriSign and Thawte and are used to initiate a secure channel of communication between the user’s browser and a website. When an attacker who owns his own domain — badguy.com — requests a certificate from the CA, the CA, using contact information from Whois records, sends him an email asking to confirm his ownership of the site. But an attacker can also request a certificate for a subdomain of his site, such as Paypal.com\0.badguy.com, using the null character \0 in the URL.

The CA will issue the certificate for a domain like PayPal.com\0.badguy.com because the hacker legitimately owns the root domain badguy.com.

Then, due to a flaw found in the way SSL is implemented in many browsers, Firefox and others theoretically can be fooled into reading his certificate as if it were one that came from the authentic PayPal site. Basically when these vulnerable browsers check the domain name contained in the attacker’s certificate, they stop reading any characters that follow the “\0″ in the name.

More significantly, an attacker can also register a wildcard domain, such as *\0.badguy.com, which would then give him a certificate that would allow him to masquerade as any site on the internet and intercept communication.

Marlinspike said he will be releasing a tool soon that automates this interception.

It’s an upgrade to a tool he released a few years ago called SSLSniff. The tool sniffs traffic going to secure web sites that have an https URL in order to conduct a man-in-the-middle attack. The user’s browser examines the attacker’s certificate sent by SSLSniff, believes the attacker is the legitimate site and begins sending data, such as log-in information, credit card and banking details or any other data through the attacker to the legitimate site. The attacker sees the data unencrypted.

A similar man-in-the-middle attack would allow someone to hi-jack software updates for Firefox or any other application that uses Mozilla’s update library. When the user’s computer initiates a search for a Firefox upgrade, SSLSniff intercepts the search and can send back malicious code that is automatically launched on the user’s computer.

Marlinspike said Firefox 3.5 is not vulnerable to this attack and that Mozilla is working on patches for 3.0.

With regard to the larger problem involving the null character, Marlinspike said since there is no legitimate reason for a null character to be in a domain name, it’s a mystery why Certificate Authorities accept them in a name. But simply stopping Certificate Authorities from issuing certificates to domains with a null character wouldn’t stop the ones that have already been issued from working. The only solution is for vendors to fix their SSL implementation so that they read the full domain name, including the letters after the null character.

(Dave Bullock contributed to this article.)

Photo of Moxie Marlinspike by Dave Bullock.

Tags: BlackHat

• Post Comment  | 
• Permalink

via wired.com

Posted via email from ElyssaD's Posterous