Let us discuss several attacks that are conducted on Secure Socket Layer, what vulnerabilities they exploit, how the attacks are conducted, and what countermeasures can be applied to mitigate them.
POODLE is an attack carried out against systems that support Secure Socket Layer (SSL) protocol 3.0 with cipher-block chaining (CBC) mode ciphers which uses nondeterministic padding. The attack allows a man-in-the-middle to extract encrypted authentication tokens such as session ids, secure “HTTP” cookies and other HTTP Authorization header contents in cleartext. It primarily makes user web browsers vulnerable to information disclosure, along with applications that use libraries such as certain versions of OpenSSL (which implements SSL v3.0) which is widely used in many web servers.
An attacker would need access to ciphertext sent through the network, and the ability to alter the length and the input sent by the client through the connection to successfully carry out this attack. These conditions could be met by mounting a man-in-the-middle attack.
The process is as follows. Let’s consider the block size of the CBC cipher to be 8 bytes, and that the attacker is trying to decrypt a cookie value. In the encryption process, a message authentication code (MAC) is generated and appended to the data. Then to make the data length a multiple of the block size, 1 to 8 bytes are appended to the message. The last of these bytes contain the value of (8 – 1) so that recipient could discard them before decryption. Altering these padded bytes would not affect the communication process in any way. The attacker would know the encrypted cookie text. He will replace the last byte of the encrypted block with the last byte of the encrypted cookie and send it through the session. The server will obtain the full block, and decrypt it. If the decryption reads the last value of the block to be 7, then the server will discard the injected block and proceed with no error. If it is above 7, or if it is between the range of 0-6 (since MAC verification would fail due to removing wrong number of bytes) it would produce an error. The attacker can observe the reaction of the server and determine when a result of 7 is obtained. Since the ciphertext of previous blocks are known, attacker can XOR the ciphertext of second to last encrypted byte with the injected cookie byte, and obtain the plaintext of the cookie. This can be repeated block by block until the cookie is fully revealed.
A caveat here is that while the protocol to use is usually negotiated by a handshake, the protocol version negotiation feature built into SSL/TLS can be influenced by network disruptions during the handshake. This causes the clients to default to SSL 3.0 or lower despite newer protocols being supported by both sides. Inducing such network disruptions requires very little effort from an attacker, which further aids the attack. This is not possible in newer protocols due to padding bytes being verified to contain the same value, rather than directly discarded without inspecting.
Vulnerability of SSL 3.0 itself cannot be fixed. But the most obvious solution would be to disable SSL 3.0 in both server and client sides. Support for CBC-based cipher suites when using SSL 3.0 should also be disabled. If legacy systems require the protocol to be enabled, forcing protocol downgrade by network disruptions can be disabled by deploying the TLS_FALLBACK_SCSV protocol extension. It must be enabled on both client and server sides for it to be effective. OpenSSL has been updated with TLS_FALLBACK_SCSV, and therefore upgrading OpenSSL is recommended. Servers should also eliminate any explicit error messages that could indicate to the attacker whether the padding check was incorrect.
It is advised that general protections against man-in-the-middle attacks, such as practicing caution when using public Wi-Fi access points, and timely installation of security updates on client browsers and other software would be useful in mitigating the attack.
Heartbleed bug is a vulnerability present in the OpenSSL’s implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension. It is a critical bug which makes secret values of servers and clients vulnerable to disclosure through exposure of system memory, affecting the world wide web in a massive scale.
DTLS is used in encrypting UDP traffic, and the heartbeat extension of OpenSSL allows a client or a server to inquire whether the connection between them is still allowed. The payload contains 3 values, length, payload, and random padding. The recipient of a heartbeat message responds with the same message, but with different random padding. The vulnerability lies in that the recipient of the heartbeat trusts the sender to specify the correct length for the payload. If the length has been modified to a larger value than the payload of sender’s heartbeat, recipient reads memory up to the specified length and responds back, making secure data in memory visible to the attacker.
DTLS is only required for encrypted UDP communication, and therefore the heartbeat protocol should be disabled from all servers that does not require it. Since both client and the server secret values could be compromised by this vulnerability, and as it has been present for a long time before public disclosure, all secret values stored in vulnerable servers have to be replaced. This requires “revocation of the compromised keys and reissuing and redistributing new keys”. Certificate Authorities have to be informed to revoke existing certificates and new certificates have to be obtained. Once these measures are taken, clients can change their shared secrets. Cookies and session keys should be invalidated.
“Timing Info-leak Made Easy” is a chosen plaintext attack on HTTP responses, which is essentially a derivation of the CRIME attack. TIME uses timing information differential analysis of HTTP response to deduce the payload size, as opposed to CRIME’s requirement of observing the payload size through eavesdropping. This makes TIME’s only requirement the ability to control plaintext sent through a connection, therefore “theoretically allowing any malicious site to launch a TIME attack against its visitors, to break SSL/TLS encryption and/or Same Origin Policy (SOP)”.
TIME is preferred to CRIME, since observing HTTP request lengths requires a MITM attack, and HTTP Request compression is widely disabled, as opposed to HTTP response compression which is widely enabled to facilitate faster page loads.
The attack is carried out by analyzing the round-trip time of TCP transmissions. It requires the server to include the values sent by the client in its compressed HTTP response. The attacker adds a guessed character following a string known to be processed by the server to the HTTP request. The idea is that accurate guesses would result in lower round-trip-times (RTT) as the payload will be smaller due to compression. Since the RTT delay is influenced by many factors of network connectivity, the attacker has to make any incorrect guesses result in noticeable RTT delays. This is achieved by setting the size of the payload to be exactly on the sender’s boundary, making any extra byte in the payload to require a transmission, and therein an RTT delay, making the time difference noticeable. Due to the unreliability of the network channel, same value has to be sent multiple times to determine the accuracy of the guessed character. This is repeated until the desired value is obtained in plain-text.
Applications should not reflect back the data sent by HTTP responses in their entirety. This data could be validated, and additional data could be disregarded, therefore making the compression result in the same size. Since the attack is only possible for alphanumeric characters due to HTTP encoding, producing secrets that would contain non-alphanumeric characters as well would also help.
As per many other timing attacks, adding random delays to decryption would also lower the risk of a successful attack. Alternatively, repetitive requests could be asked to be confirmed by the client through CAPTCHA and other anti-automation requests to alert the user of unusual activity. To add to this user awareness aspect, servers should deny the X-Frame-Options in their HTTP headers (followed by trusted exclusions), and browsers should respect the response HTTP headers in rendering webpages. This would reduce the violation of Same Origin Policy for the execution of JavaScript required to conduct the attack.
LUCKY 13 is timing attack against TLS /DTLS, which allows a MITM to recover plaintext from a TLS connection when CBC-mode encryption is used. It follows the same concepts as a padding oracle attack. To conduct the attack, the attacker has to be able to read the TLS handshake messages and inject modified cipher-text into the connection. This attack exploits MAC-then-encrypt mode of TLS/DTLS in combination with the padding of the CBC encryption. TLS version 1.1 or 1.2, or DTLS version 1.0 or 1.1, and SSL 3.0 and TLS (which were patched against padded oracle attack) remain vulnerable to this attack.
HMAC function requires the plain text message to be in a multiple of a pre-defined length, and therefore additional padding is applied to meet this condition. Depending on the number of bytes of the message, the applied no of bytes for padding differs, and the subsequent HMAC operation takes more of less compression cycles.
The attack tries different values in the last two bytes of the second to last ciphertext block, attempting to achieve an occurrence where the given padding is valid. If padding verification fails, it is considered as 0. Hash is extracted and all remaining bytes are used to calculate HMAC and verify integrity. Therefore, invalid padding causes the message length to be longer than it actually is, making the HMAC function run an additional compression cycle. If padding is valid however, this cycle is not run. This timing difference is detected by the attacker, and is used to determine the accuracy of the guess induced into two bytes of the ciphertext.
Attacker can keep trying to recover the other bytes of the encrypted value. Since the location of the cookie in an HTTP request can be obtained by observing multiple requests, JavaScript can be used to alter the request to contain only one unknown byte at each step.
Using an authenticated encryption algorithm, such as AES-GCM or AES-CCM instead of CBC would successfully countermand this attack, but since it is only available in TLS 1.2, wide adoption may be infeasible.
A uniform processing time can be implemented in decryption of ciphertext, making the execution time same and eliminating the possibility of valid padding detection. A dummy function could be used to achieve constant time implementation. Random delays could be added to decryption, as previously suggested in the TIME attack.
Appropriate security patches of application that implement SSL/TLS should be installed, such as OpenSSL, and as instructed in prevention against POODLE, caution is advised when using networks vulnerable to MITM exploits.
TLS & SSLv3 renegotiation vulnerability can be used to inject any arbitrary text into a session by a man-in-the-middle. The attacker uses this property to set up the environment for following tasks, such as extraction of secret values or obtaining access to a protected resource, and then simply piggybacks on the legitimate authentication of the session that follows.
TLS renegotiation consists of establishing a second session under the existing session, which is replaced by the second one upon successful completion. In carrying out the attack, a man-in-the-middle intercepts a client request, and holds it off. The MITM initiates its own session with the server, and runs application layer commands of his choice. This would result in a prompt from the server requesting renegotiation. It could be due to the requirement of a certificate, or a different cipher requirement to access a protected resource, or alternatively initiated by the client. Upon this prompt, the MITM would release the original client request, and the server would authenticate the legitimate client. But since the second session was established under the first session, the commands are thought to be originating from the same source, which results in attacker injected traffic being processed under the client’s context.
Servers could disable TLS renegotiation, but it may be required by application. Furthermore, certain reference libraries may not provide an option for disabling. An extension (“draft-rescorla-tls-renegotiation”) has been proposed that “cryptographically binds TLS sessions to clients” and “allows informing clients about renegotiations” as a countermeasure, and could be deployed at both client and server sides.
T. Zoller, “TLS & SSLv3 Renegotiation Vulnerability,” G-Sec, pp. 1–15, 2009.
J. Salowey and E. Rescorla, “TLS Renegotiation Vulnerability,” 2009.
P. G. Sarkar and S. Fitzgerald, “Attacks on ssl a comprehensive study of beast, crime, time, breach, lucky 13 & rc4 biases,” [Online] [June, 2014], pp. 1–23, 2013.
B. Möller, T. Duong, and K. Kotowicz, “This POODLE Bites: Exploiting the SSL 3.0 Fallback,” Secur. Advis., pp. 1–6, 2014.
G. Irazoqui, M. S. Inci, T. Eisenbarth, and B. Sunar, “Lucky 13 strikes back,” ASIACCS 2015 – Proc. 10th ACM Symp. Information, Comput. Commun. Secur., pp. 85–96, 2015.
T. Be’ery and A. Shulman, “A Perfect CRIME? Only TIME Will Tell,” BlackHat Eur. 2013, 2013.
Z. Durumeric et al., “The Matter of Heartbleed,” Proc. 2014 Conf. Internet Meas. Conf. – IMC ’14, pp. 475–488, 2014.
StackExchange, “SSL3 POODLE Vulnerability”, Information Security Stack Exchange, 2017. [Online]. [Accessed: 29- Jun- 2018].
Synopsys Inc., “Heartbleed Bug”, Heartbleed.com, 2017. [Online]. [Accessed: 29- Jun- 2018].
US-CERT, “SSL 3.0 Protocol Vulnerability and POODLE Attack | US-CERT”, Us-cert.gov, 2014. [Online]. [Accessed: 29- Jun- 2018].