Protocol state machine fuzzing of TLS Implementations
This article was published in the Usenix Security 2018 , Author: Shankara Pailoor, Andrew Aday, Suman Jana. The three authors are from Columbia University.
This article was published in the USENIX Security 2015, the author is Joeri de Ruite and Erik Poll from the University of Ladebaode from the University of Birmingham. They research in recent years, mostly secure communication protocol analysis, especially using an automatic machine to analyze the agreement.
1. The main contents
For the analysis of the existing TLS protocols include: safety analysis of the top-level design of the protocol, not a specific protocol, but most of the security problems in the concrete implementation of the agreement; the specific implementation of the TLS protocol (such as OpenSSL) of fuzzing mainly in safety analysis of a single message (e.g. fuzzing certificate); in addition to the protocol configuration information is performed analytical tools (e.g. sslmap). OF automaton that good performance can be sending and receiving messages specific implementation processes TLS protocol, it is to construct 9 different TLS protocol state machine implemented by an automatic machine learning techniques. Generated by manual analysis logic state machine to find vulnerabilities in the specific implementation, which is then analyzed to find the corresponding source bug. Through this simple and rapid method, the authors found a different realization 3 TLS vulnerabilities (GnuTLS, Java Secure Socket Extension and OpenSSL).
2. TLS protocol brief review
TLS is Transport Layer Security. Which the handshake process is as follows: First, the client sends a ClientHello message (including the client random number), the server then returns the message 3, namely: ServerHello (containing the server random number), Certificate (server certificate, comprising a public key server) , ServerHelloDone. The client then receives the message, generate a pre-master key and a master key based on the client random number and a server random number, and sending a message to the server 3, namely: ClientKeyExchange (server contains the public key encryption using a pre-master key), ChangeCipherSpec (next message indicates that the client sends the encrypted), Finished (first encrypted message sent by the client). After the server receives the message 3, the two sides share the same pre-master key, and calculates the master key. The server returns a message 2, namely: ChangeCipherSpec (server message indicates that the next transmitted encrypted), Finished (first encrypted message sent by the server). So far, Finished parties received a message docking decrypt, if the match is successful, the negotiation is successful, otherwise fail. The next communication will be both the master key generation using a key for encryption. Handshaking procedure as shown in FIG.
3. Automatic machine learning background
To understand the state-machine-learning papers mentioned here first introduce the background knowledge [1]. Finite determine the state machine M (FSM) may be a six-tuple denoted M = (S, s_0, δ, λ, X, Y), where S represents the set of all states, S0 is the initial state, X is the input dictionary, Y is output dictionary:
- Delta (δ) is a function of the state transition function, s_j = δ (s_j, x) represents the state from s_i, the state shifts to the input x s_j, x∈X
- Lambda (λ) is a function of the output function, y = λ (s_i, x) represents the state from s_i, in response to the input x and y obtained, y∈Y
- A complete state transition can be represented as a triple: (s_i, s_j, x / y)
How to distinguish between different state? Suppose there are two states and s_i s_j, if there is an input sequence ∃x∈X ^ *, so that λ (s_i, x) ≠ λ (s_j, x), then the two states are not equal. Then two states are equal in turn is determined that all the input sequence, the output sequence they return are equal (ideally be exhaustive of all possible input sequences).
One scene automatic machine learning for black-box systems, and how we can enter only through observing the response back to the goal of building a black box system of state machines? There are several existing algorithms can construct a black box system state machine, described below Angluin's L * algorithm to construct an automatic coffee machine.
Briefly workflow coffee machine is: First have a clean coffee machine, you need to add beans (pod) adding water (water), and finally press the start button (button), then the last coffee machine able to produce coffee (coffee ), if the start button is pressed prior to the addition of water and good coffee beans, coffee opportunities alarm (error), correct operation will return the correct signal (check mark). FIG coffee at the correct state transition diagram, the input dictionary is X = {water, pod, button , clean}, Y = {output dictionary is a correct signal (the check mark), Coffee (coffee flag), error (star)} .
The question now is to assume that the state machine is unknown, how we use input / output to build a proper state machine diagram? Angluin's L * algorithm observation sheet (Observation Table) to progressively build a complete state machine:
-
首先有一个初始状态s0（属于集合Sp），我们输入长度为1的输入序列，并且产生了4个输出响应。那么这4个输入/输出对（对应观察表中的每一行）能够唯一确定初始状态S0。相应地由s0产生4个不确定的状态s1，s2，s3，s4（对应表中的Lp）。我们再次从这4个不确定的状态出发输入长度为1的输入序列，得到它们的输入/输出对。发现有3个状态（s1，s2，s4）的输入/输出对和已有的初始状态s0相同，那么我们现在猜想这3个不确定的状态和s0相同而进行合并。而s3将作为新发现的状态添加到集合Sp中。在这一过程中，通过输入来获得输出的过程是membership queries。现在输入button而到达的状态是新状态，那么我们再次从这个新状态出发输入长度为1的输入序列，观察这个状态所到达的不确定状态是否与已知状态相同。发现由buttton出发的所有状态都和button状态相同，那么本次迭代结束。我们产生了一个闭合的观察表（闭合是指已知的Sp状态的每一行都是独特的，并且由已知状态产生的不确定状态Lp的每一行都能在Sp行中找到），那么Sp集合中表示已找到的不同的状态，我们生成了一个hypothesis，即假设的状态机。
图3 不确定状态s1，s2，s4可以与状态s0合并
图4 第一轮迭代利用观察表生成两个状态的hypothesis 既然我们找到了一个假设的状态机，那么我们需要验证这个状态机是否和实际的状态机相等。验证的过程称为等价查询（equivalence queries），这个过程需要找到一个输入序列c，使得λ_H (s_0,c)≠mq(c),c∈X^*，这个输入序列被称为反例（counterexample）。咖啡机的情况是，等价查询返回一个输入序列c={pod, water, button}，这个输入序列在上步获得的状态机中返回的是一个错误报警消息，但是实际查询却返回了咖啡成功消息。说明上一步中获得的hypothesis状态机与实际状态机不符。我们在找到反例后提取出其中的最小输入后缀water button，并且加入观察表的列中。
-
由反例更新观察表，再次迭代，迭代过程如步骤一。到这里，我们获得了第二张闭合的观察表，可以看到Lp中包含了由Sp引申出的不确定状态，它们的行都能在Sp中找到相同的行。经过相同行的合并，形成了Sp中6种独特的状态。在这次迭代中，我们更新了状态机hypothesis。
图5 第二轮迭代中的闭合观察表和生成的状态机hypothesis 由第二个hypothesis我们再次进行等价查询，并且获得反例（counterexample），提取反例中的最小输入后缀插入观察表中。在第三轮迭代后我们可以获得最终的状态机。如果等价查询找不到反例，即对所有的输入序列（实际上要设置一个最大查询上限），假设的状态机返回的输出与实际的查询相同，说明我们假设的状态机已经符合实际的状态机，迭代便终止。
4. 系统设计与实现
4.1 整体设计
论文工作采用LearnLib框架来进行TLS自动机学习。LearnLib框架集成了各种自动机学习算法，本文工作采用的是前面介绍的Angluin’s L* 算法。SUT（System Under Test）表示需要进行自动机构建的黑盒系统，论文分别对TLS通信的客户端和服务器进行状态机学习。输入字典根据学习的目标有所调整，如果目标是服务器，那么输入字典包含了TLS握手过程中客户端发送的消息类型，输出字典是服务器返回的消息类型。Test harness负责产生具体的消息，它能够将抽象的消息类型转化成具体的消息并且发送给SUT，同时也能够接收SUT返回的消息响应，并且转换成抽象的消息类型。LearnLib能够利用L*算法对SUT进行membership queries，并且生成观察表，进而获得假设的状态机hypothesis。为了验证hypothesis的正确性，需要进行等价查询（equivalence queries）。等价查询尝试找到一个反例，这个反例能够更新观察表，进行下一次的迭代学习过程。论文采用LearnLib内置的Chow’s W-method方法来进行等价查询寻找反例，为了加快等价查询的速度，论文对W-method进行了改进：传统的W-method在目标系统返回错误响应（例如connection closed）后还会尝试从终止状态寻找输入序列。论文改进的W-method在碰到错误响应后不再从对应状态寻找反例，这种改进加快等价查询的速度。整个学习过程图6所示：
4.2 Test harness实现
Test harness根据目标黑盒系统的不同而有所调整。如果测试服务器，那么test harness支持发送的消息类型包括：ClientHello (RSA and DHE), Certificate (RSA and empty), ClientKeyExchange, ClientCertificateVerify, ChangeCipherSpec, Finished, ApplicationData (regular and empty), HeartbeatRequest , HeartbeatResponse. 如果测试客户端，支持发送的消息类型包括：ServerHello (RSA and DHE), Certificate (RSA and empty), CertificateRequest, ServerKeyExchange, ServerHelloDone, ChangeCipherSpec, Finished, ApplicationData (regular and empty), HeartbeatRequest, HeartbeatResponse. 输出字典除了包含常规的消息类型外，还包括：空消息，即在规定的timeout内没有接收到响应；connection closed，即连接出错或者连接正常关闭；decryption failed，解密消息失败时产生。此外，test harness需要记录TLS握手过程中的信息，例如对方返回的随机数，证书公钥，预主密钥等。同时也需要根据状态对消息进行不同的处理，例如ChangeCipherSpec消息发送后或者接收后需要对下一个消息进行加密操作。
5. 实验结果与分析
论文对9种不同的TLS实现进行了自动机的构建，如图7所示，这些实现中最少的状态只有7个，最多的也只有12个。所以通过人工分析能够很快地找到一些错误的状态转移和冗余的状态。状态机构建的时间也由不同的TLS实现而变化，最快可以9分钟之内构建完成，最慢则需要9个小时。论文通过改进的W-method进行等价查询减少了查询的次数，加快了状态机学习的时间，如图8所示，对GnuTLS进行测试时，改进的W-method方法与原来的W-method方法有明显的加快，等价查询的次数大大减少。
5.1 分析方法
对于生成的状态机，论文首先检查到达握手成功的状态路径，分析这些路径是否合乎TLS规则。然后寻找状态机中的冗余状态或者非预期的状态，分析这些状态是否有问题。另外手动检查一些有趣的消息响应，例如有的状态转移返回”bad record mac”消息, 有的状态转移返回”decryption failed”消息等。下面列举出论文中找到的三种TLS具体实现中的漏洞。
GnuTLS
从状态机上可以观察到两条合法到达握手成功的路径（绿色），最终握手成功的状态是状态7. 同时发现了隐藏的路径（红色路径）到达状态8. 这条隐藏的路径是在握手的过程中发送heartbeat消息都会到达状态8，尽管test harness按照顺序发送了TLS协议中的消息，但是却不能到达成功的握手状态。经过分析GnuTLS的具体实现代码，论文发现GnuTLS会把握手过程中的消息都记录在一个buffer中，但是如果收到了heartbeat消息，GnuTLS会清空这个buffer，导致由buffer计算出的hash值与对方发送过来的加密消息中的hash值不再匹配，从而导致握手失败。
JSSE 1.8.0_25
从JSSE TLS实现的状态机中可以找到两条到达握手成功的路径，其中状态6是成功的握手状态。其中一条（绿色的路径）是合法的握手过程。另外一条是客户端跳过发送ChangeCipherSpec消息直接发送Finished消息也能够到达成功的握手状态。由于客户端发送ChangeCipherSpec消息表示客户端接下去发送消息都将用密钥加密，如果没有发送这个消息，那么将导致客户端发送的消息还是明文消息，而服务器发送的消息却是加密的。利用这个漏洞能够泄露客户端的明文消息，导致隐私泄露。这个漏洞报了CVE-2014-6593。
OpenSSL 1.01j
从OpenSSL 1.01j实现的状态机中可以找到一条到达握手成功状态7的路径。但是有一个可疑的状态8，这个状态是在握手成功后再次发送ChangeCipherSpec消息到达状态8后，所有后继的消息发送都会导致”bad record mac”错误消息响应。这通常表明错误的密钥被使用了，作者通过对其具体实现进一步分析发现OpenSSL将客户端的密钥换成了服务器的密钥，这表明双方加密的密钥是相同的（协议规定两个方向的加密密钥不同），如果双方的加密密钥相同，那么可能会被某些攻击利用（例如RC4漏洞）。
6. 评价
Thesis using the method of automatic machine learning for the first time concrete implementation of TLS protocol is modeled state machine. And logic to find the vulnerability analysis generated by the state machine manually. Automata learn to use the LearnLib framework, the author of one of the W-method is equivalent to the query algorithm has been improved, so that the equivalent number of inquiries reduce speed up the state institutions to build speed. This can be quickly constructed by a simple and fast way embodied TLS protocol state machine, the state machine also intuitive enough, we can manually check the state machine to find the error or redundant state transition state, and control the specific realizing source may be positioned to achieve the bug. However, the state machine analysis can not reflect the vulnerability of other protocol, such as the back door (e.g., a message can be transmitted 100 times for handshaking), message parsing process Vulnerability (e.g. overflow).
7. References
Wen | BlackMax, DR.XX, Harry
Reproduced in: https: //www.jianshu.com/p/9a9e12a588ed