INSE Lucky 13 attack - continued from previous lecture. Scribe Notes for Lecture 3 by Prof. Jeremy Clark (January 20th, 2014)

Transcription

1 INSE 6150 Scribe Notes for Lecture 3 by Prof. Jeremy Clark (January 20th, 2014) Lucky 13 attack - continued from previous lecture The lucky 13 attack on SSL/TLS involves an active attacker who intercepts encrypted SSL packets, modifies them on the fly and observes the response from the recipient to help determine the contents of the encrypted payload. The attack became possible due to the following characteristics of SSL/TLS and the Cipher-block Chaining (CBC) mode of operation in many SSL/TLS implementations. At the end of an encrypted block there is always at least 1 byte of padding. If the data size is a multiple of the block size such that the data boundary falls onto the end of a block, an entire block filled with padding is appended. The padding at the end of an encrypted block is not protected by the MAC, i.e. the padding is added to fill the block after the MAC of the plaintext has been calculated. Flipping a bit in a block of plaintext will cause the entire contents of that block to be garbled upon decryption by the recipient, but due to the way CBC works it will only affect a single bit in the next block, i.e. when an attacker flips a single bit in an encrypted block the recipient will be able to recover the entire the payload for the next block with just one bit flipped. The contents of the padding bytes depend only on the total length of the padding. For a total padding length of 1 byte, a single padding byte consisting of 00 (hexadecimal) is used. For 2 bytes of padding, two 01 bytes are used. For 3 bytes of padding, three 02 bytes are used, etc. If an invalid combination of bytes is encountered at the end of the last block (e.g. only a single 01 byte or two 02 bytes) then a padding error is raised. If the padding in a block is valid and the data portion is modified instead, the padding check by the receiver of the packet will succeed but the integrity check will fail. In this case, a different error (MAC failure) will be raised instead. The attacker can monitor the response from the receiver of the packet and see the type of the error that was triggered by his modification of the payload. Example Consider the two blocks depictured in figure 1 that are part of an encrypted SSL/TLS payload. A,B, C and D denote bytes in the first block that an attacker may XOR to the last bytes of the first ciphertext block. The attacker can then determine the value of the last non-padding byte in the block through the following steps: 1

2 1. The attacker flips all bits in C 15 (and resends the original recipient in order to monitor the resulting error) until he observes a MAC error rather than a padding error for the next block which can only happen if the value of M 31 is 00 indicating that 1 byte of padding is used. 2. Knowing the value of A that results in a 00 value for M 31 the attacker can calculate the original value of M 31. In this case, the value of M 31 is 02 and from this the attacker already knows that 3 bytes of padding are used and that the last non-padding byte in that block is the 13th byte of that block (C 28 ). 3. Knowing that M 31, M 30 and M 29 are all 02 the attacker sets A, B and C to 01 (hex) as this will change the 02 value to 03. The goal is to find the value of byte? (M 28 ) which is the last non-padding byte in the block. 4. The attacker proceeds by trying all possible values for D (from 00 to FF) until the processing of the next block results in a MAC error (which confirms that the padding was correct). A MAC error confirms that the value of C 28 after manipulating the bits must be 03 as well in order to satisfy the padding requirements, otherwise the recipient would have sent out a padding error instead. In this example, setting D to A2 results in a value of 03 for the? byte (M 28 ), thus the attacker can solve the following equation in order to find out the value of the? byte: A2? = 03 =? = 03 A2 =? = A1 (1) 5. Once the attacker has found out the value of the? byte he can repeat the process to find out the contents of M 27 by setting A, B, C and D such that the last 4 bytes in the block are all 04 and then try XOR ing all possible bit combinations to C 11 until he finds the one that results in good padding. The attacker can continue in this manner and tackle each byte one by one until all bytes have been recovered. Figure 1: Illustration of Lucky 13 attack 2

3 Methodology #1: Attack Trees Attack trees are a simple open methodology for determining whether something is secure or not. The more open the methodology is, the more types of attacks it can detect but is also less likely to catch all attacks. Attack trees can capture a large breadth of attacks of different types. With attack trees the root of the tree is the goal that the tree is trying to achieve. Generating an attack tree involves two steps: 1. Create root node consisting of the goal as well as the objectives/reasons why someone might want to achieve that goal. 2. Starting with the root, generate the remaining branches of the tree where each branch represents a category of attacks to accomplish the stated goal. At the higher levels the subtrees correspond to very broad categories of attacks and become much more detailed at lower levels. Once an attack tree has been captured, it can be used to help determine how to prevent these attacks. Attack trees are very error-prone as it is easy to miss a possible attack. Example: Attack Tree for observing HTTPS traffic In this section we will provide an example of an attack tree observing HTTPS traffic. The first step is to create the root node with the stated goal along with the reasons one might pursue this goal. The outcome of this step is shown in figure 2. Note that attack trees are not unique as there are typically many ways to break down the different attacks that can be used to achieve that goal. Figure 3 shows the attack tree as generated interactively in class. Figure 2: Root node of attack tree for observing HTTPS traffic 3

4 Notes on attacks included in the attack tree Figure 3: Example: attack tree for observing HTTPS traffic weak keys: Due to previous export laws that prohibited export of crypto with key lengths greater than 40 bits many certificates with 40-bit keys were being used which could be broken 4

5 through brute force using an attacker with sufficient computing power (such as government agencies). Man-in-the-middle: In order for an adversary to act as a man-in-the-middle for an HTTPS connection the SSL tunnel would have to end at the adversary (e.g. through a forced certificate) and another SSL tunnel to the web site would have to be established, i.e. the attacker would have to split the SSL tunnel. Bad RNG: Earlier versions of Netscape and some commercial crypto implementations by RSA contained predictable random number generators that could be used to lower or bypass the security. throw error: The man-in-the-middle may simply throw an error to the client and often times the user will simply click through the error and proceed anyway. implementation (client): If an adversary has access to the client machine he can install malware/key loggers etc or mess with the client s crypto (e.g. through bad RNG). Legal: Web sites may be compelled by law enforcement to decrypt SSL traffic. Similarly, CAs may be compelled by law to issue a so-called compelled certificate that can be used to impersonate a web site and intercept traffic. TLS Terminator: SSL tunnels may not always end at individual machines. Within large companies such as Google part of the SSL traffic within the internal network may actually be routed over HTTP (unencrypted) where the data is no longer protected und vulnerable to sniffing/snooping. The reason for not using SSL everywhere within an internal network is partly due to cost of decryption. Methodology #2: Evaluation Framework Evolution frameworks are an open methodology used for comparing competing technologies that aim to achieve the same goal but have different strengths/weaknesses in different areas of interest. Example: Evaluation Framework for comparing password alternatives in the context of web sites Here we discuss a specific example of an evaluation framework that compares passwords to a number of password alternatives that may be used when authenticating to a web site. This example is based on the paper The Quest to Replace Passwords by Bonneau et al., available online at Please refer to that paper for detailed explanations and reasonings for some of the ratings. In this evaluation framework, standard passwords are compared to 6 commonly used alternatives (Firefox password manager, Facebook Connect, graphical passwords, RSA SecurID, Google 2 Step and fingerprints). While passwords are most commonly used to authenticate on web sites 5

6 they do have a number of drawbacks. For example, it might take a long time to type in a complex password correctly, the process could be error-prone or the password could be vulnerable to different types of attacks (such as online/offline guessing attacks). Different alternatives to common passwords aim to address some of the shortcomings of password schemes but may introduce problems themselves. Table 1 shows the complete results of the comparison of passwords and password alternatives based on the study of the authors. The following is a brief description of the different schemes that are being compared: Password: Standard password scheme used on most web sites Firefox (password manager): Built-in password manager in Firefox that stores the passwords locally and fills them in upon visiting the site, excluding any synchronization features that have been added in more recent versions of the browser Facebook Connect: Ability to login to a web site via Facebook. This is an example of a federated identity, other examples include logins through Google and Twitter. Graphical passwords: Visual alternative to a password, typically involving a number of swipes in a particular manner and order. RSA SecurID: Hardware token for providing 2-factor authentication, very common in the corporate world. It gets full score for resilience against both throttled and unthrottled attacks due to the use of two factors. Google 2-step: Dual factor authentication from Google where a standard password is supplemented by a 6-digit code sent to a mobile device. It gets full score for resilience against both throttled and unthrottled attacks due to the use of two factors. Fingerprints: Fingerprint-based authentication involving a scanner at home that the user would use for authentication with the web site. Other biometrics-based authentication schemes such as iris scans generally have similar patterns overall, but are not considered in this particular example. A B C D E F G H I J Passwords Firefox (password manager) Facebook Connect Graphical Passwords RSA SecurID Google 2 Step Fingerprints Table 1: Evaluation framwork for comparing passwords and password alternatives using different criteria The metrics that were used for the comparison (referred to as letters A through J in table 1) are listed in table 2. The properties are taken from different categories (usability, deployability, security, sometimes referred to as the UDS framework). 6

7 A solid circle in the table indicates that the authentication scheme satisfies the criterion almost 100%. A half circle ( ) indicates that the authentication scheme satisfies the requirement partially whereas a empty space indicates that the scheme does not satisfy that requirement at all. Letter Description Category A physically effortless usability B memory-wise effortless usability C Nothing to carry usability D Negligible cost per user deployability E server compatible deployability F infrequent errors usability G Resilient-to-phishing security H No trusted third party security I Resilient-to-throttled-guessing (online attacks) security J Resilient-to-unthrottled-guessing (offline attacks) security Table 2: Properties used to evaluate passwords and password alternatives Notes regarding ratings All items that require the purchase of some hardware (e.g. phone, hardware token, fingerprint scanner) have cost associated with them and therefore do not get full score for the negligible cost per user property. All schemes other than password and Firefox get a 0 value for the server compatible property as there is some cost associated with changing the server to use a different authentication scheme. Firefox, Facebook Connect: These schemes are awaded the maximum score for the infrequent errors category since in both cases the user only needs to enter one password correctly in order to be able to access a large number of web sites. RSA SecurID: The reason for giving a 0 for no trusted third party is that currently Google is the only verifier. Google 2 Step: The reason for giving a 0 for no trusted third party is that currently Google is the only verifier. Fingerprints: This scheme is susceptible to phishing attacks as an attacker running a phishing site may capture the fingerprint data and subsequently use it to imperonate the user and login to other sites. What is the best solution? Quote: There are no solutions, only trade-offs (Thomas Sowell). There is no solution that is perfect and better than all others in all categories. The goal of an evolution framework is to lay out the trade-offs to help decide which technology works well in a particular situation, taking into accounts the relevant requirements for the properties. 7