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:
- 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
- Review the differences in the results of the two web application vulnerability scans
- Review the summarized logs in the WAF Workbook (Azure Monitor Workbook for WAF)
- 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
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
- First scan will point to the target web application directly
- URL: http://owaspdirect-<deployment guid>.azurewebsites.net
- Second scan will point to the same target web application protected by Azure WAF on Application Gateway
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.
- Sign into the Kali Linux VM using your lab credentials
- 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
- 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
- To initiate the scans, utilize the following commands. One in each of the open Nikto windows
- nikto -h http://owaspdirect-<deployment guid>.azurewebsites.net
- nikto -h http://juiceshopthruwaf.com
- 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
- To display verbose output in Nikto, use the following command
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.
- When going to the Juice Shop website directly, we see that the scanner sent 7k+ requests1 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
- While scanning Juice Shop website through the Azure WAF, we see that the scanner made >3x the number of requests1 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
1 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|
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
- 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
- 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
- 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
a.Starting from the top, the WAF actions filter shows the number of matches and the blocked requests
b.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
c.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
|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|
d.Review further details in the Message, full details section
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.