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

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.

 

Recon Scan Route	No. of Issues	No. of Items for Investigation
Direct	2	167
Through WAF	0	3

 

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

 

Rule	count_
Found User-Agent associated with security scanner	8906
Request Missing an Accept Header	8906
GET or HEAD Request with Body Content.	8860
Node-Validator Blacklist Keywords	4553
SQL Injection Attack: Common Injection Testing Detected	3354
Found request filename/argument associated with security scanner	2422
Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link	2418
Possible Remote File Inclusion (RFI) Attack: URL Payload Used w/Trailing Question Mark Character (?)	2355
Detects basic SQL authentication bypass attempts 2/3	2249
Detects MySQL comments, conditions and ch(a)r injections	2233
Path Traversal Attack (/../)	1698
OS File Access Attempt	699
Remote Command Execution: Unix Shell Code Found	682
XSS Attack Detected via libinjection	667
SQL Injection Attack: SQL Tautology Detected.	641
Possible XSS Attack Detected – HTML Tag Handler	616
XSS Filter – Category 1: Script Tag Vector	616
NoScript XSS InjectionChecker: HTML Injection	616
Detects classic SQL injection probings 2/3	455
Invalid character in request (non printable characters)	342
Invalid character in request (null character)	340
SQL Injection Attack	272
Remote Command Execution: Unix Command Injection	199
SQL Comment Sequence Detected.	197
URL file extension is restricted by policy	192
Restricted File Access Attempt	178
SQL Hex Encoding Identified	147
Possible Remote File Inclusion (RFI) Attack: Common RFI Vulnerable Parameter Name used w/URL Payload	136
PHP Injection Attack: High-Risk PHP Function Call Found	128

 

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

 

 

 

 

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.