Nytro Posted December 5, 2015 Report Posted December 5, 2015 Attacking HTTP/2 Implementations IntroductionYahoo Pentest Team members Stuart Larsen (@xc0nradx) and John Villamil (@day6reak) presented original research at Pacsec 2015 on the HTTP/2 protocol, its security implications, and flaws discovered in a number of implementations. Through this presentation, summarized below, we hope to make the protocol a more popular research target. What follows is a summary of our presentation given at Pacsec 2015 (slides).HTTP/2 is a new technology that is already seeing widespread use across the Internet. There has been little security research into this new protocol yet multiple implementations and widespread adoptions already exist. HTTP/2 lives in browsers, caching proxies, and libraries. It is the undisputed future of Internet connections and vulnerabilities in this protocol have the potential to cripple infrastructure. Our talk focused on threats, attack vectors, and vulnerabilities found during the course of our research. Two Firefox, two Apache Traffic Server (ATS), and four Node-http2 vulnerabilities will be discussed alongside the release of the first public HTTP/2 fuzzer. We showed how these bugs were found, their root cause, why they occur, and how to trigger them.We will also discuss http2fuzz, a fuzzer for both client and server endpoints of HTTP/2 connections. The fuzzer is open source and written in Go. It implements a large part of the HTTP/2 protocol and supports various frame types. It also includes a unique replay mechanism to help track down crash causing packets. We had previously blogged about two ATS bugs found by an earlier version of this fuzzer.OverviewHTTP/1.1 came out back in 1999 and it was a huge step in bringing the web forward. But since then, websites have grown drastically, and HTTP had to be revisited. Today’s sites are much more complex with many more interconnected dependencies. ISP speeds have improved and more bandwidth is available. The changes from HTTP/1.1 to HTTP/2 are all about performance. The major changes are:- Binary Protocol / Compression- Multiplexing- Server Push- FramesBut these new changes in functionality and complexity also introduce additional attack surface to HTTP implementations. HPACKOriginally, HTTP was stateless. It followed a very simple model to make a request and receive a response. But that also means lots of redundant information is sent. HPACK (RFC7541) was released to address these and other issues.HPACK is a binary header compression protocol. It uses dynamic lookup tables to store and retrieve headers. Headers only need to be sent once, and are remembered for future requests on the same connection. This differential encoding saves space and time and is a huge improvement over the vanilla protocol.FramesFrames are the fundamental unit of communication within HTTP/2. Here is a typical HTTP/2 header visualized:There are 10 different types of frames:- Headers- Data- Priority- Reset- Settings- Push- Ping- Goaway- Update- ContinuationTo learn more about individual frames, checkout the RFC.Push PromisePush Promise is a new feature of HTTP/2 that allows you to push resources to a client before the client requests them. For example if a client requests /index.html, the server can probably assume the client will also want /logo.png.New Attack Surface- HPACK- Upgrades / Downgrades- Inconsistent Multiplexing- Malformed Frames- Pushing arbitrary data to client- Pushing arbitrary data to server- Stream dependencies- Invalid Frame StatesWith all of this new attack surface we needed an automated way of getting good code coverage in HTTP2 implementations. For this we decided to build a new fuzzer.http2fuzzhttp2fuzz is a fuzzer written in golang for fuzzing HTTP/2 implementations in either server or client mode.It has a variety of strategies for both smart and dumb fuzzing. It can either rebuild valid frame structures with invalid data, or use completely random data.A big challenge in fuzzing is determining what payload actually caused the target to crash. We decided to build a replay feature that saves each frame that is sent. If a crash occurs, the replay list can be inspected and minimized to determine which payload was the cause of the crash.Bugs 1,2: Apache Traffic ServerOur fuzzer discovered two remotely exploitable vulnerabilities in Apache Traffic Server. Both of these had the potential for arbitrary code execution. These bugs were covered in a previous blog post.Bug 3: Firefox HTTP/2 Malformed Header Frame DoSNormally a header frame consists of a pad length, stream dependency identifier, weight, block header fragment, and padding. If only a single byte is sent an integer underflow occurs which causes nsCString to try to allocate nearly 2^32 bytes of memory.HTTP2Session.cpp:1226[1226]: self->mDecompressBuffer.Append(self->mInputFrameBuffer + kFrameHeaderBytes + paddingControlBytes + promiseLen , self->mInputFrameDataSize - paddingControlBytes - promiseLen - paddingLength);[1226]: self->mDecompressBuffer.Append(ptr + uint8_t(9) + uint8_t(0) + uint16_t(0) , uint32_t(1) - uint8_t(8) - uint32_t(5) - uint16_t(0));As shown above, an underflow is caused in the second parameter of the buffer decompress. These issues were addressed by the Firefox developers.Bug 4: Firefox HTTP/2 Malformed Push Promise DoSThis bug is very similar to the previous bug except it occurs inside push promise.HTTP2Session.cpp:1634[1634]: self->mDecompressBuffer.Append(self->mInputFrameBuffer + kFrameHeaderBytes + paddingControlBytes + promiseLen , self->mInputFrameDataSize - paddingControlBytes - promiseLen - paddingLength);[1634]: self->mDecompressBuffer.Append(ptr + uint8_t(9) + uint8_t(1) + uint16_t(4) , uint32_t(76) - uint8_t(1) - uint32_t(4) - uint16_t(75));Bugs 5-8: node-http2We found a number of bugs inside node-http2 through fuzzing. Most of them involve buffer out of bound reads or invalid state handling within Javascript. These issues do not appear exploitable for arbitrary code execution but could be used to perform denial of service attacks against Node based web servers that use the package.https://github.com/molnarg/node-http2/issues/145https://github.com/molnarg/node-http2/issues/146https://github.com/molnarg/node-http2/issues/147https://github.com/molnarg/node-http2/issues/148[*] These issues have not been addressed by the project maintainers. The package no longer appears to be in active development.ConclusionHTTP/2 brings with it a lot of new attack surface. More research needs to be conducted on the implications of this protocol on web security. New tools need to be developed which handle the protocol and allow penetration testers to effectively audit HTTP/2 based web sites. Security products, including NIDS, will need to implement a subset of the protocol to effectively audit connections for malicious behavior or exploits. Lastly, more testing needs to be done on implementations of the protocol before they are enabled for popular use.Stuart Larsen and John Villamil of the Yahoo Pentest TeamSursa: http://yahoo-security.tumblr.com/post/134549767190/attacking-http2-implementations Quote
