Part 3 - Vulnerability Exploitation Playbook: Azure WAF Security Protection and Detection Lab

[Mohit_Kumar]

 

Tutorial: Vulnerability Exploitation Playbook

Vulnerability Exploitation playbook is third in the four-part tutorial series for the Azure WAF protection and detection lab.  The purpose of the Azure WAF security protection lab is to demonstrate Azure WAF's capabilities in identifying and protecting against suspicious activities and potential attacks against your web applications.  This playbook explains how to test Azure WAF's protections against a Cross Site Scripting (XSS) attack with emphasis on Azure WAF protection ruleset and logging capabilities.  The lab does not include advanced application security concepts and is not intended to be a reference for application security testing as these areas are broader than the use cases demonstrated herein.

This playbook demonstrates the protection capabilities of Azure WAF against a simulated Server Side XSS injection (Stored XSS) attack from common, real-world, publicly available hacking and attack tools.

In this tutorial you will:

1. Simulate Cross Site Scripting (XSS) attack against the target OWASP Juice Shop application directly and then attack the same instance of the web application published through Azure WAF
• Inject a proof of concept (POC) XSS payload in the target OWASP Juice Shop application directly and then through Azure WAF
2. Observe the difference in the web application behavior in the two scenarios
3. Review the summarized logs in the WAF Workbook (Azure Monitor Workbook for WAF)

Prerequisites

1. A completed Azure WAF security lab setup
   • We recommend following the lab setup instructions as closely as possible. The closer your lab is to the suggested lab setup, the easier it will be to follow the Azure WAF testing procedures.
2. Completion of the reconnaissance playbook tutorial

Configuring Burp Suite and Firefox

To inject the POC XSS exploit code in the OWASP Juice Shop application, we will connect to the Kali VM with RDP.  Once connected, we will use Burp Suite (Community Edition), a powerful web application security research and analysis tool which is bundled in the Kali Linux distro.  In this playbook, we will be using Burp Suite to inspect application requests and responses to understand what happens when injecting the POC XSS payload in the target web application is different scenarios.

Burp Suite works as a client-side proxy and your web browser should point to Burp's Proxy Listener so, it can intercept requests and responses. 

1. Sign into the Kali VM using your lab credentials
2. Launch the web browser and ensure that you are able to access the OWASP Juice Shop website directly with URL http://owaspdirect-<deployment guid>.azurewebsites.net and also through Azure WAF with URL http://juiceshopthruazwaf.com
3. Launch Burp Suite by clicking on Applications on the top left and then click Web Application Analysis --> burpsuite

4. In the "Burp Suite Community Edition" window, accept the defaults (Temporary project --> Use Burp defaults --> Start Burp) to start Burp Suite

Figure 1 - Launch Burp Suite

Figure 2 - Launch Burp Suite

5. When open, click on Target --> Scope tabs and then add the 2 URLs for the Juice Shop website in the "Include in scope" box.  This will setup Burp to only capture requests and responses for these specific websites while excluding traffic going to other destinations

a. http://owaspdirect-<deployment guid>.azurewebsites.net

b. http://juiceshopthruazwaf.com/  

6. The exclusions in the "Exclude from scope" are optional and will help reduce noise in the capture

a. http://owaspdirect-<deployment guid>.azurewebsites.net/socket.io/

b. http://juiceshopthruazwaf.com/socket.io/

! IMPORTANT:  For the scenarios demonstrated in this document, OWASP Juice Shop application was running on HTTP port 3000.  This is not the case when you use the Azure WAF Attack Testing Lab Deployment Template as it configures the application to run on port 80, 443 and assigns it a URL.  For the lab tutorials, you will connect to the application on HTTP port 80 only.  The URL for the application will be http://owaspdirect-<deployment guid>.azurewebsites.net.  <deployment guid> is unique to every deployment 

7. Then click on the Proxy --> Options tabs and verify that Burp Proxy is running on 127.0.0.1:8080

8. Click on the Intercept tab and turn off intercept

9. Launch Firefox browser on the Kali Linux VM and update the proxy settings to use Burp proxy listener under Menu --> Preferences --> Network Proxy --> Settings --> Manual proxy configuration and point it to 127.0.0.1:8080

Vulnerability Exploitation

After collecting and analyzing web application specific data from the various recon activities to detect vulnerabilities, an attacker can then successfully exploit the identified vulnerabilities with the intent to compromise a user or the application itself to elevate privileges.  In this playbook, we will simulate a Cross Site Scripting (XSS) attack against the target application using a proof of concept (POC) exploit payload.

Performing Cross Site Scripting (XSS) Attack against the Target Web Application

In this tutorial, you will perform a Server Side Cross Site Scripting (XSS) attack against the OWASP Juice Shop application two times. 

1. Scenario 1: Injecting the XSS payload in the target web application directly
2. Scenario 2: Injecting the same XSS payload in the same target web application protected by Azure WAF on Application Gateway

Scenario 1:  Injecting XSS payload when going to the OWASP Juice Shop Application directly

1. Sign into the Kali VM using your lab credentials
2. Using Firefox, browse directly to the Juice Shop site by going to http://owaspdirect-<deployment guid>.azurewebsites.net
3. In Burp Suite, check the Proxy --> HTTP history tab for request and response data for this website
4. Click the website menu icon on the top left and then click on Customer Feedback

! IMPORTANT:  For the scenarios demonstrated in this document, OWASP Juice Shop application was running on HTTP port 3000.  This is not the case when you use the Azure WAF Attack Testing Lab Deployment Template as it configures the application to run on port 80, 443 and assigns it a URL.  For the lab tutorials, you will connect to the application on HTTP port 80 only.  The URL for the application will be http://owaspdirect-<deployment guid>.azurewebsites.net.  <deployment guid> is unique to every deployment 

5. In the Comment box of the Customer Feedback form, copy/paste the POC code

   <iframe src="x-javascript&colon;alert(`xss`)">

6. Give a Rating, respond to the CAPTCHA challenge and click Submit

7. Upon clicking Submit, you should see a Thank you message

8. Switching back to Burp, we can see the following request and response for the Feedback that we submitted in Step 4 above

Figure 1 – Request with XSS Payload in Burp Suite

Figure 2 – Successful Response from Juice Shop in Burp Suite

Raw Request and Response - Headers and Body

Request

Response

POST /api/Feedbacks/ HTTP/1.1 Host: juiceshopdirect.com:3000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://juiceshopdirect.com:3000/ Content-Type: application/json Content-Length: 105 Cookie: io=LsYFH7-IUxnCTaU5AAAW; language=en; welcomebanner_status=dismiss; cookieconsent_status=dismiss Connection: close {"captchaId":7,"captcha":"3","comment":"<iframe src=\"javascript&colon;alert(`xss`)\"> (anonymous)","rating":3}

HTTP/1.1 201 Created Access-Control-Allow-Origin: * X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN Feature-Policy: payment 'self' Location: /api/Feedbacks/11 Content-Type: application/json; charset=utf-8 Content-Length: 205 ETag: W/"cd-jaYV3gaD4F+1IP1EkEdoiAcNqfQ" Vary: Accept-Encoding Date: Sat, 10 Oct 2020 23:51:52 GMT Connection: close {"status":"success","data":{"id":11,"comment":"<iframe src=\"javascript&colon;alert(`xss`)\"> (anonymous)","rating":3,"updatedAt":"2020-10-10T23:51:52.834Z","createdAt":"2020-10-10T23:51:52.834Z","UserId":null}}

9. The 201 Created response code with a successful status tells us that the malicious POC XSS payload was stored successfully by the web application.  We can now check if the XSS exploit is indeed working by going to the About Us page of the application.  On this page, in addition to the company information, customer feedback is also displayed with rating and comments
10. As shown in image on the right below, as soon as we browse to the About Us page, we see the pop-up with indicates that the exploit is working as expected

Scenario 2:  Injecting XSS payload when going to the OWASP Juice Shop Application through Azure WAF

We will now attempt to perform the injection of the same XSS payload in the Customer Feedback form on the Juice Shop website when going through Azure WAF on Application Gateway.

1. On Kali VM, launch a new instance of Firefox and browse to the Juice Shop website published through Application Gateway and protected with Azure WAF by going to http://juiceshopthruazwaf.com/
2. In Burp Suite, check the Proxy --> HTTP history tab for the request and response data for this website

• Tip:  To see the latest request/response, sort by #

3. In the browser window, click on the website menu icon on the top left and then click on Customer Feedback
4. In the Comment box of the Customer Feedback form, copy/paste the POC code

   <iframe src="x-javascript&colon;alert(`xss`)">

5. Give a Rating, respond to the CAPTCHA challenge and click Submit

6. Upon clicking Submit, you will observe that the thank you message does not show up this time

• Tip:  The web application does not provide an error response in this scenario.  This is due to the behavior of the Juice Shop application

7. Switching back to Burp, we can see the following request and response for the Feedback that we submitted in Step 5 above

Figure 1 – Request with XSS Payload in Burp Suite

Figure 2 – 403 Forbidden Response from Application Gateway in Burp Suite

Raw Request and Response - Headers and Body

Request

Response

POST /api/Feedbacks/ HTTP/1.1 Host: juiceshopthruazwaf.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://juiceshopthruazwaf.com/ Content-Type: application/json Content-Length: 107 Cookie: io=ygD2rhS_-3S5-Q_vAAF2; language=en; welcomebanner_status=dismiss; cookieconsent_status=dismiss Connection: close {"captchaId":14,"captcha":"-6","comment":"<iframe src=\"javascript&colon;alert(`xss`)\"> (anonymous)","rating":3}

HTTP/1.1 403 Forbidden Server: Microsoft-Azure-Application-Gateway/v2 Date: Sun, 11 Oct 2020 02:26:32 GMT Content-Type: text/html Content-Length: 179 Connection: close <html> <head><title>403 Forbidden</title></head> <body> <center><h1>403 Forbidden</h1></center> <hr><center>Microsoft-Azure-Application-Gateway/v2</center> </body> </html>

8. The 403 Forbidden response from the Application Gateway tells us that the request with the POC XSS payload was blocked by Azure WAF

Understanding What Happened 

Upon reviewing the HTTP requests and responses for the two attempts to inject POC XSS payload to the same instance of the Juice Shop application, we see the pattern as shown in the below table.  This clearly indicates that the malicious XSS payload which could otherwise be stored in the application is not allowed through by Azure WAF.

XSS Exploitation Route	Success
Direct	Yes
Through WAF	No

Now let us use the Azure Monitor Workbook for WAF to understand how the WAF handled traffic with the XSS payload.  This workbook visualizes security relevant WAF events across several filterable panels.  It works with all WAF types, including Application Gateway, Front Door, and CDN, and can be filtered based on WAF type or a specific WAF instance.

Click here to deploy Azure Monitor Workbook for WAF to your subscription in Azure.

• Tip:  To understand what is happening when traffic with XSS payload destined for the Juice Shop application goes through the Azure WAF, you can also examine the log entries associated with ApplicationGatewayFirewallLog in the Azure Monitor

Reviewing WAF logs in the Workbook

1. You can access the WAF workbook by going into the Workbook blade and then selecting the WAF workbook deployed for this testing.  Once in the workbook, ensure that you have selected the appropriate Time Range, WAF Type and WAF Items

2. You should also ensure that you have selected the correct Public IP address for your attacker machine (Kali VM) in the Top 10 Attacking IP Addresses, filter to single IP address pane

• Tip:  If you are using the Azure WAF Attack Testing Lab Environment Deployment Template and have followed the lab setup instructions then the client IP address will be the public IP address of the Azure Firewall in your demo environment

3. After selecting the correct client IP, we scroll back up to the top of the Workbook and review the visualizations at the top, in the WAF Workbook.  Following are the sections of the workbook we will be using as called out in the figure below

a. WAF actions filter

b. Top 40 Blocked Request URI addresses, filter to single URI address

c. Top 50 event trigger, filter by rule name

d. Message, full details

Note:  For a detailed overview of these sections of the WAF workbook, please refer to the Overview of the Workbook Sections in the previous tutorial, Reconnaissance Playbook

4. From the sliced data in the WAF workbook, we can see that two requests to the /api/Feedbacks/ URI were blocked by WAF.  Upon reviewing the Top 50 event trigger, filter by rule name we see all the rules which evaluated the POC XSS payload in the request; the Message, full details section shows that the traffic was blocked by Mandatory rule because the Anomaly Score threshold was exceeded (Total Score: 53, XSS=35) with XSS attack being the closest match
5. The below table shows an extract of the Top 50 event trigger, filter by rule name output for request with the XSS traffic.  This data shows that the WAF evaluated the POC payload in the HTTP request to detect XSS injection and therefore blocked it

Rule	count_
Remote Command Execution: Unix Shell Expression Found	1
XSS Attack Detected via libinjection	1
XSS Filter - Category 4: Javascript URI Vector	1
NoScript XSS InjectionChecker: HTML Injection	1
NoScript XSS InjectionChecker: Attribute Injection	1
IE XSS Filters - Attack Detected.	1
XSS Filter - Category 5: Disallowed HTML Attributes	1
Possible XSS Attack Detected - HTML Tag Handler	1
SQL Injection Attack: SQL Tautology Detected.	1
Detects basic SQL authentication bypass attempts 3/3	1
Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (12)	1

Key Takeaway

Cross Site Scripting (XSS) is one of the most common type of application security vulnerability and an external adversary can easily exploit a vulnerable application to compromise the application and its users to elevate their privileges.

For web applications secured with it, Azure WAF can protect against XSS attacks by detecting and blocking XSS payload at the network edge, with its out of the box ruleset.

Previous: Reconnaissance Playbook

Next: Data Disclosure and Exfiltration Playbook