ThreatRadar Feed: Malicious Scanner

Transcription

ThreatRadar Feed: Malicious Scanner
TECHNICAL BRIEF
ThreatRadar Feed:
Malicious Scanner
In This Brief:
Product Overview
Product Overview
About This Feed
About This Feed
Imperva ThreatRadar Reputation
Services
ThreatRadar Community Defense
Background
Supporting Research
Key Findings
Not All Scanner Traffic
is Created Equal
Scanner Traffic in the Wild
Mitigation Technique
Organizations are typically unaware that their web applications are being scanned by
a vulnerability scanner as part of an attacker’s reconnaissance efforts. The threat posed
by vulnerability scanners is serious because they excel at finding web application
vulnerabilities, and are relatively easy to acquire. When organizations are not defending
against vulnerability scanners, they are simply left to defend against the attacks once
they are levied.
Imperva’s Malicious Scanner IP feed allows organizations to filter out unwanted scanner
traffic as a precautionary step. Further, by blocking all traffic from sources known to be
abusing these scanners, an organization can preemptively block attacks.
The Malicious Scanner IP feed is developed from attack data that is crowd-sourced from
Imperva’s ThreatRadar Community Defense participants (see more about Imperva’s
ThreatRadar Reputation Services below), and then analyzed by the Imperva Application
Defense Center (ADC). The resulting reputation feed is used by organizations to block
IP addresses known to be scanning multiple websites for vulnerabilities.
Imperva ThreatRadar Reputation Services
Hackers are becoming more industrialized and well resourced. Sophisticated criminals
are leveraging networks of remotely-controlled computers, or bots, to launch large-scale
automated attacks. Stopping automated attacks requires identifying users—typically
bots—that are actively attacking other websites.
ThreatRadar Reputation Services provide an automated defense against automated
attacks by instantly detecting and stopping known malicious sources. As an add-on
service to the SecureSphere Web Application Firewall (WAF), ThreatRadar detects
web traffic originating from bots attacking other websites, from anonymizing services,
and from undesirable geographic locations. Up-to-date lists of phishing sites enable
SecureSphere to detect compromised users and fraudulent file requests.
ThreatRadar Community Defense
ThreatRadar Community Defense, an industry-leading innovation for ThreatRadar Reputation Services, delivers crowdsourced threat intelligence to SecureSphere Web Application Firewalls. Community Defense gathers attack data from
SecureSphere WAF deployments around the world and translates this data into attack patterns, policies, and reputation
feeds. Crowd-sourced security content is distributed in near-real time to fortify the entire community against emerging
threats. ThreatRadar Community Defense demonstrates the positive network effect of sharing attack data, a new threat
reported from one company could protect hundreds of web applications that are being protected by SecureSphere.
While ThreatRadar Reputation Services relies on security information from leading external security providers, Community
Defense draws on live attacks detected by SecureSphere Web Application Firewalls. Together, they provide the most
comprehensive protection on the market.
Figure 1.
Background
According to OWASP, web application vulnerability scanners are “…automated tools that scan web applications to look
for known security vulnerabilities such as cross-site scripting, SQL injection, command execution, directory traversal and
insecure server configuration.“ 1 In the context of a web application attack, these scanners are used in the reconnaissance
phase before an attack.
A scanner maps a web application in order to find its vulnerabilities. It uses “legitimate looking” browsing to scan the
application, and real attack vectors to find its vulnerabilities. Figure 2 shows the application structure produced by an
Acunetix scanner.2
OWASP “Vulnerability Scanning Tools”
www.acunetix.com
1
2
2
Figure 2. Acunetix Web application Structure Example
Supporting Research
Key Findings
1. Vulnerability scanners are widely used in web application attacks, and the patterns of scanner attacks
are highly diverse.
2. Attack prevention mechanisms tailored to specific scanner behavior might not match that of other
scanners; a broader perspective is required in order to block malicious scanner traffic.
3. During our research, we uncovered that small percentage of attack sources generated highly persistent
scanner traffic. Sharing the source IP information of the population producing malicious scanner traffic
among a community of web application members can help block malicious scanner traffic.
Not All Scanner Traffic is Created Equal
We first investigated the ratio between legitimate-looking and malicious scanner traffic. We chose Netsparker and
Acunetix scanners, ran them against sample web applications and analyzed their scanning traffic. Figure 3 shows
an example of a Netsparker scan.
3
Figure 3. Netsparkers Scan
Figure 4 shows Netsparker and Acunetix traffic breakdown: legitimate-looking versus malicious traffic.
Figure 4. Netsparker and Acunetix: Normal versus Malicious Traffic
Figure 4 shows that 17% of Netsparker traffic can be classified as legitimate-looking traffic compared to 87% of Acunetix.
This finding has a few implications. First, it means that both scanners include legitimate-looking browsing traffic that
cannot be detected by attack prevention mechanisms. Second, in cases where a web application has defense mechanisms
that block malicious scanner traffic, some scanners like Acunetix will still consume a lot of the web application resources.
Finally, there is a notable difference in the breakdown of the scanner traffic. This finding indicates that defense mechanisms
tailored to specific scanner behavior might not match other scanners. A broader perspective is required in order to block
malicious scanner traffic.
4
Scanner Traffic in the Wild
We analyzed data from attacks that leveraged malicious scanners over a week-long period. There were a total of 24,803 events.
Figure 5. Scanner Distribution
Note that this traffic is only a product of what defense mechanisms were able to detect, as discussed above. This analysis
shows to what extent the scanners are used maliciously, and the high diversity of the tools.
Figure 6 shows an “Attack-Source Reputation Quadrant” graph. The Y-axis represents the number of web applications that
were attacked, and the X-axis represents the duration of an attack. Each dot in the graph represents an attack source and
corresponds to the source’s longevity and the number of web applications it has attacked during the course of our analysis.
Figure 6. Attack Source Reputation Quadrant
5
To express the “Attack-Source Reputation Quadrant” as a graph we added two more divisions. The first is a vertical line
along the Y-axis which separates attack sources that were active for a single day or less, from those active for more than
a single day. The second is a horizontal line which similarly isolates sources that attacked only a single target from those
that attacked multiple targets.
This produces four quadrants:
1. The upper left quadrant (in purple) includes all attack sources that were active for only one day and attacked more
than one target.
2. The lower left corner (in yellow) includes all attack sources that were active for only one day and attacked only a
single target.
3. The upper right quadrant (in blue) includes all attack sources that were active for more than one day and attacked
more than one target.
4. The lower right quadrant (in green) includes all attack sources that were active for more than one day and attacked
only a single target.
To quantify the data, we enhanced the “Attack-Source Reputation Quadrant” with two pie-charts (color-coded to the
quadrants, respectively):
▪▪ The left pie chart represents the number of attacks each attack source generated.
▪▪ The right pie chart represents the number of attack sources within each quadrant.
Figure 7.
As Figure 7 shows, 8% of the attack sources generated scanner traffic that targeted multiple sources for more than a day.
This part of the population produced 16% of the scanner traffic. Sharing this information among a community of web
application members can help block malicious scanner traffic. Under the assumption that a large part of the scanner
traffic is not visible because scanners have legitimate-looking browsing traffic (as noted above), we conclude that even
a larger percentage of the scanner traffic can be blocked.
Figure 8 visually shows the relationship between attackers (source IPs in red) and targets (web applications in green):
some attackers scan multiple targets, while some targets are scanned by multiple attackers.
6
Figure 8. Attackers and Targets
In order to have a more quantitative estimation we created Figure 9 which focuses on one target that was heavily attacked
by various scanners. This target experienced 8,159 alerts during one week; they originated from 147 source IPs using five
different tools.
Figure 9. Source IP Percent of Traffic
There were two dominant IPs: the first one is an Iraqi IP that produced 27% of the alerts in fewer than five minutes;
all the alerts were identified as an Acunetix scanner. It appears to scan the application in order to find its vulnerabilities.
The second is a Moldavian IP that produced 16% of the alerts during half an hour. The scanner used was SQLMap and
most of the requests were made to the same URL with different SQL injection strings. This shows, once again, that
scanners are widely used and the patterns of scanner attacks are highly diverse.
7
Mitigation Technique
Imperva offers a new approach to prevent malicious scanners from accessing web applications: block the source IPs
that were identified as having produced malicious scanner traffic. We rely on a community of web applications that share
scanner traffic, and this feed is updated automatically on a daily basis. With this approach, both the legitimate-looking and
malicious scanner traffic is blocked before accessing the web application.
This method has two main advantages. First, we block legitimate-looking traffic produced by scanners that contributed to
a significant percentage of the scanner activity. Second, we reduce the amount of attack traffic produced by scanners and
block zero-day attacks launched by attackers.
About Imperva
Imperva, pioneering the third pillar of enterprise security, fills the gaps in endpoint and network security by directly
protecting high-value applications and data assets in physical and virtual data centers. With an integrated security
platform built specifically for modern threats, Imperva data center security provides the visibility and control needed to
neutralize attack, theft, and fraud from inside and outside the organization, mitigate risk, and streamline compliance.
www.imperva.com
© Copyright 2014, Imperva
All rights reserved. Imperva and SecureSphere are registered trademarks of Imperva.
All other brand or product names are trademarks or registered trademarks of their respective holders. ThreatRadar-Feed-Malicious-Scanner-0414.1