New JavaScript hacking tool can intercept PayPal, other secure sessions

BEAST, a JavaScript hacking tool developed by two security researchers, can …

On Friday, a pair of security researchers will present a hacking tool which they claim decrypts secure Web requests to sites using the Transport Layer Security 1.0 protocol and SSL 3.0, allowing a person or program to hijack sessions with financial websites and other services. Juliano Rizzo and Thai Duong are unveiling their Browser Exploit Against SSL/TLS tool, dubbed BEAST, at the Ekoparty security conference in Buenos Aires.

The tool is based on a blockwise-adaptive chosen-plaintext attack, a man-in-the-middle approach that injects segments of plain text sent by the target's browser into the encrypted request stream to determine the shared key. The code can be injected into the user's browser through JavaScript associated with a malicious advertisement distributed through a Web ad service or an IFRAME in a linkjacked site, ad, or other scripted elements on a webpage.

Using the known text blocks, BEAST can then use information collected to decrypt the target's AES-encrypted requests, including encrypted cookies, and then hijack the no-longer secure connection. That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long.

The attack, according to Duong, is capable of intercepting sessions with PayPal and other services that still use TLS 1.0—which would be most secure sites, since follow-on versions of TLS aren't yet supported in most browsers or Web server implementations.

While Rizzo and Duong believe BEAST is the first attack against SSL 3.0 that decrypts HTTPS requests, the vulnerability that BEAST exploits is well-known; BT chief security technology officer Bruce Schneier and UC Berkeley's David Wagner pointed out in a 1999 analysis of SSL 3.0 that "SSL will provide a lot of known plain-text to the eavesdropper, but there seems to be no better alternative." And TLS's vulnerability to man-in-the middle attacks was made public in 2009. The IETF's TLS Working Group published a fix for the problem, but the fix is unsupported by SSL.

PayPal spokesperson Anuj Nayar issued this statement regarding the threat embodied by BEAST: “We’ve seen speculation about new research into the security of the SSL technology used by most websites around the world. This research has not been made public, but we have already been looking into the SSL technology employed on the PayPal website and reinforcing our security. We’ll continue to do so once the research is released in the coming week. In the meantime, we can reassure our customers that PayPal’s top priority is the security of their accounts and their personal and financial information. We have dedicated teams of information security experts who continually review and strengthen our security systems. We’ll further review this once we have details of the research later in the week.”

53 Reader Comments

"That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long."That seems like a long time for a transaction to take place. My sessions usually last less then 5 mins.

I don't understand about these things. Code that's injected this way: if you close the window that originally bore this malicious ad, is the code still there? If you quit your browser, then restart a new session every time you want to sign into PayPal, did the code persist from the last session? Or is it only monitoring your sessions while that malicious-code-bearing window is still extant?

"That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long."That seems like a long time for a transaction to take place. My sessions usually last less then 5 mins.

This is a proof of concept -- I'm thinking if someone wanted to throw more CPU horsepower at it (via a botnet army) it would be able to decrypt it in a much shorter time frame.

I don't understand about these things. Code that's injected this way: if you close the window that originally bore this malicious ad, is the code still there? If you quit your browser, then restart a new session every time you want to sign into PayPal, did the code persist from the last session? Or is it only monitoring your sessions while that malicious-code-bearing window is still extant?

Script injection by itself only lasts until you've closed the window (that is unless they did something else along with the injection and installed something more permanent)

"That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long."That seems like a long time for a transaction to take place. My sessions usually last less then 5 mins.

This is a proof of concept -- I'm thinking if someone wanted to throw more CPU horsepower at it (via a botnet army) it would be able to decrypt it in a much shorter time frame.

I may have misunderstand (and if I have, I'm sure I'll be corrected in short order), but I don't think it's an issue of available processing power. I think it's an issue of getting enough traffic from the target to be able to decipher the key. The amount of time mentioned there would should increase or decrease based on the amount of traffic the attacker is able to sniff.

"That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long."That seems like a long time for a transaction to take place. My sessions usually last less then 5 mins.

This is a proof of concept -- I'm thinking if someone wanted to throw more CPU horsepower at it (via a botnet army) it would be able to decrypt it in a much shorter time frame.

CPU power isn't the only bottleneck here.

You will need to flood the link with enough known data to actually be able to break the encryption. I'm guessing that network transfer speeds and client/server SSL/TLS overhead contribute a lot to those 30 minutes.

It's not clear to me how much of a real problem this is. The description indicates that the code needs to be able to inject plaintext into the SSL session. If that's the case, IMHO if you have malicious Javascript which has access to the plaintext end of the SSL session to your bank you've already lost. To the extent that browser windows and tabs are sandboxed from each other, it seems to imply that the malicious code is already in the same sandbox as your secure bank/paypal/etc. session. Or is there something I'm missing?

A chosen plaintext attack by definition is one where an attacker can choose plaintext which will be encrypted and the attacker can then view the encrypted text and use that information to determine the private key in use. But as I said, I would think that any Javascript in a position to pull off this attack would likely just be able to read the plaintext before it was sent or read the session cookies directly.

It's not clear to me how much of a real problem this is. The description indicates that the code needs to be able to inject plaintext into the SSL session. If that's the case, IMHO if you have malicious Javascript which has access to the plaintext end of the SSL session to your bank you've already lost. To the extent that browser windows and tabs are sandboxed from each other, it seems to imply that the malicious code is already in the same sandbox as your secure bank/paypal/etc. session. Or is there something I'm missing?

A chosen plaintext attack by definition is one where an attacker can choose plaintext which will be encrypted and the attacker can then view the encrypted text and use that information to determine the private key in use. But as I said, I would think that any Javascript in a position to pull off this attack would likely just be able to read the plaintext before it was sent or read the session cookies directly.

++

It seems that the code would have to actually be on the server hosting the page... I didnt think javascript could interact with an SSL connection unless it is in that session... meaning if your in your SSL email account and an ad that is hosted on another service is embeded in your email, it could scrape web information, but not actually do anything to the underlying SSL connection? Maybe I am looking at this wrong?

1) wow, kudo's to those guys for experimenting and doing something like this2) now how the hell do I protect myself from it?

As opposed to other news sites where folks go

1) these guys are a menace to society and deserve to get their computers taken away if they're gonna do stuff like this2) now, why the hell is my IE6 and Win98 not working? God, I must have another virus...ugh...stupid computer

It seems that the code would have to actually be on the server hosting the page... I didnt think javascript could interact with an SSL connection unless it is in that session... meaning if your in your SSL email account and an ad that is hosted on another service is embeded in your email, it could scrape web information, but not actually do anything to the underlying SSL connection? Maybe I am looking at this wrong?

The attack can sneak in through an advertisement or anything else that allows external code to execute within a page. So, if someone manages to corrupt the server that's providing graphics or ads to a site, they can inject the code into the page.

WRT NoScript, a number of supposedly secure websites (including one of my two banks) still insist on using JavaScript in stupid places, but it does at least reduce the chances where good security is in place.

++ on that. I often have to switch browsers (or disable NoScript) to get a page to work -- usually when there's content embedded like video -- but I sure like having this for casual browsing.

Definitely agree - noscript FTW!

Not sure why you have to switch browsers. I sometimes have to figure out which of the 36+ .com/.net/.whatever embedded in each web page I have to temporarily enable to be able to see what I want to see which is sometimes a PITA. But if I had to switch browsers then it is too much trouble to get the content.+

The code can be injected into the user's browser through JavaScript associated with a malicious advertisement distributed through a Web ad service or an IFRAME in a linkjacked site, ad, or other scripted elements on a webpage.

I'm trying to understand the scope of this. Since new keys are generated with each connection, this only applies to javascript that can inject plain-text into the connection which they wish to snoop on. Do browsers allow javascript on other pages the ability to do this? If so that in itself is a huge vulnerability. If not, then it only applies to javascript on the same page, requiring compromise of the host, or any other third-party content. Furthermore, if the javascript exploit can read the incoming plain-text in addition to injecting outgoing plain-text, which I think it should, then the whole elaborate MitM known-plaintext attack is just a waste of time.

So it seems the best defense against this attack is to not have third party iframes/javascript on encrypted pages. I would have thought that would be obvious by now with all the XSS vulnerabilities, but developers still keep doing it for convenience/features/performance reasons.

It seems that the code would have to actually be on the server hosting the page... I didnt think javascript could interact with an SSL connection unless it is in that session... meaning if your in your SSL email account and an ad that is hosted on another service is embeded in your email, it could scrape web information, but not actually do anything to the underlying SSL connection? Maybe I am looking at this wrong?

The attack can sneak in through an advertisement or anything else that allows external code to execute within a page. So, if someone manages to corrupt the server that's providing graphics or ads to a site, they can inject the code into the page.

That's how I read it, too. For instance, if you have a secure Gmail session, and some ad or HTML email includes:<iframe src="https://mail.google.com/?[long string of injected text]">

your browser should theoretically make that request to Gmail over your currently-established SSL session.

The 30 minute portion is still unclear to me, though. Does it need to capture

a) 30 minutes worth of that encrypted request with the injected textb) one instance of that request and 30 minutes of other traffic, or c) one instance which takes 30 minutes of processing power?

This seems to make a great case that secure session pages should never have advertisements. Am I right?

If you already have my money (a bank) or I'm buying something (check out), ads on these pages seem rather unnecessary from a revenue generating perspective. Sure they may try to inform me of things that interest me, but in the interest of not having my shit jacked...I'll pass on the ads until my transaction is complete.

"That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long."That seems like a long time for a transaction to take place. My sessions usually last less then 5 mins.

This is a proof of concept -- I'm thinking if someone wanted to throw more CPU horsepower at it (via a botnet army) it would be able to decrypt it in a much shorter time frame.

I may have misunderstand (and if I have, I'm sure I'll be corrected in short order), but I don't think it's an issue of available processing power. I think it's an issue of getting enough traffic from the target to be able to decipher the key. The amount of time mentioned there would should increase or decrease based on the amount of traffic the attacker is able to sniff.

One possible solution for high-profile SSL-enabled sites to implement, short of upgrading to a newer TLS:

This attack is based on a client sending some pre-determined injected text to the server. So the server can be set to say, "if I ever receive a request for something that doesn't exist, immediately de-authenticate the session".

Here's a question, though: is injecting that text really even necessary? For instance, in Gmail, when you're looking at the inbox, I'd imagine that everyone's URI (the part after "mail.google.com") is the same. Can't they do the attack based on that string? Or what about common browser user-agents? Or is it simply that the injected string has to be so long that it's not likely to exist in most browsing sessions?

Except then you are fooling yourself into a false sense of security.What happens when the site you trust gets compromised, whoops you get pwnd.

Someone else can correct me if I am wrong, but if that happened then NoScript would display the malicious script separately. The user must single out and white list the malicious script in order for it to function. That same user should be able to allow the other non-malicious scripts on the site to work without white listing the malicious script so that they can perform transactions and other activities.

The attack does not recover the key, but lets the site you connect with (unwittingly) decrypt the message indirectly. This has been known to be possible for quite a long time, but was deemed "theoretical", which thanks to scripting isn't anymore. The latest standards (TLS 1.1 and higher) are already immune, but it will take some convincing to convert browser makers and sites to move on.

Except then you are fooling yourself into a false sense of security.What happens when the site you trust gets compromised, whoops you get pwnd.

Methinks everyone else felt sorry for you and resisted the temptation to point out the obvious.But I'll do it!

If your banking site is already pwnd, whoops your banking site is pwnd.

But seriously if your banking site does business with an advertiser, and that advertiser is already pwnd; then noscript will allow your trusted banking site and simultaneously block the pwnd advertiser. See how some pro-active security is better than none at all. Silly rabbit, kicks are for ribs!

I don't understand why a simple regular check-sum can't thwart the man-in-the-middle injection. If the incoming message, with injection, doesn't add up to the correct count then reject the message, yielding no information for a bad guy to chew on and alerting us there is a transmission error of some sort.

I've used it in the past to make sure web hosts and servers meet "modern" standards, but obviously this new Javascript exploit discovery knocks the standards up another level.

And I'd also like to say that it really annoys me that Microsoft won't release a version of Internet Explorer 8 or 9 for Windows XP that has TLS 1.1 and 1.2 support! OS dependent security is ridiculous.

Sean Gallagher / Sean is Ars Technica's IT Editor. A former Navy officer, systems administrator, and network systems integrator with 20 years of IT journalism experience, he lives and works in Baltimore, Maryland.