The first working attack on the SSL / TLS protocol
Data transmitted over an SSL connection can be decrypted! To do this, Julian Rizzo and Tai Duong managed to use flaws in the SSL protocol itself. And let it not yet be a matter of completely decrypting the traffic, the BEAST utility developed by them can extract from the encrypted stream what is of the greatest interest - secret cookies with the user session ID.
It took only 103 seconds for the BEAST utility (Browser Exploit Against SSL / TLS) to decrypt the secret cookie to log into your PayPal account. You can watch the videocast on Youtube . This is not a fake. A live demonstration of the utility took place at the Ekoparty conference in Buenos Airos, where researchers gave a presentation and showed a working proof-of-concept. The used vulnerability really allows to intercept imperceptibly the data transmitted between the web server and the user's browser. Ironically, the attack does not exploit any new flaw found in the protocol, but the SSL / TLS vulnerability of a decade ago, which for a long time was considered purely theoretical. But, as they say, once a year and a stick shoots, so for ten years, the vulnerability can definitely pass from the theoretical level to a completely practical one.
Researchers do not publish the utility yet, but they share whitepaper about the work done . The program consists of two elements: a sniffer, which 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 a page with the necessary code). The agent is needed in order to specifically embed data into the same secure communication channel that is used to transfer secret cookies. How does this allow to decrypt data? This is where the long-known SSL 3.0 / TLS 1.0 vulnerability comes in, which we will focus on in more detail.
')
The SSL 1.0 / TLS 3.0 protocol allows the use of encryption with a symmetric key, using either block or stream ciphers. In practice, however, block ciphers are commonly used, and the attack we are describing is applicable to them. To grasp the essence, you need to be well aware of basic concepts.
The principle of a block cipher is to display plaintext blocks in encrypted blocks of the same size. The easiest way is to present a block cipher as a giant table containing 2 ^ 128 entries, each of which contains a block of text M and its corresponding encrypted block C. Accordingly, for each encryption key there will be a separate such table. Further we will denote encryption as a function:
C = E (Key, M), where M is the original data, Key is the encryption key, and C is the encrypted data received.
The blocks are small (usually 16 bytes). Therefore, the question arises: how to encrypt a long message? You can break the message into blocks of the same length (the same 16 bytes) and encrypt each block separately. This approach is called simple replacement mode (ECB, Electronic codebook), but is rarely used. There is a reason for this: if we encrypt two blocks of the same content, then as a result and at the output we will get two identical encrypted blocks. This entails the problem of maintaining the statistical characteristics of the source text, which is well demonstrated in the illustration. To avoid such an effect, a cipher-block chaining linkage mode was developed, in which every next XOR plaintext block with the previous encryption result:
During the encryption of the first block, the source text XOR'is some initialization vector (Initialization Vector, IV), which replaces the result of the previous encryption, which for obvious reasons is not. As you can see, everything is quite simple. However, this theory describes the situation for a single large object, such as, for example, a file that is easily broken 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 broken into one or more packets, which, in turn, can be sent within a few seconds or a few minutes. In this situation, there are two ways to use CBC mode:
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 attack is based on several assumptions, but the experience of the creators of BEAST has shown that they can be fully realized in real life. The first assumption: the attacker must be able to sniff the traffic that the browser transmits. Second assumption: the bad guy must somehow force the victim to transfer data over the same secure channel of communication. Why do you need it? Consider the case when a secure connection is established between the Bob and Alice computers. We receive a message, the i-block of which, as we assume, contains the password of Alice (or the secret cookie — it does not matter). Denote the encrypted block as Ci, respectively, Mi is its password. Recall 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 (because we were able to intercept) the initialization vector, which will be used to encrypt the first block of the next message. This is, accordingly, the last block of the previous message (in encrypted form) - we denote it IV. We also intercepted and know the value of the block coming in front of Ci - we denote it by Ci-1. We need this data very much. With their help, we in a special way form a message so that the first block is equal to the following:
If the message could be transmitted via the same secure communication channel, the first block of the new message after encryption will look like this:
All I did was use the full form of the M1 record, after which I simplified the formula using the fact that (IV xor IV) is destroyed (a remarkable feature of XOR). It turns out that if our assumption about the Alice password is correct (that is, M really equals 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 wrong, there will be no equality. So we can test our assumptions.
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, the M block is 16 bytes in length. Even if we know the meaning of all but two bytes, we will need 2 ^ 15 (32,768) attempts to guess the remaining bytes. And if we do not know anything at all? In short, the technique can work only in one case - if you have some limited number of assumptions about the value of M. More precisely: we need to know most of the contents of this block - this is the only way to exploit the described vulnerability. There is one trick here.
Suppose that an attacker can control how the data will be located in the block to be encrypted. Let's go back to the Alice example. Suppose we know that the length of her password is 8 characters. If an attacker can arrange the password so that only one character gets into the first block, and the remaining seven hit the next. The idea is to transfer 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 need to send a line of the form: “user: alice password: ********”, where “********” is the password itself. If the attacker manages to transfer the string so that it is split into the following blocks "[lice password: *] [******* .........]", then selecting the first character of the password does not seem impracticable challenge On the contrary, in the worst case, we will need a miserable 256 attempts. And in the case of special luck, and at all alone :)! Having picked up the first byte, you can shift the partitioning boundary by one character: that is, to transfer 14 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 picked up. 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. Selection is accelerated by narrowing possible characters (not all can be used in the request), as well as by the assumptions of the name cookies.
However, the vulnerability itself and the optimized way to perform decryption have been described for a long time. What the BEAST developers really did was to implement all the necessary conditions for the execution of the attack:
Silently injecting an applet or JavaScript to the user is not really that difficult. But there remains a small nuance - in order for the script or applet to send data over the connection established by the victim, it is necessary to bypass the 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 on the pages of one site to access methods and properties of each other without restrictions, but prevents access to most methods and properties for pages on different sites. Simply put, a client running on the same page will not be able to make requests to the desired site (say, Paypal.com). To circumvent the SOP policy, the authors found a 0day vulnerability in the Java virtual machine and wrote a working float for it. Just do not think that this allows you to read existing cookies. If this were true, then why was all this fuss stuffed with encrypted traffic necessary? Using a flop to bypass the 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 a story about creating an agent in their blog .
In conclusion, I would like to note the tremendous work of researchers, who not only managed to exploit the vulnerability forgotten by everyone ten years ago, but also put a lot of work to make their utility work. Within the framework of this material, we have quite strongly simplified the descriptions of the techniques used, trying to convey the basic idea. But we really enjoyed reading the detailed document from the researchers, in which they tell in detail about the implemented attack. Good job!
So what is the scale of the disaster? Or in other words - who is vulnerable? Virtually any site that uses 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, it has been used by units!
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 prevails, you can try disabling insecure protocols in the browser (TLS 1.0 and SSL 3.0), and at the same time Java. True, it is not necessary in this case to be very surprised that many sites will stop working.
Journal Hacker, November (11) 154
Collective intelligence .
Subscribe to "Hacker"
What is BEAST?
It took only 103 seconds for the BEAST utility (Browser Exploit Against SSL / TLS) to decrypt the secret cookie to log into your PayPal account. You can watch the videocast on Youtube . This is not a fake. A live demonstration of the utility took place at the Ekoparty conference in Buenos Airos, where researchers gave a presentation and showed a working proof-of-concept. The used vulnerability really allows to intercept imperceptibly the data transmitted between the web server and the user's browser. Ironically, the attack does not exploit any new flaw found in the protocol, but the SSL / TLS vulnerability of a decade ago, which for a long time was considered purely theoretical. But, as they say, once a year and a stick shoots, so for ten years, the vulnerability can definitely pass from the theoretical level to a completely practical one.
Researchers do not publish the utility yet, but they share whitepaper about the work done . The program consists of two elements: a sniffer, which 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 a page with the necessary code). The agent is needed in order to specifically embed data into the same secure communication channel that is used to transfer secret cookies. How does this allow to decrypt data? This is where the long-known SSL 3.0 / TLS 1.0 vulnerability comes in, which we will focus on in more detail.
')
Simple replacement mode issue
SSL Encryption Features 1.0
The SSL 1.0 / TLS 3.0 protocol allows the use of encryption with a symmetric key, using either block or stream ciphers. In practice, however, block ciphers are commonly used, and the attack we are describing is applicable to them. To grasp the essence, you need to be well aware of basic concepts.
The principle of a block cipher is to display plaintext blocks in encrypted blocks of the same size. The easiest way is to present a block cipher as a giant table containing 2 ^ 128 entries, each of which contains a block of text M and its corresponding encrypted block C. Accordingly, for each encryption key there will be a separate such table. Further we will denote encryption as a function:
C = E (Key, M), where M is the original data, Key is the encryption key, and C is the encrypted data received.
The blocks are small (usually 16 bytes). Therefore, the question arises: how to encrypt a long message? You can break the message into blocks of the same length (the same 16 bytes) and encrypt each block separately. This approach is called simple replacement mode (ECB, Electronic codebook), but is rarely used. There is a reason for this: if we encrypt two blocks of the same content, then as a result and at the output we will get two identical encrypted blocks. This entails the problem of maintaining the statistical characteristics of the source text, which is well demonstrated in the illustration. To avoid such an effect, a cipher-block chaining linkage mode was developed, in which every next XOR plaintext block with the previous encryption result:
Ci = E(Key, Mi xor Ci-1)During the encryption of the first block, the source text XOR'is some initialization vector (Initialization Vector, IV), which replaces the result of the previous encryption, which for obvious reasons is not. As you can see, everything is quite simple. However, this theory describes the situation for a single large object, such as, for example, a file that is easily broken 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 broken into one or more packets, which, in turn, can be sent within a few seconds or a few minutes. In this situation, there are two ways to use CBC mode:
- process each message as a separate object, generate a new initialization vector and encrypt according to the described scheme.
- to process all messages as if they were combined into one large object, keeping the CBC mode between them. This can be achieved by using the last cipher of the previous message (n-1) as the initialization vector for the 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 the CBC-cipher
Predictable initialization vector
The attack is based on several assumptions, but the experience of the creators of BEAST has shown that they can be fully realized in real life. The first assumption: the attacker must be able to sniff the traffic that the browser transmits. Second assumption: the bad guy must somehow force the victim to transfer data over the same secure channel of communication. Why do you need it? Consider the case when a secure connection is established between the Bob and Alice computers. We receive a message, the i-block of which, as we assume, contains the password of Alice (or the secret cookie — it does not matter). Denote the encrypted block as Ci, respectively, Mi is its password. Recall 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 (because we were able to intercept) the initialization vector, which will be used to encrypt the first block of the next message. This is, accordingly, the last block of the previous message (in encrypted form) - we denote it IV. We also intercepted and know the value of the block coming in front of Ci - we denote it by Ci-1. We need this data very much. With their help, we in a special way form a message so that the first block is equal to the following:
M1 = Ci-1 xor IV xor PIf the message could be transmitted via the same secure communication channel, the first block of the 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))
= iAll I did was use the full form of the M1 record, after which I simplified the formula using the fact that (IV xor IV) is destroyed (a remarkable feature of XOR). It turns out that if our assumption about the Alice password is correct (that is, M really equals 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 wrong, there will be no equality. So we can test our assumptions.
Sending a request to the server to implement an SSL attack
Features brute force
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, the M block is 16 bytes in length. Even if we know the meaning of all but two bytes, we will need 2 ^ 15 (32,768) attempts to guess the remaining bytes. And if we do not know anything at all? In short, the technique can work only in one case - if you have some limited number of assumptions about the value of M. More precisely: we need to know most of the contents of this block - this is the only way to exploit the described vulnerability. There is one trick here.
Suppose that an attacker can control how the data will be located in the block to be encrypted. Let's go back to the Alice example. Suppose we know that the length of her password is 8 characters. If an attacker can arrange the password so that only one character gets into the first block, and the remaining seven hit the next. The idea is to transfer 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 need to send a line of the form: “user: alice password: ********”, where “********” is the password itself. If the attacker manages to transfer the string so that it is split into the following blocks "[lice password: *] [******* .........]", then selecting the first character of the password does not seem impracticable challenge On the contrary, in the worst case, we will need a miserable 256 attempts. And in the case of special luck, and at all alone :)! Having picked up the first byte, you can shift the partitioning boundary by one character: that is, to transfer 14 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 picked up. 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. Selection is accelerated by narrowing possible characters (not all can be used in the request), as well as by the assumptions of the name cookies.
Only 103 seconds were required to decrypt the secret PayPal cookies.
Attack implementation
However, the vulnerability itself and the optimized way to perform decryption have been described for a long time. What the BEAST developers really did was to implement all the necessary conditions for the execution of the attack:
- the attacker must be able to listen on network connections initiated by the victim’s browser;
- the attacker must be able to embed the agent in the victim's browser;
- the agent must be able to send arbitrary (more or less) HTTPS requests;
Silently injecting an applet or JavaScript to the user is not really that difficult. But there remains a small nuance - in order for the script or applet to send data over the connection established by the victim, it is necessary to bypass the 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 on the pages of one site to access methods and properties of each other without restrictions, but prevents access to most methods and properties for pages on different sites. Simply put, a client running on the same page will not be able to make requests to the desired site (say, Paypal.com). To circumvent the SOP policy, the authors found a 0day vulnerability in the Java virtual machine and wrote a working float for it. Just do not think that this allows you to read existing cookies. If this were true, then why was all this fuss stuffed with encrypted traffic necessary? Using a flop to bypass the 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 a story about creating an agent in their blog .
Respect
In conclusion, I would like to note the tremendous work of researchers, who not only managed to exploit the vulnerability forgotten by everyone ten years ago, but also put a lot of work to make their utility work. Within the framework of this material, we have quite strongly simplified the descriptions of the techniques used, trying to convey the basic idea. But we really enjoyed reading the detailed document from the researchers, in which they tell in detail about the implemented attack. Good job!
Extent of the problem
So what is the scale of the disaster? Or in other words - who is vulnerable? Virtually any site that uses 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, it has been used by units!
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 prevails, you can try disabling insecure protocols in the browser (TLS 1.0 and SSL 3.0), and at the same time Java. True, it is not necessary in this case to be very surprised that many sites will stop working.
Journal Hacker, November (11) 154
Collective intelligence .
Subscribe to "Hacker"
Source: https://habr.com/ru/post/132344/
All Articles