First working attack on SSL / TLS protocol

    The data transmitted over the SSL connection can be decrypted! For this, Julian Rizzo and Tai Duong managed to use the flaws in the SSL protocol itself. And while we are not talking about a complete decryption of traffic, the BEAST utility they developed can extract from the encrypted stream what is of most interest - secret cookies with the user session identifier.



    What is BEAST?


    It took just 103 seconds for the BEAST (Browser Exploit Against SSL / TLS) utility to decrypt the secret cookie to log in to the PayPal account. You can watch the video on Youtube. This is not a fake. A live demonstration of the utility took place at the Ekoparty conference in Buenos Airos, where researchers made a presentation and showed a working proof-of-concept. The vulnerability used really allows you to quietly intercept data transmitted between the web server and the user's browser. Ironically, the attack does not exploit any new vulnerability found in the protocol, but a ten-year-old SSL / TLS vulnerability that has long been considered purely theoretical. But, as they say, once a year a stick shoots, so within ten years, vulnerability can certainly pass from the category of theoretical to quite practical.

    Researchers do not yet publish the utility, but share whitepaper about the work done.. The program consists of two elements: a sniffer that analyzes HTTPS traffic, and a special agent written in JavaScript and Java, which must be loaded in the victim’s browser (for this, for example, you must force the user to open the page with the necessary code). An agent is needed in order to specifically embed data in the same secure communication channel that is used to transmit secret cookies. How does this decrypt data? This is where the long-known SSL 3.0 / TLS 1.0 vulnerability comes in, which we will dwell on in more detail.


    Simple replacement mode problem



    SSL Encryption Features 1.0


    SSL 1.0 / TLS 3.0 allows symmetric key encryption using either block or stream ciphers. In practice, however, block ciphers are usually used, and the attack we describe is applicable specifically for them. To understand the essence, you need to have a good idea of ​​the basic concepts.

    The principle of operation of a block cipher is to display plaintext blocks in encrypted blocks of the same size. It is easiest to imagine a block cipher in the form of a giant table containing 2 ^ 128 entries, each of which contains a block of text M and its corresponding encrypted block C. Accordingly, there will be a separate such table for each encryption key. Next, we will denote encryption as a function:

    C = E (Key, M), where M is the source data, Key is the encryption key, and C is the received encrypted data.

    Blocks are small (usually 16 bytes). Therefore, the question arises: how to encrypt a long message? You can split the message into blocks of the same length (the same 16 bytes) and encrypt each block individually. This approach is called the simple replacement mode (ECB, Electronic codebook), but is rarely used. There is a reason for this: if we encrypt two identical blocks in content, then as a result we get two identical encrypted blocks. This entails the problem of preserving the statistical features of the source text, which is well demonstrated in the illustration. To avoid this effect, a cipher-block chaining blocking mode (CBC) was developed, in which each next block of plaintext XOR is associated with the previous encryption result:

    Ci = E(Key, Mi xor Ci-1)

    During encryption of the first block, the XOR source code is some initialization vector (Initialization Vector, IV), which replaces the result of the previous encryption, which for obvious reason is not. As you can see, everything is quite simple. However, this theory describes the situation for one large object, such as, for example, a file that is easily divided into blocks. In turn, SSL / TLS is a cryptographic protocol - it needs to encrypt not a single file, but a series of packets. An SSL / TLS connection can be used to send a series of HTTPS requests, each of which can be divided into one or more packets, which, in turn, can be sent within a few seconds or several minutes. In this situation, there are two ways to use CBC mode:

    1. process each message as a separate object, generate a new initialization vector and encrypt according to the described scheme.
    2. process all messages as if they were combined into one large object, preserving the CBC mode between them. This can be achieved by using the last encryption block of the previous message (n-1) as the initialization vector for message n.

    Attention, an important point. The SSL 3.0 / TLS 1.0 protocol uses the second option, and this is where the opportunity for an attack lies.


    The principle of operation of the CBC cipher



    Predictable Initialization Vector


    The attack is based on several assumptions, but the experience of the creators of BEAST has shown that it is quite realistic to implement them in real life. The first assumption: an attacker must be able to sniff the traffic that the browser sends. Second assumption: the bad guy somehow has to force the victim to transmit data over the same secure communication channel. Why is this needed? Consider a case where a secure connection is established between Bob and Alice computers. We get a message whose i-block, as we assume, contains Alice’s password (or secret cookie - it doesn’t matter). Denote the encrypted block as Ci, respectively Mi - its password. Let me remind you that Ci = E (Key, Mi xor Ci-1). Now suppose her password is R. The main idea is that we can verify the correctness of our assumption!

    So, we know (as we were able to intercept) the initialization vector, which will be used to encrypt the first block of the next message. This, respectively, is the last block of the previous message (in encrypted form) - we denote it IV. We also intercepted and know the meaning of the block in front of Ci - we denote it by Ci-1. We really need this data. With their help, we form a message in a special way so that the first block is equal to the following:

    M1 = Ci-1 xor IV xor P

    If the message was transmitted via the same secure communication channel, then the first block of a new message after encryption will look like this:

    C1 = E(Key, M1 xor IV) =
    = E(Key, (Ci-1 xor IV xor P) xor IV)
    = E(Key, (Ci-1 xor P))
    = Сi


    All I did was use the full M1 notation, after which I simplified the formula using the fact that (IV xor IV) would be destroyed (XOR’s remarkable property). It turns out that if our assumption regarding Alice’s password is correct (that is, M is really equal to P), then the first encrypted block of the new message C1 will be equal to the previously intercepted Ci! And vice versa: if the assumption is incorrect, there will be no equality. So we can test our assumptions.


    Sending a request to the server to implement an SSL attack



    Search Features


    If we assume that we have a lot of time and many attempts, we can repeat this technique again and again until we find the correct value of M. However, in practice, a block of M is 16 bytes in length. Even if we know the value of all bytes except two, in order to guess the remaining bytes, we need 2 ^ 15 (32,768) attempts. And if we don’t know anything at all? In short, a technique can only work in the only case - if you have a limited number of assumptions about the value of M. More precisely: we should know most of the contents of this block - this is the only way to exploit the described vulnerability. There is one trick.
    Suppose an attacker can control how the data will be located in an encrypted block. Let's go back, for example, with Alice. Suppose we know that her password is 8 characters long. If an attacker can arrange the password so that only one character falls into the first block, and the remaining seven fall into the next. The idea is to transmit known data in the first 15 bytes of the first block - then it will be possible to select only the last byte, which is the first character of the password. For example, suppose you want to send a line of the form: "user: alice password: ********", where "********" is the password itself. If an attacker manages to pass the line so that it is broken into the following blocks "[lice password: *] [******* .........]", then the selection of the first character of the password no longer seems an impossible task. In the worst case scenario, we will need a pathetic 256 attempts. And in case of special luck, it’s completely one :)! Having picked up the first byte, it is possible to shift the boundary of the partition by one character: that is, to transmit 14 previously known bytes in the first message. The block will now end with the first two bytes of the password, the first of which we have already selected. And again: we get 256 necessary attempts to guess its second byte. The process can be repeated until the password is selected. This principle is also used in BEAST for the selection of secret cookies, and modified request headers are used as known data. The selection is accelerated by narrowing the possible characters (not all can be used in the request), as well as by assuming the name of the cookie. In the worst case scenario, we will need a pathetic 256 attempts. And in case of special luck, it’s completely one :)! Having picked up the first byte, it is possible to shift the boundary of the partition by one character: that is, to transmit 14 previously known bytes in the first message. The block will now end with the first two bytes of the password, the first of which we have already selected. And again: we get 256 necessary attempts to guess its second byte. The process can be repeated until the password is selected. This principle is also used in BEAST for the selection of secret cookies, and modified request headers are used as known data. The selection is accelerated by narrowing the possible characters (not all can be used in the request), as well as by assuming the name of the cookie. In the worst case scenario, we will need a pathetic 256 attempts. And in case of special luck, it’s completely one :)! Having picked up the first byte, it is possible to shift the boundary of the partition by one character: that is, to transmit 14 previously known bytes in the first message. The block will now end with the first two bytes of the password, the first of which we have already selected. And again: we get 256 necessary attempts to guess its second byte. The process can be repeated until the password is selected. This principle is also used in BEAST for the selection of secret cookies, and modified request headers are used as known data. The selection is accelerated by narrowing the possible characters (not all can be used in the request), as well as by assuming the name of the cookie. And in case of special luck, it’s completely one :)! Having picked up the first byte, it is possible to shift the boundary of the partition by one character: that is, to transmit 14 previously known bytes in the first message. The block will now end with the first two bytes of the password, the first of which we have already selected. And again: we get 256 necessary attempts to guess its second byte. The process can be repeated until the password is selected. This principle is also used in BEAST for the selection of secret cookies, and modified request headers are used as known data. The selection is accelerated by narrowing the possible characters (not all can be used in the request), as well as by assuming the name of the cookie. And in case of special luck, it’s completely one :)! Having picked up the first byte, it is possible to shift the boundary of the partition by one character: that is, to transmit 14 previously known bytes in the first message. The block will now end with the first two bytes of the password, the first of which we have already selected. And again: we get 256 necessary attempts to guess its second byte. The process can be repeated until the password is selected. This principle is also used in BEAST for the selection of secret cookies, and modified request headers are used as known data. The selection is accelerated by narrowing the possible characters (not all can be used in the request), as well as by assuming the name of the cookie. that is, to transmit 14 previously known bytes in the first message. The block will now end with the first two bytes of the password, the first of which we have already selected. And again: we get 256 necessary attempts to guess its second byte. The process can be repeated until the password is selected. This principle is also used in BEAST for the selection of secret cookies, and modified request headers are used as known data. The selection is accelerated by narrowing the possible characters (not all can be used in the request), as well as by assuming the name of the cookie. that is, to transmit 14 previously known bytes in the first message. The block will now end with the first two bytes of the password, the first of which we have already selected. And again: we get 256 necessary attempts to guess its second byte. The process can be repeated until the password is selected. This principle is also used in BEAST for the selection of secret cookies, and modified request headers are used as known data. The selection is accelerated by narrowing the possible characters (not all can be used in the request), as well as by assuming the name of the cookie. This principle is also used in BEAST for the selection of secret cookies, and modified request headers are used as known data. The selection is accelerated by narrowing the possible characters (not all can be used in the request), as well as by assuming the name of the cookie. This principle is also used in BEAST for the selection of secret cookies, and modified request headers are used as known data. The selection is accelerated by narrowing the possible characters (not all can be used in the request), as well as by assuming the name of the cookie.


    It took just 103 seconds to decrypt the secret PayPal cookie.



    Attack implementation


    However, the vulnerability itself and an optimized way to perform decryption have been described for a long time. What BEAST developers really managed to do was to implement all the necessary conditions for an attack:
    1. the attacker should be able to listen to network connections initiated by the victim’s browser;
    2. the attacker should be able to inject the agent into the victim’s browser;
    3. the agent must be able to send arbitrary (more or less) HTTPS requests;
    At the very beginning of the material, I already said that an important part of BEAST is the so-called agent, which will be able to transfer requests to the attacker to the server (using a secure protocol). Researchers have compiled a list of various technologies and browser plug-ins that can fulfill this condition. As it turned out, there are quite a few of them: Javascript XMLHttpRequest API, HTML5 WebSocket API, Flash URLRequest API, Java Applet URLConnection API, and Silverlight WebClient API. However, in a first approximation, some of them were unsuitable due to the presence of restrictions that impede the implementation of attacks. The result is only the HTML5 WebSocket API, Java URLConnection API, and Silverlight WebClient API. At the moment when the researchers reported their bug to the vendors, they had in their hands a working agent based on HTML5 WebSockets. But this technology is constantly evolving, and the protocol itself is constantly changing. As a result, the working agent corny stopped working. The current version of BEAST, which the guys presented to the public, consists of an agent written in Javascript / Java, and a network sniffer.
    Silently deploying an applet or JavaScript to the user is actually not such a difficult task. But there remains a small nuance - in order for the script or applet to be able to send data on the connection established by the victim, it is necessary to bypass SOP restrictions (same-origin policy, domain restriction rule). This is an important security concept for some client-side programming languages, such as JavaScript. The policy allows scripts located on the pages of one site to access each other's methods and properties without restrictions, but prevents access to most methods and properties for pages on different sites. Simply put, a client running on one page will not be able to make requests to the desired site (say Paypal.com). To get around the SOP policy, the authors found a 0day vulnerability in the Java virtual machine and wrote a working spoof for it. Just don’t think that it allows you to read existing cookies. If this were so, then why was all this fuss with encrypted traffic needed? Using splits to bypass SOP, you can send requests and read server responses (including responses with new cookies), but you cannot read existing cookies that are stored in the browser. Developers share the whole story of creating an agent inyour blog post .

    Respect


    In conclusion, I want to note the enormous work of researchers who not only managed to use the vulnerability forgotten by all ten years ago, but also put a lot of work to make their utility work. As part of this material, we have greatly simplified the descriptions of the techniques used, trying to convey the main idea. But we really enjoyed reading the detailed document from the researchers, in which they talk in detail about the implemented attack. Good job!


    Magnitude of the problem


    So what is the scale of the disaster? Or in other words - who is vulnerable? Virtually any website using TLS1.0, which is the most common security protocol. It's funny that after all this hype with BEAST, many began to show interest in newer versions of the protocol - TLS 1.1 and higher. But how many sites now support these protocols? Yes, almost no one! Look at the illustration. Even though TLS 1.1 is already five years old, units use it!



    Another question: how to protect yourself? In fact, it makes no sense to panic - the vulnerability has already been fixed in most browsers. But if paranoia takes over, you can try disabling insecure protocols in the browser (TLS 1.0 and SSL 3.0), and at the same time Java. However, in this case it is not worth much surprise that many sites will stop working.


    image
    Hacker Magazine, November (11) 154
    Collective Mind
    .

    Subscribe to Hacker

    Also popular now: