Part 2 – Reconnaissance Playbook: Azure WAF Security Protection and Detection Lab

by Contributed | Jan 14, 2021 | Technology

This article is contributed. See the original author and article here.

Tutorial: Reconnaissance Playbook

The second tutorial in this four-part series for Azure WAF protection and detection lab is the reconnaissance playbook.  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 reconnaissance 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 web application protection capabilities of Azure WAF against a simulated reconnaissance (recon) attack from common, real-world, publicly available hacking and attack tools.

In this tutorial you will:

1. Run web application vulnerability scan against the target OWASP Juice Shop web application directly and then scan the same instance of the web application published through Azure WAF


2. Review the differences in the results of the two web application vulnerability scans


3. Review the summarized logs in the WAF Workbook (Azure Monitor Workbook for WAF)

Prerequisites

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

Reconnaissance Attack

Before an attacker can exploit a vulnerability, they will typically spend time researching their target web application which involves collecting application specific data and analyzing it for potential vulnerabilities.  One of the methods for collecting sensitive security data to identify potential vulnerabilities in a web application is to utilize web application security vulnerability scanners.  These scanners can analyze an application’s response headers to identify potential vulnerabilities.  Data collected with web application vulnerability scanners can reveal potential vulnerabilities that an attacker could then test, develop, and leverage for exploitation or exfiltration.  Such reconnaissance activities also allow attackers to gain a thorough understanding and complete mapping of your application for later use.

Performing Reconnaissance with Web Application Vulnerability Scanner

One of the first things an attacker will attempt is to try and gain extensive understanding of the application components, framework, and the potential vulnerabilities in a target web application.  The quickest, most common method of doing this is to use a commercial or an open source web application vulnerability scanner (also called security scanners) to run unauthenticated/unauthorized scans against a target.  In this tutorial, you will run two web application vulnerability scans against the target web application

1. First scan will point to the target web application directly




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




2. Second scan will point to the same target web application protected by Azure WAF on Application Gateway




• URL: http://juiceshopthruwaf.com

Running Web Application Vulnerability Scan against the Target Application

To run the web application vulnerability scans, we will connect to the Kali VM with RDP.  Once connected, we will use Nikto, a versatile, command line open source web application vulnerability scanning tool which is bundled in the Kali Linux distro.  When pointed to the target web application, Nikto will scan the application for common vulnerabilities and display the scan output in the terminal window for quick review.

1. Sign into the Kali Linux 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 WAF with URL http://juiceshopthruwaf.com


3. Launch two instances of Nikto Web Vulnerability Scanner.  Click on Applications on the top left and then click Web Application Analysis –> Web Vulnerability Scanners –> Nikto

4. To initiate the scans, utilize the following commands.  One in each of the open Nikto windows
   
   
   
   1. nikto -h http://owaspdirect-<deployment guid>.azurewebsites.net
   
   
   2. nikto -h http://juiceshopthruwaf.com
   
   
   
   

• Tips
  
  
  
  • To display verbose output in Nikto, use the following command
    
    
    
    
    • nikto -h <http://owaspdirect-<deployment guid>.azurewebsites.net> -Display v
    
    
    
    
  
  
  • To save Nikto output to a file to review later, use the following command
    
    
    
    
    • nikto -h <http://owaspdirect-<deployment guid>.azurewebsites.net> -Save ./juiceshopdirect.htm 
    
    
    
    
  
  
  
  

Reviewing Web Application Vulnerability Scan Results

After the scans finish running, we can quickly review the results by looking at the highlighted lines in the figures below.

1. When going to the Juice Shop website directly, we see that the scanner sent 7k+ requests¹ to the web server and as a result found 2 errors and 150+ items/issues which could then be used to develop further attack and exploitation scenarios

Figure 1 (Scan Start)

Figure 2 (Scan End)

! 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

2. While scanning Juice Shop website through the Azure WAF, we see that the scanner made >3x the number of requests¹ when compared to scanning the website directly in Step 1 and still it did not find any errors to report.  Similarly, this scan is only able to report <1% of the number of items/issues for further investigation as compared to when scanning the website directly

¹ Request count for http://owaspdirect-<deployment guid>.azurewebsites.net taken from baseline of scans for comparison

Understanding What Happened

Upon reviewing the Nikto scan outputs, we see the pattern as shown in the below table.  This clearly indicates that when going through the Azure WAF, the scanner is not as effective in assessing the web application and identifying potential vulnerabilities.

Now let us use the Azure Monitor Workbook for WAF to understand how WAF handled traffic from the Nikto security scanner.  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 scan traffic 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 lab.  Once in the workbook, ensure that you have selected the appropriate Time Range, WAF Type and WAF Items in the event filters

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.  The sections of the workbook we will be using here are highlighted with alphabetized callouts in the below figure, we see that they map to the following sections

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

Overview of the Workbook sections

1. Starting from the top, the WAF actions filter shows the number of matches and the blocked requests

2. We can then look at the Top 40 Blocked Request URI addresses, filter to single URI address to identify the top URIs for which requests were blocked by WAF

3. The Top 50 event trigger, filter by rule name shows all the rules which evaluated the scanner traffic

• The below table shows an extract of the Top 50 event trigger, filter by rule name output for scanner traffic.  This data clearly shows that WAF was able to detect the security scanner and blocked suspicious requests/payloads from the Nikto Scanner.  This is expected because a security scanner will attempt to perform various types of operations to test security of the web application

4. Review further details in the Message, full details section

Key Takeaway

Using security scanners to perform web application vulnerability assessment scans to expose vulnerabilities in a target web application is a common technique used by attackers.  When external adversaries can perform these scans against your web applications, they are able to learn about your application design and its vulnerabilities which could potentially lead to exploitation. 

For web applications secured with it, Azure WAF can detect and protect against reconnaissance attacks executed with security scanners at the network edge, with its out of the box ruleset.

Next: Vulnerability Exploitation Playbook

Part 4 – Data Disclosure and Exfiltration Playbook: Azure WAF Security Protection and Detection Lab

by Contributed | Jan 14, 2021 | Technology

This article is contributed. See the original author and article here.

Tutorial: Data Disclosure and Exfiltration Playbook

The last tutorial in this four-part series for Azure WAF protection is the data exfiltration playbook.  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 SQL Injection (SQLi) 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 SQL Injection attack from common, real-world, publicly available hacking and attack tools.

In this tutorial you will:

1. Simulate SQL Injection (SQLi) attack against the target OWASP Juice Shop application directly and then attack the same instance of the web application published 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 ATP testing procedures.
   
   
   
   


2. Completion of the reconnaissance playbook tutorial


3. Completion of the vulnerability exploitation playbook tutorial

Configuring Burp Suite and Firefox

Before you being, please refer to the Configuring Burp Suite and Firefox section in the previous tutorial, Vulnerability Exploitation Playbook to setup Burp Suite and the Firefox web browser on the Kali VM.

Sensitive Data Exposure and Exfiltration

In this phase, the attacker is ready to use a vulnerability they have previously discovered, tested, and developed further to achieve their objective to access and exfiltrate data.  In this playbook, we will perform a SQL Injection attack to disclose and then exfiltrate the list of all user credentials in the OWASP Juice Shop application.

Performing SQL Injection against the Target Web Application

In this tutorial, you will perform a SQL Injection (SQLi) attack against the OWASP Juice Shop application two times. 

1. Scenario 1: Performing SQL injection in the target web application directly


2. Scenario 2: Performing the same injection in the same target web application protected by Azure WAF on Application Gateway

Scenario 1:  Performing SQL Injection when going to the OWASP Juice Shop Application directly

1. Sign into the Kali VM using your lab credentials


2. Launch Burp Suite and ensure you have Burp Suite configured and running as described in the Configuring Burp Suite and Firefox section of the Vulnerability Exploitation Playbook


3. Using Firefox, browse directly to the Juice Shop site by going to http://owaspdirect-<deployment guid>.azurewebsites.net


4. In Burp Suite, check the Proxy –> HTTP history tab for the request and response data for this website


5. In the search bar on the Juice Shop website, type “apple” and examine the request and response in Burp Suite

! 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

6. We see that when searching, the client makes a connection to the /rest/products/search endpoint

7. The /rest/products/search endpoint of the OWASP Juice Shop application is vulnerable to SQL injection.  In this tutorial, we will be exploiting the SQLi vulnerability in this endpoint


8. To exploit the SQLi vulnerability in the /rest/products/search endpoint, we will use Burp Suite’s Repeater functionality to inject a specifically crafted SQL query in the request to this endpoint


9. To do this, right click one of the GET requests to the /rest/products/search endpoint and then click Send to Repeater

Figure 1 – Send Request to Burp Repeater

Figure 2 – Request in Burp Repeater

10. When ready to perform the injection, we will copy/paste and append the following encoded SQL query to the Request URI /rest/products/search?q= (as value to the query parameter) in the Burp Repeater window

a. URL encoded SQL query

%71%77%65%72%74%27%29%29%20%55%4e%49%4f%4e%20%53%45%4c%45%43%54%20%69%64%2c%20%65%6d%61%69%6c%2c%20%70%61%73%73%77%6f%72%64%2c%20%27%34%27%2c%20%27%35%27%2c%20%27%36%27%2c%20%27%37%27%2c%20%27%38%27%2c%20%27%39%27%20%46%52%4f%4d%20%55%73%65%72%73%2d%2d 

b. Plain text SQL query (for reference)

qwert')) UNION SELECT id, email, password, '4', '5', '6', '7', '8', '9' FROM Users-- 

• Tip: You can also append the plain text SQL query to the request URI, but it may fail in certain conditions

11. After appending the encoded query to the request URI, as value to the to the query parameter, click Go (or Send button)

12. You should see a successful response from the OWASP Juice Shop application with details of all the users and their credentials disclosed by the web application.  This indicates that our SQL injection attack was successful

JSON data in the response body

{"status":"success","data":[{"id":1,"name":"admin@juice-sh.op","description":"0192023a7bbd73250516f069df18b500","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":2,"name":"jim@juice-sh.op","description":"e541ca7ecf72b8d1286474fc613e5e45","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":3,"name":"bender@juice-sh.op","description":"0c36e517e3fa95aabf1bbffc6744a4ef","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":4,"name":"bjoern.kimminich@gmail.com","description":"6edd9d726cbdc873c539e41ae8757b8c","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":5,"name":"ciso@juice-sh.op","description":"861917d5fa5f1172f931dc700d81a8fb","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":6,"name":"support@juice-sh.op","description":"d57386e76107100a7d6c2782978b2e7b","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":7,"name":"morty@juice-sh.op","description":"f2f933d0bb0ba057bc8e33b8ebd6d9e8","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":8,"name":"mc.safesearch@juice-sh.op","description":"b03f4b0ba8b458fa0acdc02cdb953bc8","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":9,"name":"J12934@juice-sh.op","description":"3c2abc04e4a6ea8f1327d0aae3714b7d","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":10,"name":"wurstbrot@juice-sh.op","description":"9ad5b0492bbe528583e128d2a8941de4","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":11,"name":"amy@juice-sh.op","description":"030f05e45e30710c3ad3c32f00de0473","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":12,"name":"bjoern@juice-sh.op","description":"7f311911af16fa8f418dd1a3051d6810","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":13,"name":"bjoern@owasp.org","description":"9283f1b2e9669749081963be0462e466","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":14,"name":"chris.pike@juice-sh.op","description":"10a783b9ed19ea1c67c3a27699f0095b","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":15,"name":"accountant@juice-sh.op","description":"963e10f92a70b4b463220cb4c5d636dc","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":16,"name":"uvogin@juice-sh.op","description":"05f92148b4b60f7dacd04cceebb8f1af","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":17,"name":"demo","description":"fe01ce2a7fbac8fafaed7c982a04e229","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":18,"name":"john@juice-sh.op","description":"00479e957b6b42c459ee5746478e4d45","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"},{"id":19,"name":"emma@juice-sh.op","description":"402f1c4a75e316afec5a6ea63147f739","price":"4","deluxePrice":"5","image":"6","createdAt":"7","updatedAt":"8","deletedAt":"9"}]}

• Tip:  Data in the “Description” field in the server response is the password hash of the users which can be reversed using free tools available on the internet

Scenario 2:  Performing SQL Injection when going to the OWASP Juice Shop Application through Azure WAF

You will now attempt to perform SQL Injection with the same query when going to the OWASP Juice Shop site through Azure WAF.

1. On Kali VM, launch a new instance of Burp Suite and the Firefox browser


2. Using Firefox, browse to http://juiceshopthruazwaf.com and check the Proxy –> HTTP history tab for the request and response data for this website in Burp Suite

3. Search for “apple” in the search bar, find the request to the vulnerable /rest/products/search endpoint and send it to the Burp Repeater

Send Request to Burp Repeater

Request in Burp Repeater

4. Append the encoded SQL query (from Step 10 in Scenario 1 above) as value to the query parameter in the Burp Repeater and click Go (or Send)

5. Upon examining the response, we find that the request was blocked by Azure WAF on Application Gateway

Understanding What Happened

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

Now let us use the Azure Monitor Workbook for WAF to understand how the WAF handled traffic with the SQL Injection query.  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 SQL Injection query 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.  Below are the sections of the workbook we will be using as numbered in the below figure

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 prior tutorial, Reconnaissance Playbook

4. From the sliced data in the WAF workbook, we can see that two requests to the /rest/products/search 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 code 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: 43, SQLi=43) with SQL Injection attack being the closest match


5. The below table shows an extract of the Top 50 event trigger, filter by rule name output for scanner traffic.  This data shows that the WAF evaluated the encoded query in the HTTP request to detect that it was a SQL injection attack and therefore blocked it

Key Takeaway

SQL Injection (SQLi) is one of the most common type of application security vulnerability which allows an external adversary to exploit a vulnerable application to disclose and exfiltrate sensitive information in the application.

For web applications secured with it, Azure WAF can protect against SQL Injection (SQLi) attacks by detecting and blocking suspicious SQL queries at the network edge, with its out of the box ruleset.

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

by Contributed | Jan 14, 2021 | Technology

This article is contributed. See the original author and article here.

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

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

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.

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

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.

Next: Data Disclosure and Exfiltration Playbook

Part 1 – Lab Setup: Azure WAF Security Protection and Detection Lab

by Contributed | Jan 14, 2021 | Technology

This article is contributed. See the original author and article here.

Tutorial: Setup an Azure WAF Security Protection and Detection Lab

The purpose of the Azure WAF security protection and detection lab tutorial is to demonstrate Azure Web Application Firewall (WAF) capabilities in identifying, detecting, and protecting against suspicious activities and potential attacks against your Web Applications.  This first tutorial in a four-part series walks you through creating a lab environment for testing against Azure WAF’s protections.  This lab focuses on the OWASP protection ruleset and logging capabilities of Azure WAF.  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.  For more information about each tutorial in this series, refer to the previous section, Tutorial Overview.

In this tutorial you will:

1. Deploy a demo test environment in Azure


2. Deploy Azure Monitor Workbook for WAF


3. Enable desktop environment on Linux VM


4. Create host file entries to resolve host names

Prerequisites

1. An Azure subscription to deploy the Azure WAF Attack Testing Lab Environment Deployment Template
   
   
   
   
   • Do not have an Azure subscription? Create a free account
   
   
   
   


2. A Log Analytics workspace to send all diagnostic logs
   
   
   
   • Azure Monitor Workbook for WAF deployed to the same workspace
   
   
   
   


3. Familiarity with Azure Application Gateway WAF

Deployment Steps

1. Click here to deploy the lab environment to your Azure subscription


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

• Tip:  For more information, refer to the detailed deployment instructions here – Deploying Network security demo environment
  
  
  
  • Please refer to the above document for deployment instructions only and do not use the deployment template linked in it.  The deployment template used in these lab tutorials is different from the one used in the deployment instructions document
  
  
  
  

Recommendations

We recommend using the Azure WAF Attack Testing Lab Environment Deployment Template as it already contains all the components needed for this lab including a customized version of the OWASP Juice Shop application.  The closer your lab is to the suggested lab setup, the easier it will be to follow the Azure WAF testing procedures.  After deployment and minimum configuration steps, you will be ready to perform actions with the suggested hacking research tools and review Azure WAF’s protections against those malicious actions. 

When using the Azure WAF Attack Testing Lab Environment Deployment Template, additional resources such as VMs and Azure Front Door will be deployed.  The below diagram represents resources in the environment which are utilized in this lab.  The resources which are not used in this lab have been grayed out (VMs, Azure Front Door, DDoS Protection).

! IMPORTANT:  This environment will be used as the baseline for the remainder of this document and the tutorial

In this setup, traffic from the attacker machine (Kali VM) will be routed to the internet through the Azure Firewall.  Successful attack path is one where malicious data is sent directly by the attacker to the OWASP Juice Shop web application leading to successful exploitation.  Attack path defended by WAF represents the path where malicious data is inspected by Azure WAF (on Azure Application Gateway) and blocked with its out of the box ruleset before it reaches the web application.

You can also use a preexisting environment for this lab.  For completing these tutorials, your environment must have the following key components:

1. An instance of the customized OWASP Juice Shop web application with an internet accessible endpoint


2. An instance of Application Gateway with Azure WAF which publishes the OWASP Juice Shop web application to the internet


3. An attacker machine (VM) with common hacking tools and internet connectivity.  We use Kali Linux as the attacker VM

If manually deploying the components required for this tutorial, your complete lab setup should look as similar as possible to the following diagram:

Resources

The below table details the resources needed from all resources deployed with the Azure WAF Attack Testing Lab Environment Deployment Template. 

! 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 Environment 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.  

• Tip: As it is a security best practice, we strongly recommend that you change the default lab password after deployment

Configuration

Additional configuration is required on the Kali Linux VM before getting started on the lab exercises.  The Kali VM in this lab environment needs remote desktop environment installed and configured.  Please complete the steps in the order outlined below.

Updating Kali Linux and Installing Desktop Environment

1. Launch PowerShell on your local machine and run the following command to connect to the Kali VM

ssh svradmin@<Public IP Address of Azure Firewall> 

<Type your password when prompted to login>

• Tips:
  
  
  
  • You can find the public IP of Azure Firewall in the Azure Portal under Resource Group –> SOC-NS-FW –> Public IP configuration
  
  
  • You can also use Putty client on your local machine to connect to the Kali VM
  
  
  
  

2. Once connected to the Kali VM with SSH, run the following command to update the Kali Linux distro

sudo apt-get update

<Type your password when prompted>

3. Once the Kali Linux distro is updated, run the following command to install and configure the remote desktop server on the Kali VM

a. sudo apt-get -y install xrdp

b. sudo systemctl enable xrdp

c. echo xfce4-session >~/.xsession

d. sudo service xrdp restart

• Tip:  For more information, refer to the step by step instructions to Install Desktop Environment on Linux VMs – Install and configure Remote Desktop to connect to a Linux VM in Azure 

4. Upon completing the abovementioned steps, you should be able to connect to the Kali VM over RDP on port 33892 

a. Connect to the Kali VM over RDP by using the following IP address and port combination

<Public IP Address of Azure Firewall>:33892 

b. When prompted to choose the setup for the first startup, click to select “Use default config”

c. You can now close your SSH session to the Kali VM by typing “exit” in the SSH session running in PowerShell

5. Create an entry in the HOSTS file on Kali VM to map a name to the Public IP address of the OWASP Juice Shop site published on Application Gateway

a. Launch Terminal and run the following command

sudo nano /etc/hosts

<Type your password when prompted>

b. Create the following entry

c. Save the hosts file and exit

Use Ctrl+S to save and Ctrl+X to exit

• Tip:  You can find public IP of the Application Gateway in the Azure Portal under Resource Group –> SOC-NS-AG-WAFv2 –> Frontend Public IP address

Next Steps

Before proceeding to the next tutorial, take a few mins to review the following

1. OWASP Juice Shop publishing rule on Application Gateway


2. Web Application Firewall configuration on Application Gateway


3. Test connectivity to the OWASP Juice Shop website when accessing the application directly and when going to it through the Application Gateway

• Tip:  You can find the public URL of the deployed Juice Shop app in the Azure Portal under Resource Group –>  owaspdirect-<guid> –> URL

Next: Reconnaissance Playbook