uncompiled.com

Two researchers at the Black Hat conference in Las Vegas on Thursday exposed 24 ways hackers can hijack seemingly secure browser sessions.

Robert Hansen and Josh Sokol demonstrated methods attackers can use to take over users’ accounts or assume control of a website without the need for any exploits, due to the way browsers implement “HTTPS.” HTTPS, a combination of the Hypertext Transfer Protocol with the SSL/TLS Protocol, allows a website owner to encrypt a session using a digital certificate.

For any of the two dozen attacks to work, however, a criminal would have to have assumed control of a user’s computer via a man-in-the-middle (MITM) exploit, by which an attacker intercepts communications between two systems.

But the researchers wanted to show that HTTPS protection alone won’t stop bad things from happening.

For example, the pair detailed an attack known as “session fixation” that takes advantage of the fact that banks using HTTPS don’t change a user’s cookie after they login — they simply mark it as valid. As a result, an attacker with MITM control could visit the bank site ahead of the user and set the cookie, essentially logging in the crook as the legitimate user.

Another scenario, known as “delayed pop-up,” involves a user who visits a website, such as a bank, and clicks on a link to go the SSL-protected version of the site. This opens a second tab, but if the attacker has control of the first tab, he is able to change the other HTTPS tab to redirect users to malicious executables or authentication forms.

Still, the reliance on MITM makes the scenarios Hansen and Sokol demonstrated unlikely to happen on a widespread scale, they said.

“You’d have to be a very determined attacker,” Hansen said. “And determined attackers have a lot of other avenues for attack.”

He did say that while “the world is not crashing,” website owners and users should take the threats seriously as they have the potential to threaten secure electronic commerce. Potential mitigations include the browser makers offering tab, port and cookie sandboxing controls.

Hansen added that there are likely “hundreds” of other similar vulnerabilities.

Source

LAS VEGAS–A security researcher has found a slew of fundamental problems with the way that modern browsers are designed and built, leading to serious questions about the security of these applications and the way that they handle SSL sessions.

The research, done by Robert Hansen of SecTheory, shows that browsers such as Firefox, Internet Explorer and Chrome have a number of architectural problems that can essentially negate the security that SSL is meant to provide for sensitive Web transactions. The techniques that Hansen has developed, which he demonstrated at the Black Hat conference here Thursday, give an attacker the ability to do any number of nasty things to a target machine, including forcing the download of an executable file, overwriting the URL field in the browser and overwrite secure HTTPS cookies with non-secure cookies.

In all, Hansen found 24 problems before he decided to stop looking. “I had basically had to stop the research because there were just too many issues. I didn’t have time to deal with anymore,” Hansen said.

A big part of the problem, Hansen said in an interview, is that browsers don’t enforce policies that would isolate the tabs in an open browser from one another. This allows an attacker who can control one of the tabs, say a normal non-SSL session, to also affect content in the other tabs, even if they’re using SSL. Hansen identified several techniques that enable him to watch an SSL-protected session and glean a lot of information about what the user is doing, based on timing certain parts of the Web session and knowing how long it takes for part of a site to load. He also can tell whether a user is logged in on a given site and use a specific technique to log the user out so he can then watch the login operation and steal the credentials.

“When you look at it, what does SSL really offer? What this means is that for the average user, against a determined adversary, there really is no protection,” said Hansen, who presented his findings at the Black Hat conference here Thursday. “People give SSL and TLS a lot of credit, when it shouldn’t have any at all.”

SSL is the main transport security used by millions of Web sites to protect data being sent from browsers to Web servers. It’s been shown to be vulnerable to a number of different attacks, including several man-in-the-middle attacks, which could be used in conjunction with some of Hansen’s techniques to completely compromise a supposedly secure Web session.

“The most important thing is that if an attacker can map out the domain ahead of time, he can get a really good feel for how the site is built,” Hansen said. “If there’s a side channel, I can force them to precache some of the content on the page so that I don’t see that again when they reload the page. Then, the only thing you’re seeing are the things that are interesting to the attacker. You can map out the user’s flow around the site and the attacker can force the user to make an SSL connection to them so they can tell which SSL and HTTP headers are being sent in which direction. It’s about narrowing down the number of bytes that are interesting.”

As troubling as the problems that Hansen found are, he emphasized that they don’t mean that the sky is falling.

“You still need to be a man in the middle first and there are probably easier ways to attack people once you are, but there are a lot of issues here,” he said. “If there was better jitter and padding in SSL, a lof of this wouldn’t even be possible.”

Source

Google has paid out its highest sum yet, $2,000, for the discovery of a vulnerability found in its Chrome browser. The recipient is developer Sergey Glazunov, who found a DOM method-related means of circumventing the same origin policy. Details of the vulnerability are not yet publicly available, but it is likely that it could allow a web page to access content from other web pages. Google classifies the risk as high. Update 5.0.375.70 for Windows, Mac and Linux resolves the problem.

The update also fixes a further 10 vulnerabilities, eight of which are classified critical. Two of the vulnerabilities were discovered by Apple – both Chrome and Apple’s Safari being WebKit based. An update for Safari which fixed 48 vulnerabilities was released yesterday. One of the vulnerabilities in Chrome affects only the Linux version and enables escape from the sandbox.

As part of its Chromium Security Reward programme, launched earlier this year, Google has been rewarding those reporting security vulnerabilities with $500. In special cases, a committee can decide to increase the amount to a maximum of $1,337, but the maximum is only awarded for vulnerabilities which are particularly critical, or for particularly clever reports on vulnerabilities and their exploitation.

Google is hoping that this will improve the security of its browser and therefore the security of its users. It’s not clear why Google raised the sum to $2,000 in this case.

Source

Application security vendor Cenzic today released its security trends report for the first half of 2009 application. In it, Cenzic claims that the Mozilla’s Firefox browser led the field of Web browsers in terms of total vulnerabilities.

According to Cenzic, Firefox accounted for 44 percent of all browser vulnerabilities reported in the first half of 2009. In contrast, Apple’s Safari had 35 percent of all reported browser vulnerability, Microsoft’s Internet Explorer was third at 15 percent and Opera had just six percent share.

The 2009 figures stand in contrast to Cenzic’s Q3/Q4 2008 report, where IE accounted for 43 percent of all reported Web browser vulnerabilities and Firefox followed closely at 39 percent.

Source

Google has released version 3.0.195.32 of Chrome, a security update that addresses a high risk vulnerability in its WebKit-based browser. In addition to a number of stability fixes, the stable channel update fixes a bug that could lead to possible memory corruption in the Gears plug-in. For an attack to be successful, a victim would have to visit a site under the attackers control and give that site access to Gears. The attacker could then place the Gears SQL metadata into a bad state which, in turn would cause memory corruption that could cause the Gears plugin to crash or allow for arbitrary code execution.

Source

Researchers say they’ve uncovered a flaw in the secure sockets layer protocol that allows attackers to inject text into encrypted traffic passing between two endpoints.

The vulnerability in the transport layer security protocol allows man-in-the-middle attackers to surreptitiously introduce text at the beginning of an SSL session, said Marsh Ray, a security researcher who discovered the bug. A typical SSL transaction may be broken into multiple sessions, providing the attacker ample opportunity to sneak password resets and other commands into communications believed to be cryptographically authenticated.

Practical attacks have been demonstrated against both the Apache and Microsoft IIS webservers communicating with a variety of client applications. A consortium of some of the world’s biggest technology companies have been meeting since late September to hash out a new industry standard that will fix the flaw. A draft is expected to be submitted on Thursday to the Internet Engineering Task Force.

Source

In this exploit, an attacker uses a maliciously crafted RSS payload to achieve full control over the Victim’s Opera Browser. The attack works by convincing a user to visit a RSS feed link. When the user opens the url in Opera, there are two things that take place. The first one being Javascript in various RSS feed entries gets executed in the context of the calling site. This part was discussed in the previous post and can be used to execute XSS in the context of that site. The second thing that occurs is the untrusted rss feed content lands up in the Opera’s Feed Subscription Page (also the reason for this post). Since this is a native page, it runs in a higher privileged zone than the internet zone (something similar to chrome:// in Firefox and Chrome).

Source