Simulate SQLi – Microsoft Sentinel LAB Series
Managing comprehensive security products and controls can be complicated, requiring a specific skill set and control over the security process. In addition to managing complexity, monitoring the simulation activities, alerts, and results is reflected during the evaluation and testing.
The Microsoft Sentinel LAB series focuses on creating the correct queries, testing and raising alerts, and investigating an incident to identify web application attacks and security issues. With the simplified practice, you can run security tests and simulations and see how Microsoft Sentinel can identify, protect, and investigate an incident. The WebAppSec – Microsoft Sentinel LAB Series – SQLi includes several scenarios:
- SQLi (this post)
- XSS Manipulation
- Cookie Abuse
- URL Jumping
- Remote Command Execution
What is WebAppSec
Web application security or Web AppSec is the idea of building websites to function as expected, even when they are under attack. The concept includes a collection of security controls into a Web application to protect its assets from potentially malicious actions.
Like any other software, Web applications inevitably contain bugs and security issues. Some of these issues constitute vulnerabilities that can be exploited, introducing risks to organizations. Web application security is supposed to protect against such problems.
Web App Security Types
Web security testing aims to find security vulnerabilities in Web applications and their configuration. The primary target is the application layer. Testing the security of a Web application often involves sending different types of input to provoke errors and make the system behave in unexpected ways. These so-called “negative tests” examine whether the system is doing something it isn’t designed to do.
Dynamic Application Security Test (DAST) – This automated application security test is best for internally facing, low-risk applications that comply with regulatory security assessments.
Static Application Security Test (SAST) – This application security approach offers automated and manual testing techniques. It is best for identifying bugs without the need to execute applications in a production environment.
Runtime Application Self-Protection (RASP) – This evolving application security approach encompasses several technological techniques to instrument an application so that attacks can be monitored as they execute and, ideally, blocked in real time.
Penetration Test – This manual application security test is best for critical applications, especially those undergoing significant changes.
Ways to reduce risks
Majority of Web Application Attacks
- SQL Injection
- XSS (Cross-Site Scripting)
- Remote Command Execution
- Path Traversal
- Cookie Abuse
- Session Hijacking
- URL Jumping
- File Guessing attacks
- Web Site Pilfering
More information about risks – OWASP Top Ten Web Application Security Risks | OWASP
The image is from sqreen.com
Web App Security test review
The following non-exhaustive list of features should be reviewed during Web application security testing. Inappropriate implementation of each could result in vulnerabilities, creating severe risk for your organization.
Application and server configuration – Potential defects are related to encryption/cryptographic arrangements, Web server configurations, etc.
Input validation and error handling – SQL injection, cross-site scripting (XSS), and other common injection vulnerabilities result from poor input and output handling.
Authentication and session management – Vulnerabilities are potentially resulting in user impersonation. Credential strength and protection should also be considered.
Authorization – I tested the application’s ability to protect against vertical and horizontal privilege escalations.
Business logic – These are important to most applications that provide business functionality.
Note: Client-side logic. With modern, JavaScript-heavy webpages, in addition to webpages using other types of client-side technologies (e.g., Silverlight, Flash, Java applets), this type of feature is becoming more prevalent.
The Attack & LAB Artifacts
Like the previous lab of initial access, this lab includes many artifacts, such as the attack method, the attack process, the investigation tools, and other artifacts.
The Attack
SQL injection is a web security vulnerability that allows an attacker to interfere with an application’s queries to its database. It generally allows an attacker to view data that they cannot retrieve. This might include data belonging to other users or any other data that the application can access. An attacker can modify or delete this data often, causing persistent changes to the application’s content or behavior.
In some situations, an attacker can escalate an SQL injection attack to compromise the underlying server or other back-end infrastructure or perform a denial-of-service attack.
SQL Injection Scenarios
There are many SQL injection vulnerabilities, attacks, and techniques, which arise in different situations. Some common SQL injection examples include:
- Retrieving hidden data, where you can modify an SQL query to return additional results.
- Subverting application logic, where you can change a query to interfere with the application’s logic.
- UNION attacks, where you can retrieve data from different database tables.
- You are examining the database, where you can extract information about the version and structure of the database.
- Blind SQL injection, where a query you control results are not returned in the application’s responses.
For example, Consider a shopping application that displays products in different categories. When the user clicks on the Gifts category, their browser requests the URL:
https://website.com/products?category=Gift
This causes the application to make an SQL query to retrieve details of the relevant products from the database:
SELECT * FROM products WHERE category = ‘Gifts’ AND released = 1
This SQL query asks the database to return:
all details (*)
from the products table
where the category is Gifts
and released is 1
More information about SQL Injection | OWASP
Microsoft Sentinel & Azure WAF
Microsoft Sentinel can detect, monitor, and investigate any web app attack by having a layer of protection and leveraging the Azure Web Application Firewall or any other third-party WAF. If you’re using Azure WAF, life is easier because some tables have reliable SQL injection data.
The Azure WAF logs are simple, and you can monitor attacks against our web applications by utilizing a genuine-time WAF log. The log is integrated with Azure Monitor to track WAF alerts and monitor trends. In addition, the Application Gateway WAF is integrated with Azure Security Center. Security Center provides a central view of the security state of all your Azure resources.
Once your Application Gateway WAF is operational, you can enable logs to inspect what is happening with each request. Firewall logs give insight into the WAF’s evaluation, matching, and blocking. With Log Analytics, you can examine the data inside the firewall logs to provide even more insights.
The Azure WAF is straightforward because most of the settings are predefined, but there are a big but, the advanced web attack tactics are collected via additional logs. Therefore, you must create a particular query and analytics rules for it.
What does it mean? The web attack can be run via tools like Nikto or directly via the browser – we must detect all of these scenarios.
For example, the AzureDiagnostics table provides a resource type with Application Gateways, and “message” contains SQL injection and other payload parameters. The query on the image below describes a simple way to identify SQL injection from the message, details, and other fields.
The LAB Tools
- Website to check the (in this lab, the website is on Azure web app)
- Burp Suite
- OWASP ZAP tool
- Damn Vulnerable Web Application
- Cross-Site Scripting (XSS) Cheat Sheet – 2021 Edition
Note: for this lab and the real world, you don’t have to use all the tools, but make sure to choose a favorite one
Lab Stages
- Collect WAF logs and others
- Run SQL injection
- Create an Incident rule
- Investigation
Collect WAF logs and others
Each WAF has dedicated logs; if it is Azure WAF, the logs come from the “AzureDiagnostics” table with specific resources. The logs come from the Syslog or CEF from third-party WAF with different tables, fields, and columns. In some situations, you could find yourself with logs that need to encode or prase.
Depending on your WAF system, collect the WAF logs and know which columns provide the message, URL, and web app attack information.
In this lab, we’re using the Azure web app. Hence the logs come from a specific table, the “AppServiceHTTPLogs” table.
Running SQL injection
There are many ways to run web app simulations and attacks, from manual testing with the browser through online tools and specific tools like OWASP ZAP tool and other tools. During the simulation, you can know if your website is secure. Still, you can also know if your Microsoft Sentinel collects and receives the correct logs, provides the information for the investigation and allows you to build an incident.
If you want to check your website manually, you can run the parameters in your browser. The parameters are available on the portswigger site.
But, in this lab, I preferred to run the OWASP ZAP tool with built-in simulations like spider, fizzing, and others. Once I ran the tools against a testing website, the Microsoft Sentinel received information. Of course, most of the actions didn’t succeed, but I’ve got a lot of information to play with it. The OWASP ZAP runs against an Azure web app with a specific website. Therefore Microsoft Sentinel take uses the “AppServiceHTTPLogs” table and all information within. The report includes the tools made for all the actions.
How to attack? one example can be the easy one. Using a simple page, which displays an article with a given ID as the parameter, the attacker may perform a couple of simple tests to determine if the page is vulnerable to SQL Injection attacks. Example URL: http://website.com/items.php?id=2.
Then, it will send the following query to the database: SELECT title, description, body FROM items WHERE ID = 2
The attacker may then try to inject a query that returns ‘false’: http://website.com/items.php?id=2 and 1=2.
Create an Incident rule
Once you drop a simulation to your website, you’re good to go to the next stage, and now is the time to create the incident inside the Microsoft Sentinel analytics rule.
But, just a second, cuz’ before the incident creation, let’s try one of the examples to detect SQL injection or some of the scanning. The query below calls to an external list with all SQL payload and checks if the AppServiceHTTPLogs contain the SQL injection attack parameters within the URL.
This query is excellent for identifying a potential attack and not waiting until the attack succeeds.
let SIPayload = (externaldata(payload:string)
[@”https://raw.githubusercontent.com/eshlomo1/Azure-Sentinel-4-SecOps/master/WebAppsAttack/si-payload-list.txt”
]);
AppServiceHTTPLogs
| where TimeGenerated >= ago(5h)
| where CsHost == “websitee1.azurewebsites.net” // Put your website here
| where CsUriQuery has_any (SIPayload) // Checking payload list within the uri
| summarize SqlInjectionAttempt = count(CsUriQuery) by CsHost, UserAgent, Cookie
| where SqlInjectionAttempt >
Note: you can change the table to any table you need or add more than one.
Once we’ve got the query, you can continue the analytics rule creation based on the following example. Nothing special inside the Microsoft Sentinel analytics rule.
Note: alert enrichment is one of the essential phases in rule creation.
Then, configure the threshold required, and it must be at least with the parameter 1.
Investigation Exercises
The first step in dealing with SQLi exploits is to detect the event and investigate them, and under attack, the following questions are critical:
- When was I attacked?
- Where was I attacked?
- How widespread was the attack?
- Were any files or tables overwritten?
- Who is attacking me, and are others being attacked as well?
- What is the adversary IP address?
- if it was SQL Injection for drop query, insert operation, or other types of injection
SQL Injection can provide analysis via the following artifacts:
- Activities count per time and object
- Error count per time and error
- Outlier count per time and outlier reason
- Violations count per time and violation
- Suspicious error types
- Suspicious object names
The Investigation
The SQli is a direct attack in its first stages. You will probably see many more complex everyday attacks, most likely daily. Please understand, however, that it is essential to understand the concept of an attack before you can properly analyze it. When we tail the logs on Microsoft Sentinel, we can see that the normal and the attack query are recorded.
The IP address “20.101.73.25” in this lab and the OWASP ZAP tool are the attacker IP addresses. This IP might give you some interesting pointers about what you are looking for in a real-life scenario.
Second, the target is another pointer to understand which assets are part of the attack and if it’s an essential assets. You might want to find out if the information is exfiltrated to external storage.
I ran the query below to check if someone scans and fuzzes the website with some tactics. The query checks the count of requests, which asset is part of the game, which method is part of the attack, and the IP address, and you can add the URI to know what is running behind the scene on your website.
We can see the GET requests to the web app containing irrelevant field information. This will show you the attempted attack and might identify a False Positive alert due to, for example, a user typo. It can also lead to an insight into what the attacker was trying to accomplish. Did the attacker have a particular application and vulnerability in mind to perform the attack? How customized or targeted was the attack?
Because this attack didn’t succeed, we don’t have additional information to investigate. Still, in a real-life scenario, when the attacker can continue with the injection, we could see information such as drop query:
$injection[‘inject’]=array(“LIKE”,”– “,”insert”,”update”,”delete”,”drop”,”‘='”);
$querytofire=$query;
$regex=implode(“|”,$injection[‘inject’]); if(preg_match(“/(\b{$regex}\b)/i”,$querytofire,$matche s))
As we can see, we’ve got a lot of requests and attempts but have not succeeded.
Remember, if you’ve got many failed requests and then a successful one, it must be checked because it can be the infiltrate and success injection.
Below is an additional query to check if we’ve got a successful injection.
References
- All the queries are in the following link Azure-Sentinel-4-SecOps/WebAppsAttack.
- What is SQL Injection? (portswigger.net)
