Black Hat: Researchers poke holes in HTTPS, SSL Web browser security

Attackers capable of carrying out man-in-the-middle attacks to hijack Web browsing sessions can go further and render Web security protocols HTTPS and SSL/TLS useless against attack.

This Content Component encountered an error

LAS VEGAS -- The HTTPS and SSL/TLS protocols are at the heart of Web security and trusted ecommerce, but today at the Black Hat Briefings Web application security experts Robert "RSnake" Hansen and Josh Sokol identified two dozen vulnerabilities of varying criticality in the fundamental architecture of Web browsers. These flaws essentially eliminate the protections that HTTPS and SSL are supposed to bring to the browsing experience...

.

HTTPS (HTTP over SSL or HTTP Secure) adds encryption to the HTTP protocol to protect user page requests as well as the pages that are returned by the Web server from eavesdropping. SSL and its successor, TLS, are the protocols that enable HTTPS via public key cryptography to authenticate clients and servers on the Web.

Hansen and Sokol explained that exploitation first requires a man-in-the-middle attack. Once sitting in the middle of a browser session, an attacker can then exploit most of these issues to redirect sessions to steal credentials or remotely force code execution.

The two researchers, however, did emphasize that these aren't "game-over" types of attacks.

"There are much easier attacks out there," Hansen said. "You still have to [execute a] man-in-the-middle and you have to be a very determined attacker...No, this is not the worst thing ever. But there are situations for ecommerce where this can be devastating."

Hansen, in fact, said that he suspects there could be hundreds of similar security issues with browser security and SSL/TLS still to be uncovered; he said that time constraints prior to preparation of their Black Hat talk prevented them from further research.

Man-in-the-middle attacks are nothing new. Attackers can manage to interject themselves at several junctures in a browser session for a variety of reasons. Some attackers have been able to forge or steal SSL certificates using a variety of methods, including MD5 collisions. Also, because SSL makes DNS and HTTP requests in plain text before a session reaches an encrypted portion of an authentication negotiation, attackers can exploit any of those stops to hijack a session. Attackers have also been successful using MitM attacks to strip out HTTPS links and redirecting users to a malicious HTTP site.

For any attacker, duplicating Hansen's and Sokol's work would require patience and resources. The duo explained two attacks of particularly high criticality that could occur on the heels of a man-in-the-middle attack.

The first is a take on cookie poisoning where an attacker exploits a situation where a browser does not change cookies between a user's sessions, and instead just marks the same cookie over and over as valid. If an attacker could hijack the cookie from the website in advance and then set that one in a visitor's browser, when the user authenticates to a HTTPS site, the attacker would see the credentials and could then log on as the user.

In another scenario, many banking sites redirect users from HTTP to HTTPS site sessions, but rather than opening in a new window, the session opens in a browser tab. Since the old tab is under the attacker's control, that person is able to inject Javascript into the URL and change what happens in the new table. The victim would be susceptible to downloading executables, for example, or being redirected to a malicious login page.

Hansen and Sokol also explained attacks against SSL Web browser sessions where they were able to watch and chart the amount of time users were spending on particular pages within a website. These could indicate stops where data is being processed, Hansen said. They added that, at that point, they could employ a technique on the webpage that would force the user to log out and reauthenticate, giving the attacker the user's credentials.

"There needs to be changes to SSL, like adding extra padding and jitter," Hansen said, explaining that by adding the coding equivalent of jibberish to a request, it would take an attacker longer to carry out an exploit and perhaps frustrate the hacker enough to move on. "There has to be proper tab isolation and sandboxing to be able to fix this class of exploits."

"Security experts might be able to avoid these situations, but normal consumers have to live with it," he added. "We're really stuck with what we've got. I'm not sure there's a simple way to fix this."

Dig deeper on Network Protocols and Security

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close