February 4, 2022

A detailed guide on protecting against the 8KB AWS WAF limitation

The AWS WAF and Shield service has a 8KB limitation on the size of the request body that it can inspect. This article shows the additional configuration you can do to add checks to ensure attackers are not able to exploit the limitation so that you are continued to be protected.

Table of Contents

Introduction

What is the 8KB limitation of AWS WAF?

What is the impact if left at defaults?

How do we mitigate the risk?

     Creating a SizeConstraint rule in AWS WAF

What else can we do?

Conclusion


Introduction


We recently wrote about a documented yet little known limitation with the AWS WAF that prevents the Web Application Firewall from inspecting HTTP packets whose request body is larger than 8KB in size. The default behaviour in such a case is to let the request pass the WAF and reach the web application it is protecting, resulting in weaknesses within the web application to be exposed to attackers.

This post will take you through some of the possible mitigations and architectural updates you could potentially do to ensure the 8KB size limitation does not cause a business disruption due to an attack.

What is the 8KB limitation of AWS WAF?

For a more detailed post and to see how an attacker can actually abuse this to exploit web applications behind the WAF, do take a look at our blogpost at Bypassing the AWS WAF protection with an 8KB bullet.

In brief, the AWS WAF has a limitation when it comes to inspecting HTTP request bodies that are larger than 8KB. The default behavior when a packet whose request body size is larger than 8KB reaches the AWS WAF is to forward the request to the web application for processing.


Knows issues/limitations


Although documented by AWS, the implications of this limitation are far reaching if additional measures are not put in place to prevent attackers from abusing this.

What is the impact if left at defaults?


A Web Application Firewall by definition is meant to prevent malicious traffic from reaching the web application. It is also important to note that a WAF, like a network firewall, works optimally based on the rules that are in place.

When a rule is added to block specific attacks, and if no contingency rules are added for packets that are larger than 8KB (which is the most common way SREs and infra administrators will set this up), the WAFs ability to protect resources diminishes.

An attacker could use a packet larger than 8KB to bypass the AWS WAF effectively and attempt to exploit the vulnerability. The nature of impact of exploitation is dependent on the vulnerability being exploited and is only limited by the attacker’s imagination and access obtained. 

To give you a sense of impact, imagine a web application vulnerable to a command injection vulnerability running on an EC2 instance behind an AWS Load Balancer with the AWS WAF preventing malicious requests from reaching the web application.


Illustration depicting the limitation

An attacker in this scenario would be able to use a packet larger than 8KB to reach the web application with malicious data. A successful exploitation would give the attacker remote command execution capabilities. The attacker would use this access to run commands on the server hosting the web application, use cURL commands to access the instance metadata endpoint on the EC2, extract temporary AWS security IAM credentials, impersonate the role attached to the EC2 and attempt to access other resources within AWS like S3 for example, resulting in the attacker successfully moving from the EC2 machine to other data stores within the AWS account.


How do we mitigate the risk?


What can we do to minimize or mitigate the risk associated with this configuration? AWS recommends that a size constraint rule must be added alongside other rules to ensure packets larger than 8KB do not pass through.

This may sound counterintuitive to some of the web applications functionality (present and future) where 8KB data is expected to be received from the user. File uploads, dashboard configuration saves and some custom functionality that have web components could exceed 8KB in size (like the ASP.NET viewstate data).

What is a good approach then in such cases? The approach to creating an acceptable solution requires a risk mindset and a defence in depth approach.

Creating a SizeConstraint rule in AWS WAF


Adding a SizeConstraint rule with an 8KB limit in AWS WAF will cause the WAF to block requests larger than the prescribed limit. You can initially set the rule to “Count” in Step 7, so that you can evaluate if your application does really receive packets larger than 8KB in day to day operations.

We can use the following steps to set up the rule.


  1. Navigate to the AWS WAF service in the web console and identify the Web ACL that needs to be updated.
  2. Click on the Web ACL and go to the “Rules” tab


go to the “Rules” tab


  1. Click on “Add rules” and select “Add my own rules and rule groups” option
select “Add my own rules and rule groups” option


  1. In the next page, under “Rule builder”, give the rule a name and ensure that “Regular rule” type is selected.


give the rule a name and ensure that “Regular rule” type is selected.


  1. Select “matches the statement” from the drop down for request



  1. Under the Statement section, choose the following
  1. Inspect - “Body” from the drop down, 
  2. Content Type - “Plain text” or “JSON” based on your application
  3. Match type - “Size greater than or equal to”
  4. Size in bytes - “8192”


The statement section


  1. In the “Then” section, you will describe what the WAF needs to do if the condition is met. The default action selected is “Block”. We can set this to “Count” to evaluate if the target application does actually receive web packets larger than 8KB. In such cases, the WAF will allow packets to pass through even if they are larger than 8KB but will log what pages received larger requests.


the “Then” section


Once the rule is added, it needs to be moved to the top of the rule set so that the SizeConstraint check is run before any other rules are processed. This can be done by selecting the newly created rule and clicking the “Move Up” button in the “Set rule priority” page as shown below.


Set rule priority


What else can we do?

Although not the best solution to the 8KB limitation, adding a SizeConstraint creates a starting point for adding a defense in depth approach for your applications.

Using additional rules, you can set up the WAF to allow traffic for specific URI paths. However, this is not straightforward to set up since AWS WAF follows rule priority for parsing requests and malicious requests may actually pass through if the order is not configured properly.

From the web application and shift left perspective, ensuring proper security coding guidelines are followed, the dependencies that the application uses are verified to be the current secure versions, and ensuring that the web application is tested for security weaknesses periodically, can all become ground rules while setting up the WAF. This allows the application environment to remain secure regardless of the limitations that an AWS resource may have.

Conclusion


Attackers are constantly researching new ways of bypassing protection mechanisms that SREs and infrastructure owners impose. Although documented by AWS, the 8KB limitation is not well known and worse, the implications of the limitations are not well understood. When a new team member joins, they inherit the infrastructure and nuances such as these, and are often unaware of the potential dangers they can create. 

Using the recommendations provided by AWS, we can add a rule to constrain the size of the packet that would be sent by an attacker to the 8KB limit. Additional security measures can be added in place to ensure exception rules added to pages like file upload to prevent the 8KB limit from applying while making sure that  the application is secure. This can be done by confirming if  the functionality is thoroughly tested for security flaws and secure coding practices have been followed during the development lifecycle.

***


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. If you wish to give your feedback on this article, you can write to us 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