Hacking HTTP/2: New attacks on the Internet’s Next Generation Foundation

© 2016 Imperva, Inc. All rights reserved.
Hacking HTTP/2
New attacks on the Internet’s Next Generation Foundation
Itsik Mantin, Nadav Avital
August 2016

• Itsik Mantin
• Director of Security Research at Imperva
• 15 years experience in the security industry
• Holds an M.Sc. in Applied Math and Computer
Science
• Nadav Avital
• Application security research team leader
• 10 years of industry experience, mostly hacking
and security technology
• Holds B. Sc. in Computer Science
Speakers

Credit
• Noam Mazor,
Application Security researcher at Imperva
• Alex Maidanik and Avihai Cohen,
Technion - Israeli Institute of Technology

The Research
• Unexplored territories of HTTP/2
– New mechanisms
– New server implementations
HTTP/2

The Servers

Outline
HTTP/2 Motivation and Background
HTTP/2 Technology
The Attacks
Summary and Conclusion

HTTP/2 Motivation
• HTTP 1.1 is no longer suitable for
modern web content
– Large number of web resources per page
– Latency
– Head of Line blocking
– Large headers

2016 Web

HTTP/2 Design Principles
• Main goal: speed
– Reduce latency
– Reduce bandwidth
• Support gradual deployment
– Preserve HTTP 1.1 semantics
(over a new binary layer)
– Negotiation protocol (ALPN)
• Encryption
– Mandated by many implementations

Lightfast Adoption
Web Clients
Content Delivery
Networks
Sites
Web Servers

HTTP/2 Technology

HTTP/2 Technology
HPACK
Server Push
Stream
Multiplexing
HPACK
Compression
Flow Control

HTTP/2 Transport Layer
•Binary objects
•The smallest data delivery unit
•Can include headers, data, settings, etc.
Frame
•Carrying Request+Response
•Multiple frames
Stream
•Application layer connection over TCP connection
•Carries multiple streams (using Stream Multiplexing)
HTTP/2 Connection

HTTP/2 Binary Layer

New 0-day DoS Attacks
CVE-2016-1546
CVE-2015-8659* (not by Imperva)
CVE-2016-0150
CVE-2016-1544
CVE-2016-2525

Attack Summary
Compression
Stream
Dependency
& Priority
Stream
Multiplexing
Flow Control

• CVE-2016-1546 – Window size Compression
Stream
Dependency
& Priority
Stream
Multiplexing
Flow Control
Attacking HTTP/2 Flow Control Mechanism

Flow Control
• Based on WINDOW_UPDATE frames
• Defined to protect endpoints that operate
under resource constraints
• Specific to a connection
• Spec only defines format and semantics
• Mandatory and cannot be disabled

Flow Control LDR Attack Flow
ClientsServer
Attacker reduces window size
Request for a large resource (Stream 1)
Request for a large resource (Stream 3)
• When Jetty gets a request for a
resource larger than the
window size, the thread that
handles the request is going to
sleep (30 seconds)
• In ApacheIIS the attacker keeps
the connection alive by slowly
increasing the window size
• By sending multiplies requests
an attacker can make all the
threads sleep for a long time
and cause a denial of service
Users cannot get responses
Slowly increase the window size
Single HTTP/2
connection

• CVE-2015-8659* - memory cleanup Compression
Stream
Dependency
& Priority
Stream
Multiplexing
Flow Control
Attacking HTTP/2 Dependency Mechanism

Stream Priority & Dependency
• Optional (can be ignored)
• Each stream can be given an explicit
dependency on another stream
• Allow an endpoint to express how it
would prefer its peer to allocate
resources
• The graph is a tree

Stream Dependency Cycle
• Assume MAX_CONCURRENT_STREAM = 4 (tree size)
• Send the priority frames
– Stream 7  stream 5 (forces the server to remove of stream 7)
– Stream 5  stream 3
• Stream 3 is saved in the same address as stream 7
• Dependency cycle is created
13
11
9
7
5
3

• Both stream 7 and 3 are located
in the same memory address
• stream_update_dep_set_top
function is in infinite loop
Stream
7
address
Infinite
loop
Same
address for
stream 3
Stream Dependency Denial of Service

• CVE-2016-0150
Compression
Stream
Dependency
& Priority
Stream
Multiplexing
Flow Control
Attacking HTTP/2 Stream Multiplexing Mechanism

Stream Multiplexing
• multiple request and response at
the same time over a single
connection.
• The partition of the TCP connection
is purely logical

Stream Abuse
ClientsServer • Attacker sends multiple
requests on the same stream
• HTTP.sys in Windows 10
crashes (Blue Screen of
Death)
Open HTTP/2 connection
Send two requests on one stream

• CVE-2016-1544 - HPACK Bomb
• CVE-2016-2525 - Wireshark
Compression
Stream
Dependency
& Priority
Stream
Multiplexing
Flow Control
Attacking HTTP/2 Compression Mechanism

Headers Compression
• Both sides (Client/ Server) maintain headers tables per TCP
connection direction
• These tables consist of static and dynamic parts
• These tables are used as dictionaries to compress/
decompress the headers

Headers Compression

HPACK Bomb Attack Flow
ClientsServer • Attacker sends a request
with extremely long header
“X” (Header frame)
• The request contains
maximum number of
references to header “X”
• By sending 14 frames,
attacker can crash nghttp
Send requests with thousands
header references
Insert long header to the dynamic table
16,000
references x
4 KByte
--------------
64 MByte
16,000
references x
1-byte
--------------
16 KByte

HPACK Bomb – Calculation
• The default size of the dynamic table is 4KB
• Request can contain 16KB of headers
• One request can be decompressed to 16K*4KB = 64MB
• 14 requests will be decompressed to 14*64MB = 896MB, enough to crash our
nghttp server

HPACK Bomb – Collateral Damage
• Wireshark
– Uses nghttp2 library to decompress
headers
– Other application that rely on nghttp2
library may be vulnerable

Risk Mitigation

Mitigation
• Abandon your HTTP/2 plans?
– HTTP/2 is the next generation protocol for the Internet
– HTTP/2 serves acute business needs
– Dozens of CVEs published every month for non-HTTP/2
servers
• Choose “secure” server implementation?
– None was found immune
– What about 3rd party software?
– More vulnerabilities to come
• Patch?
– Build patching framework
Compression
Stream
Dependency
& Priority
Stream
Multiplexing
Flow Control

How to win the Patching Race? How do I know that a
vulnerability exists?
When will patch be
ready?
What’s the impact of patch
(and reboot) on my
business?
Is patch stable? Am I
risking my business?

Web Application Firewall and Virtual Patching
Web Application Firewall
(on premise/ cloud)
Security
flaw
Business owner
focuses on business
Server remains intact
Server remains protected

Summary
• HTTP/2 protocol is an excellent technology to provide the next generation of the
Internet
• HTTP/2 is gaining popularity and support by all significant web stake holders
• We demonstrated new attacks on implementations of significant HTTP/2 servers
– Utilizing the significant power given to the sender
– Implementation pitfalls

Conclusions
• HTTP/2 is here to stay, and rightfully so
• HTTP/2 extends the attack surface for web attackers
– New highly customizable transport mechanisms
– New code released to the wild
– Unplowed land
• The HTTP/2 ecosystem is still not security-mature.
Moreover, things may get worse when websites start utilizing HTTP/2 capabilities
• Without external protection and virtual patching, the business owner will always be behind in the
patching race

http://www.imperva.com/DefenseCenter/HackerIntelligenceReports
Download the full report here:

Hacking HTTP/2: New attacks on the Internet’s Next Generation Foundation

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Hacking HTTP/2: New attacks on the Internet’s Next Generation Foundation

Similar to Hacking HTTP/2: New attacks on the Internet’s Next Generation Foundation (20)

More from Imperva

More from Imperva (17)

Recently uploaded

Recently uploaded (20)