Module-3 | Introduction -Pentesting & Bypassing AWS/Azure/GCP Cloud WAF Fun & Profit

Divyanshu

Published in

InfoSec Write-ups

11 min readMay 25, 2022

1. Setting up Vulnerable Application For AWS WAF

We will be setting custom DVWA for pentesting WAF.

1.1. We need to set up the ec2 instance where we will host DVWA. Let’s start by creating the instance by clicking “Launch Instances”.

1.2. Choose an Ubuntu 20.04 AMI for the server and click select.

1.3. Select the instance type as T2 micro and click on the Configure Instance Details.

1.4. In the Configure the instance, leave everything as default. Make sure Auto-assign Public IP is set to Enable.

1.5. Keep the storage as 8 GB. It will come in a free tier.

1.6. Next we need to configure the security group for HTTP traffic & SSH. Then add the source as MY IP for All traffic & SSH.

We can also select port 80, but this is the lab so I am selecting all traffic. For Source keep the IP to VPN or static IP. We will be modifying this again later after setting ELB.

1.7. Review the instance launch and click Launch.

1.8. Then to login into the instance we will ssh key. We will create or select an existing key pair for ssh into the instance.

Name your key-pair anything. Let’s name it ssh-key.

1.9. Check the instance state and wait for the instance to come up. The instance state should be Running.

1.10 . Then to install the DVWA we need to login via ssh:

#ssh -i ssh-key.pem ubuntu@34.218.245.107

1.11. Now we will be installing custom DVWA which was forked from original DVWA.

I have customised DVWA intentionally to perform and showcase the other attacks which were not possible to demo in the original DVWA.

1.12 Run the below-mentioned command to download the bash script for Ubuntu which will set up preconfigured DVWA.

#sudo su
#wget https://raw.githubusercontent.com/justmorpheus/waf-dvwa/main/automate.sh
#chmod +x automate.sh
#bash automate.sh

1.13 Now to check the DVWA installation, let’s access the instance via IP. We can confirm it is working.

Do not make DVWA public as it is a vulnerable application.

1.14 Below is the snippet of DVWA stored XSS which I modified to test my scenario.

<!DOCTYPE html>
<html>
<body><?php  
$input = "https%2525252525253A%2525252525252F%2525252525252Fw3schools.in%2525252525252F";
$temp = urldecode($input);
while($temp != $input) {$input = $temp;
  $temp = urldecode($input);}
$message= $input;
echo $message;
?></body>
</html>

In this part, I am trying to recursively decode on multiple times URL encoded string. This will decode multi URL encodings performed on any string. I got this from StackOverflow.

2. Setting up the AWS WAF

2.1 We need to set up the WAF but before that, we need to create a load balancer and target group.

A target group tells a load balancer where to direct traffic to : EC2 instances, fixed IP addresses; or AWS Lambda functions, amongst others.

2.2 We will start by creating a Target Group. Select the target group option is situated on the left panel of ec2 and then click on Create Target Group.

2.3. We need to fill in the details of the target group name and keep the VPC as default. Let’s keep it as tg-waf and then click on Next.

2.4. Once the target group is created then we need to register the target which will be the instance. Then select the EC2 for registering in the target group.

This ec2 is the instance where we have installed the vulnerable DVWA. Please make sure to keep the region the same.

2.5. After the addition of the target we need to click on Create target group.

In case of error we need to check for “Health Status Details”.

2.6. Here we can check that the ec2 has been successfully added in the Target Groups.

2.7. Now we will configure the load balancer via the load balancer tab. Click on Create Load Balancer.

2.8. Select the Application Load Balancer. Fill the Load balancer name and keep the zones of the VPC.

2.9. We need to select at least two VPC, here we are selecting all four.

2.10. Then in the target type select the waf-elb i.e. target group we created earlier.

2.11. After creating a load balancer, it will be provisioned. We need to wait once the provisioning is complete.

2.12. Copy the ALB DNS Name from the description.

2.13. Let’s try to access the ec2 via ALB.

This is showing an error because we have updated the security group of the ec2 to allow the traffic via ALB.

2.14. Now let’s make changes to networking so that instance can be accessed via ELB only.
Visit the load balancer and in the security click on the security group.

2.15. Select the security group in the load balancer. Then edit inbound rules for the security group of the load balancer.

Make sure the traffic to be allowed from the internet to ALB. Add 0.0.0.0/0 to allow traffic from the public in case not added.

2.16. Then switch back to the ec2 and open the security group of the ec2 instance. Then select and edit the inbound traffic rules.

Here we will be adding the ALB security group to the source of the ec2 lab inbound rule.

2.17. We need to select and add traffic allowed to be HTTP on port 80 and for source enter the load balancer sg-group to allow traffic from ELB to ec2 instance.

This is a lab hence all traffic is selected.

2.18. Now we will try to access the ALB via DNS name.

3. Setting the AWS WAF

3.1. In the AWS Management Console, in the search bar at the top, enter WAF, and under Services, click the WAF & Shield result.

AWS Shield is a subscription based service from the Amazon that protects resources against denial of service (DOS) attacks.

3.2. In the left-hand menu, under AWS WAF, click Web ACLs.

3.3. The on the right-hand side, click Create web ACL. It will open up a multi-step wizard load. Then in the Web ACL details section, scroll down to Region and select US West (Oregon).

We are creating resources in this region. Set the region first because sometimes changing the region can cause the page to reload and erase the other form fields.
Also, the CloudWatch metric name field should auto-populate.

3.4. In the Associated AWS resources section, on the right, click Add AWS resources
In the options that opens, under Resource type, select Application Load Balancer.

3.5. Then we need to enable the rules. In step 2 Add rules and rule groups.

3.6. In the Rules section, click Add rules and click Add managed rule groups.
We need to enable Core Rule Set, select AWS managed rule groups and select Core Rule Set.

Managed rule groups are pre-defined groups of rules that are provided either by AWS or AWS Marketplace sellers.
Rule groups from marketplace sellers usually require a subscription and have a charge associated with it. This charge is in addition to charges for using AWS WAF to monitor web requests. AWS-managed rule groups can be used at no extra charge.

You can also create your own rule groups with rules you specify. We will see that in the later section.

3.7 To see the available AWS provided rules & rule groups, click AWS managed rule groups.

3.8 You will see the section expand and the list of AWS-provided rule groups.

Scroll down to the Core ruleset and click the Add to web ACL toggle.
Select the other relevant rules and enable other rules from the list as well.

Note: Total WEB ACL capacity for AWS is 1500 units.

4. CRS — Core Rule Set

The ACL we created above has no rules defined and permits the entry of all traffic by default. Not very useful is it! To add rules, you can either write them yourself and/or use predefined managed rule groups. Using managed rule groups is the easiest way to get started, so let’s start there.
ModSecurity is an open-source web-based firewall application (or WAF) supported by different web servers. It comes with a Core Rule Set (CRS) which has various rules for cross-website scripting, bad user agents, SQL injection, trojans, session hijacking, and other exploits. ModSecurity is the engine that uses the core rule set i.e. signature-based rules by which blocks or allow the request.

More about the CRS can be found at https://coreruleset.org/. Also for an in-depth tutorial by one of the CRS co-lead & an amazing person Christian Folini visit https://www.netnea.com/cms/tutorials.

Note: Using the AWS CLI, you can create a Web ACL using JSON to describe the rules. You can also view the JSON definition of existing Web ACL’s, making it easy to copy/paste between them if desired.

4.1 Using Managed Rule Groups

A managed rule group is a predefined set of rules which are managed by either AWS or a 3rd party vendor. The rulesets provide immediate protection from a variety of threats such as the OWASP Top 10 list and are continuously updated to ensure protection against new threats. The AWS provided rules are free to use, while the 3rd party ones require a paid subscription.
You have selected a rule group that identifies web requests containing known SQL attacks such as SQL injection (sometimes referred to as SQLi) attacks.
A SQL injection attack is commonly a web request that contains SQL syntax. A web application with poor security may execute the SQL syntax without safely escaping it.
If an attacker can run SQL of their choice on the SQL database of a system, then they could use this to delete and modify data. They could also use it to compromise the entire system by gaining an unauthorised higher-level of access.
Well-implemented modern web applications should not be vulnerable to this kind of attack. However, most information security experts recommend an approach to system security called Defence in Depth. This can be summarised as layering security controls into every part of a system.
This kind of Web ACL rule may be particularly useful when migrating legacy applications to the cloud when their security model is not well documented or suspected to be weak.