Waf Charm

Blog

AWS WAF

How to detect attacks aimed at vulnerability on AWS WAF

This post was originally published in Japanese in the past.

Table of Contents

  1. 1. Introduction
  2. 2. Basic premises
  3. 3. Understanding the attacks
  4. 4. Setting a condition
  5. 5. Conclusion

1. Introduction

Do you regularly check for cybersecurity vulnerability information?
New vulnerabilities are identified and updated daily. Some of you may be faced with a situation to urgently respond to counter them.

You may even have considered using WAF because following the updates and the impact of vulnerabilities could take time.

In this post, we are going to take a look at a way to utilize WAF to counter vulnerabilities.

2. Basic premises

As a basis, ensure web applications are securely structured with operation in mind. There are many cases that require you to update dependencies when vulnerabilities are identified, so plan response methods ahead of time.

In addition, follow the actions recommended by vendors as an official response. Consider actions taken through WAF as a way to mitigate the impact. If the vulnerabilities' severity is high, websites could stop providing services because of the attacks. Have strategies to maintain secure websites by quickly responding to the information provided by credible sources.

With the basics explained above in mind, let's continue.

3. Understanding the attacks

When vulnerability information is published, CVE-ID is given to that vulnerability and listed in databases such as the NVD database. Check the provided information and decide whether you need to take action against it.

Furthermore, differences in source code or testing results called PoC (Proof of Concept) are published for many open source projects, so use the available information to comprehensively decide on the action.

In terms of using WAF, if the attacks that exploit vulnerabilities were not coming through HTTP/HTTPS connections, you will not be able to use WAF as the countermeasure. Having public vulnerability information does not necessarily mean that WAF could be set up to protect against attacks immediately, so we recommend collecting information regularly and considering the actual countermeasures.

Next, we will use an actual vulnerability, ShellShock (CVE-2014-6271), as an example.

The function definitions in the values of environment variables are not processed appropriately, which allows attackers to execute arbitrary code. The impact could include data leakage and data fabrication.
*Please note that this post is not intended to explain a certain vulnerability. For more details, refer to the information provided by organizations or personnel who publish them.

We are going to detect an attack pattern that can be detected by WAF based on the published PoC below which uses a user-agent in HTTP header.

https://github.com/opsxcq/exploit-CVE-2014-6271

4. Setting a condition

From the vulnerability information and PoC, we could see that the attacks were executed when values were passed on as below.

() { :; }; echo; echo; /bin/bash -c 'cat /etc/passwd'

Let's set up a Filter to detect the attack.

If you want to detect it simply based on the PoC, you just need to input the same content in the string match condition. However, because the important part of this vulnerability is the function definitions in the values of environment variables, the condition should essentially be focused on that part.

For the purpose of this post, we are going to simply detect the value above.
We've focused on certain parts of the value and picked the three parts below.

() {
echo;
/bin/bash

The important thing to keep in mind is that you should avoid getting false positives.
In this condition, the values to be detected are not typical values that are used under user-agent, so the possibilities of getting false positives are low, but the possibility could increase in the body of the requests. It is inevitable to have false positives in WAF, but the reason for it is that false positives occur when there are values that should be detected but cannot be differentiated from the typical process.

Let's set the condition. Details are as below.

  • type: String

Filters will be set for each string () {, echo;, abd /bin/bash.

  • Part of the request to filter on: Select Header and User-Agent
  • Transformation: Convert to lowercase
  • Match type: Contains
  • "() {", "echo;", "/bin/bash"

The steps to setting up the condition are complete. If you are going to use the condition for a rule, refer to the blog posts below for more details on how to create a rule.

5. Conclusion

You will need various knowledge to create an effective rule that does not cause too many false positives. If your organization has security engineers who are familiar with web applications, you could operate within your organization, but it could be difficult to constantly respond to vulnerabilities. As your official action, make sure to follow through with a vendor-recommended action from published information. However, if you cannot update immediately, consider using outside security products as well.