September 17, 2009, 3:58 PM — Microsoft still does not acknowledge a weakness in its Internet Explorer browser that was pointed out seven weeks ago and enables attackers to hijack what are supposed to be secure Web sessions.
The company says it is still evaluating whether the weakness exists, but Apple, which bases its Safari for Windows browser on Microsoft code, says Safari for Windows has the weakness and the Microsoft code is the reason. If Microsoft doesn't fix the problem, Apple can't fix it on its own, Apple says. Apple has fixed the problem for Safari for Macs.
Black Hat's most notorious incidents: a quiz
"Microsoft is currently investigating a possible vulnerability in Microsoft Windows. Once our investigation is complete, we will take appropriate action to help protect customers," a Microsoft spokesperson said via e-mail. "We will not have any more to share at this time."
The weakness can be exploited by man-in-the-middle attackers who trick the browser into making SSL sessions with malicious servers rather than the legitimate servers users intend to connect to.
Current versions of Safari for Mac, Firefox and Opera address the problem, which is linked to how browsers read the x.509 certificates that are used to authenticate machines involved in setting up SSL/TLS sessions.
In July two separate talks presented by researchers Dan Kaminski and Moxie Marlinspike at the Black Hat Conference warned about how the vulnerability could be exploited by using what they call null-prefix attacks. The attacks involve getting certificate authorities to sign certificates for domain names assigned to legitimate domain-name holders and making vulnerable browsers interpret the certificates as being authorized for different domain-name holders.
For instance, someone might register www.hacker.com. In many x.509 implementations the certificate authority will sign certificates for any request from the hacker.com root domain, regardless of any sub-domain prefixes that might be appended. In that case, the authority would sign a certificate for bestbank.hacker.com, ignoring the sub-domain bestbank and signing based on the root domain hacker.com, Marlinspike says.
At the same time, browsers with the flaw he describes read x.509 certificates until they reach a null character, such as 0. If such a browser reads bestbank.com\0hacker.com, it would stop reading at the 0 and interpret the certificate as authenticating the root domain bestbank.com, the researcher says. Browsers without the flaw correctly identify the root domain and sign or don't sign based on it.
An attacker could exploit the weakness by setting up a man-in-the-middle attack and intercepting requests from vulnerable browsers to set up SSL connections. If the attacking server picks off a request to bestbank.com, it could respond with an authenticated x.509 certificate from bestbank.com\0hacker.com. The vulnerable browser would interpret the certificate as being authorized for bestbank.com and set up a secure session with the attacking server. The user who has requested a session with bestbank would naturally assume the connection established was to bestbank.
Once the link is made, the malicious server can ask for passwords and user identifications that the attackers can exploit to break into users' bestbank accounts and manipulate funds, for example, Marlinspike says.
In some cases attackers can create what Marlinspike calls wildcard certificates that will authenticate any domain name. These certificates use an asterisk as the sub-domain followed by a null character followed by a registered root domain. A vulnerable browser that initiated an SSL session with bestbank.com would interpret a certificate marked *\0hacker.com as coming from bestbank.com because it would automatically accept the * as legitimate for any root domain.
This is due to "an idiosyncrasy in the way Network Security Services (NSS) matches wildcards," Marlinspike says in a paper detailing the attack. Such a wildcard will match any domain, he says.
The differences between what users see on their screens when they hit the site they are aiming for and when they hit an attacker's mock site can be subtle. The URLs in the browser would reveal that the wrong site has been reached, but many users don't check for that, Marlinspike says.
