14 DAY TRIAL // A vulnerability researcher announces that the latest version of Apple's Safari browser fails to properly protect its users from a technique called URL obfuscation, which has been used by phishers for years. Mitigation efforts in other major browsers are inconsistent with each other and also leave room for improvement.
"Well it is hard to believe, but the new version of Apple’s browser 'Safari 4' still continues to be vulnerable to URL obfuscation techniques," "Inferno" warns on his SecureThoughts blog, after looking into how major browsers handle the problem.
URL obfuscation abuses link-based authentication to hide the real destination of a URL. Such a technique allows attackers to easily trick users into visiting and potentially trusting phishing websites. For his testing, the researcher crafted a URL that looks like:
http://www.bankofamerica.com&service=accountlogin&sessionid= AxYghT809532AjAhklkjfldsl4380439053Xvgjy73099538309 AngfldhgTYiHYojn43540538080985034LAAJKnhfdser6545342iuSA6 feerhteh358fhds&accessip=@69.162.70.130/~appsec/b/index.htm
What happens in this case is that the legit-looking URL, colored in blue above, is being passed as a username for the actual malicious destination link, colored in red. The general format is http://username:password@phishingwebsite.com, where the ":password" part is optional. The attacker's intention is to create a URL that is long enough for the users to no longer notice the malicious part at its end in their browsers.
In Safari, this URL will behave exactly as the attacker expects. The end portion will not appear in the address bar, as the URL exceeds its length. It is, however, noticeable in the status bar, as the browser truncates the link by adding ".." at the middle. There is one problem, though, – the status bar is disabled by default. "Since most users don’t change the default settings, [the] user is again more likely to fall prey when they click a hyperlink somewhere on the web," Inferno notes.
Starting from version 7, Internet Explorer solves this problem by completely removing support for URL-embedded authentication. If a URL formatted in this way is entered into IE7 and above, the browser will return an error prompt. However, the error message is rather confusing, saying that, "Windows cannot find: [link]. Check the spelling and try again." This poses a problem, according to Inferno, because "A normal user might think that IE is not able to open such urls and might try using other browsers like Safari, where they become a prey to his phishing attack."
Opera's mitigation is better, but still has its downsides. Opening such a URL will prompt a security warning alerting the user that they are about to visit an address that contains a username, which it clearly displays separated from the destination server. Again, there's a catch. The option highlighted by default on this prompt is "Yes," which many users might press without reading the message or by accident and continue to the phishing site. Additionally, the status bar truncates the URL at the end, thus keeping the malicious portion hidden.
Firefox seems to have one of the best approaches of all, but still not perfect. Attempting to open such a link will prompt an alert similar to the one in Opera, but with several improvements and much less cryptic for average users. "You are about to log in to the site '[destination]' with the username '[username],' but the site does not require authentication. This may be an attempt to trick you." Note that Firefox additionally checks if the destination web server requires authentication or not. The alert is accompanied by a question that asks, "Is [destination] the site you want to visit?," with the "No" option selected by default.
Where Firefox falls short too is the status bar, overly long URLs getting also truncated at the end, indirectly making the malicious site information unnoticeable when users hover over such links on Web pages.
Chrome has an interesting mitigation to this problem too. While it does not prompt any kind of alerts when such URLs are opened in the browser, it does apply other prevention mechanisms. For one, it strips the "username:password" portion in the address bar, causing the destination to be clearly revealed. The same portion is also stripped when hovering the mouse over such hyperlinks. Additionally, it also converts IP addresses in decimal format to the commonly used IPv4 representation, thus mitigating a secondary URL obfuscation technique.
"I feel that common mitigation techniques should be implemented uniformly in all browsers," Inferno concludes. "If we combine the techniques used by Firefox and Chrome, we can get the best of both worlds which is to continue to support link based authentication and mitigating the security vulnerabilities arising from url obfuscation with overly long urls," he explains.
