Wednesday, October 7, 2009

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

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.



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

PayPal Suspends Researcher’s Account for Distributing Hacking Tools | Threat Level | Wired.com

A security researcher who disclosed a serious vulnerability in online certificates has been blocked from accessing his PayPal account after someone released a counterfeit PayPal certificate he created for a professional training session.

Moxie Marlinspike, who gave a talk at the Black Hat security conference in July about vulnerabilities in the ways that certificate authorities issue website certificates, told The Register that PayPal suspended his account, which contains $500 in value, a day after someone posted his certificate online.

“This is not something I had anything to do with, and they responded by suspending my account,” he told the publication. “I’ve been the one trying to warn them of this in the first place.”

An e-mail to Marlinspike from PayPal indicated the account was being suspended, not for the certificate, but for misuse of the payment processing service.

“Under the Acceptable Use Policy, PayPal may not be used to send or receive payments for items that show the personal information of third parties in violation of applicable law,” the e-mail read. “Please understand that this is a security measure meant to help protect you and your account.”

Marlinspike was told the account would be reinstated once he had removed the PayPal logo from his website.

Marlinspike’s site includes a page where visitors can download free tools he’s written and donate money to him through PayPal. The tools include SSLSniff and SSLStrip, a recent tool he released following his presentation at Black Hat in Las Vegas.

Both tools are used to trick browsers into visiting bogus sites, such as fake PayPal or banking sites, using a bogus certificate.

SSLStrip sniffs traffic going to secure websites that have an https URL in order to conduct a man-in-the-middle attack and take the traffic to an attacker’s fake site instead. The user’s browser examines the attacker’s web 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 would be able to see the data unencrypted.

A PayPal spokeswoman told The Register that the company does not allow PayPal “to be used in the sale or dissemination of tools which have the sole purpose to attack customers and illegally obtain individual customer information.”

The spokeswoman didn’t explain why other sites distributing so-called “hacking tools” and using PayPal to process payments have not had their accounts suspended. She also didn’t say why the company decided to suspend Marlinspike’s account only after someone had posted his bogus PayPal certificate.

Marlinspike’s talk at Black Hat showed how an attacker can legitimately obtain a web 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 some certificate authorities issue Secure Socket Layer (SSL) certificates and in the way that browsers implement SSL communications.

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

Certificates for authenticating SSL communications are issued through Certificate Authorities (CAs) 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 e-mail 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.

Some CAs 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 how SSL is implemented in many browsers, Internet Explorer and other browsers can be fooled into reading the certificate as if it were one that came from PayPal. 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.

Marlinspike said that an attacker could even register a wildcard domain, such as *\0.badguy.com, which would give him a certificate that would allow him to masquerade as any site on the internet and intercept communication. He said there were ways to trick some browsers into accepting a bogus certificate even if an issuing authority later revoked it.

During a private Black Hat training session that Marlinspike gave to security professionals prior to his public talk, he showed participants a PayPal certificate that he obtained as a proof of concept. Marlinspike told the Register he never distributed the certificate to participants, although a person going by the name “Tim Jones” who posted the certificate to the Full Disclosure mailing list on Monday indicated that Marlinspike did distribute it.

“Attached is one of the null-prefix certificates that [Marlinspike] distributed during his ‘intercepting secure communication’ training at Black Hat,” the person wrote. “This one’s for www.paypal.com, and since the Microsoft crypto api appears to remain unpatched, it works flawlessly with sslsniff against all clients on Windows (IE, Chrome, Safari).”

Marlinspike’s PayPal certificate was issued by IPS CA, based in Spain, which reportedly has since revoked the certificate. No one was available at IPS CA to answer questions when contacted by Threat Level.

Some browsers, such as Firefox, post a warning to users that the certificate has been revoked when they try to access a site using the certificate. But other browsers don’t trigger an alert and are fooled into accepting the certificate.

The vulnerability still exists, despite Marlinspike’s warning about it in July, because a bug in Microsoft’s CryptoAPI hasn’t been fixed. Google’s Chrome and Apple’s Safari for Windows, which rely on the Microsoft library to examine certificates, are two browsers vulnerable to spoofed certificates.


PayPal Suspends Researcher’s Account for Distributing Hacking Tools | Threat Level | Wired.com