May 20, 2022

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.

Table of Contents

Short Introduction

Introduction

HTTP Desync Attack overview

How to configure AWS Load Balancers against HTTP Desync attacks

Conclusion

Introduction

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
Host: example.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked
test
GET /admin HTTP/1.0
Bug: x

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

  1. Ensure your region is correctly selected
  2. Navigate to the EC2 console at https://console.aws.amazon.com/ec2/v2/home
  3. On the left navigation pane, under “Load Balancing”, choose “Load Balancers”

Load Balancers

  1. Select the load balancer from the list
  2. On the “Description” tab, click on the “Configure desync mitigation mode” button under “Attributes”

Configure desync mitigation mode

  1. The default “Defensive” is already chosen. However, if you wish to change the mitigation mode choose from “Strictest” or “Monitor” mode and click “Save”
Configure desync mitigation mode

How to configure Desync Mitigation Mode in ALB/CLB using the command line

  1. 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)
aws elb describe-load-balancers --query "LoadBalancerDescriptions[].LoadBalancerName" --region us-east-1

  1. Use the modify-load-balancer-attributes command with the elb.http.desyncmitigationmode attribute set to monitor, defensive, or strictest

aws elb modify-load-balancer-attributes --load-balancer-name my-load-balancer --load-balancer-attributes file://attribute.json

Following is the content of attribute.json

{
    "AdditionalAttributes": [
        {
            "Key": "elb.http.desyncmitigationmode",
            "Value": "strictest"
        }
    ]
}

Conclusion

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.

Written by:
Riyaz Walikar

Riyaz Walikar

Chief Hacker

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

Read more