James Kettle – director of research at PortSwigger – demonstrated at BlackHat 2021 how attackers can exploit current practices surrounding the HTTP/2 protocol to launch a variety of attacks against web servers and end-users.
In fact, he managed to demonstrate this type of attack is possible against popular services such as Netflix, Amazon Application Load Balancer, and Imperva’s cloud Web application firewall. These so-called Desync attacks can be used against providers using HTTP/2 downgrading to hijack clients, poison caches, and steal credentials to critical effect.
HTTP/2 downgrading occurs when a front-end server uses HTTP/2 to communicate with clients while using HTTP/1.1 to communicate with the back-ends that content the application or processing logic.
In today’s multi-cloud environments, HTTP/2 downgrading has become an almost unavoidable fact of life which makes it frighteningly common. Since HTTP/2’s adoption in 2015, there has also been a widespread tendency to treat it as a transport-layer protocol that can be swapped in with zero security implications.
However, the uncomfortable truth is that viewing it this way has led to a slew of unresolved security concerns up until today, even in large-scale consumer-oriented services.
Kettle was subsequently awarded $20,000 as a bounty for reporting the issue to Netflix. He also demonstrated how this vulnerability affects almost all websites using the Amazon Load Balancer and managed to compromise a law enforcement website.
Test the real-world effectiveness of your security controls while achieving compliance and protecting your brand. Cyberwarfare expert, NATO offensive Top Security Clearance and ex-NSA are main members of our core team. Our ethical hackers will find weaknesses in your infrastructure, exploit them, and report their findings.
How do attackers exploit websites that use HTTP/2?
Attackers can exploit the fact that HTTP/1.1 and HTTP/2 have different methods of interpreting message length in order to interfere in the way in which a website, web server, or application processes sequences of HTTP requests.
One common type of interference employed by attackers is that of HTTP request smuggling. Using this technique, an attacker can exploit this difference in interpretation to smuggle their front-end request in a way that the back-end server accepts it as the start of the next request.
In effect, this allows attackers to smuggle through their own requests or to alter the ways in which succeeding quests are processed.
Successful HTTP smuggling attacks are critical in severity and can lead to attackers bypassing security controls, gaining unauthorized access to sensitive data, and directly compromising other front-end users.
One way in which this type of attack can be utilized to harm end-users is to smuggle requests into a downgraded HTTP request between a front-end and back-end server to redirect website visitors to another server.
From there, attackers can launch a variety of attacks, such as spoofing visitors to hand over sensitive information, deploy malware, steal credit cards or passwords, etc.
How can you prevent this type of attack?
The simplest and most effective way to ward off this type of attack is to simply use end-to-end HTTP/2 communication and avoid HTTP/2 downgrading to HTTP/1.1. In his presentation, Kettle himself states that by just implementing this one measure, you will nullify about 80% of the techniques he used to exploit these servers.
However, another takeaway from this whole saga is the importance of utilizing services such as ethical hacking, red-teaming, etc. Outsourcing some of your security testing can help to identify vulnerabilities that your own internal team might not think of.
Organizations can also use tools like HTTP Request Smuggler (also developed by Kettle) to search for HTTP/2 vulnerabilities across their servers.
As mentioned, this is a serious threat that can lead to severe damages for both businesses and end-users, so it must be given the appropriate attention it deserves.
HTTP/2 Implementation Errors Exposing Websites to Serious Risks
HTTP/2: The Sequel is Always Worse