Implementation Vulnerabilities in SSL/TLS Marián Novotný novotny@eset.sk ESET, spol. s r.o. Bratislava, Slovak Republic Abstract SSL/TLS protocol has become a standard way for establishing a secure communication channel in internet applications. In recent years several vulnerabilities related to SSL/TLS protocol were disclosed. We will discuss differences between design, implementation and deployment vulnerabilities and try to summarize design flaws in SSL/TLS. However, we will focus on the implementatio n vulnerabilities. We will present how difficult it is to exploit the mentioned vulnerabilities, demonstrate some exploitation and try to evaluate their impact. Finally, we will discuss security risks that design, implementation and realization of SSL/TLS protocol have brought to us. Keywords: SSL, TLS, vulnerability, implementation, OpenSSL, Schannel. 1 Introduction The primary goal of the SSL/TLS protocol is to provide privacy and data integrity between two communicating applications. Various versions of SSL/TLS protocol have been proposed and SSL 3.0 [8] is now an obsolete protocol that has been replaced by its successors TLS 1.0 [4], TLS 1.1. [5], TLS 1.2 [6]. However, TLS implementations still remain backward compatible with SSL 3.0. In the following we discuss differences between design, implementation and deployment vulnerabilities in SSL/TLS while we focus on the implementation vulnerabilities. Design vulnerabilities are flows in specifications that can affect all possible implementations in general. Active and passive adversaries are considered in a security analysis, while the goal of an attacker is to break the privacy or the integrity of communication provided by the protocol. RC4 or a block cipher in CBC mode is used in SSL 3.0 for encryption. Recently published attacks try to exploit a design choice of CBC-MAC in SSL/TLS - it authenticates before encryption. We can mention POODLE [11], BEAST [7], Lucky13 [1].
SSL/TLS protocol is deployed and used as a secure transport for application protocols such as HTTP [13]. For this purpose, web browser should implement a certificate trust verification including a dialog with a user about security of the certificate and a certificate revocation checking. Moreover a browser needs to decide whether HTTP data should be sent over SSL/TLS or in plaintext. Similarly, the server should be configured in order to avoid operational vulnerabilities such as mixed scripting or SSL stripping [10] - very simple attack to realize however probable more exploited than the above mentioned attacks on the design. 2 Implementation Vulnerabilities In this section we will focus on implementation vulnerabilities in OpenSSL and Secure Channel (Schannel) library. OpenSSL library is a popular open source implementation of SSL/TLS as well as a full-strength general purpose cryptography library. Schannel is a Security Support Provider developed by Microsoft that contains SSL/TLS implementation and is used in Microsoft Windows operating systems. Heartbleed - CVE-2014-0160. The vulnerability is caused by a bug in the implementation of a heartbeat extension [15] which allows leaking certain memory content from a host with the vulnerable library and enabled heartbeat. The leak is sent in the heartbeat response packet and can contain confidential data from the host including cookies, passwords and moreover can be repeated in order to read more memory space. CloudFlare announced Heartbleed Challenge competition [14] in order to verify possibility of leaking the private keys from a vulnerable server using the vulnerability. Surprisingly, the private keys were revealed in the competition thanks to the second bug [14] discovered in OpenSSL. Moreover, the vulnerability shows us that the certification revocation system cannot scale up to such massive revocation of SSL certificates which occurred after disclosing the vulnerability [14]. WinShock - CVE-2014-6321. The implementation bugs in Schannel cause various vulnerabilities related to verification of ECDSA signatures that could allow remote code execution or server authentication verification bypass in ECDSA. We reproduced the vulnerabilities in different scenarios including the server authentication bypass in Internet Explorer 11 on Win 7 with the vulnerable Schannel version. We were able to realize MITM attack with our implementation of testing malicious server that uses a valid Extended Validated certificate without knowledge of the private key as shown on Fig 1. Note that the browser displays the green address bar because we use the certificate with the EV flag. Fortunately,
ECDSA certificates are not widespread, but they are used by innovative companies in order to provide Perfect Forward Secrecy using ECDHE-ECDSA key exchange. Figure 1: Example of successful attack that bypasses the server authentication. Freak attack (CVE-2015-0204 in OpenSSL, CVE-2015-1637 in Schannel). SSL/TLS is a complex protocol that supports various versions with many cipher suites with cryptographic blocks defined in different specifications. The data structures for parsing are selected according to a global state and actual received data. To develop and maintain a session state machine with allowed and forbidden transitions is not trivial and error prone task as shown research in [2]. FREAK attack is based on a particular forbidden transition where a client receives a weak server RSA public key in Server Key Exchange message which is in contrast to a chosen RSA cipher suite. It is interesting that the transition is allowed in many libraries including OpenSSL and Schannel. Moreover, the export RSA keys is disabled in TLS 1.1 and the feature is disabled in clients by default they do not offer the export cipher suites in Client Hello message. Note that, for a successful exploitation export RSA cipher suites must be supported by the server, a weak public key need to be shared
between sessions for a certain period of time and the attacker need to break the weak RSA key (512 bit or lesser) by factoring. Therefore, the cost of a successful MITM attack is too high. 3 Conclusions Design vulnerabilities are dangerous because all libraries and implementations of the protocol may be affected. Moreover, it is not easy to remove obsolete version of the protocol due to backward capability of servers and clients. The vulnerabilities are needed to be mitigated by implementation or configuration workarounds such as a TLS fallback signaling cipher suite proposed in [12] that should prevent protocol downgrade attacks. On the other hand, the attacks on the design flaws mentioned in Chapter 1 are not so easy to realize and therefore we do not expect wide scale exploitations. Recently disclosed implementation vulnerabilities show us that a simple bug in the library code can be used for disclosing passwords stored in the memory of the server, or for remote code execution. This way SSL/TLS protocol can downgrade the whole security since it should provide only the confidentiality and the integrity of communication. An implementation bug could be present in a library for many years. The risk is higher in open source libraries which can be searched for bugs for profit. On the other hand, exploitation mitigation techniques such as ASLR, DEP increase the cost for a development of the exploit. Moreover, memory corruption exploits has become less reliable due to the mitigations. Deployment of SSL/TLS protocol into real implementations requires others protocols to be integrated and requires clients such as web browser to follow security best practices including user experience design. Moreover, servers need to be deployed according to best practices such as guidelines developed by OWASP [3] which contain recommendations for usage of mitigation mechanism such as HTTP Strict Transport Security [9], secure Cookie flag or do not mixing TLS and Non-TLS content. References [ 1 ] AlFardan N.J., Paterson K.G.: Lucky Thirteen: Breaking the TLS and DTLS Record Protocols, in IEEE Symposium on Security and Privacy, 2013. [ 2 ] Beurdouche B., et al.: A messy state of the union: taming the composite state machines of TLS, in IEEE S&P, 2015.
[ 3 ] Coates M., Wichers D., Boberski M., Reguly T.: Transport Layer Protection Cheat Sheet. Available: https://owasp.org [ 4 ] Dierks T., Allen C.: The TLS Protocol Version 1.0, RFC 2246, 1998. [ 5 ] Dierks T., Rescorla E.: The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346, 2006. [ 6 ] Dierks T., Rescorla E.: The Transport Layer Security (TLS) Protocol Version 1.2, RFC 5246, 2008. [ 7 ] Duong T., Rizzo J.: Here Come The Ninjas, 2011. [ 8 ] Freier A., Karlton P., Kocher P.: The Secure Sockets Layer (SSL) Protocol Version 3.0, RFC 6101, 1996. [ 9 ] Hodges J., Jackson C., Barth A.: HTTP Strict Transport Security (HSTS), RFC 6797, 2012. [ 10 ] Marlinspike, M.: More tricks for defeating SSL in practice. Black Hat USA, 2009. [ 11 ] Möller B., Duong T., Kotowicz K.: This POODLE bites: exploiting the SSL 3.0 fallback, 2014 [ 12 ] Möller B.: Langley A.: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks, Internet Draft, 2014. [ 13 ] E. Rescorla.: HTTP over TLS RFC 2818. RFC Editor United States, 2000. [ 14 ] Sullivan N.: Heartache and Heartbleed: The insider s perspective on the aftermath of Heartbleed, 31st Chaos Communication Congress (31C3), 2014. [ 15 ] Tuexen M., Seggelmann R.: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension, RFC 6520, 2012.