Misuse Patterns for the SSL/TLS Protocol
by
Ali Alkazimi
A Dissertation Submitted to the Faculty of
College of Engineering & Computer Science
In Partial Fulfillment of the Requirements for the Degree of
Doctor of Philosophy
Florida Atlantic University
Boca Raton, FL
May 2017
Copyright by Ali Alkazimi 2017
ii
ACKNOWLEDGEMENTS
I would like to thank my advisor, Dr. Eduardo B. Fernandez, for his guidance during these years. He has been a true mentor by supporting me not only during my research but also in my personal life. I would also like to express my gratitude to my committee members, Dr. Mohammad Ilyas, Dr. Maria Petrie, and the members of the Secure Systems
Research Group for all their advice and constructive comments of this dissertation. I would like to thank my beloved wife, Abrar Almoosa, and my kids, Fadak, Mohammed, Jude and
Lia for giving me the support during my studies.
I want to thank my father and my mother because without them I would not accomplish anything. I also want to thank my brothers (Mohammad and Zaid) and my sister (Noor) for their continuous support.
I want to thank the Central Bank of Kuwait for their generous support and for giving me the opportunity to achieve my goals.
iv ABSTRACT
Author: Ali Alkazimi
Title: Misuse Patterns for the SSL/TLS Protocol
Institution: Florida Atlantic University
Dissertation Advisor: Dr. Eduardo B. Fernandez
Degree: Doctor of Philosophy
Year: 2017
The SSL/TLS is the main protocol used to provide secure data connection between a client and a server. The main concern of using this protocol is to avoid the secure connection from being breached. Computer systems and their applications are becoming more complex and keeping these secure connections between all the connected components is a challenge.
To avoid any new security flaws and protocol connections weaknesses, the SSL/TLS protocol is always releasing newer versions after discovering security bugs and vulnerabilities in any of its previous version. We have described some of the common security flaws in the SSL/TLS protocol by identifying them in the literature and then by analyzing the activities from each of their use cases to find any possible threats. These threats are realized in the form of misuse cases to understand how an attack happens from the point of the attacker. This approach implies the development of some security patterns which will be added as a reference for designing secure systems using the SSL/TLS
v protocol. We finally evaluate its security level by using misuse patterns and considering the threat coverage of the models
vi MISUSE PATTERNS FOR SSL/TLS PROTOCOL
TABLES ...... xi
FIGURES ...... xii
1. INTRODUCTION ...... 1
2. SSL/TLS THREATS: STATUS AND PATTERNS ...... 6
2.1. Introduction ...... 6
2.1.1. Background ...... 7
2.1.2. SSL/TLS Protocols ...... 12
2.1.3. SSL/TLS Implementations...... 14
2.2. Common Vulerabilities and Attacks in the SSL/TLS Protocol ...... 15
2.3. Vulnerabilities of SSL/TLS ...... 15
2.4. Relatioship between Attacks, Misuse Threats, Vulnerabilites and their
Countermeasures ...... 20
2.5. Template of misuse pattern ...... 22
2.5.1. Name ...... 22
2.5.2. Context ...... 22
2.5.3. Problem ...... 22
2.5.4. Solution ...... 22
2.5.5. Affected system components (Where to look for evidence) (Targets) ...... 23
2.5.6. Known Uses ...... 23
2.5.7. Consequences ...... 23
vii 2.5.8. Countermeasures and Forensics ...... 23
2.5.9. Related Patterns ...... 24
3. MISUSE PATTERN: DENIAL OF SERVICE USING A MESSAGE DROP
ATTACK ...... 25
3.1. Misuse Pattern: Denial of Service Using a Message Drop Attack ...... 26
3.1.1. Intent ...... 26
3.1.2. Context ...... 27
3.1.3. Problem ...... 29
3.1.4. Solution ...... 30
3.1.5. Known Uses ...... 31
3.1.6. Consequences ...... 33
3.1.7. Countermeausre and Forensics ...... 35
3.1.8. Related Patterns ...... 36
4. CIPHER SUITE ROLLBACK: A MISUSE PATTERN FOR THE SSL/TLS
CLIENT/SERVER AUTHENTICATION HANDSHAKE PROTOCOL...... 37
4.1. Intent ...... 37
4.2. Context ...... 38
4.3. Problem ...... 39
4.4. Solution ...... 42
4.5. Known Uses ...... 44
4.6. Consequences ...... 44
4.7. Countermeasures ...... 45
4.8. Related Patterns ...... 46
viii 5. TRIPLE HANDSHAKE AUTHENTICATION ATTACK ...... 48
5.1. Intent ...... 48
5.2. Context ...... 48
5.3. Problem for the attacker ...... 49
5.4. Solution ...... 50
5.4.1. Structure (Affected system components) ...... 50
5.4.2. Dynamics ...... 50
5.5. Affected system components ...... 53
5.6. Known uses ...... 54
5.7. Consequences for the attack...... 54
5.8. Countermeasures ...... 54
5.9. Related patterns ...... 55
6. “HEARTBLEED”: A MISUSE PATTERN FOR THE OPENSSL
IMPLEMENTATION OF THE SSL/TLS PROTOCOL ...... 56
6.1. Intent ...... 56
6.2. Context ...... 57
6.3. Problem for the attacker ...... 58
6.4. Solution ...... 58
6.4.1. Structure (Affected System Components) ...... 59
6.4.2. Dynamics ...... 60
6.5. Affected system components (Where can we find evidence of this attack?) ...... 61
6.6. Known Uses ...... 61
6.7. Consequences ...... 62
ix 6.8. Countermeasures ...... 63
6.9. Related Patterns ...... 64
7. RELATED WORK ...... 65
8. CONCLUSIONS AND FUTURE WORK ...... 68
REFERENCES ...... 74
x TABLES
Table 1: List of Vulnerabilities in SSL/TLS Protocol ...... 16
Table 2: Common Attack in SSL/TLS Protocol ...... 17
Table 3: Relationship Between Attack and Vulnerabilities in SSL/TLS Protocol and
Their Countermeasures ...... 20
xi FIGURES
Figure 1: SSL/TLS Protocol ...... 9
Figure 2: Class Diagram for SSL Client/Server Communication ...... 29
Figure 3: Sequence Diagram for Server SSL Communication ...... 32
Figure 4: Change Cipher Specification Message Attack Sequence Diagram ...... 33
Figure 5: Class Diagram for SSL/TLS Server Handshake ...... 40
Figure 6: Sequence Diagram for Server SSL/TLS Handshake ...... 41
Figure 7: Cipher Suite Rollback Attack Sequence Diagram ...... 43
Figure 8: Class Diagram for Use Case “Triple Handshake Attack” ...... 51
Figure 9: Sequence Diagram for the use case Triple Handshake Attack ...... 53
Figure 10: Class diagram for Heartbeat connection in OpenSSL ...... 57
Figure 11: Class diagram showing the affected units ...... 59
Figure 12: Sequence diagram for use case to get server information ...... 61
xii 1. INTRODUCTION
Providing communications security over the Internet has grown to be a major issue in the modern day. Data connection over any network always implies the possibility of loss of message authentication, integrity or confidentiality. Regardless of the content of the data which may include financial, business or personal information, people want to know who they are communicating with (message authentication), that what is sent is exactly what is received (message integrity), and how to prevent others from reading what they are communicating (message confidentiality). The protocol called SSL (Secure Sockets
Layer), which later became TLS (Transport Layer Security), provides the mechanisms to achieve these security goals to protect the web traffic during the data transit.
SSL became a global standard security technology that was developed by Netscape
Communications to allow secure communication between a browser and a web server
(Thomas, 2000). The protocol assures secure data transmission using several security mechanisms each consist of one or more cryptographic algorithms. SSL is a security protocol that provides the necessary mechanisms to achieve these security goals using cryptography, certificates and digital signatures.
There were some major deficiencies in the first version of SSL which made Netscape eliminate that version’s release. Netscape released SSLv2 in November 1994 after fixing the vulnerabilities in the previous version. It was deployed in Netscape Navigator 1.1 a few months later, in March of 1995. Like the previous version, SSLv2 had security vulnerabilities. One of the main vulnerabilities of SSLv2 was having weak encryption that
1 could lead to breaking its secured data connection in a short amount of time. Netscape modified SSLv2 and strengthened the cryptographic algorithms along with number of solutions to previous security problems and released SSLv3.
In May 1996, the Internet Engineering Task Force (IETF) started standardizing an SSL- like protocol and gave it a new name, Transport Layer Security (TLS). TLS establishes a point to point communication between client and server that uses encryption to provide message confidentiality and authentication. The encrypted messages may be object of attacks that include message reading, modification, and interruption.
In order to understand the security of the data connection between the client and the server, we have enumerated SSL/TLS threats by studying several chosen attacks on these protocols, because it is not possible to enumerate all the threats. We have done this research by first identifying them in the literature and then by analyzing the activities from each of their use cases to find possible threats. These threats are described in the form of misuse patterns in order to understand how an attack happens from the point view an attacker. The misuse patterns can be used as a reference to find where to add security measures to mitigate or stop an attack. They define the environment where the attack is performed and countermeasures to stop it. Misuse patterns provide forensic information to trace the attack once it happens. They are useful for developers because once they determine that a possible attack can happen in the environment, a corresponding misuse pattern will indicate what security mechanisms are needed a countermeasures. Also, misuse patterns can be very useful for forensic examiners to determine how an attack is performed, and where they can find useful evidence information after the attack is done. An important value of misuse
2 patterns is their description of the components of the system where the attack is performed by using class diagrams and sequence diagrams, relating the attack to specific system units.
In this work, we make the following contributions:
1. Threats, Status and Patterns for SSL/TLS (Chapter 2). This analysis helps to
understand security implications on some common threats and the existing patterns
in order to avoid them. Starting with an overview of the challenges identified in the
literature, the analysis identifies the main vulnerabilities and threats of SSL/TLS.
Also, we describe the relationship between these vulnerabilities and threats, and
how these vulnerabilities can be exploited in order to perform an attack, as well as
how to defend against them.
2. In (Chapter 3), we present a misuse pattern: Denial of Service Message Drop
Attack: A Misuse Pattern for the SSL/TLS Server Authentication Handshake
Protocol. In this attack, the attacker performs a Man in The Middle attack to
intercept and drop the “ChangeCipherSpec” message during the client/server
handshake process which causes the server to never leave its pending state and the
communication with the client will not happen, leading to Denial of Service
situation.
3. Analyzing and listing possible attacks and threats for SSL/TLS environments is not
sufficient; we need to understand how these attacks operate when the data
connection is using these protocols. For this, we developed a misuse pattern to
describe how an attack is performed on the authentication handshake protocol for
SSL/TLS in (Chapter 4) that describes how a Cipher Suite Rollback attack happens
from the point of view of the attacker. In this attack, the attacker follows a man-in-
3 the-middle approach to intercept the “ClientHello” message, replaces its Cipher
Suite with a weak or NULL-Cipher, and passes the intercepted message to the
server, which will use now a weaker cipher, allowing the attacker to gain access to
the exchanged data between the client and the server. We developed in Chapter 5
another misuse pattern for the SSL/TLS that involves the attack on client/server
authentication which exploits the encryption algorithms during their connections to
establish secure communication. In the misuse pattern; Transport Layer Security
(TLS): Triple Handshake Authentication Attack; we showed how the attacker with
an access to a breached server can impersonate a client connected to the same
server. The attacker then can get the client’s credentials and use them to gain access
to other servers accepting these credentials. This attack may also allow the attacker
to read sensitive data from other servers by using the targeted client’s credentials.
4. We extended our research to analyze and list another possible attack on one of
SSL/TLS protocol implementations; Open SSL. In Chapter 6 we introduced
another pattern; “Heartbleed”: A Misuse Pattern for the OpenSSL Implementation
of the SSL/TLS Protocol. This misuse pattern covers security issues about the
heartbleed vulnerability in Open SSL. This vulnerability results from improper
input validation (lack of bounds check) in the implementation of the TLS heartbeat
extension. Heartbeats are used to check if connected client/server nodes are
working. The attacker can modify this feature to obtain sensitive data from servers
by modifying the length of the heartbeat message body.
Our approach aims towards a reference guide that can be used by system designers, developers, or network administrators for taking security measures while designing their
4 system. This work is based primarily in identifying main threats and describing them by using misuse patterns, and providing security defenses in the form of security patterns.
Chapter 2 presents some background information that will be useful for the reader to understand better this work. In Chapter 2, we present an analysis of the common threats of
TLS and the patterns related to them to help understand their security implications. Chapter
3 illustrates a misuse pattern Denial of Service Message Drop Attack: A Misuse Pattern for the SSL/TLS Client/Server Authentication Handshake Protocol. Chapter 4 includes another misuse pattern; Cipher Suite Rollback: A Misuse Pattern for the SSL/TLS
Client/Server Authentication Handshake Protocol. Chapter 5 presents another misuse pattern Transport Layer Security (TLS): Triple Handshake Authentication Attack. Chapter
6 includes another misuse pattern “Heartbleed”: A Misuse Pattern for the OpenSSL
Implementation of the SSL/TLS Protocol. Chapter 8 considers related work. We end with conclusions and possible future work.
.
5 2. SSL/TLS THREATS: STATUS AND PATTERNS
This section presents basic concepts in order to have a better understanding of this work.
2.1. Introduction
Data security is a matter of great urgency considering that data transmission via untrusted networks is needed and more for business activity in today's market.
Predominantly, approaches in the client to server security have been based on encryption technologies, where SSL/TLS encryption is the most widely used. SSL/TLS security was developed to address specifically web-based threats for operations that are run on supportive operating systems. Considering that threats are numerous, and new threats emerge every day, mitigation strategies can be reinforced by identifying taxonomical features that would aid the developing of more versatile mitigation strategies. More significantly, developing an elaborate study of threats based on their patterns provides an avenue to identify, categorize, and describe new threats for purposes of creating their mitigation framework. There has been a significant focus on patterns to understand to design secure systems in a wide range of subjects including software engineering
(Fernandez, 2013). Patterns, provide not only a mechanism for research but also offer a framework for grouping and identifying the common factors that would aid essential functions such as management and control. To add to the recent studies on security threats on several information and communication technologies areas, this study focuses on
6 SSL/TLS-enabled applications which have not received adequate attention to date (Pelaez,
Fernandez, & Larrondo-Petrie, 2007; Fernandez, Monge, & Hashizume, 2015).
This survey reviews related studies to list SSL/TLS threats. To create a basis for this survey, the various areas of possible attacks in a SSL/TLS security system are identified through threat modeling. This involves an overview of the specific areas of dependencies of the system, and a review of the threats associated with these areas
(Uzunov, Fernandez, & Falkner, 2012). We tried to identify existing patterns that relate to the threat models identified earlier.
A background section includes discussion of various topical issues that relate to
TLS'SSL systems, and the development of a taxonomy for the system. The results section includes a detailed exploration of various works to identify the applicable classification model for the study and creating a taxonomy using the model. Specifically, Uzunov and
Fernandez's (2014) model was used because of its relevance and compliance with the foundational principles of classification as described in the STRIDE model. The validity of the taxonomy was explained in a section, followed by a detailed discussion of the entire study about other studies in the same field. Finally, the conclusion section contains a summary of the results and suggestions for further studies.
2.1.1. Background
The main purpose of SSL/TLS is to provide confidentiality for an active connection through encryption, authentication through certificates, and reliability through message integrity checking between two communicating applications using the TCP protocol
(Freier, Karlton, & Kocher, 2011). In 1994, Netscape Inc. introduced the Secure Socket
Layer Protocol (SSL); which was later renamed the Transport Layer Security Protocol
7 (TLS). It has evolved to be the most widely used cryptographic protocol and a security standard for the Internet (Krawczyk, Paterson, & Wee, 2013). One of the main features of the protocol is its flexibility where modes of operation and security goals can easily be configured through different cipher suites (Krawczyk et al., 2013; Meyer, 2014). There are several revisions of the SSL/TLS and the development of these revisions were intended to enhance the security of the previous versions. The latest version is TLS 1.2 (when writing this paper) while the upcoming version, TLS 1.3, is still a draft (Wikipedia, 2015). TLS is used for all kinds of applications that include Virtual Private Networks (VPN), banking transactions, e-commerce transactions, smart phone applications, and other related SSL protocols such as Datagram Transport Layer Security (DTLS) (Fahl, Harbach, Perl, Kotter,
& Smith, 2013; Georgiev, Iyengar, Jana, Anubhai, Boneh, & Shmatikov 2012).
The SSL/TLS protocol is layered between the Application protocol layer and TCP/IP
(Figure 1). The SSL/TLS protocol is divided into two layers; the Handshake Layer and the
Record Layer. The Handshake Layer consists of three sub-protocols (The Handshake
Protocol, ChangeCipherSpec Protocol, and the Alert Protocol). The second layer, the
Record Layer, consists of the Record Protocol (Microsoft, 2003).
The combined four protocol layers of SSL/TLS encapsulate all communication between the client and the server (McKinley, 2003). The Record Layer is a communication protocol layer that accepts a stream of bytes and splits them into blocks processed and handed to TCP (Meyer, 2014). The record layer includes the Alert, ChangeCipherSpec,
Handshake and application protocol messages. This formatting provides a header for each message, and a hash, generated from a Message Authentication Code (MAC) at the end
(McKinley, 2003).
8 The ChangeCipherSpec layer is composed of one message that signals the beginning of secure communications between the client and server. The actual ChangeCipherSpec message is only one byte long, and signals the change in communications protocol by having a value of ‘1’. The Alert protocol layer of the SSL/TLS sends errors, problems or warnings about the connection between the two parties. The handshake layer in the
SSL/TLS protocol contains messages passed back and forth between the client and web application server to establish a handshake that begins a secure connection. The messages that compose this handshake contains: ClientHello, ServerHello, ServerKeyExchange,
ServerHelloDone, ClientKeyExchange, ChangeCipherSpec, Finished, ChangeCipherSpec,
Finished. (McKinley, 2003).
Figure 1: SSL/TLS Protocol
The proper functioning of SSL and TLS is made possible by the other related systems such as the operating system and network connectivity through TCP/IP (which is a critical element for authentication to occur) (Sumner, 2009; Uzunov, Fernandez, and Falkner,
2012). Additionally, the system directory, which also supports the authentication process,
9 and the trusted certificate authorities play an important role in enabling proper TSL/SSL functioning. As such, the quality and reliability of these auxiliary systems are critical to effective SSL/TLS security. Robustness of these features will also determine how well the entire system will withstand security threats (Van Heerden, Irwin, Burke, & Leenen, 2012).
The record and transport layers are single components that are the connecting interfaces between the SSL/TLS protocol and the source. With this layout, a threat to the SSL/TLS occurs along these protocols, and threat modeling will involve evaluation of critical areas of the entire SSL/TLS system. The typical application of SSL/TLS is in client-server networks, where data is sourced from a central server/s and distributed among several clients (Thomas, 2000).
In the SSL/TLS architecture in (Fig 1), there are four major protocols: Handshake,
ChangeCypherSpec, Alert, and Record. Primarily, the handshake protocol manages the authentication processes between the server and client by first allowing the negotiation of the algorithm for encryption and exchanging the subsequent encryption keys (Thomas
2000). The ChangeCypherSpec protocol is specifically concerned with the encryption according to the algorithm determined at the handshake level and it is used change the encryption used by the client and server as part of the handshake process. On the other hand, the Alert protocol gives information about the authentication process such as failure to authenticate, errors incurred in the process, or an alert to end the communication. Once authentication is complete, the record protocol performs the related functions of preparing the data for transmission, including encrypting it, dividing it into manageable blocks for transmission, and applying the message authentication code (Thomas, 2000). The record
10 protocol receives and prepares incoming data by decrypting it, uncompressing; if it is compressed, reassembling data, and verifying the message authentication code.
The SSL/TLS protocol’s message authentication is performed by using “an algorithm that uses cryptographic technology to create a digital summary of information so that if the information is altered, the summary (known as a hash) will also change.” (Thomas, 2000).
The SSL/TLS protocol uses this algorithm to authenticate the connected messages between the client and the server. Some examples used in the SSL/TLS protocol for its hash cryptographic algorithms are:
MD5 algorithms: Commonly used hash function producing a 128-bit hash value. It was initially designed to be used as a cryptographic hash function but found to suffer from extensive vulnerabilities.
The Secure Hash Algorithm: Several cryptographic hash functions published by the
National Institute of Standards and Technology (NIST) as a U.S. Federal Information
Processing Standard (FIPS) which includes (Wikipedia, 2015):
SHA-0: A retronym applied to the original version of the 160-bit hash function published in 1993 under the name "SHA". It had significant flaws that made the NIST withdraw it shortly after publication and replace it by the slightly revised version SHA-1.
SHA-1: A 160-bit hash function like the earlier MD5 algorithm. It was designed by the
National Security Agency (NSA).
SHA-2: These are two similar hash functions that were designed by the NSA. They have different block sizes, known as SHA-256 and SHA-512. They differ in the word size;
SHA-256 uses 32 byte words where SHA-512 uses 64 byte words.
11 SHA-3: Supports the same hash lengths as SHA-2, and its internal structure differs significantly from the rest of the SHA family.
2.1.2. SSL/TLS Protocols
In order to understand the most common threats and vulnerabilities for each version found in the SSL/TLS protocol, we will provide brief details for the development of
SSL/TLS indicating their security problems that we found in the literature (Hickman &
Elgamal, 1995; McKinley, 2001; Meyer, 2014; Microsoft, 2003; Thomas, 2000; Wagner
& Schneier, 1996; Wikipedia, 2015), they cover our subject until the latest available version upon writing this paper (TLS 1.2).
2.1.2.1. SSL 1.0
This version was designed by Netscape Communication Corp. SSL 1.0 had security flaws due to the weaknesses related to authentication and the complete lack for timestamps or sequence numbers to prevent packet replays. It did not make it to the public (Meyer,
2014; Wikipedia, 2015).
2.1.2.2. SSL 2.0
Released in February 1995 (Hickman, 1995; Wikipedia, 2015), SSL 2.0 had several weaknesses related to the handshake phase (Meyer, 2014):
• The MAC does not cover the padding length field.
• Missing handshake authentication.
• Using a weak algorithm during handshake.
This led to the design of SSL 3.0. The Internet Engineering Task Force (IETF) prohibited the use of SSL 2.0 in 2011 (Turner & Polk, 2011).
12 2.1.2.3. SSL 3.0
The vulnerabilities in previous SSL versions were addressed in SSL 3.0 and new features were introduced (Freier, 2011; Meyer, 2014). The handshake in SSL 3.0 contains an additional new protocol (ChangeCiperSpec). SSL 3.0 is backward compatible with SSL
2.0. The IETF prohibited the use of the SSL 3.0 in 2015 (Barnes, Thomson, Pironti, &
Langley, 2015; IETF, 2014) due to:
• The key exchange is vulnerable to man in the middle attacks or session
resumption.
• The SSL 3.0 does not support ClientHello extensions.
• SSL 3.0 defines custom constructions primitives which lack cryptographic
scrutiny. These are Pseudorandom Function (PRF), Hashed Message
Authentication Code (HMAC), and digital signature primitives.
• SSL 3.0 uses weak hash algorithms.
2.1.2.4. TLS 1.0
The development of TLS 1.0 is described in (Dierks & Allen, 1999), and this protocol has also the version number SSL 3.1. TLS 1.0 had some minor changes to the previous version of SSL 3.0. The Internet Engineering Task Force (IETF) made the name change from SSL to TLS for the standardization process (Dierks & Allen, 1999). The major security flaw in TLS 1.0 implementation is the support of a downgrade negotiation process where the client and server can agree on the weaker SSL protocol.
2.1.2.5. TLS 1.1
Like the previous versions, some minor updates were made on TLS 1.0 to prevent attacks and it is described in (Rescorla, 2001). TLS 1.1 prohibits the use of weak cipher
13 suites. The main vulnerability of the TLS 1.1 implementation is using a combination of
MD5 and SHA-1 hash functions which have been proven that they can be broken (Meyer,
2014).
2.1.2.6. TLS 1.2
The TLS 1.2 was defined in (Dierks & Rescorla, 2008). This version prohibits Message
Digest Algorithm (MD5) and Secure Hash Algorithm 1 (SHA-1) and replaces them with a configurable hash function (Meyer, 2014). Backward compatibility was removed to make the TLS 1.2 unable to negotiate with SSL 2.0 (Wikipedia, 2015).
2.1.3. SSL/TLS Implementations
There are several SSL/TLS implementations (Meyer, 2014; Wikipedia, 2015) and we will list some of the most commonly used implementations:
Java Secure Socket Extensions (JSSE)
The Java Secure Socket Extension (JSEE) contains packages that provide secure
Internet communication using Java’s default SSL/TLS implementation (Oracle, 2014).
Network Security Services (NSS)
NSS is a set of libraries designed to secure the communication between the client and server applications. NSS supports SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and other security standards. It is used frequently between the browser and client software (Meyer, 2014;
Mozilla, 2015).
Secure Channel (SChannel)
Developed by Microsoft, the Secure Channel (Schannel) is the implementation of the
SSL/TLS on the Windows Operating Systems. SChannel supports TLS versions 1.0, 1.1 and 1.2 (Microsoft, 2003).
14 OpenSSL
OpenSSL is an open source implementation of SSL/TLS. The main library for
OpenSSL was written in the C programming language. OpenSSL supports SSL 2.0,
SSL3.0, TLS 1.0, TLS 1.1, TLS 1.2 (Meyer, 2014; OpenSSL, 2015).
We found several publications (Bard, 2004; Barnes et al., 2015; Krawczyk et al., 2013;
McKinley, 2003; Meyer, Somorovsky, Weiss, Schwenk, Schinzel, & Tews, 2014; Sarkar
& Fitzgerald, 2013; Wagner & Schneier, 1996; Zhang, 2003) and others that only describe the attacks or the vulnerabilities on the SSL/TLS protocol. We did not find in the literature an analysis that correlates attacks, threats and vulnerabilities. In this paper, we list the most common attacks that we found in the literature and the threats related to the attacks. We also list the vulnerabilities we found and combine all the attacks, the threats and the vulnerabilities in one table in order to define the required defenses.
2.2. Common Vulerabilities and Attacks in the SSL/TLS Protocol
2.3. Vulnerabilities of SSL/TLS
For the past few years, several vulnerabilities have been discovered in the SSL/TLS protocol. We found several vulnerabilities in the literature (Alkazimi & Fernandez, 2014a,
2014b; Bard, 2004; Engle & Khan, 2006; Igure & Williams, 2008; Meyer & Schwenk,
2014; Muñoz-Arteaga, Fernandez, & Caudel, 2011) that list these vulnerabilities. We present in Table 1 an analysis of vulnerabilities in SSL/TLS and offers a brief description of the vulnerabilities. We should note to the reader that the list of the vulnerabilities here is related to the list of the attacks in our paper.
15 Table 1: List of Vulnerabilities in SSL/TLS Protocol
ID Vulnerability Description
Weaknesses in the algorithm responsible for random number Weakness in the SSL/TLS generation such as A weakness in the handling cipher suites in SSL, V01 algorithm for random TLS and DTLS which could lead to plaintext recovery by number generation exploiting timing differences arising during MAC processing.
The connection between client/server can use different Using different key materials temporary key materials during handshake phase (RSA public key V02 during Client/Server or DH public parameters) (Meyer et al., 2014) and the attacker can handshake use this confusion to enforce decrypting the temporary key material that is used during the handshake. - Weakness of RSA to Chosen Cipher Text Attack (CCA) Using weak cryptography where the attacker hides the original Ciphertext, passes it V03 during Client/Server to the decrypted and finally separate the hidden value Handshake. - RC4 has long been known to have a variety of cryptographic weaknesses Weakness in protocol Using protocol version such as SSL 2.0 (Alkazimi & V04 version used in Client/Server Fernandez, 2014a, 2014b) during the Client/Server connection connection Weakness in verifying Destination Server unable to verify the origin of the request V05 message source during the (Muñoz-Arteaga et al., 2011) Client/Server connection Accepting a weaker Cipher Weakness in accepting lower Cipher Suite or Null (Alkazimi V06 Suite & Fernandez, 2014b)
The attacker can predict the quality of the random numbers Predictable Random V07 used for the SSL in the Netscape browser (Goldberg & Wagner, Numbers 1996; Meyer, 2014)
The protocol usage of the weak key exchange algorithm during Using weak algorithm in Key the handshake phase enables the attacker the use of a temporary V08 Exchange key material (RSA public keys or DH public parameters) signed with a long-term key to interrupt the connection.
There are several versions of the SSL/TLS protocol. The attack that were found in the
SSL/TLS protocol led to improvements in the next versions (Wagner & Schneier, 1996).
In Table 2, we present an overview of the attacks found in the literature in SSL/TLS versions with a brief description of the attack with their effect.
16 Table 2: Common Attack in SSL/TLS Protocol
ID Attack Name Attack Description Attack Effect An attacker replaces the • Messages between the cipher suite list with a weaker one to eavesdrop client and the server messages to the receiver A01 Cipher Suite Rollback (Alkazimi & Fernandez, can be read by the 2014a; Alkazimi & Fernandez, 2014b; Meyer, attacker. 2014; Wagner & Schneier, • Denial of Service 1996; Zhang, 2003) • Server will be in The attacker drops the pending stage waiting ChangeCipherSpec message between the client and the for a response from server that causes both parties never activate the the client which gives ChangeCipher Message A02 pending state in order to Drop initiate the client/server more time for the secure communication attacker to initiate (Alkazimi & Fernandez, 2014a; Meyer, 2014; different attacks. Zhang, 2003) • Denial of Service • Weakness in current Attack on RSA cipher Suite by removing the security protocol. original ciphertext, pass it to A03 Bleichenbacher’s Attack the destination to decrypt • Possible downgrade and finally separate the original ciphertext value of the current protocol (Meyer et al., 2014) version. • In the padding oracle attack, the attacker The attacker extracts the private key from a target can decrypt arbitrary server with an observation of the timing differences and cipher text (Brumley sends a special Timing Attacks: ClientKeyExchange & Boneh, 2005; Holz, Padding Oracle A04 - message to receive an Alert attack message inducing an invalid Sheffer, & Saint- - Lucky 13 attack formatted PreMasterSecret Andre, 2015) which (Brumley & Boneh, 2005; Meyer, 2014; Meyer et al., leads to weakening of 2014). the currently used security protocol.
17 • The Lucky 13 Attack uses the same attack mechanism as the padding oracle attack (Sarkar & Fitzgerald, 2013) leading to the same results. • Denial of Service. • MITM attack that Modifying unencrypted forces a victim's protocol that requests the A05 SSL Stripping Attack use of TLS (Bard, 2004; browser into Holz et al., 2015; Meyer, 2014) communicating with plain-text. • Attackers can insert An attack removes the commands into STARTTLS Command unprotected STARTTLS A06 Injection Attack from TLS transmission encrypted SMTP (Holz et al., 2015) sessions. • Attacker can encrypt and obtain access to The attacker decrypts the parts of the packets from the the data passed data passing over the TLS Browser Exploit Against A07 1.0 implementation of between a web server SSL/TLS (BEAST) Attack Cipher Block Chaining (CBC) (Holz et al., 2015; and the client’s web Sarkar & Fitzgerald, 2013) browser accessing the server.
Compression Attacks: • The attacker can - Browser Reconnaissance The attacker exploits the inject partial chosen and Exfiltration compression and encryption via Adaptive combination used to interact A08 plaintext into a Compression of with users and target servers Hypertext (Meyer, 2014; Sarkar & victim’s HTTP (BREACH) Fitzgerald, 2013) Attack requests and measure - Compression Ratio Info-leak 18 Made Easy the size of the (CRIME) Attack - Timing Info-leak encrypted traffic. Made Easy (TIME) Attack
• Attacker recovers parts of session Attack on TLS RC4 Attacks on RC4 when used A09 algorithm (Holz et al., 2015; cookies, passwords in SSL/TLS protocol Meyer, 2014) and credit card numbers. • The attacker impersonates the client by using her credentials to gain access to other servers The attack makes two TLS connections sharing keying accepting those materials which leads to breaking channel binding credentials which may A10 Triple Handshake Attack via TLS Exporter or "tls- unique" (Holz et al., 2015; lead to reading Ristic, 2010; Alkazimi & sensitive Fernandez, 2016a) cryptographic keys, login credentials and private data from other servers.
• The attacker can obtain sensitive data from servers by
Attack on the heartbeat modifying the length A11 Heartbleed feature OpenSSL (Alkazimi & Fernandez, 2016b) of the heartbeat message body between the client and the server.
19 2.4. Relatioship between Attacks, Misuse Threats, Vulnerabilites and their
Countermeasures
We list in Table 3 the relationship between attacks, misuse threats and vulnerabilities in SSL/TLS protocol along with the corresponding countermeasures.
Table 3: Relationship Between Attack and Vulnerabilities in SSL/TLS Protocol and Their
Countermeasures
Attack Vulnerabilities Countermeasures
Logging (replicated logs)
Monitoring (auditing) the connection source A01 V04, V05 User authentication
Storage security
A02 V01, V04, V06 Input source network filtering
User authentication
A03 V02, V03, V04 Input source network filtering
Upgrade security protocol
User authentication A04 V02, V08 Monitoring (auditing) the connection source
Updating security protocol with stronger security algorithms to A05 V01 enforce client/server encrypted connection
Updating security protocol with stronger security algorithms to A06 V01 enforce client/server encrypted connection
User authentication
A07 V03 Input source network filtering
Upgrade security protocol
20 Input source filtering A08 V07 User authentication
Updating security protocol with stronger security algorithms to A09 V01 enforce client/server encrypted connection
V03, V04, V05, Input source network filtering A10 V06 Upgrade security protocol
Monitoring (auditing) the connection source A11 V04, V05 User authentication
Some papers have discussed security issues about TLS/SSL without making any difference between vulnerabilities and attacks. We have focused on this distinction, where we consider important to understand these issues. Enumerating these security issues was not enough that is why we made a relationship between attacks and vulnerabilities so we can identify what vulnerabilities contribute to these attacks and make the TLS/SSL protocol more robust. We provided a descriptive summary of the SSL/TLS protocol and its related implementations along with the construction of a table that indicated the vulnerabilities and attacks we found in the literature. We also constructed a table that showed the relationship between the vulnerabilities and attacks along with their countermeasures to give a better understanding of the SSL/TLS protocol’s weaknesses and their defenses. However, new security countermeasures are needed as well as updating the design of the SSL/TLS protocol due to the discovery of its vulnerabilities. We have expressed four misuse patterns for the SSL/TLS protocol and its implementations
(Alkazimi & Fernandez, 2014a; Alkazimi & Fernandez, 2014b; Alkazimi & Fernandez,
2016a; Alkazimi & Fernandez, 2016b). We intend to complete all the others in the future.
21 2.5. Template of misuse pattern
This section describes each part of the template for misuse patterns used in the next chapters.
2.5.1. Name
The name of the pattern should correspond to the generic name given to the specific type of attack in standard attack repositories such as CERT.
2.5.2. Context
The context describes the generic environment including the conditions under which the attack may occur. This may include minimal defenses present in the system as well as typical vulnerabilities of the system. The context can be specified using a deployment diagram of the relevant portions of the system as well as sequence or collaboration diagrams that show the normal use of the system. A class diagram may show the relevant system structure. We can list specific preconditions for an attack to happen.
2.5.3. Problem
From an attacker’s perspective, the problem is how to find a way to attack the system.
An additional problem occurs whenever a system is protected by some defense mechanisms. The forces indicate what factors may be required in order to accomplish the attack and in what way; for example, which vulnerabilities can be exploited. Also, which factors may obstruct or delay accomplishing the attack.
2.5.4. Solution
This section describes the solution of the hacker’s problem, i.e., how the attack can reach its objectives and the expected results of the attack. UML class diagrams show the involved units of the system under attack. Sequence or collaboration diagrams show the
22 exchange of messages needed to accomplish the attack. State or activity diagrams may add further detail.
2.5.5. Affected system components (Where to look for evidence) (Targets)
This is a new section compared to standard security patterns. The solution should not be a comprehensive representation of all components and relationships involved in an attack. Rather, the solution should represent all components that are involved in the attack, are important to prevent the attacks, or are essential to the forensic examination. This can be represented by a class diagram that is a subset or superset of the class diagram of the context.
2.5.6. Known Uses
Specific incidents where this attack occurred are preferred but for new vulnerabilities, where an attack has not yet occurred, specific contexts where the potential attack may occur are enough.
2.5.7. Consequences
Discusses the benefits and drawbacks of a misuse pattern from the attacker’s viewpoint.
Is the effort and cost of the attack commensurate with the results obtained? This is an evaluation that must be made by the attacker when deciding to perform the attack; the designers should evaluate the risk to their assets using some risk analysis approach. The enumeration includes good and bad aspects and should match the forces.
2.5.8. Countermeasures and Forensics
This section describes the security measures necessary in order to stop, mitigate, or trace this type of attack. This implies an enumeration of which security patterns are effective against this attack. From a forensic viewpoint, it describes what information can
23 be obtained at each stage tracing back the attack and what can be deduced from this data in order to identify this specific attack. Finally, it may indicate what additional information should be collected at the involved units to improve forensic analysis.
2.5.9. Related Patterns
Discusses other misuse patterns with different objectives but performed in a similar way or with similar objectives but performed in a different way.
24 3. MISUSE PATTERN: DENIAL OF SERVICE USING A MESSAGE DROP
ATTACK
The Network Layer uses connection-oriented protocols that provide secure channels between the clients and the servers to protect their interactions. The SSL/TLS is the most common protocol used in the Internet for this purpose. The SSL/TLS Communication protocol is a sub protocol in the SSL/TLS layer (Figure 1). It is divided into two layers:
The first layer is the Handshake layer which contains three sub protocols: Handshake
Protocol, Change Cipher Specification Protocol, and the Alert Protocol. The second layer in the SSL/TLS protocol is the Record Layer which sends secure data from the application using the Transport Layer (Microsoft, 2003). We concentrate here only on an interception attack of the client server authentication procedure which is used to negotiate the session parameters between the client and the server.
In order to design a secure system, we first need to understand possible threats to our system. Several methods have been developed to identify threats, e.g. (Braz, Fernandez, &
VanHilst, 2008). Once identified, we need to describe how these threats are realized to accomplish a misuse according to the goals of the attacker. A misuse pattern describes how a misuse is performed from the point of view of the attacker (Fernandez, 2013). It defines the environment where the attack is performed, countermeasures to stop it, and it provides forensic information in order to trace the attack once it happens. Misuse patterns are useful for developers because once they determine that a possible attack can happen in the environment, a corresponding misuse pattern will indicate what security mechanisms are
25 needed as countermeasures. Also, misuse patterns can be very useful for forensic examiners to determine how an attack is performed, and where they can find useful evidence information after the attack is done. An important value of misuse patterns is that they describe the components of the system where the attack is performed using class diagrams and sequence diagrams, relating the attack to specific system units.
We describe here a misuse pattern for the SSL/TLS security protocol: DoS Misuse
Pattern Using a Message Drop Attack. During the first step of the initial communication between the client and the server, the client sends a “ChangeCipherSpec” message to the server to request a secure channel to establish communicating through it.
This step comes after both parties go through a series of validating messages in order to establish the secure communication (Alkazimi & Fernandez 2014). The server will be in a pending state immediately after receiving the ChangeCipherSpec message from the client (Meyer & Schwenk, 2013). Dropping this message will leave it in this state indefinitely and the communication will never start; i.e., this is a DoS attack.
We assume that the readers are familiar with the POSA template and the network concepts that are used to describe these patterns (Buschmann, Meunier, Rohnert,
Sommerlad, & Stal, 1996). These patterns could be used by network administrators, users, testers, and researchers.
3.1. Misuse Pattern: Denial of Service Using a Message Drop Attack
3.1.1. Intent
The attacker performs a Man in the Middle attack to prevent the client and the server to start a communication. To achieve this goal, the attacker intercepts and drops the client’s
“ChangeCipherSpec” message sent by the client to the server. This message informs both
26 parties to activate the pending state immediately after receiving this notification (Meyer &
Schwenk 2013). This is the final stage in client/server Communication process to establish the secure channel in order to communicate through it. If the attack is successful in dropping this message, the client and the server will never be able to start their communication.
3.1.2. Context
This client/server authentication can be used on some TLS clients and servers that support negotiating the use of Secure Sockets Layer (SSL) version 2.0 (IETF 2011). Also, it can be used on some internet browsers that are set to use the TLS 1.0 or TLS 1.1 by default instead of using the more secure TLS 1.2 which makes them vulnerable to the rollback attack. We assume here that we’re establishing a secure connection between a browser and a server that uses an implementation of TLS 1.0 or TLS 1.1, which were allowed to support the SSL 2.0 negotiation. This problem affects SSL and TLS implementations previous to the 2011 specifications, when the use of SSL 2.0 was prohibited (IETF 2011).
The SSL/TLS security protocol is an Authenticated Key Exchange (AKE) protocol for negotiating cryptographic information and algorithms which authenticate the identities of the parties involved in the key exchange (Meyer & Schwenk 2013, Kumar & Fernandez
2012). Figure 2 shows the class diagram of the components involved in normal communication in the SSL/TLS Server Authentication. This is a basic communication procedure where a certificate is required from the client to the participating server during the connection.
27 The client sends an unprotected ClientHelloMessage that contains a RandomNumber, the CipherSuite, the ClientTLSVersion and the CompressionMethod to the server (Figure
3). When the server receives this message, it responds with a ServerHelloMessage and exchanges the RandomNumber with the CipherSuite. Then it sends the
CompressionMethod and its SSL certificate followed by the ServerDoneMessage. The client replies with a key exchange message for establishing the communication session,
“KeyMaterial” in Figure 2, and begins computing the master secret along with the server.
The ChangeCipherSpec message is then sent by the client to indicate that the future messages will be encrypted and authenticated. Finally, the client sends the DoneMessage which the server will decrypt and verify. The server sends the ChangeCipherSpec and the
DoneMessage to the client, who has the identical decryption and verification functions as the server. Finally, the secure messages between the client and the server start flowing
(Rahm, 2014).
The SSL/TLS communication between the client and server begins by exchanging the
ClientHelloMessage between them. The message has the CipherSuite and a security list that is exchanged between both parties. The server finds the security list and matches the client’s and starts the connection. They connect through highest security level through the
Cipher Suit for the client/server connection that determines the cryptographic primitives.
If the client server want to establish a new state of secure communication, it is necessary for one of the parties to send a ChangeCipherSpec message (Figure 3). The client sends an informative message to the server explaining that the following communication is secured by the previously agreed parameters. The pending state is activated immediately after the
ChangeCipherSpec message is received by the server followed by the DoneMessage. The
28 attacker can delete the client’s ChangeCipherSpec message which makes the server’s pending state inactive and which makes the DoneMessage from the server unavailable
(Meyer & Schwenk, 2013; Zhang, 2003). Intercepting and dropping an email message the client sends through an email server is a good example of this attack.
Figure 2: Class Diagram for SSL Client/Server Communication
3.1.3. Problem
How can we perform the Change Cipher Specification Message Drop attack on the client/server communication protocol in order to delay the server’s pending state and prevent it from sending the finished message to establish the secure communication with the client.
29 The attack can be performed by taking advantage of the following vulnerability:
• The Change Cipher Specification Message is not encrypted and the attacker
can access it, which allows him to destroy or reroute it.
3.1.4. Solution
If the attacker manages to intercept the client’s Change Cipher Specification message, he can delete the Change Cipher Specification message and this defeats the authentication protection between the client/server communications which has the impacts described in
Consequences.
The class diagram in Figure 2 shows the Change Cipher Specification Message Drop attack. The attack is performed on the client/server communication protocol
The sequence diagram in Figure 3 shows the steps to perform a Change Cipher
Specification Message Drop attack. It begins when the client requests to connect with the server by using secure channel provided by the SSL/TLS communication protocol. There are several steps to start the connection negotiation until the client sends the
ChangeCipherSpec message to the server and waits for the response. The attacker here intercepts this message by generating a ChangeCipherSpecMsgDrop attack and he either drops the client’s message or sends his own modified ChangeCipherSpec message to connect with the server. The attacker now can collect the server’s information and modifies the connection to be unencrypted for further future attacks.
The server does not know that the message is coming from the attacker. The server had several checks before getting into the step of receiving the Change Cipher Specification
Message from the client. It does not send a confirmation upon receiving the Change Cipher
Specification Message from the client but instead it sends the DoneMessage to the client
30 immediately after receiving the ChangeCipherSpec from any source. The attack is explained in Figure 4
3.1.5. Known Uses
This attack was used for password interception on an email server while the client was connecting with it. It was performed by Martin Vuagnoux in 2002 by intercepting passwords sent to an IMAP server when checking emails with MS Outlook Express 6.x client using a secure connection (Zhang, 2003). The attack is also used for SSL Spoofing and it is a form of a Man in the Middle attack on SSL in the server/client communication protocol (OWASP, 2014). Another usage of this attack is when the Man in the Middle attack is performed by the attacker when he drops the ChageCipherSpecMessage between the client and the server to force them to not to activate the pending sate to establish secure communication (Wagner & Schneier 1996).
31 Figure 3: Sequence Diagram for Server SSL Communication
32 Figure 4: Change Cipher Specification Message Attack Sequence Diagram
3.1.6. Consequences
If the attack is successful the attacker can do the following:
• The attacker can produce a Denial of Service Misuse preventing
communications between all clients and servers.
33 • If the Change Cipher Specification message is not updated, the message
authentication or the encryption in the record layer for the upcoming
packets will not be enabled to initiate secure communication channel
(Wagner & Schneier, 1996).
• The result of the attack can make the system more vulnerable to several
attacks for the lack of secure connection between the client and the server
that are affected by the DoS misuse.
• The attacker can perform a cache poisoning attack by redirecting the users
that want to communicate to a specific server to a different server. The
attacker could download the server’s Java Script file, modify it (poison it)
and serve it to the client which gives the attacker the ability to access the
client’s sensitive data (iSec Partners, 2012)
Some disadvantages include:
• The attack will not take place if there is an acknowledgement from the server
for receiving the client’s Change Cipher Specification message.
• If the server has a mechanism of keeping track of the client’s source when
requesting the Change Cipher Specification messages, the attacker can be
identified.
• Some of the defenses below can stop the attack.
Affected Components:
When the attack is completed, several components will be affected:
• Change Cipher Specification Message: This message will not be trusted
because it was intercepted and modified by the attacker. This message will
34 contain the server’s information of the trusted communication that can be
modified by the attacker to initiate a DoS misuse.
• Client Credentials: After the attack is initiated and succeeds, the client will be
compromised and his credentials should be revoked.
• Server to Client Secure Connection: When the attack is successful, the server
to client connection is unencrypted which leads to insecure connectivity. The
attacker causes a DoS for all the clients and server communications.
3.1.7. Countermeausre and Forensics
To defend against this attack, we could use the following countermeasures:
• The continuous authentication of the messages; in this case the Change
Cipher Specification Message; for preventing the messages from being
masqueraded (Fernandez, 2013).
• Authorization to prevent reading and modification of the interchanged
messages between the client and the server (Fernandez, 2013).
• Include the Change Cipher Spec in the server’s Done message (Zhang,
2003).
We can find these countermeasures in the following patterns:
• The Authenticator pattern (Brown et al.1999) which describes the procedure
of client server authentication in a distributed setting.
• A Security Pattern for the Transport Layer Security (TLS) Protocol (Kumar &
Fernandez, 2012).
• Authenticate all the messages of the communication protocol (Meyer &
Schwenk 2013).
35 3.1.8. Related Patterns
To defend against this attack, we could use the following countermeasures:
• The continuous authentication of the messages; in this case the Change Cipher
Specification Message; for preventing the messages from being masqueraded
(Fernandez, 2013).
• Authorization to prevent reading and modification of the interchanged
messages between the client and the server (Fernandez, 2013).
• Include the Change Cipher Spec in the server’s Done message (Zhang, 2003).
We can find these countermeasures in the following patterns:
• The Authenticator pattern (Brown et al.1999) which describes the procedure
of client server authentication in a distributed setting.
• A Security Pattern for the Transport Layer Security (TLS) Protocol (Kumar &
Fernandez, 2012).
• Authenticate all the messages of the communication protocol (Meyer &
Schwenk, 2013).
36 4. CIPHER SUITE ROLLBACK: A MISUSE PATTERN FOR THE SSL/TLS
CLIENT/SERVER AUTHENTICATION HANDSHAKE PROTOCOL
The Cipher Suite Rollback describes how this attack is performed from the viewpoint of the attacker. The Cipher Suite is a list of symmetric and asymmetric encryption algorithms that can be used by hosts to establish secure communication. In the attack, the attacker follows a man-in-the-middle approach to intercept the “ClientHello” message, replaces its CipherSuite with a weak or NULL-Cipher, and passes the intercepted message to the server, which will use now a weaker cipher, allowing the attacker to gain access to the exchanged data between the client and the server.
4.1. Intent
In the Cipher Suite Rollback the attacker has the goal of eavesdropping the communication between a client and a server. To achieve this goal, the attacker impersonates the client from the point of view of the server, and the server from the point of view of the client during the initial security negotiation in order to force the communication between them to use weak security or no security at all. Specifically, the attacker intercepts the “ClientHelloMessage”, replaces the CipherSuite with a weak or
NULL-Cipher, and passes the intercepted message to the server. The server accepts the weak CipherSuite from the attacker and thinks that it is establishing a secure connection with the intended client, which lets the attacker eavesdrop on it. The attacker can now gain access to the exchanged data between the client and the server
37 4.2. Context
This client/server authentication handshake can be used on TLS clients and servers that support Secure Sockets Layer (SSL) version 2.0 (IETF 2011). Also, it can be used on
Internet browsers that are set to use the TLS 1.0 or TLS 1.1 by default instead of using the more secure TLS 1.2, which makes them vulnerable to the rollback attack. This problem affects SSL and TLS implementations previous to the 2011 specifications, when the use of
SSL 2.0 was prohibited (IETF, 2011).
The SSL/TLS Handshake protocol is an Authenticated Key Exchange (AKE) protocol for negotiating cryptographic information and algorithms which authenticate the identities of the parties involved in the key exchange (Meyer & Schwenk 2013, Kumar & Fernandez
2012). Figure 6 shows the class diagram of the components involved in normal communication in the SSL/TLS Server Authentication handshake. This is a basic handshake procedure where a certificate is required to be sent by the client to the participating server during the connection. The SSL/TLS Authority Service generates certificates which are assigned to Clients and Servers. Certificates can use Public Keys or
Symmetric Keys.
The client sends first a ClientHelloMessage that contains a RandomNumber, the
CipherSuite, the ClientTLSVersion and the CompressionMethod to the server (Figure 7).
When the server receives this message, it responds with a ServerHelloMessage and exchanges the RandomNumber with the CipherSuite. Then it sends the
CompressionMethod and its SSL certificate followed by the ServerDoneMessage. The client replies with a key exchange message for establishing the communication session,
“KeyMaterial” in Figure 2, and begins computing the master secret along with the server.
38 The ChangeCipherSpec message is then sent by the client to indicate that the future messages will be encrypted and authenticated. Finally, the client sends the DoneMessage which the server will decrypt and verify. The server sends the ChangeCipherSpec and the
DoneMessage to the client, who has the identical decryption and verification functions as the server. Finally the secure messages between the client and the server start flowing
(Rahm, 2014)
4.3. Problem
If the attacker can manage to intercept these messages, he can communicate with the server impersonating the client and get valuable information (such as client’s information, account number, social security number, etc.). The attacker can also attach a malicious code that could be harmful to the server. The initial handshake between the client and the server is not protected and this is the main reason that the client sends the “Change Cipher
Spec” message to the server before finishing the handshake. This message is also not protected. The attacker can modify the exchanged Change Cipher Spec message to stop client and server from updating it and then intercept the connection (Zhang, 2003).
The attack can be performed by taking advantage of the following vulnerabilities:
• The system could be using an outdated security policy for its SSL/TLS which
makes it vulnerable to this and several other attacks.
• The data exchanged between the server and the client for their initial contact
can be read and modified. This step does not check the credentials of source or
destination.
39 • It is possible that the server accepts the attacker’s weak or Null Cipher Suite
list and reply to it in order to establish the Handshake.The resulting damage will
depend on the access the attacker gains from the server authentication.
• The exchanged data might not be encrypted and the exchanged data of the
attacked server might be stolen by using special software (Pelaez et al., 2007).
• There are still a large number of personal computers that are running outdated
versions of the TLS protocols that could use the SSL 2.0 handshake. (Cluley,
2014) indicates that by early 2014 about 27 % of all Windows OSs are XP.
Even if inflated, this figure is significant. These computers are not receiving
security updates, which means that an attacker has plenty of opportunities.
Figure 5: Class Diagram for SSL/TLS Server Handshake
40 Figure 6: Sequence Diagram for Server SSL/TLS Handshake
41 4.4. Solution
The SSL/TLS handshake begins by exchanging the ClientHelloMessage between the client and the server. This message contains the client’s CipherSuite that has a list of cryptographic algorithms. The server receives this list and then a secure connection can begin. They communicate using the common Cipher Suite based on the server’s selection that offers the highest level of security. This procedure can be exposed to several attacks when the message is intercepted. When a Cipher Suite Rollback occurs in this setting, an attacker edits the list of the Cipher Suite in the ClientHelloMessage to force both endpoints to use a weaker form of encryption than they would choose (Zhang, 2003).
The Cipher Suite Rollback attack is performed on the client/server handshake protocol by intercepting the upcoming secure connection. In reference of the class diagram for
Figure 2, the Attacker intercepts the connection between the client and the server by generating a ChangeCipherSpecMsgDrop() to the Client and sending ChangeCipherSpec() message to the server. As mentioned previously, this attack is feasible only in old implementations of the TLS 1.0 or TLS 1.1 that support the SSL 2.0 negotiation.
Supporting SSL 2.0 was prohibited in March 2011, but still today many of these outdated implementations exist.
The sequence diagram of Figure 7 shows the typical steps to perform a Cipher Suite
Rollback misuse. The Client sends a request to initiate a secure connection with the server.
As mentioned earlier, this communication will contain the Cipher Suite message. The attacker intercepts the message with his own CipherSuite-Attacker message and waits for the server’s response. When the attacker establishes the secure connection with the server,
42 he has the ability to collect and modify the exchanged data in the coming connections. The attacker can also redirect the client/server connection.
The server does not know whether the client on the other side of the connection is the actual client or an imposter. Based on the Cipher Suite that the server receives from the client, the server replies back with a ServerCipherSuite to establish the connection with the client as shown in (Figure 7).
Figure 7: Cipher Suite Rollback Attack Sequence Diagram
43 4.5. Known Uses
(Hole, Moen, & Tjostheim, 2006) describe a brute force attack that intercepted the login password in Norway Online Banking System during 2003 and 2004 period. The attack used a large number of botnets that divided large numbers of Social Security Numbers across a network containing zombie PCs. It tried to login in an account by the assigned SSNs. The bank was not able to distinguish between the customer and the zombie PCs trying to log in. Another known issue of this attack is the email interception while connecting to an email server. This attack was performed by Martin Vuagnoux in 2002 by intercepting passwords sent to an IMAP server when checking emails with MS Outlook Express 6.x client using a secure connection (Zhang, 2003; Hole et al., 2006).
4.6. Consequences
The success of this attack results in:
• The attacker can impersonate a valid user, access the server, and view the
client’s information.
• The attacker can modify or read the intercepted messages and perform
transactions as a valid user.
• The attacker can inject a malicious code to the intercepted messages to
bring on further attacks.
• Once the attack is successful, the attacker may get the user credentials and
can use those in attacking other systems.
44 Disadvantages include:
• If the attacker does not know that the server has some logging mechanism
that keeps track of all message requests from the client, he might be
identified.
• The defenses below can stop the attack
Affected Components
When the attack is finished, several components will be affected:
• Cipher Suite Message: This message will not be trusted because it was
intercepted and modified by the attacker. If the server selects a Null
Cipher from the client’s Cipher Suite List, the log should contain a
message indicating the server’s use of the Null Cipher. (Oracle, 2014)
• Client Credentials: After the attack is initiated and succeeds, the client will
be compromised and his credentials should be revoked.
• Server to Client Certificate: When the attack is successful, the server issues
a certificate to the attacker instead of to the client.
4.7. Countermeasures
There are several countermeasures for defending against the Cipher Suite Rollback
Attack:
• Message Authentication to prevent the messages from being modified
(Fernandez, 2013).
• Sender Authentication that insures the non-repudiation of the
messages.(Fernandez, 2013; Schumacher, Fernandez, Hybertson, Buschmann,
& Sommerlad, 2013)
45 • Message integrity that prevents the messages from any modification
(Fernandez, 2013).
• Confidentiality of traffic flow that prevents traffic analysis (Fernandez, 2013).
We can defend against this attack in the following patterns:
• The Authenticator pattern (Brown et al.1999), which describes the procedure
of client server authentication in a distributed setting.
• A Security Pattern for the Transport Layer Security (TLS) Protocol (Kumar &
Fernandez, 2012), which includes authentication in the handshaking.
• Include the Change Cipher Spec in the server’s finished authentication
message for comparing the interchanged Cipher Spec with the original one
sent by the client (Zhang, 2003).
• Authenticate all the messages of the handshake protocol by including a hash
value of all the interchanged messages between the client and the server. This
was done with the release of SSL 3.0. The hash value does not include the
interchanged messages (ChangeCipherSpec is an example) which leaves room
for future attacks (Meyer & Schwenk 2013) such as SSL downgrading or use
of fake SSL certificates.
4.8. Related Patterns
• Misuse Patterns in VoIP: These patterns include call hijacking, theft of
service, and denial of service (DoS) on VoIP (Pelaez et al., 2007). Some of
these misuses could be performed using TLS.
46 • A Security Pattern for the Transport Layer Security (TLS) Protocol: This
pattern presents the security measures of the TLS protocol (Kumar &
Fernandez, 2012).
• An authentication attack to a bank, based on web services, is described in
(Muñoz-Arteaga et al., 2011).
47 5. TRIPLE HANDSHAKE AUTHENTICATION ATTACK
There have been several versions of this protocol which present several vulnerabilities even after several years of continuous development. We present here the Triple Handshake
Authentication attack where an unaware client connects to a server that has already been breached by an attacker. This attacker can then impersonate the new client and use her credentials to gain access to other servers accepting those credentials. This attack may allow the attacker to read sensitive data from other servers.
5.1. Intent
An attacker compromises a server and waits for a new client to connect to it. The attacker can then impersonate the new client by using her credentials to gain access to other servers accepting those credentials. This attack may allow the attacker to read sensitive data from other servers.
5.2. Context
The attack is possible if all these conditions are satisfied (Bhargavan, Delignat-Lavaud,
Fournet, Pironti, & Strub, 2014):
• The RSA key exchange algorithm is used for server authentication and key
exchange .
• The destination server chooses the Diffie-Hellman (DHE) parameters during
the handshake.
48 • The attack involves a Client, a Compromised Application Server (CAS) and
a Target Application Server (TAS), all of which must use the same keys and
session parameters; otherwise their handshakes are not possible
5.3. Problem for the attacker
From the attacker’s perspective, the problem is how to get the victim’s credentials and initiate other connections to several servers which may accept the victim’s credentials. The client’s main reason for this communication is to securely gain access to her personal data
(bank account, email, health records) through the server. The servers’ involvement in this procedure is to authenticate the client and provide access to the resources based on the client’s credentials. In general, the client does not know if a server has been compromised.
The attack can be performed by taking advantage of any of the following TLS vulnerabilities during the client/server handshake:
• Some servers are not well protected and can be easily compromised, e,g., using
XSS attacks (Sulaticky & Fernandez 2016).
• The server session resumption on new connections uses an abbreviated handshake
which only verifies that the client and server share the same master secret (MS),
ciphersuite, and server-issued session ticket (SID) (Bhargavan et al., 2014).
• The use of unsuitable ciphersuites during the TLS handshake (AlFardan &
Bernstein 2013).
• Ignoring a state change during the TLS handshake (Raymond & Stiglic, 2000).
• Using compression during the TLS handshake (Rizzo & Duong, 2012).
49 5.4. Solution
The attack uses an active TLS client connection to a malicious server. The server presents a stolen client’s credential to impersonate her at another server accepting this credential. The attacker performs a variety of man-in-the-middle attack in two successive handshakes between the client and server; he then succeeds in impersonating the client on the third handshake (Bhargavan et al. 2014).
5.4.1. Structure (Affected system components)
The class diagram in (Figure 8) demonstrates the Triple Handshake use of vulnerabilities in a client/server connection. In the figure the Attacker class indicates the possible commands he would use in his interface to perform the attack, it is not an actual system class. The Attacker first compromises the Application Server (as shown above, there are several ways to accomplish this). Now the server become a Compromised
Application Server (AS) and the Attacker waits for a Client to initiate a connection with it to take the Client’s credential and uses the Compromised Application Server (AS) to act as a Client to initiate another connection with a Target Application Server (TS) that accepts the Client credentials.
5.4.2. Dynamics
The following use case describes the sequence of the attack to make the compromised application server connect and get information of the target application server.
UC: Triple Handshake Attack (Figure 9)
Summary: The Attacker takes control of an Application Server and makes it act as a Client to connect to another server in order to get sensitive information from it.
Actor: Attacker
50 Precondition: One of the vulnerabilities of Section 5.3 must be present.
Figure 8: Class Diagram for Use Case “Triple Handshake Attack”
Description:
1. When the Attacker gains access to the Compromised Application Server (CAS), he
injects a script containing malicious code into the server or performs a similar attack
which gives her full control of this server.
2. A Client visits the Compromised Application Server (CAS) to initiate a connection
in order to access an application (this is the first handshake).
3. The Attacker can force the Client and Target Application Server (TAS) through the
Compromised Application Server (CAS) to use the RSA key exchange (and can
51 then decrypt the connection) even if they would normally prefer a different cipher
in the handshake (Aviram et al., 2016).
4. The Attacker waits for the response from the Compromised Application Server
(CAS), Target Application Server (TAS), and the Client to complete their
handshake.
5. The Attacker uses this handshake to make the Compromised Application Server
(CAS) connect with the Target Application Server (TAS) as a Client with a third
handshake.
6. The Target Application Server does not know that the connection is with another
server instead of a connection to a Client due to the Attacker forcing to use the RSA
key exchange in the client/server initial handshake.
7. The Attacker performs some misuse on the Target Application Server once he gets
the credential of the client.
Post-condition: Client’s credentials and Target Application Server (TS) are compromised (see possible benefits for the Attacker in Section 5.7).
52 Figure 9: Sequence Diagram for the use case Triple Handshake Attack
:Compromised Application :Target Application Server Server (CAS) (TAS) Client Attacker
1 attack
Server Compromised [Attacker has Full Access To CAS]
Client Requests Connection to CAS 2 1st Handshake Successful Handshake
Connect to TAS as Client
Connect to TAS as Client 2nd Handshake 3 Initiate RSA key exchange Client 4Connect with RSA key exchange
5 Server Handshake with Client 3rd Handshake Server Handshake with Client Server Handshake with Client 6 Grant Client Connection to TAS
Client Connection 7 Attacker Impersonates
To CAS Client
5.5. Affected system components
• We can audit a compromised Target Application Server (TAS) connection and check in application or connection logs which handshake method was used in the client/server communication for evidence of this attack • We can also check the logs of the CAS to see how the attacker took control of it.
53 5.6. Known uses
The attack was discovered by a group at INRIA, Paris, in 2014 (Bhargavan et al., 2014), and there are no known incidents where this attack was used.
5.7. Consequences for the attack
Some of the benefits of this pattern for the attacker are the following:
• The attacker can perform one of the following misuses: session hijacking, steal
sensitive information such as usernames and passwords, insert poison cookies,
impersonate a web page to gather information later from other clients, or create a
pivoting point for other attacks.
Possible sources of failure for the attacker include:
• The countermeasures below (section 5.8) would cause the attacker to fail 5.8. Countermeasures
The Triple Handshake Attack can be prevented by the following countermeasures:
• Validate all user inputs and reject any connection requests that are not explicitly
allowed on the server and the client (Sulatycki & Fernandez, 2015).
• Use of a Content Security Policy (CSP) is a possibility. This policy instructs the
client browser on the location and type of resources that are allowed to be loaded
(Cobb, 2009).
• Validate all client/server certificates during the TLS handshake and abort the
handshake if they are not valid because of date or revocation (Bhargavan et al.,
2014).
54 5.9. Related patterns
• Denial of Service Message Drop Attack: A Misuse Pattern for the SSL/TLS
Server Authentication Handshake Protocol (Alkazimi & Fernandez 2014a).
Another attack to TLS.
• Change Cipher Specification Message Drop Attack: A Misuse Pattern for the
SSL/TLS Server Authentication Handshake Protocol (Alkazimi & Fernandez
2014b). Another attack to TLS.
• State pattern (Gamma et al., 1994). A server can be in two states: active and
compromised.
• XSS (Sulatycki & Fernandez, 2015) In a Cross-Site Scripting attack attackers
insert scripts in web applications that can make the browser interpreter switch
from a data context to code execution able to perform a misuse in the victim’s
application. This attack can be used to compromise serverses.
55 6. “HEARTBLEED”: A MISUSE PATTERN FOR THE OPENSSL
IMPLEMENTATION OF THE SSL/TLS PROTOCOL
OpenSSL is an open-source cryptographic library for the implementation of SSL/TLS.
The OpenSSL main library was written in the C programming language and has had many released versions. As of 2014, two thirds of all web servers used OpenSSL to secure end- to-end communications (Goodin, 2014). OpenSSL has had several notable vulnerabilities and the Heartbleed vulnerability has had the most serious impact (Durumeric et al., 2014).
Heartbleed is a vulnerability of the heartbeat extension of OpenSSL, where a message is sent to another node that is echoed back to assure the sender that the receiver is working
(Carvalho et al., 2014). A Heartbeat is a well-known reliability mechanism, described by a pattern in (Buckley & Fernandez 2009). This vulnerability results from improper input validation (lack of bounds check) in the implementation of the TLS heartbeat extension
(OpenSSL, Wikipedia). Heartbleed is registered in the Common Vulnerabilities and
Exposures system as CVE-2014-0160 (CVE, 2016). While this extension is an implementation feature of OpenSSL, it is possible that other protocols may use heartbeats in the future, in which case designers should know how to avoid a potential vulnerability.
This possibility makes this attack a pattern as opposed to just an incident.
6.1. Intent
In the Heartbleed attack, the attacker modifies the length of the payload of the heartbeat to receive a much longer amount of information from the server (instead of just a short message). The attacker will be able to read protected memory from web servers running
56 one of the OpenSSL vulnerable versions and thus maybe collect some sensitive information.
6.2. Context
In an OpenSSL secure connection, the person’s device that visits a website sends a
“heartbeat request” message periodically during the lifetime of the connection. The message contains an arbitrary field that defines the payload length “payload_length”. The corresponding “hearbeat_response” message is sent from the destination website on the other end that has the same copy of the “payload_length” to make sure that the connection is still active (Carvalho et al., 2014). Figure 10 shows a class diagram for the basic architecture of OpenSSL secure communication after establishing the connection with the client and the server to set a Secure Channel. The client initiates a Heartbeat Request and sends it to the Server. OpenSSL takes the request through the Secure Channel that was established during the connection then sends back the Heartbeat Response to the Client.
Figure 10: Class diagram for Heartbeat connection in OpenSSL
57 6.3. Problem for the attacker
From the attacker’s perspective, the problem is getting to execute a script in a victim’s browser to modify the payload message between the client and the server which gives the attacker access to possible sensitive confidential information without leaving a trace of the attack.
The attack can be performed by taking advantage of the following vulnerabilities:
• The client’s request can be intercepted and modified.
• Some data in the server’s memory can be read. That means the attacker can get
some sensitive information from the server.
6.4. Solution
As mentioned previously, the OpenSSL library has vulnerabilities that were inherited from previous versions of the SSL/TLS protocols. These vulnerabilities allow the attacker to read the memory content of the server by intercepting and modifying the exchanged heartbeat message between the client and the server. The problem lays in the vulnerability of the “Payload_Length” message that the client sends to the server. This message can be modified by the attacker that sends the “Payload_length” message which leads to controlling the length of data in the “Heartbeat_request” message and the actual parent length, located in the SSL3 record field that was implemented in the OpenSSL library and never checked (Williams, 2014). For example, the attacker sends a four-byte actual parent length of “Heartbeat_request” including a single byte “Payload_length”. The attacker gives a false number in the “Payload_length” field and claim it is 65535 bytes in size. The victim reads the 65535 bytes from its own memory, starting from “Heartbeat_request” payload and copies it into a suitably sized buffer to send back to the attacker in the
58 “hearbeat_response” message (Williams, 2014). he system is using an outdated security policy for OpenSSL which makes it vulnerable to this attack.
6.4.1. Structure (Affected System Components)
Figure 11 shows a class diagram for compromising a server with Heartbleed vulnerability. The Attacker, who impersonates the Client, sends requests to the SSL
Process which links it to the Server to access Services. The SSL Process sets up a Secure
Channel between the Client and the Server.
Figure 11: Class diagram showing the affected units
Client
sendHeartbeat_request
*
OpenSSL Process establishSecureChannel_connection * forwardHeartbeat_request Server Attacker forwardHeartbeat_response forwardRequest sendHeartbeat_request request to sendPayload_Length sendHeartbeat_response 1..* 1 * *
* Service
1
Secure Channel
59 6.4.2. Dynamics
The following use case describes the sequence of the attack.
Use Case: Heartbleed attack (Figure 11)
Summary: The Attacker, who impersonates the client, sends a Heartbeat request with a
“Modified_Payload_Length” that includes a false length in order to get more information from the attacked server. The OpenSSL process receives the input that includes the false length and sends back information located in the server’s memory which may include sensitive information.
Actor: Attacker
Description:
• The Client sends a Heartbeat request including a payload and its length to the
server.
• The Attacker intercepts the Heartbeat message and modifies the Payload Length (to
its maximum value, 64K) and waits for the server’s response. The server does not
know whether the client on the other side of the connection is the actual client or
an impostor and responds sending an amount of information defined by the
Modified Payload Length (long response).
Postcondition:
The attacker may have obtained some sensitive information for the attacker.
60 Figure 12: Sequence diagram for use case to get server information
6.5. Affected system components (Where can we find evidence of this attack?)
This attack does not leave any trace even if we check the attacked server’s log.
6.6. Known Uses
Some potential places where this pattern could have been used are the following:
• Web servers like Apache and NGINX are the most used open source web servers
using OpenSSL.
• Around 66% of HTPS sites were vulnerable (Durumeric et al., 2014; Heartbleed,
2014).
• (Al-Bassam, 2014) completed a vulnerability scan of the Alexa Top 10,000
domains on April 8, 2014 at 16:00 UTC and found 630 vulnerable sites, 3,687
supporting HTTPS but not vulnerable, and 5,683 not supporting HTTPS. The sites
61 include Yahoo, Stack Overflow, Flickr, and some other websites that were found
vulnerable (Durumeric et al., 2014).
Specific incidents include (Wikipedia):
• Security keys were stolen from Community Health Systems in August 2014, the
second-biggest for-profit U.S. hospital chain in the United States, compromising
the confidentiality of 4.5 million patient records
• The Canada Revenue Agency reported a theft of Social Insurance Numbers
belonging to 900 taxpayers, and said that they were accessed through an exploit of
the bug during a 6-hour period on April 8, 2014.
6.7. Consequences
The success of this attack results in:
• The attacker can impersonate a client or even be a legitimate client, access the
server and view sensitive information.
• Once the attack is successful, the attacker may get the user credentials and can use
those in attacking other systems.
Disadvantages include:
• If the attacker does not know that the server is not using a vulnerable OpenSSL
version, he might be identified by using the logging system.
Failure of the attack:
The implementations of OpenSSL from version 1.0.1 until before version1.0.1g do not handle Heartbeat extension packets.
Affected Components:
When the attack is completed, several components will be affected:
62 • Server Certificate: When the attack is successful, the attacker can identify which
certificate the server is using and use this information for future attacks.
• The data retrieved by the attacker may be used to change the configuration of the
server and make it vulnerable to other attacks.
6.8. Countermeasures
There are several possible recommended mitigations:
• Inspect client Heartbeat request and reject it when the response length is longer than
the one in the request.
• Version 1.0.1g of OpenSSL adds some bounds checks to prevent the buffer over-
read (OpenSSL, Wikipedia).
• Regenerate new private keys for the client and the server during the active
connection.
• Revoke old certificates to avoid attackers from using them.
• Message Authentication to prevent the messages from being modified.
• Sender Authentication to insure the non-repudiation of the messages.
• Reject client request to connect through OpenSSL vulnerable versions.
• Consequences of Heartbleed may remain even after the vulnerability was fixed.
The system’s integrity must be carefully checked as well as certificates or keys that
might have been compromised.
(Wheeler, 2014) describes several measures to detect or mitigate the effects of
Heartbleed, including negative testing, using a safer language, and others. He also mentions formal methods to specify and verify the protocol; however, although the basic protocol
63 was formally verified (Diaz et al., 2014) extensions like Heartbeats are added later and require a new versification.
6.9. Related Patterns
• Transport Layer Security (TLS) Protocol: This pattern presents the security
measures of the TLS protocol (Kumar & Fernandez 2012)
• The Authenticator pattern (Brown et al., 1999), which describes the procedure of
client server authentication in a distributed setting.
• This attack is a variety of Man-in-the-Middle attack.
64 7. RELATED WORK
Misuse patterns can be used as a reference to find where to add security measure to mitigate or stop the attacks on the SSL/TLS protocol. Misuse patterns provide forensic information to trace the attack once it happens (Fernandez et al., 2007). They are useful developers because once they determine that a possible attack can happen in the environment, a corresponding misuse pattern will indicate what security mechanisms are needed as countermeasures. Also, misuse patterns can be very useful for forensic examiners to determine how an attack is performed, and where they can find useful evidence information after the attack is done (Fernandez et al., 2007). An important value of misuse patterns is their description of the components of the system where the attack is performed by using class diagrams and sequence diagrams, relating the attack to specific system units.
A survey by (Uzunov & Fernandez, 2013) combines the values of threat libraries and threat taxonomies and proposes a pattern-based threat taxonomy for (general) distributed systems. In their approach, each threat is encapsulated in a new type of pattern called a threat pattern. They relate threat patterns to corresponding misuse patterns, which can detail the attacks realizing a particular threat and educate developers.
Another survey, (Sarkar & Fitzgerald, 2013), describes the vulnerabilities in the
Transport Layer Security protocol and gives an analysis of recent six different attacks on
SSL/TLS related to HTTPS and suggests the countermeasures
65 The third survey, (Zauner, 2014) lists the attacks on TLS without giving the countermeasures. Our survey has the same goals as (Uzunov & Fernandez, 2013; Sarkar &
Fitzgerald, 2013; Zauner, 2014) which provides common attacks that have occurred in the
SSL/TLS protocol, describing them in as misuse patterns and consider countermeasures.
The survey can be used as guidance for network designers or network administrator.
(Zhang, 2003) provides a review of three client/server SSL attacks and their solutions.
These solutions include: change in SSL specification, generate a warning message for specific attack on the server side and intrusion detection that inspects all traffic moving in/out on the server side. This document describes a specific solution either by upgrading the protocol or installing an equipment to detect the attack. However, our goal is to describe what the main components for SSL/TLS attack are and provide detailed description of several solutions of the attack with suggesting related security patterns, not how to implement specific solutions. Our misuse patterns have the same goals as (Zhang, 2003); provide common attacks that have occurred in the SSL/TLS protocol, but we describe them as misuse patterns and consider the countermeasures for network designers and network security administrators
(Bhagravan et al., 2014) explains some TLS versions’ flaws and have the interchanged encrypted messages are the object of attacks. These attacks include message scanning, message modification and message interruption, specifically the triple handshake attack.
In this attack, an unaware TLS client connects to a server that has already been breached by an attacker. The attacker can then impersonate the new client and use her credentials to gain access to other servers accepting those credentials. This attack may allow the attacker to read sensitive data from another server. Our misuse pattern; A Misuse Pattern for
66 Transport Layer Security (TLS): Triple Handshake Authentication Attack; has the same goals as (Bhagravan et al., 2014); provide a description of the attacks that have occurred in the TLS protocol, but we describe it as a misuse pattern and consider countermeasures.
67 8. CONCLUSIONS AND FUTURE WORK
Transport Layer Security (TLS) is a cryptographic protocol that provides a secure channel between a client and a server. The client/server secure connection prevents an attacker from eavesdropping an established connection. The protocol is used in most internet communications for enabling secure web browsing. There have been major vulnerabilities and security issues in TLS previous versions. Theses flaws made attackers either gain access to the data connection, eavesdrop on the insecure connection, or cause damage or loss of data for the connection. We need to understand its security issues so we can make new versions of this protocol (and related protocols) secure. In this work, we have provided the following contributions:
1. We proposed a method of stating the common attacks on SSL/TLS in Chapter 2;
SSL/TLS Threats: Status and Patterns; as well as their misuse patterns. We also
described the relationship between the common attacks, misuse threats and their
vulnerabilities on the SSL/TLS. Finally, we suggested proper countermeasures for
the attacks.
2. We developed a misuse pattern (Alkazimi and Fernandez, 2014b); Denial of
Service Using Message Drop Attack: A Misuse Pattern for the SSL/TLS Server
Authentication Handshake Protocol; where the attacker performs a Man in The
Middle attack to intercept and drop the “ChangeCipherSpec” message which causes
the server to never leave its pending state and the communication will not happen.
Then, we provided class diagrams and sequence diagrams to describe the attack in
68 detail. We finally suggested counter measures showing security patterns to use and
gave some description of the misuse patterns related to the attack We developed
another misuse pattern (Alkazimi and Fernandez, 2014a); Cipher Suite Rollback:
A Misuse Pattern for the SSL/TLS Client/Server Authentication Handshake
Protocol; which is used to negotiate the session parameters between the client and
the server and we introduced a misuse pattern describing this attack. We showed
how it can be stopped by taking the security measures we suggested.
3. (Alkazimi and Fernandez, 2016b) was another misuse pattern we developed; A
Misuse Pattern for Transport Layer Security (TLS): Triple Handshake
Authentication Attack. In this attack, an unaware client connects to a server that
has already been breached by an attacker. We showed in a class diagram how the
attacker can impersonate the new client, and use her credentials to gain access to
other servers accepting those credentials. We followed our class diagram with a
sequence diagram that explains how the attack is performed. We concluded our
misuse pattern with suggested countermeasures to avoid this attack and listed the
related misuse patterns.
4. The final misuse pattern (Alkazimi and Fernandez, 2016a) was a misuse pattern
for OpenSSL; an open source implementation to SSL/TLS protocol. In
“Heartbleed”: A Misuse Pattern for the OpenSSL Implementation of the SSL/TLS
Protocol, we explained in detail this attack which takes an advantage of improper
input validation (lack of bounds check) in the implementation of the TLS heartbeat
extension. This attack allows the attacker to obtain sensitive data from servers by
modifying the length of the heartbeat message body. We analyzed the attack with
69 class diagrams followed by a sequence diagram to give a detailed idea about the
attack. We included several countermeasures to stop the attack.
While we described specific attacks in a specific protocol, our work has a more general value in that:
• TLS is the most important protocol used in browsers that provides
communication security. New versions, new specific implementations, and new
libraries keep appearing and are implemented in the new generations of laptops,
tablets, and smartphones. Some upgraded versions of the TLS have had
repeated flaws that could have been avoided if the designers of these specific
implementations were aware of the previous version’s security flaws that have
been shown as misuse patterns. Implementation vulnerabilities repeat due to the
lack of awareness of the designers, who are usually experts on protocols but
know little about security. Our results are of value for the designers of those
systems to avoid repeating the same errors.
• Although our patterns describe the attacks in a TLS context, they can be
implemented in other communication protocols, e.g. IPSec, Wi-Fi, and
Bluetooth, perform mutual authentication in similar ways. No matter how
secure other communication protocols are, there will always be security flaws
in them as we discovered in the several versions of the TLS protocol that are
always being updated due to the discovery of new security flaws and
vulnerabilities. That means they are susceptible to similar attacks. Our patterns
indicate how to avoid these attacks also in those protocols.
70 • When using existing systems, it is important after an attack to trace how it
happened and collect forensic information. Our patterns through their UML
class diagrams, show where in the system this information can be found, which
allows to collect evidence and suggest how to improve the system. These UML
class diagrams help security and network designers recognize the best practices
to avoid any security flaw in their design. It also allows security or
communication protocol designers understand where exactly the attack starts
and in which phase they should focus for their future design to avoid these
common flaws. This helps more designers of any protocol implementation to
get a broader idea of the attacks their protocols will face.
• Often in practice we need to evaluate existing systems. By analyzing if a misuse
pattern could be successful in a system we can deduce the degree of security of
the system. In fact, we can perform a measure of security in a new or existing
system by testing it using misuse patterns. Since our patterns are only for TLS
we can only analyze this aspect of a complex system but other misuse patterns
can be used to test the rest of the system as it has been done for cloud systems.
This work can be extended by misuse patterns to include the threats identified in
(Alkazimi and Fernandez, 2017). From Table 2 in Chapter 2, we can identify some attacks that can be described as misuse patterns:
• Bleichenbacher’s Attack – describes an attack on the Cipher Suite by removing
the original ciphertext, pass it to the destination to decrypt and finally separate
the original ciphertext value.
71 • Stripping Attack – describes how the attacker can modify an unencrypted
protocol that requests the use of TLS.
• STARTTLS Command Injection Attack – describes how the attack removes the
unprotected STARTTLS from TLS transmission.
• Browser Exploit Against SSL/TLS (BEAST) Attack – describes how the
attacker decrypts parts of the packets from the data passing over TLS 1.0
implementation of Cipher Block Chaining (CBC)
While all these attacks have been studied before, their description using misuse patterns as an original contribution. A good number of security patterns have been produced
(Fernandez, 2013), but we still need to adjust them to be valid for SSL/TLS protocol or to develop more security patterns that are specific for SSL/TLS. Also from Table 1 in Chapter
2, we can identify some vulnerabilities in the SSL/TLS protocol and represent this as security patterns:
• Weakness in the SSL/TLS algorithm – provides the algorithm responsible for
random number generation in SSL/TLS algorithm.
• Using different key materials during Client/Server handshake – reinforces the
security of the client/server handshake to avoid some attacks.
• Using weak cryptography during Client/Server Handshake – using different
temporary key materials during the handshake phase.
Misuse patterns can help network designers, network security officers and network administrator to add and evaluate security. Another use of misuse patterns is to be a reference for security measurements. Misuse patterns can show if the current or future designed networks can handle the corresponding threats. Also, they can be used to support
72 standards and help the network administrators or designers to identify the components of security threats and related common attacks.
Moreover, the SSL/TLS protocol and its implementations is becoming the most popular protocol used to secure the client / server data communication. The TLS protocol and its implementations are the standard protocols for any secure data connection. If protocol designers want to start developing future communication protocols, they have to consider reviewing the misuse patterns before they begin their design. The same concept goes for the network administrators when starting to design their network or reviewing their network security. They have to consider reviewing the misuse patterns before designing the network. We conclude that we have to consider reviewing misuse patterns for our security measurements in any current networks to understand the inherent issues and limitations, and to avoid attacks and valuable data loss.SS.
73 REFERENCES
Al-Bassam, M. (2014). Top Alexa 10,000 Heartbleed Scan. Retrieved from https://github.com/musalbas/heartbleed-masstest/blob/ 94cd9b6426311f0d20539e696496ed3d7bdd2a94/ top1000.txt.
Alfardan, N., Bernstein, D., Paterson, K., Poettering, B., & Schuldt, J. (2013). On the security of RC4 in TLS. 22nd USENIX Security Symposium, 305- 320Noureldien.
Alkazimi, A. & Fernandez, E. B. (2014a). Denial of Service Misuse Pattern Using a Message Drop Attack. In Proceedings of the 10th Latin American Conference on Pattern Languages of Programs (SugarLaof PLoP '14).
Alkazimi, A., & Fernandez, E. B. (2014b). ''Cipher Suite Rollback Attack: A Misuse Pattern for TLS Server Authentication Handshake Protocol”. In Proceedings of the 21st Conference on Pattern Languages of Programs (PLoP 2014), Monticello, IL, September 12-17, 2014.
Alkazimi, A., & Fernandez, E. B. (2016a). “Heartbleed” Attack: A Misuse Pattern for the OpenSSL Protocol”. In Proceedings of the 23rd Conference on Pattern Languages of Programs (PLoP 2014), Monticello, IL, October 24-26, 2016.
Alkazimi, A., &. Fernandez, E. B. (2016b). Misuse Pattern for Transport Layer Security (TLS): Triple Handshake Authentication Attack. In Proceedings of the 11th Latin American Conference on Pattern Languages of Programs (SugarLaof PLoP '16.
Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N., Dankel, M., Steube, J., & Käsper, E. (2016). DROWN: breaking TLS using SSLv2. In 25th USENIX Security Symposium (USENIX Security 16)(Aug. 2016).
Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., & Strub, P. (2014). Triple handshakes and cookie cutters: Breaking and fixing authentication over TLS. Proceedings of the IEEE Symposium on Security and Privacy (98–113). DOI: http://doi.org/10.1109/SP.2014.14.
Braz, F., Fernandez, E.B., & VanHilst, M. (2008). "Eliciting security requirements through misuse activities" Procs. of the 2nd Int. Workshop on Secure Systems Methodologies using Patterns (SPattern'08). In conjunction with the 4th International Conference onTrust, Privacy & Security in Digital Busines(TrustBus'08), Turin, Italy, September 1-5, 2008. 328-333.
74 Brown, F. L., DiVietri, J., De Villegas, G. D., & Fernandez, E. B. (1999). The Authenticator Pattern. In Proceedings of the Conference on Pattern Language of Programs (PloP'99).
Buckley, I., & Fernandez, E.B. (2009). Three patterns for fault tolerance. In Proceedings of the OOPSLA MiniPLoP, Orlando, FL October 26, 2009.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., & Stal, M. (1996). Pattern- Oriented Software Architecture: A System of Patterns, Volume 1, Wiley, Chichester, New York, N.Y.
Carvalho, M., Demott, J., Ford, R., & Wheeler, D. (2014). Heartbleed 101. IEEE Security and Privacy, vol. 12, no. 4, pp. 63–67. DOI:http://doi.org/10.1109/MSP.2014.66.
Cluley, J. (2014) “With just days to go, just how many PCs are still running Windows XP”. Retrieved from http://www.welivesecurity.com/2014/04/02/with-just-days- to-go-just-how-many-pcs-are-still-running-windows-xp.
Cobb M. (2009). Cross-site scripting explained: How to prevent XSS attacks. Retrieved June 12, 2016 from http://www.computerweekly.com/tip/Cross-site-scripting- explained-How-to-prevent-XSS-attack.
CVE, CVE-2014-0160. (2016) Retrieved http://CVE Mitre.org.
Díaz, G., Cuartero, F., Valero, V., & Pelayo, F. (2004). Automatic verification of the TLS handshake protocol. In Proceedings of the 2004 ACM symposium on Applied computing (pp. 789-794). ACM.
Dierks, T., & Allen, C. (1999). The TLS Protocol, Version 1.0. Internet Engineering Task Force. RFC 2246.
Dierks, T. & Rescorla, E. (2008). RFC 5246 - The transport layer security (TLS) protocol - Version 1.2. In Network Working Group, IETF, 1–105.
Durumeric, Z., Kasten, J., Adrian, D., Halderman, J. A., Bailey, M., Li, F., ... & Paxson, V. (2014). The matter of heartbleed. In Proceedings of the 2014 Conference on Internet Measurement Conference (pp. 475-488). ACM.
Fahl, S., Harbach, M., Perl, H., Koetter, M., & Smith, M. (2013). Rethinking SSL development in an appified world. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security (pp. 49-60). ACM.
Fernandez, E.B. (2013). Security patterns in practice - Designing secure architectures using software patterns. Wiley Series on Software Design Patterns. John Wiley & Sons.
75 Fernandez, E. B., Pelaez, J., & Larrondo-Petrie, M. (2007). Attack patterns: A new forensic and design tool, Procs. of the Third Annual IFIP WG 11.9 Int. Conf. on DigitalForensics, Orlando, FL, Jan. 29-31, 2007. www.cis.utulsa.edu/ifip119. Chapter 24 in Advances in Digital Forensics III, P. Craiger and S. Shenoi (Eds.), Springer/IFIP, 2007, 345-357.
Fernandez, E. B., Monge, R., & Hashizume, K. (2015). Building a security reference architecture for cloud systems. Requirements Engineering, 21(2), 225-249. DOI:http://dx.doi.org/10.1007/s00766-014-0218-7.
Freier, A., Karlton, P., & Kocher, P. (2011). The secure sockets layer (SSL) protocol version 3.0.
Gamma, E., Helm, R., Johnson, R. & Vlissides, V. 1994 Design patterns –Element of reusable object-oriented software, Addison-Wesley 1994.
Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D., & Shmatikov, V. (2012, October). The most dangerous code in the world: validating SSL certificates in non-browser software. In Proceedings of the 2012 ACM conference on Computer and communications security (pp. 38-49). ACM.
Goodin, D. (2014). Critical crypto bug in OpenSSL opens two-thirds of the Web to eavesdropping. Retrieved from http://arstechnica.com/security/2014/04/critical- crypto-bug-in-openssl-opens-two-thirds-of-the-web-to-eavesdropping/.
Heartbleed. (2014). Heartbleed Bug. Retrieved from http://heartbleed.com/.
Hickman, K., & Elgamal, T. (1995). The SSL protocol. Netscape communications corp.
Hole, K. J., Moen, V., & Tjostheim, T. (2006). Case study: Online banking security. IEEE Security & Privacy, 4(2), 14-20. iSec Partners. (2012) An attack on SSL Certificate. Retrieved from https://isecpartners.com/blog/2012/december/an-attack-on-ssl-client- certificates.aspx.
Kumar, A., and Fernandez, E.B. (2012). A Security Pattern for the Transport Layer Security (TLS) Protocol. Procs. 19th. Int. Conference on Pattern Languages of Programs (PLoP2012).
McKinley, H. L. (2003). SSl and TLS: A beginner’s guide. SANS Institute.
Meyer, C. (2014). 20 Years of SSL/TLS Research An Analysis of the Internet’s Security Foundation. (Doctoral dissertation). Retrieved from http://www-brs.ub.ruhr-uni- bochum.de/netahtml/HSS/Diss/MeyerChristopher/diss.pdf.
76 Meyer, C., Somorovsky, J., Weiss, E., Schwenk, J., Schinzel, S., & Tews, E. (2014, August). Revisiting SSL/TLS Implementations: New Bleichenbacher Side Channels and Attacks. In USENIX Security (Vol. 14, pp. 733-748).
Microsoft Corporation. (2003). Overview of SSL/TLS Encryption. Retrieved from http://technet.microsoft.com/en-us/library/cc781476(v=ws.10).aspx.
Muñoz-Arteaga, J., Fernandez, E.B., & Caudel, H. (2011). Misuse Pattern: Spoofing Web Services. In Proceedings of the Asian Pattern Languages of Programs Conference.
OpenSSL. (2015). OpenSSL: Cryptography and SSL/TLS toolkit. Retrieved from https://www.openssl.org/.
Open Web Application Security Project (OWASP). (2014). SSL Spoofing. https://www.owasp.org/images/7/7a/SSL_Spoofing.pdf.
Oracle Corporation. (2014). An Important Note Regarding Null Cipher Use in SSL. http://docs.oracle.com/cd/E14571_01/web.1111/e13705/practices.htm.
Pelaez, J. C., Fernandez, E.B., & Larrondo-Petrie, M.M. (2007). Attack patterns in VoIP", Procs. of the 14th Pattern Languages of Programs Conference (PLoP2007).
Rahm, J. (2010). SSL Profiles: Part 1. Retrieved from https://devcentral.f5.com/articles/ssl-profiles-part-1#.U36xji8WdhX.
Rescorla, E. (2001) SSL and TLS: Designing and building secure systems, Addison- Wesley.
Raymond, J., & Stiglic, A. (2000). Security issues in the Diffie-Hellman key agreement protocol. IEEE Transactions on Information Theory, 22, 1-17.
Rizzo J., & Duong T. (2012). "The CRIME attack", ekoparty security conference. Retrieved from https://www.youtube.com/watch?v=BysvLotMrwY.
Sarkar, P. G., & Fitzgerald, S. (2013). Attacks on ssl a comprehensive study of beast, crime, time, breach, lucky 13 & rc4 biases. iSEC Partners.
Schumacher, M., Fernandez, E.B., Hybertson, D., Buschmann, F., & Sommerlad, P. (2013). Security Patterns: Integrating security and systems engineering. John Wiley & Sons.
Sulatycki, R, & Fernandez, E.B. (2015). A threat pattern for the “Cross-Site Scripting (XSS)” attack. In Proceedings of the 22nd Conference on Pattern Languages of Programs 2015 (PLoP 2015), Pittsburgh, PA, October 24-26, 2015.
77 Sumner, M. (2009). Information Security Threats: A Comparative Analysis of Impact, Probability, and Preparedness. Information Systems Management, 26(1), 2-12. DOI:http://dx.doi.org/10.1080/10580530802384639.
The Internet Engineering Task Force (IETF). (2014). Prohibiting Secure Sockets Layer (SSL) Version 2.0. Retrieved from http://tools.ietf.org/html/rfc6176 Thomas, S. 2000. SSL & TLS essentials. New York: Wiley.
Uzunov, A., & Fernandez, E. B. (2014). An extensible pattern-based library and taxonomy of security threats for distributed systems. Computer Standards & Interfaces, 36(4), 734-747. DOIhttp://dx.doi.org/10.1016/j.csi.2013.12.008.
Uzunov, A., & Fernandez, E. B. & Falkner, K. (2012). Securing distributed systems using patterns: A survey. Computers & Security, 31(5), 681- 703. DOI:http://dx.doi.org/10.1016/j.cose.2012.04.005.
Van Heerden, R., Irwin, B., Burke, I., & Leenen, L. (2012). A Computer Network Attack Taxonomy and Ontology. International Journal of Cyber. Warfare and Terrorism, 2(3), 12-25. http://dx.doi.org/10.4018/ijcwt.2012070102.
Wagner, D., & Schneier, B. (1996). Analysis of the SSL 3.0 protocol. In The Second USENIX Workshop on Electronic Commerce Proceedings (Vol. 1, No. 1, pp. 29- 40).
Wheeler, D. (2014). Preventing Heartbleed, Computer, vol. 47, no. 8, pp. 80-83, August 2014, IEEE. DOI: 10.1109/MC.2014.217.
Wikipedia. (2015). Transport Layer Security. Retrieved from https://en.wikipedia.org/wiki/Transport_Layer_Security.
Wikipedia. (2016). Heartbleed. Retrieved from https://en.wikipedia.org/wiki/Heartbleed.
Williams, C. (2014). Anatomy of OpenSSL’s Heartbleed: Just four bytes trigger horror bug. Retrieved from http://www.theregister.co.uk/2014/04/09/heartbleed_explained/.
Zhang, H.L. (2003). Three attacks in SSL protocol and their solutions. Retrieved from https://www.cs.auckland.ac.nz/courses/compsci725s2c/archive/termpapers/725zhan g.pdf.
78