Protocol state fuzzing of TLS implementations

We describe a largely automated and systematic analysis of TLS implementations by what we call ‘protocol state fuzzing’: we use state machine learning to infer state ma-chines from protocol implementations, using only black-box testing, and then inspect the inferred state machines to look for spurious behaviour which might be an indica-tion of flaws in the program logic. For detecting the pres-ence of spurious behaviour the approach is almost fully automatic: we automatically obtain state machines and any spurious behaviour is then trivial to see. Detecting whether the spurious behaviour introduces exploitable security weaknesses does require manual investigation. Still, we take the point of view that any spurious func-tionality in a security protocol implementation is danger-ous and should be removed. We analysed both server- and client-side implemen-tations with a test harness that supports several key ex-change algorithms and the option of client certificate au-thentication. We show that this approach can catch an interesting class of implementation flaws that is appar-ently common in security protocol implementations: in three of the TLS implementations analysed new security flaws were found (in GnuTLS, the Java Secure Socket Extension, and OpenSSL). This shows that protocol state fuzzing is a useful technique to systematically analyse security protocol implementations. As our analysis of different TLS implementations resulted in different and unique state machines for each one, the technique can also be used for fingerprinting TLS implementations.

Compiling symbolic attacks to protocol implementation tests

Recently efficient model-checking tools have been developed to find flaws in security protocols specifications. These flaws can be interpreted as potential attacks scenarios but the feasability of these scenarios need to be confirmed at the implementation level. However, bridging the gap between an abstract attack scenario derived from a specification and a penetration test on real implementations of a protocol is still an open issue. This work investigates an architecture for automatically generating abstract attacks and converting them to concrete tests on protocol implementations. In particular we aim to improve previously proposed blackbox testing methods in order to discover automatically new attacks and vulnerabilities. As a proof of concept we have experimented our proposed architecture to detect a renegotiation vulnerability on some implementations of SSL/TLS, a protocol widely used for securing electronic transactions.Comment: In Proceedings SCSS 2012, arXiv:1307.802

Identification of Bugs and Vulnerabilities in TLS Implementation for Windows Operating System Using State Machine Learning

TLS protocol is an essential part of secure Internet communication. In past, many attacks have been identified on the protocol. Most of these attacks are due to flaws in protocol implementation. The flaws are due to improper design and implementation of program logic by programmers. One of the widely used implementation of TLS is SChannel which is used in Windows operating system since its inception. We have used protocol state fuzzing to identify vulnerable and undesired state transitions in the state machine of the protocol for various versions of SChannel. The client as well as server components have been analyzed thoroughly using this technique and various flaws have been discovered in the implementation. Exploitation of these flaws under specific circumstances may lead to serious attacks which could disrupt secure communication. In this paper, we analyze state machine models of TLS protocol implementation of SChannel library and describe weaknesses and design flaws in these models, found using protocol state fuzzing.Comment: 9 pages, 8 figures, 1 tabl

A Formal TLS Handshake Model in LNT

Testing of network services represents one of the biggest challenges in cyber security. Because new vulnerabilities are detected on a regular basis, more research is needed. These faults have their roots in the software development cycle or because of intrinsic leaks in the system specification. Conformance testing checks whether a system behaves according to its specification. Here model-based testing provides several methods for automated detection of shortcomings. The formal specification of a system behavior represents the starting point of the testing process. In this paper, a widely used cryptographic protocol is specified and tested for conformance with a test execution framework. The first empirical results are presented and discussed.Comment: In Proceedings MARS/VPT 2018, arXiv:1803.0866

Stacco: Differentially Analyzing Side-Channel Traces for Detecting SSL/TLS Vulnerabilities in Secure Enclaves

Intel Software Guard Extension (SGX) offers software applications enclave to protect their confidentiality and integrity from malicious operating systems. The SSL/TLS protocol, which is the de facto standard for protecting transport-layer network communications, has been broadly deployed for a secure communication channel. However, in this paper, we show that the marriage between SGX and SSL may not be smooth sailing. Particularly, we consider a category of side-channel attacks against SSL/TLS implementations in secure enclaves, which we call the control-flow inference attacks. In these attacks, the malicious operating system kernel may perform a powerful man-in-the-kernel attack to collect execution traces of the enclave programs at page, cacheline, or branch level, while positioning itself in the middle of the two communicating parties. At the center of our work is a differential analysis framework, dubbed Stacco, to dynamically analyze the SSL/TLS implementations and detect vulnerabilities that can be exploited as decryption oracles. Surprisingly, we found exploitable vulnerabilities in the latest versions of all the SSL/TLS libraries we have examined. To validate the detected vulnerabilities, we developed a man-in-the-kernel adversary to demonstrate Bleichenbacher attacks against the latest OpenSSL library running in the SGX enclave (with the help of Graphene) and completely broke the PreMasterSecret encrypted by a 4096-bit RSA public key with only 57286 queries. We also conducted CBC padding oracle attacks against the latest GnuTLS running in Graphene-SGX and an open-source SGX-implementation of mbedTLS (i.e., mbedTLS-SGX) that runs directly inside the enclave, and showed that it only needs 48388 and 25717 queries, respectively, to break one block of AES ciphertext. Empirical evaluation suggests these man-in-the-kernel attacks can be completed within 1 or 2 hours.Comment: CCS 17, October 30-November 3, 2017, Dallas, TX, US

Stateful Greybox Fuzzing

Many bugs in protocol implementations may only manifest when the system is in a particular "state". For instance, to trigger one of the bugs we found in an RTSP implementation, the fuzzer must first send two different types of messages to usher the protocol implementation from the INIT via the READY to the PLAY state where the bug is exposed. Without knowledge of the protocol, it is inherently difficult for a fuzzer to discover such stateful bugs. A key challenge in fuzzing stateful systems, therefore, is to cover the state space without an explicit specification of the protocol. So, how can we help our fuzzer navigate an unknown state space? In our analysis of the Top-50 most widely used open-source protocol implementations, we found that every implementation uses state variables that are assigned named constants (such as INIT, READY) to represent the current state. In this work, we propose to automatically identify such state variables and track the sequence of values assigned to them during fuzzing to produce a "map" of the explored state space. Our stateful greybox fuzzing approach uses this map to focus on the most promising regions of the code and state space. Our experiments confirm that our stateful fuzzer discovers stateful bugs twice as fast as the baseline greybox fuzzer that we extended. The state sequence for an input is determined by the sequence of values assigned to the state variables during its execution. Starting from the initial state, our fuzzer exercises one order of magnitude more state sequences and covers the same code two times faster than the baseline fuzzer. Several zero-day bugs in prominent protocol implementations were found by our fuzzer, and 8 CVEs have been assigned

Security Analysis of HTTP/2 Protocol

abstract: The Internet traffic, today, comprises majorly of Hyper Text Transfer Protocol (HTTP). The first version of HTTP protocol was standardized in 1991, followed by a major upgrade in May 2015. HTTP/2 is the next generation of HTTP protocol that promises to resolve short-comings of HTTP 1.1 and provide features to greatly improve upon its performance. There has been a 1000\% increase in the cyber crimes rate over the past two years. Since HTTP/2 is a relatively new protocol with a very high acceptance rate (around 68\% of all HTTPS traffic), it gives rise to an urgent need of analyzing this protocol from a security vulnerability perspective. In this thesis, I have systematically analyzed the security concerns in HTTP/2 protocol - starting from the specifications, testing all variation of frames (basic entity in HTTP/2 protocol) and every new introduced feature. In this thesis, I also propose the Context Aware fuzz Testing for Binary communication protocols methodology. Using this testing methodology, I was able to discover a serious security susceptibility using which an attacker can carry out a denial-of-service attack on ApacheDissertation/ThesisMasters Thesis Computer Science 201