Configuring AWS Load Balancers to protect against HTTP Desync attacks
HTTP Desync attacks are a category of attacks on a system of proxies and load balancers when multiple devices in the chain parse parts of the HTTP request differently, resulting in tampering of legitimate HTTP sessions and bypassing application level security. AWS offers protection against these attacks in their Load Balancer service that prevents exploitation.
How to configure AWS Load Balancers against HTTP Desync attacks
As web and other HTTP based applications become more complex, there is always going to be room for errors, especially since the large variety of systems that need to work together to function as a service are created, implemented, and maintained by very different people and teams. This allows for interesting quirks to come into play, notwithstanding your standard run of the mill web application security issues.
Most web application vulnerabilities are caused due to improper input validation. These are issues that result due to the application not parsing user supplied data contextually. HTTP desync attacks, which are a type of request smuggling attack, occur due to non-compliant HTTP request headers being parsed differently by different systems on their way to the target server.
HTTP desync attacks can lead to caching issues, access to sessions of other users, cache poisoning, arbitrary redirection etc. The attack usually results in a large set of the application’s user base to be affected.
In this Kloudle Academy article, we will do a quick review of what HTTP Desync attacks look like in the real world and how to configure AWS Load Balancers to resist these attacks and prevent them from being processed by proxies or app servers sitting behind the Load Balancers.
HTTP Desync Attack overview
In its most basic form, HTTP desync attacks occur when a front-end proxy and the back end server understand and interpret a single HTTP request header differently. This causes both the front-end proxy (load balancer/reverse proxy) and the backend to become out of sync with each other, thereby allowing the attacker to modify the next request that arrives at the backend server.
Two HTTP request headers are commonly abused to do this: Content-Length (CL) and Transfer-Encoding (TE). Content-Length header is used to indicate the size of the request body in bytes denoted using a decimal number. The Transfer-Encoding header specifies the form of encoding used to transfer the payload.
The RFC specification 2616, states that “If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored”. This however is not implemented correctly across different types of proxies and app servers, especially when the headers themselves are malformed in the request. Various combinations of CL or TE header being parsed first leads to different attack scenarios, the most popular of which are:
CL.TE: the front-end server parses the Content-Length header and the back-end server parses the Transfer-Encoding header.
TE.CL: the front-end server parses the Transfer-Encoding header and the back-end server parses the Content-Length header.
A malicious HTTP request looks as follows
POST / HTTP/1.1
GET /admin HTTP/1.0
The CL header is parsed by the frontend reverse proxy (nginx for eg.) causing the entire request to be sent to the backend (gunicorn for eg.) which parses the TE header resulting in the GET /admin HTTP/1.0 to be processed as the beginning of the next request. When the attacker makes an actual HTTP request, it is appended to Bug: x
How to configure AWS Load Balancers against HTTP Desync attacks
AWS, like most other major cloud providers, allows you to set up applications behind load balancers. The Application Load Balancer (ALB) and Classic Load Balancer (CLB) support mitigation modes for HTTP Desync attacks.
In an ideal world, to mitigate HTTP Desync attacks, you would need to only allow requests that conform to the standard RFC 7230 and 2616. However, real world web traffic contains mutations induced by browsers and middleware that results in non compliant headers. To counter this reality, AWS’s “Desync MItigation Mode” classifies every request reaching the ALB/CLB with a threat level using the AWS HTTP Desync Guardian library.
With Desync Mitigation Mode, customers can choose among three modes - “Defensive”, “Strictest”, and “Monitor”
In the “Defensive” mode, the load balancer allows apps to receive known safe requests irrespective of their RFC 7230 compliance and block requests that are known security threats.
The “Strictest” mode allows only requests that are RFC 7230 compliant and drops the request if they are not.
The “Monitor” mode is useful if you want to simply log potentially malicious requests while allowing the app to receive all requests as they are sent from the client.
How to configure Desync Mitigation Mode in ALB/CLB using the console
To update the mitigation mode for an existing load balancer
On the left navigation pane, under “Load Balancing”, choose “Load Balancers”
Select the load balancer from the list
On the “Description” tab, click on the “Configure desync mitigation mode” button under “Attributes”
The default “Defensive” is already chosen. However, if you wish to change the mitigation mode choose from “Strictest” or “Monitor” mode and click “Save”
How to configure Desync Mitigation Mode in ALB/CLB using the command line
Enumerate the current list of load balancers in your account in a specific region. If you already know the name of the load balancer where you want to apply the change, you can skip this step. (Note: use elbv2 for ALB)
HTTP Desync attacks are a novel way to perform HTTP request smuggling and like most systems that put usability ahead of security, affect chains of proxies and app servers. HTTP Desync attacks can be used to poison HTTP caches and cause information leak. Multiple publicly disclosed security issues have shown this which can lead to cross user session leakage and unauthorized access to restricted regions of web applications.
AWS provides a Desync Mitigation Mode that can be enabled to prevent attackers from exploiting this weakness in differential parsing of HTTP headers. The mitigation mode allows for completely disabling malicious requests, allowing trusted requests to pass through or simply monitoring traffic to understand the threat perception that your application faces from attackers. This feature is available free of charge for all load balancers within AWS for both the Classic Load Balancer (CLB) and Application Load Balancer (ALB) and can be configured by using either the console or the CLI.
This article is brought to you by Kloudle Academy, a free e-resource compilation, created and curated by Kloudle. Kloudle is a cloud security management platform that uses the power of automation and simplifies human requirements in cloud security. Receive alerts for Academy by subscribing here.
Riyaz is a security evangelist, offensive security expert and researcher with over a decade of experience in the cyber security industry. His passion to break into some of the most well defended networks and systems in his career spanning 15 years has earned him a lot respect within the security industry. He has led Security Assessment and Penetration Testing teams at Pricewaterhouse Coopers (PwC) and Appsecco, and the Product Security Team at Citrix before co-founding Kloudle. Riyaz now specializes in cloud native, container and cloud security in general, helping build an easy to use security management platform to help companies enhance their visibility in the cloud, identify security misconfigurations and automate remediation for security gaps enabling compliance and operational security in multi-cloud environments. He is also an avid speaker and trainer and presents his research and findings at security conferences and community meetups around the world including BlackHat USA, BH Europe, BH Asia, nullcon and OWASP AppsecUSA.Specialties: Cloud (AWS, GCP, Azure, IBM, Others) Security, Cloud-Native Security, Kubernetes, Container Security, Web Application Security, Network and System Penetration Testing, Wireless Network Security, Malware Analysis and Reverse Engineering, Threat Modelling, Windows Forensics, Security Code Review, Vulnerability Research, Exploit Development and Reverse Engineering. Certifications: CKA, CKAD, OSCP