Detecting vulnerabilities¶
Due to negligence or inadequate information when building or implementing an application, it can be vulnerable to attacks. From this article, you will learn how the Wallarm platform detects application vulnerabilities enabling you to enhance system security.
What is a vulnerability?¶
A vulnerability is an error made due to negligence or inadequate information when building or implementing an application. A vulnerability can be exploited by an attacker to cross privilege boundaries (i.e. perform unauthorized actions) within an application.
Vulnerability detection methods¶
When scanning the application for active vulnerabilities, Wallarm sends requests with attack signs to the protected application address and analyzes application responses. If the response matches one or more pre‑defined vulnerability signs, Wallarm records active vulnerability.
For example: if the response to the request sent to read the /etc/passwd
contents returns the /etc/passwd
contents, protected application is vulnerable to the Path Traversal attacks. Wallarm will record the vulnerability with an appropriate type.
To detect vulnerabilities in the application, Wallarm sends requests with attack signs using the following methods:
-
Passive detection: the vulnerability was found due to the security incident that occurred.
-
Active threat verification: lets you turn attackers into penetration testers and discover possible security issues from their activity as they probe your apps/APIs for vulnerabilities. This module finds possible vulnerabilities by probing application endpoints using real attack data from the traffic. By default this method is disabled.
-
Vulnerability Scanner: company's exposed assets are scanned for typical vulnerabilities.
Passive detection¶
With passive detection, Wallarm detects a vulnerability due to the security incident that occurred. If an application vulnerability has been exploited during an attack, Wallarm records the security incident and the exploited vulnerability.
Passive vulnerability detection is enabled by default.
Active threat verification¶
How it works¶
Based on the initial detected attacks, the Active threat verification module creates a lot of new test requests with different payloads attacking the same endpoint. This mechanism allows Wallarm to detect vulnerabilities that could be potentially exploited during attacks. The process of active threat verification will either confirm that the application is not vulnerable to the specific attack vectors or find actual application security issues.
List of vulnerabilities that can be detected by the module
The Active threat verification process uses the following logic to check the protected application for possible Web and API security vulnerabilities:
-
For every group of malicious request (every attack) detected by a Wallarm filtering node and uploaded to the connected Wallarm Cloud, the system analyzes which specific endpoint (URL, request string parameter, JSON attribute, XML field, etc) was attacked and which specific kind of vulnerability (SQLi, RCE, XSS, etc) the attacker was trying to exploit. For example, let's take a look at the following malicious GET request:
https://example.com/login?token=IyEvYmluL3NoCg&user=UNION SELECT username, password
From the request the system will learn the following details:
- The attacked URL is
https://example.com/login
- The type of used attack is SQLi (according to the
UNION SELECT username, password
payload) - The attacked query string parameter is
user
- Additional piece of information provided in the request is the request string parameter
token=IyEvYmluL3NoCg
(it is probably used by the application to authenticate the user)
- The attacked URL is
-
Using the collected information the Active threat verification module will create a list of about 100-150 test requests to the originally targeted endpoint but with different types of malicious payloads for the same type of attack (like SQLi). For example:
https://example.com/login?token=IyEvYmluL3NoCg&user=1')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+SLEEP(10)--+wlrm https://example.com/login?token=IyEvYmluL3NoCg&user=1);SELECT+PG_SLEEP(10)-- https://example.com/login?token=IyEvYmluL3NoCg&user=1'+OR+SLEEP(10)+AND+'wlrm'='wlrm https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+1=(SELECT+1+FROM+PG_SLEEP(10)) https://example.com/login?token=IyEvYmluL3NoCg&user=%23'%23\x22%0a-sleep(10)%23 https://example.com/login?token=IyEvYmluL3NoCg&user=1';+WAITFOR+DELAY+'0code:10'-- https://example.com/login?token=IyEvYmluL3NoCg&user=1%27%29+OR+SLEEP%280%29+AND+%28%27wlrm%27%3D%27wlrm https://example.com/login?token=IyEvYmluL3NoCg&user=SLEEP(10)/*'XOR(SLEEP(10))OR'|\x22XOR(SLEEP(10))OR\x22*/
Malicious payloads do not harm your resources
Malicious payloads of generated requests do not include real malicious syntax, they are intended just to imitate the attack principle. As a result, they do not harm your resources.
-
The Active threat verification module will send generated test requests to the application bypassing the Wallarm protection (using the allowlisting feature) and verify that the application at the specific endpoint is not vulnerable to the specific attack type. If the module suspects that the application has an actual security vulnerability, it will create an event with type incident.
User-Agent
HTTPS header value in the requestsThe
User-Agent
HTTP header in the Active threat verification module requests will have the valueWallarm Threat-Verification (v1.x)
. -
Detected security incidents are reported in Wallarm Console and are able to be dispatched to your security team via available third-party Integrations and Triggers.
Active threat verification if hits are grouped by IP
If an attack is hits grouped by originating IPs, active verification of this attack is unavailable.
Potential risks from the "Active threat verification" module¶
-
In rare cases when a legitimate request is detected by Wallarm as an attack, the request will be replayed by the Active threat verification module. If the request is not idempotent (for example, an authenticated request creating a new object in the application), then the requests generated by the module for threat verification may create many new unwanted objects in the client account or perform other unexpected operations.
To minimize the risk of the described situation, the Active threat verification module will automatically strip the following HTTP headers from the replayed requests:
Cookie
Authorization: Basic
Viewstate
-
In cases when the application uses a non-standard authentication method or does not require authenticating the requests, the Active threat verification module may replay any request from the traffic and harm the system. For example: repeat 100 and more money transactions or orders. To minimize the risk of the described situation, it is recommended to use testing or staging environments for attack replaying and mask non-standard request authentication parameters.
Configuration¶
The module Active threat verification is disabled by default. It should be enabled and properly configured to work correctly. Please learn the Active threat verification configuration options and best practices for these options setup from this document.
Vulnerability Scanner¶
How it works¶
Vulnerability Scanner checks all company's exposed assets for typical vulnerabilities. Scanner sends requests to application addresses from fixed IP addresses and adds the header X-Wallarm-Scanner-Info
to the requests.
Configuration¶
-
Scanner can be enabled or disabled in Wallarm Console → Vulnerabilities → Configure. By default, Scanner is enabled.
-
The list of vulnerabilities that can be detected by Scanner can be configured in Wallarm Console → Vulnerabilities → Configure. By default, Vulnerability Scanner detects all available vulnerabilities.
-
The limit of requests sent from Scanner can be configured for each asset in Wallarm Console → Scanner → Configure.
-
If the filtering node operates in the
block
mode, it is required to disable blocking of IP addresses from which Scanner sends requests
False positives¶
False positive occurs when attack signs are detected in the legitimate request or when legitimate entity is qualified as a vulnerability. More details on false positives in attack detection →
False positives in vulnerability scanning may occur due to the protected application specificities. Similar responses to similar requests may indicate an active vulnerability in one protected application and be expected behavior of another protected application.
If a false positive for a vulnerability is detected, you can add an appropriate mark to the vulnerability in Wallarm Console. A vulnerability marked as a false positive will be closed and will not be rechecked.
If the detected vulnerability exists in the protected application but cannot be fixed, we recommend setting up the Create a virtual patch rule. This rule will allow blocking attacks exploiting the detected type of vulnerability and will eliminate the risk of an incident.
Managing discovered vulnerabilities¶
All detected vulnerabilities are displayed in the Wallarm Console → Vulnerabilities section. You can manage vulnerabilities through the interface as follows:
-
View and analyze vulnerabilities
-
Run vulnerability status verification: still active or fixed on the application side
-
Close vulnerabilities or mark them as false positives
For more information on managing vulnerabilities, see the instructions on working with vulnerabilities.
Notifications about discovered vulnerabilities¶
Wallarm can send you notifications on discovered vulnerabilities. It allows you to be aware of newly discovered vulnerabilities of your applications and respond to them promptly. Responding to vulnerabilities includes fixing them on the application side, reporting false positives and applying virtual patches.
To configure notifications:
-
Create the native integration with the system to send notifications (e.g. PagerDuty, Opsgenie, Splunk, Slack, Telegram).
-
In the integration card, select the Vulnerabilities detected in the list of available events.
Example of the Splunk notification about detected vulnerability:
{
summary:"[Test message] [Test partner(US)] New vulnerability detected",
description:"Notification type: vuln
New vulnerability was detected in your system.
ID:
Title: Test
Domain: example.com
Path:
Method:
Discovered by:
Parameter:
Type: Info
Threat: Medium
More details: https://us1.my.wallarm.com/object/555
Client: TestCompany
Cloud: US
",
details:{
client_name:"TestCompany",
cloud:"US",
notification_type:"vuln",
vuln_link:"https://us1.my.wallarm.com/object/555",
vuln:{
domain:"example.com",
id:null,
method:null,
parameter:null,
path:null,
title:"Test",
discovered_by:null,
threat:"Medium",
type:"Info"
}
}
}