Microsoft Internet Explorer SSL security hole lingers

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. If Microsoft doesn't fix the problem, Apple can't fix it on its own, Apple says. 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.

Apple has fixed the problem for Safari for Macs. 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. Black Hat's most notorious incidents: a quiz "Microsoft is currently investigating a possible vulnerability in Microsoft Windows. 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. 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. 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.

For instance, someone might register www.hacker.com. 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. 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. 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. 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.

Browsers without the flaw correctly identify the root domain and sign or don't sign based on it. 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 user who has requested a session with bestbank would naturally assume the connection established was to bestbank. The vulnerable browser would interpret the certificate as being authorized for bestbank.com and set up a secure session with the attacking server. 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. These certificates use an asterisk as the sub-domain followed by a null character followed by a registered root domain.

In some cases attackers can create what Marlinspike calls wildcard certificates that will authenticate any domain name. 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. Such a wildcard will match any domain, he says. This is due to "an idiosyncrasy in the way Network Security Services (NSS) matches wildcards," Marlinspike says in a paper detailing the attack. 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.

A Microsoft spokesperson says Internet Explorer 8 highlights domains to make them more visually obvious, printed in black while the rest of the URL is gray. "Internet Explorer 8's improved address bar helps users more easily ensure that they provide personal information only to sites they trust," a Microsoft spokesperson said in an e-mail. The URLs in the browser would reveal that the wrong site has been reached, but many users don't check for that, Marlinspike says. Marlinspike says the null character vulnerability is not limited to browsers. "[P]lenty of non-Web browsers are also vulnerable. Outlook, for example, uses SSL to protect your login/password when communicating over SMTP and POP3/IMAP. There are probably countless other Windows-based SSL VPNs, chat clients, etc. that are all vulnerable as well" he said in an e-mail.

0 comments:

Post a Comment