Two researchers have developed a new attack on TLS 1.0/SSL 3.0 that enables them to decrypt client requests on the fly and hijack supposedly confidential sessions with sensitive sites such as online banking, e-commerce and payment sites. The attack breaks the confidentiality model of the protocol and is the first known exploitation of a long-known flaw in TLS, potentially affecting the security of transactions on millions of sites.

The attack, developed by Juliano Rizzo and Thai Duong, will be presented at the Ekoparty conference in Argentina on Friday, and, unlike many other attacks on TLS and SSL, it has nothing to do with the certificate trust model in the protocol. Instead, the researchers have developed a tool called BEAST that enables them to grab and decrypt HTTPS cookies from active user sessions. The attack can even decrypt cookies that are marked HTTPS only from sites that use HTTP Strict Transport Security, which forces browsers to communicate over TLS/SSL when it’s available.

The researchers use what’s known as a block-wise chosen-plaintext attack against the AES encryption algorithm that’s used in TLS/SSL.  In order to execute their attack, Rizzo and Duong use BEAST (Browser Exploit Against SSL/TLS) against a victim who is on a network on which they have a man-in-the-middle position. Once a victim visits a high-value site, such as PayPal, that uses TLS 1.0, and logs in and receives a cookie, they inject the client-side BEAST code into the victim’s browser. This can be done through the use of an iframe ad or just loading the BEAST JavaScript into the victim’s browser.

After the BEAST agent is loaded, the second part of the tool, a network sniffer, looks for active TLS connections and then grabs and decrypts the HTTPS cookie, enabling the attacker to hijack the victim’s session with that site. Once that encrypted connection with the site is established, the victim can move off to another tab or do other things on the machine and the attack will still work. The attack forces the browser to load pages from the target site, and the tool then decrypts the first part of the request to the Web server, which includes the secure cookie. The researchers have the ability to decrypt those cookies from within SSL sessions, which essentially negates the confidentiality promise of the protocol.

The decryption process is fast enough that it’s likely imperceptible users, and the researchers said that in a targeted attack, they likely could steal the cookie from a specific site within five minutes of loading the tool. Rizzo and Duong said that their attack exploits a vulnerability in the TLS 1.0 protocol that has been known for quite some time, but was thought to be unexploitable.

“It is worth noting that the vulnerability that BEAST exploits has been presented since the very first version of SSL. Most people in the crypto and security community have concluded that it is non-exploitable, that’s why it has been largely ignored for many years. Our work has two contributions,” Duong said in an email interview. “We introduce a practical and efficient plaintext-recovery attack for that vulnerability. It’s an enhancement of something crypto people call ‘block-wise chosen-plaintext attack’. We present one application the attack: BEAST. BEAST focuses on SSL implementations on browsers which is HTTPS. BEAST works for most major browsers and websites.”

The researchers said that the browser-based attack is just one variant. They said they also could implement a similar attack against other services that use SSL, such as instant-messaging clients or VPNs.

“While other attacks focus on the authenticity property of SSL, BEAST attacks the confidentiality of the protocol. As far as we know, BEAST implements the first attack that actually decrypts HTTPS requests,” Duong said. “While fixing the authenticity vulnerabilities may require a new trust model, fixing the vulnerability that BEAST exploits may require a major change to the protocol itself. Actually we have worked with browser and SSL vendors since early May, and every single proposed fix is incompatible with some existing SSL applications.”

Rizzo and Duong are well-known in the security world for the research last year, also presented at Ekoparty, on the padding oracle attack on ASP.NET applications. That research prompted an emergency out-of-band patch from Microsoft. Opera already has implemented a fix for the TLS attack, and the researchers have been in touch with the other major browser vendors, but it’s not clear when their fixes will be available.

“Browser vendors are implementing a workaround to stop this attack but the real solution is switching to a new protocol,” Rizzo said.

A spokesman for Opera said that the gorup has found that the patch to fix this problem breaks a small number of sites and most users employ the browser’s default configuration, which is not vulnerable to this attack.

“In fact, we do have a patch as you alluded to, but we have not put it in the final release of the browser because, according to our testing, it breaks some sites. Since the vast majority of Opera’s users use the default security configuration and are thus not vulnerable, we decided to pull it at this time rather than risk site breakage,” Opera’s Thomas Ford said in an email.

Categories: SMB Security, Vulnerabilities

Comments (33)

  1. Larry Seltzer
    1

    I guess I’ll have to wait for the conference, but I have to wonder what is meant by “inject the client-side BEAST code into the victim’s browser.

  2. Anonymous
    3

    This is a ridiculous amount of hype for a vulnerability that has been known for almost a decade.

    “Browser vendors are implementing a workaround to stop this attack but the real solution is switching to a new protocol…” and we could call that protocol TLS 1.1!  Wait, theIETF already created something with that name! In 2006….

     

  3. Anonymous
    4

    Wouldn’t the practice of good journalism require you to include at least one quote from an expert in this field, to confirm that this is a vulnerability which is so severe that it requires us to replace SSL?

    Oh, that’s right, you can’t, because the details haven’t been released yet, so there’s no way to know what this actually does or whether these claims are just exaggerated. It’s probably fine, nobody ever exaggerates anything in the security industry.

  4. Marsh Ray
    5

    Anonymous 12:41 pm: I’ve spoken with some experts who do know the details. They are all of the opinion that the sky is not falling. If it were a total BS attack they would have said so.

    Duong and Rizzo have a track record of delivering the goods. It should be interesting.

  5. Anonymous
    6

    The moral of the story is be diligent about browser patching; if you’re vulnerable to anything except a zero-day you are negligent!

  6. Anonymous
    8

    If the browser architecture is remotely reasonable, then the fix might be easy an straightfoward: Don’t let the different environments (the rightful page and the BEAST communication) share the same socket for the communication. As soon as seperate network sockets are used for the communication, even when resuming the same underlying TLS session on each, the traffic encryption and mac keys differ, and the attack on CBC-mode of encryption will no longer work!

    For a browser this should be much easier to do than for an SSL-VPN channel.

  7. William
    9

    so this leverages a MITM to do it’s work?  NO big deal here..if youa vhe a MITM then all the security in the world is de34ad.  NO news here..move along.

  8. brian-griffin
    10

    Ok folks, say what you want; Padding oracle might be old but common vuln scanners never raise an alert till Juliano and Thai presented it @ekoparty. THEN MS released a patch.

  9. Jonathan Ray
    11

    Firefox and chrome both still use TLS 1.0 in their latest versions despite MITM vulnerability that has been known for years. :(

  10. Jonathan Ray
    12

    @William

    The whole point of https is to protect against MITM.  If you could assume there was no MITM, then there would be no need for https and you could just send plaintext back and forth.

  11. Anonymous
    14

    It’s called a honeypot! Catch them, don’t let them get in. Besides who doesn’t like to catch someone in the act!

  12. wtarreau
    15

    I fail to see what’s new here, all browser-based malware do just that every day. They may have just implemented the first *documented* malware.

     

  13. Anonymous
    16

    @William

    “The whole point of https is to protect against MITM.  If you could assume there was no MITM, then there would be no need for https and you could just send plaintext back and forth.”

    That is a false statement, Mutual authentication help prevent MITM. SSL encrypts your traffic, but can be broken in a MITM if mutual auth isn’t used by intercepting the cert. 

     

  14. Anonymous
    17

    And the moral of the story;

    Don’t do banking from work or any other network you don’t have stict control over until this is fixed!

  15. Jamkomo
    18

    So they need a MITM and Browser Agent injected via 3rd party site/ flash ad (or java) or malicious pdf, etc. 

    Well,  I guess there’s simpler ways to do an exploit, but they wanted to make a point about it being able to decrypt the session.

    Still noteable.

  16. duder
    19

    Absolutely notable if true. Combination of two common and within-reach attack methods plus their new technique, and a result that exposes targets of enormous scope and value.

     

    Pizza time at openssl.org, apache.org et al

  17. Anonymous
    20

    @Jamkomo: the Javascript code is just a proof of concept.

    If I’m correctly understanding what the researchers are saying then you don’t need a MITM attack – just have a sniffer running on any infected machine in a network segment and it could decrypt SSL traffic passing by in real time (either itself, or using compute clusters) capturing “secure” cookies, usernames/passwords and other confidential information.

  18. Anonymous
    22

    I’m just trying to get a better understanding of this from a laymans standpoint.  The way I understand it is that someone (anyone really) must first have their browser/computer comprimised and the code running on their system.  Once that ocurrs, then the encrypted SSL/TLS traffic can be sniffed and eventually decrypted, negating that particular certificate, correct?  So it’s not a function of having to comprimise EVERY browser, simply one and you can get ahold of the key for that particular cert and decrypt all traffic from that website?

  19. Anonymous
    23

    Enable RC4 (a stream cipher) ONLY and all your problems are fixed! Only AES and a few other ciphers are vurnerable. Good old RC4, which is a stream cipher, aint!

  20. Anonymous
    24

    These are all silly comments. MITM attacks against SSL/HTTPS have been and will be just as much a problem, long after TLS v.1.2 has been around. Just look at ssl-strip and ssl-sniff. That problem will not go away until there are fundamental changes in the client-server model.

  21. Tom
    25

    The whole point of SSL is to protect the connection, not the end points. If one of the end points is compromised, then there are a host of attacks that can be performed. I don’t see how anyone can make the possision that atacking an end point is an attack on SSL. That’s not what SSL is designed to protect.

  22. Anonymous
    28

    As a user, I would agree. It’s not a case of patching our software in this case though. The vast majority of servers simply don’t offer TLS 1.1+ and retain the older protocols for compatibility. Just try shutting off the older protocols and you’ll probably find your favorite online bank isn’t up to snuff. This won’t be fixed until server administrators force the migration (add support for the new protocols AND drop the old ones).

     

  23. Dennis Fisher
    29

    @william The whole point of SSL is to provide a barrier against someone who can intercept your traffic. If no one can see your traffic in the first place, why do you care whether it’s encrypted? If a MITM can sniff your traffic but can’t decrypt the SSL-protected session, then who cares? But if he can decrypt your supposedly secure cookies and then hijack your session with PayPal or your bank or whomever, you’re in serious trouble.

  24. Anonymous
    31

    there you go! think of it as a jobs program – they’ll have to hire back all those bank tellers they’ve been laying off…?

  25. Anonymous
    32

    That is because OpenSSL and NSS do not support TLS v1.1, so no Apache web servers are going to support 1.1, and the libraries used by the browsers don’t support it either.

     

  26. corrector
    33

    “no way to know what this actually does or whether these claims are just exaggerated.”

    So, what should journalists do? They shouldn’t ever report anything that hasn’t been independently verified?

    Do you think we shouldn’t even talk about any experiment that hasn’t been reproduced?

    This issue is serious: we want verifiable stories. But don’t blame the journalist on this.

Comments are closed.