Conference PaperPDF Available

Never Trust Your Victim: Weaponizing Vulnerabilities in Security Scanners


Abstract and Figures

The first step of every attack is reconnaissance, i.e., to acquire information about the target. A common belief is that there is almost no risk in scanning a target from a remote location. In this paper we falsify this belief by showing that scanners are exposed to the same risks as their targets. Our methodology is based on a novel attacker model where the scan author becomes the victim of a counter-strike. We developed a working prototype, called RevOK, and we applied it to 78 scanning systems. Out of them, 36 were found vulnerable to XSS. Remarkably, RevOK also found a severe vulnerability in Metasploit Pro, a mainstream penetration testing tool.
Content may be subject to copyright.
Never Trust Your Victim: Weaponizing Vulnerabilities in Security Scanners
Andrea Valenza
University of Genova
Gabriele Costa
IMT School for Advanced Studies Lucca
Alessandro Armando
University of Genova
The first step of every attack is reconnaissance, i.e., to ac-
quire information about the target. A common belief is that
there is almost no risk in scanning a target from a remote
location. In this paper we falsify this belief by showing that
scanners are exposed to the same risks as their targets. Our
methodology is based on a novel attacker model where the
scan author becomes the victim of a counter-strike. We devel-
oped a working prototype, called RevOK, and we applied it to
78 scanning systems. Out of them, 36 were found vulnerable
to XSS. Remarkably, RevOK also found a severe vulnerability
in Metasploit Pro, a mainstream penetration testing tool.
1 Introduction
Performing a network scan of a target system is a surpris-
ingly frequent operation. There can be several agents behind
a scan, e.g., attackers that gather technical information, pen-
etration testers searching for vulnerabilities, Internet users
checking a suspicious address. Often, when the motivations
of the scan author are unknown, it is perceived by the target
as a hostile operation. However, scanning is so frequent that it
is largely tolerated by the target. Even from the perspective of
the scanning agent, starting a scan seems not risky. Although
not completely stealthy, an attacker can be reasonably sure
to remain anonymous by adopting basic precautions, such as
proxies, virtual private networks and onion routing.
Yet, expecting an acquiescent scan target is a mere assump-
tion. The scanning system may receive poisoned responses
aiming to trigger vulnerabilities in the scanning host. Since
most scanning systems generate an HTML report, scan au-
thors can be exposed to attacks via their browser. This occurs
when the scanning system permits an unsanitized flow of in-
formation from the response to the user browser. To illustrate,
consider the following, minimal HTTP response.
HT TP / 1. 1 20 0 OK
S er ve r : ng i nx /1 .1 7 .0
. . .
A naive scanning system might extract the value of the
field (namely, the string
in the above
example) and include it in the HTML report. This implicitly
allows the scan target to access the scan author’s browser and
inject malicious payloads.
In this paper we investigate this attack scenario. We start
by defining an attacker model that precisely characterizes
the threats informally introduced above. To the best of our
knowledge, this is the first time that such an attacker model is
defined in literature. Inspired by the attacker model, we de-
fine an effective methodology to discover cross-site scripting
(XSS) vulnerabilities in the scanning systems and we imple-
ment a working prototype. We applied our prototype to 78
real-world scanning systems. The results confirm our expec-
tation: several (36) scanning systems convey attacks. All of
these vulnerabilities have been notified through a responsible
disclosure process.
The most remarkable outcome of our activity is possibly
an XSS vulnerability enabling remote code execution (RCE)
in Rapid7 Metasploit Pro. We show that the attack leads to
the complete takeover of the scanning host. Our notification
prompted Rapid7 to undertake a wider assessment of their
products based on our attacker model.
The main contributions of this paper are:
1. a novel attacker model affecting scanning systems;
a testing methodology for finding vulnerabilities in scan-
ning systems;
RevOK, a prototype implementation of our testing
an analysis of the experimental results on 78 real-world
scanning systems, and;
three application scenarios highlighting the impact of
our attacker model.
This paper is structured as follows. Section 2recalls some
preliminary notions. Section 3presents our attacker model.
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 17
Figure 1: Abstract architecture of a scanning system.
We introduce our methodology in Section 4. Our prototype
and experimental results are given in Section 5. Then, we
present the three use cases in Section 6, while we survey on
the related literature in Section 7. Finally, Section 8concludes
the paper.
2 Background
In this section we recall some preliminary notions necessary
to correctly understand our methodology.
2.1 Scanning systems
A scanning system is a piece of software that
a target through network requests,
collects the responses,
compiles a report. Security analysts often use scan-
ning systems for technical information gathering [8]. Scan-
ning systems used for this purpose are called security scan-
ners. Our definition encompasses a wide range of systems,
from complex vulnerability scanners to simple ping utilities.
Figure 1shows the key actors involved in a scan process.
Human analysts use a user agent, e.g., a web browser, to select
a target, possibly setting some parameters, and start the scan
(1. start). Then, the scanning system crafts and sends request
messages to the target (2. request). The scanning system
parses the received response messages (3. response), extracts
the relevant information and provides the analyst with the
scan result (4. report). Finally, the analysts inspect the report
via their user agent.
Whenever a scanning system runs on a separate, remote
scanning host, we say that it is provided as-a-service. Instead,
when the scanner and scanning hosts coincide, we say that
the scanning system is on-premise.
A popular, command line scanning system is Nmap [25].
To start a scan, the analyst runs a command from the command
line, such as
nmap -sV -oX report.xml
Then, Nmap scans the target (
) with requests
aimed at identifying its active services (
). By default,
Nmap sends requests to 1,000 frequently used TCP ports and
collects responses from the services running on the target.
The result of the scan is then saved (
) on
Interestingly, some web applications, e.g., Nmap Online [15],
provide the functionalities of Nmap as-a-service.
Scanning systems are often components of larger, more
complex systems, sometimes providing a browser-based GUI.
For instance, Rapid7 Metasploit Pro is a full-fledged pen-
etration testing software. Among its many functionalities,
Metasploit Pro also performs automated information gath-
ering, even including vulnerability scanning. The reporting
system of Metasploit Pro is based on an interactive Web UI
used to browse the report.
2.2 Taint analysis
Taint analysis [26] refers to the techniques used to detect
how the information flows within a program. Programs read
inputs from some sources, e.g., files, and write outputs to some
destinations, e.g., network connections. For instance, taint
analysis is used to understand whether an attacker can force a
program to generate undesired/illegal outputs by manipulating
some of its inputs. A tainted flow occurs when (part of) the
input provided by the attacker is included in the (tainted)
output of the program. In this way, the attacker controls the
tainted output which can be used to inject malicious payloads
to the output recipient.
2.3 Cross-site scripting
Cross-site scripting (XSS) is a major attack vector for the
web, stably in the OWASP Top 10 vulnerabilities [12] since
its initial release in 2003. Briefly, an XSS attack occurs when
the attacker injects a third-party web page with an executable
script, e.g., a JavaScript fragment. The script is then executed
by the victim’s browser. The simplest payload for showing
that a web application suffers from an XSS vulnerability is
that causes the browser to display an alert window. This pay-
load is often used as a proof-of-concept (PoC) to safely prove
the existence of an XSS vulnerability.
There are several variants to XSS. Among them, stored
XSS has highly disruptive potential. An attacker can exploit a
stored XSS on a vulnerable web application to permanently
save the malicious payload on the server. In this way, the
attack is directly conveyed by the server that delivers the in-
jected web page to all of its clients. Another variant is blind
XSS, in which the attacker cannot observe the injected page.
For this reason, blind XSS relies on a few payloads, each
adapting to multiple HTML contexts. These payloads are
called polyglots. A remarkable example is the polyglot pre-
sented in [11] which adapts to at least 26 different contexts.
3 Attacker model
The idea behind our attacker model is sketched in Figure 2
(bottom), where we compare it with a traditional web secu-
rity attacker model (top). Typically, attackers use a security
scanner to gather technical information about a target appli-
cation. If the application suffers from some vulnerabilities,
18 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
Figure 2: Comparison between attacker models.
attackers can exploit them to deliver an attack towards their
victims, e.g., the application users. On the contrary, in our
attacker model attackers use malicious applications to attack
the author of a scan, e.g., a security analyst.
Here are the two novelties of our attacker model.
Attacks are delivered through HTTP responses instead
of requests.
Attackers exploit the vulnerabilities of scanning systems
to strike their victims, i.e., the scan initiator.
Below, we detail the attacker’s goal and capabilities.
Attacker goal.
The objective of the attacker is to directly
strike the analyst. To do so, the attacker exploits the vulnera-
bilities of the target scanning system and its reporting system
to hit the analyst user agent. In this work, we assume that the
user agent is a web browser. This assumption covers every
as-a-service scanning system, as well as many on-premise
ones, which generate HTML reports. As a consequence, here
we focus on XSS which is a major attack vector for web
browsers. As usual in XSS, the attacker succeeds when the
victim’s browser executes a piece of attacker-provided code,
e.g., JavaScript.
Attacker capabilities.
First, we state that the attacker has
adequate resources to detect vulnerabilities in scanning sys-
tems before deploying the malicious application. However,
the attacker capabilities do not include the possibility of ob-
serving the internal logic of the scanning system. That is, our
attacker operates in black-box mode.
Secondly, our attacker has complete control over the ma-
licious application, e.g., the attacker owns the scanned host.
However, we do not assume that the attacker can force the
victim to initiate the scanning process.
4 Testing methodology
In this section, we define a vulnerability detection methodol-
ogy based on our attacker model.
Figure 3: Phase 1 – find tainted flows.
4.1 Test execution environment
Our methodology relies on a test execution environment (TEE)
to automatically detect vulnerabilities in scanning systems. In
particular, a test driver simulates the user agent of the security
analyst, while a test stub simulates the scanned application.
Our TEE can
start a new scan,
receives the requests
of the scanning system,
craft the responses of the target
application, and
access the report of the scanning system.
Intuitively, the TEE replicates the configuration of Figure 1.
In this configuration, the test driver is executed by the scanner
host, and the test stub runs on the scanned host. In general, the
test driver is customized for each scanning system under test-
ing. For instance, it may consist of a Selenium-enabled [14]
browser stimulating the web UI of the scanning system.
Both the test driver and the test stub consist of some sub-
modules. These submodules are responsible for implementing
the two phases described below.
4.2 Phase 1: tainted flows enumeration
The first phase aims at detecting the existing tainted destina-
tions in the report generated by the scanning system. Having
a characterization of the tainted flows is crucial to deal with
the input transformation logic of the target scanning system.
In general, since payloads may be arbitrarily modified before
being displayed in the report, detecting actual injections is
non-trivial. Instead, through this phase, injections can be de-
tected just by monitoring tainted destinations. The process is
depicted in Figure 3. Initially, the test driver asks the scanning
system to perform a scan of the test stub. The scan logic is
not exposed by the scanning system and, thus, it is opaque
from our perspective. Nevertheless, it generates some requests
toward the test stub. Each request is received by the scan fron-
tend and dispatched to the response generator, which crafts
the response.
The response generation process requires special attention.
One might think that a single, general-purpose response is
sufficient. However, some scanning systems process the re-
sponses in non-trivial ways. For instance, they may abort
the scan if a malformed or suspicious response is received.
For this reason, we proceed as follows. First, we generate a
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 19
response template, i.e., an HTTP response containing vari-
ables, denoted by
. Response templates are generated from a
fuzzer through a probabilistic context-free grammar (PCFG).
A PCFG is a tuple
, where
G= (N,Σ,R,S)
is a
context-free grammar such that
is the set of non-terminal
is the set of terminal symbols,
are the production
rules and
is the starting symbol. The additional component
of the PCFG, namely
, associates each rule in
with a probability, i.e., the probability to be selected by the
fuzzer generating a string of
. Additionally, we require that
is a probability distribution over each non-terminal
, in
P(α7→β) = 1
In the following, we write
P(α7→ β) = p
α7→p1β1|p2. . . |pnβn
(where "" is the empty string).
The probability values appearing in our PCFG are assigned
according to the results presented in [20,21]. There, the au-
thors provide a statistical analysis of the frequency of real
response headers as well as a list of information-revealing
ones. Such headers are thus likely to be reported by a scanning
system. Finally, when the frequency of a field is not given
(e.g., for variables), we apply the uniform distribution.
An excerpt of our PCFG is given in Figure 4. For the sake of
presentation, here we omit some of the rules and we refer the
interested reader to the project web site
. The grammar defines
the structure of a generic HTTP response (
) made of a
version (
), a status (
), a list of headers (
), and
a body (
). Variables
are all fresh and they can appear in
several parts of the generated response template. In particular,
variables can be located in status messages (i.e.,
), header fields (i.e.,
) and
body. For instance, a field can be
Server: nginx/t
, where
nginx/ is a server type (SrvT, omitted for brevity).
The response template is then populated by replacing each
variable with a token. A token is a unique sequence of char-
acters that is both recognizable, i.e., it has a negligible prob-
ability of appearing by chance, and uninterpreted, i.e., the
browser treats it as plain text, when appearing in an HTML
document. All tokens are mapped to the responses containing
them. Responses are stored in a database. Finally, the test
driver matches the tokens appearing in the responses database
with those occurring in the scan report. Such tokens are evi-
dence that there are tainted flows in the internal logic of the
scanning system. Tokens mark the source and the sink of a
flow in the response and report, respectively. All these tokens
are stored in the tainted tokens database.
Resp 7→1Vers Stat Head Body
Vers 7→0.5" HT T P /1 . 0" |0.5" H TT P / 1. 1 "
Stat 7→0.554 Succ |0.427 Redr |0.013 ClEr |0.006 SvEr
Succ 7→0.5"2 0 0 OK " | 0.5"200" t
Redr 7→0.386 "3 01 M ov ed P er m an e nt l y " | 0.386 "301" t
|0.114 "3 0 2 Fou n d " | 0.114 "302" t
ClEr 7→0.26 "403 Forbidden" |0.26 "403" t
|0.24 "4 0 4 N o t Fou n d " | 0.24 "404" t
SvEr 7→0.5"5 00 I nt er na l Se rv er Er ro r " |0.5"500" t
Head 7→1Serv PwBy Locn SetC CntT AspV MvcV Varn
Serv 7→0.475 " Se r ve r : " t|0.475 " Se rv e r :" Sr v T t
PwBy 7→0.24 "X - P o we r ed -B y : php "
|0.24 "X - P o we r ed -B y :" t
Locn 7→0.315 " Lo c at i on : " Lin k |0.315 " Location:" t
Link 7→0.516 " ht t ps : / /" t
|0.167 "http ://" t":8899"
|0.135 "http ://" t":8090"
|0.065 "http ://" t"/ l og i n . l p "
|0.059 "/ n o co o k ie s . h tm l "
|0.058 " c oo k ie c h ec k e r ? ur i = /"
SetC 7→0.175 " Se t - C o o k ie : " Cki e
Ckie 7→0.471 "__cfduid =" t|0.394 "PHPSESSID=" t
|0.087 " AS P . NE T Se s si o n = " t
|0.048 "JSESSIONID =" t
CntT 7→0.07 "X - C on te n t - Ty pe - O p ti on s : no sn i ff "
|0.07 "X - C o nt e nt -T yp e - O p ti o n s :" t
AspV 7→0.5"X - A s pN e t - V e r si o n : " t
MvcV 7→0.5"X - A s p Ne t Mv c - V e r si o n : " t
Varn 7→0.5"X - V a r ni s h : " t
StTS 7→0.5" St ri c t - T r an s po r t - S e cu r i ty : " STS A
STSA 7→0.111 " ma x - a g e = " N+
|0.111 " ma x - a g e = " t
|0.111 " ma x - a g e = " N+" ; p r el o ad "
|0.111 " ma x - a g e = " t"; p re lo a d "
Figure 4: Response template grammar (excerpt).
4.3 Phase 2: vulnerable flows identification
The second phase aims to confirm which tainted flows are
actually vulnerable. We use PoC exploits to confirm the vul-
nerability. The workflow is depicted in Figure 5. As for the
first phase, the test driver launches a scan of the test stub.
When the test stub receives the requests, the exploit builder
extracts a response from the responses database. Then, the
response is injected with a PoC exploit. More precisely, a
tainted token is selected among those generated during Phase
1. The tainted token in the response is replaced with a payload
taken from a predefined injection payload database. In gen-
eral, a vulnerability is confirmed by the test driver according
to predefined, exploit-dependent heuristics. Although tainted
flows can be subject to different types of vulnerabilities, as
discussed in Section 3, we focus on XSS. Thus, the heuristics
implemented by the exploit checker consists of recognizing
a vulnerable flow when an alert window is spawned by the
corresponding, tainted flow. Finally, the exploit checker stores
the vulnerable flows in the confirmed vulnerabilities database.
The definition of injection payload is non-trivial. Since our
20 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
Figure 5: Phase 2 – find vulnerable flows.
TEE applies to both on-premise and as-a-service scanning
systems, some issues must be considered. The first issue is
testing performances. As a matter of fact, scanning systems
can take a considerable amount of time to perform a single
scan. Moreover, as-a-service scanning systems should not
be flooded by requests to avoid degradation of the quality
of service. For these reasons, we aim to limit the number of
payloads to check.
As discussed in Section 2.3, polyglots allow us to test mul-
tiple contexts with a single payload. In this way, we increase
the success probability of each payload and, thus, we reduce
the overall number of tests.
In principle, we might resort to the polyglot of [11], which
escapes 26 contexts. However, its length (144 characters)
is not adequate since many scanning systems shorten long
strings when compiling their reports, so preventing the ex-
ploit from taking place. To avoid this issue, we opted for poly-
glots such as
"’/><img src=’x’ onerror=’alert(1)’/>
This is rendered by the browser when appearing inside both
an HTML tag and an HTML attribute. The reason is that
the initial
allow the payload to escape from quoted
Furthermore, delivering the JavaScript payload in
has two advantages. First, it circumvents basic input filtering
methods, e.g., blacklisting of the
string. Secondly,
our payload applies to both static and dynamic reports. More
precisely, a static report consists of HTML pages that are
created by the scanning system and subsequently loaded by
the analyst’s browser. Instead, a dynamic report is loaded
by the browser and updated by the scanning system during
the scan process. The HTML5 standard specification [16,
§ 8.4.3] clearly states that browsers can skip the execution of
dynamically loaded scripts. For this reason, our payload binds
the script execution to an error event that we trigger using
a broken image link (i.e.,
). A concrete example of
this scenario is discussed in Section 6.2.
5 Implementation and results
In this section, we present our prototype RevOK. We used it
to carry out an experimental assessment that we discuss in
Section 5.3.
5.1 RevOK
Our prototype consists of two modules: the test driver and the
test stub. We detail them below.
Test driver
A dedicated test driver is used for each scanning
system. The test driver
triggers a scan against the test stub,
saves the report in HTML format and
processes the
report to detect tainted and vulnerable flows (in Phase 1 and
2, respectively). While
is the same for all the scanning
systems, (i)and (ii)may vary.
In general, the implementation of
belongs to
two categories depending on whether the scanning system
has a programmable interface or only a GUI. When a pro-
grammable interface is available, we implement a Python 3
client application. For instance, we use the native os Python
module to launch Nmap so that its report is saved in a spe-
cific location (as describe in Section 2). Similarly, we use the
requests Python library
to invoke the REST APIs provided
by a scanning system and save the returned HTML report.
Instead, when the scanning system only supports GUI-based
interactions, we resort to GUI automation. In particular, we
use the Selenium Python library
for browser-based GUIs and
for desktop GUIs. In the case of GUI automa-
tion, the test driver repeats a sequence of operations recorded
during a manual test.
Finally, for the report processing step
we distinguish
between two operations. The tainted flow detection trivially
searches the report for the injected tokens provided by the
response generator (see below). Instead, vulnerable flows are
confirmed by checking the presence of alert windows through
the Selenium function switch_to_alert().
Test stub
For the response generator, we implemented
the PCFG grammar fuzzer detailed in Section 4.2 in
Python. Tokens are represented by randomly-generated Uni-
versally Unique Identifiers [22] (UUID). A UUID con-
sists of 32 hexadecimal characters organized in 5 groups
that are separated by the
symbol. An example UUID is
. As required
in Section 4.2, UUIDs are both recognizable (as collisions
are extremely unlikely to happen) and uninterpreted (as they
contain no HTML special characters).
On the other hand, starting from a response, the exploit
builder replaces a given UUID with an injection payload.
Payloads are taken for a predefined list of selected polyglots,
as discussed in Section 4.3.
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 21
5.2 Selection criteria
We applied our prototype implementation to 78 scanning
systems. The full list of scanning systems, together with our
experimental results (see Section 5.3), is given in Table 1.
There, we use
to distinguish between as-a-service
and on-premise scanning systems, respectively.
For our experiments, we searched for scanning systems
included in several categories. In particular, we considered
security scanners, server fingerprinting tools, search engine
optimization (SEO) tools, redirect checkers, and more. From
these, we removed scanning systems belonging to the follow-
ing categories.
Abandonware, i.e., on-premise scanning systems that
were not maintained in the last 5 years.
Paywalled, i.e., scanning systems that are not free and
have no trial version.
Scheduled, i.e., as-a-service scanning systems that only
perform periodic scans, not controlled by the analyst.
5.3 Results
We applied RevOK to the scanning systems of Table 1. For
each scanning system, we used RevOK to execute 10 scan
rounds (see Section 4) and we listed all the detected tainted
and vulnerable flows. As a result, we discovered that 67 scan-
ning systems have tainted flows and, among them, 36 are
vulnerable to XSS.
In Table 1, for each scanning system we report the number
of tainted and vulnerable flows (
, respectively) de-
tected by RevOK. After running RevOK, we also conducted
a manual vulnerability assessment of each scanning system.
The assessment consisted of a review of each tainted flow,
followed by a manual payload generation (see below).
Under column
indicates that an XSS vulnerability
was found by a human analyst starting from the outcome
of RevOK. It is worth noticing that only in one case, i.e.,
DupliChecker, RevOK resulted in a false negative w.r.t. the
manual analysis. By investigating the causes, we discovered
that DupliChecker performs URL encoding on the tainted
locations. This encoding, among other operations, replaces
white spaces with
, thus invalidating our payloads. To
effectively bypass URL encoding, we replaced white spaces
(U+0020) with non-breaking spaces (U+00A0) that are not
modified. Thus, we defined a new polyglot payload that uses
non-breaking spaces and we added it to the injection list
included in RevOK. Using this new payload, RevOK could
also detect the vulnerability in DupliChecker.
At the time of writing, all the vulnerabilities detected by
RevOK have been reported to the tool vendors and are under-
going a responsible disclosure process (see Appendix A).
In Figure 6we show the frequency of the tainted and vulner-
able flows over the 14 fields considered by RevOK. Location
60 Vulnerable
Figure 6: Frequency of tainted and vulnerable flows.
Figure 7: Correlation between tainted fields.
has 59 tainted flows, the highest number, and 21 vulnerable
flows. Server only has 51 tainted flows, but it has 26 vul-
nerable flows, the highest number. On the other hand, Body
has only 14 tainted flows and only 1 vulnerable flow. This
highlights that most scanning systems sanitize the Body field
in their reports. The reason is that HTTP responses most
likely contain HTML code in their Body. Thus, sanitization is
mandatory to preserve the report layout. Also, the Body field
is often omitted by the considered scanning systems.
In Figure 7and Figure 8we show the correlation matrices
for tainted and vulnerable fields, respectively. From these
matrices we observe a few, relevant facts. We briefly discuss
them below.
The first observation is that the Body field is almost unre-
lated to the other fields, both in terms of tainted and vulnerable
flows. This is somehow expected since the Body field is often
neglected as discussed above.
22 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
Table 1: Experimental results for the considered scanning systems. († requested to stay anonymous.)
T is the number of tainted flows, V is the number of vulnerable flows, M indicates if a human analyst found a vulnerability.
Name T V M Name T V M Name T V M
AddMe 11 11 XInternetOfficer 2 1 XSecurity Headers 13 -
AdResults 14 - [Anonymous]11 1 XSEO Review Tools - -
HArachni 14 - - - SeoBook 12 11 X
AUKSEO - - IPv6 Scanner - - SERP-Eye - -
BeautifyTools 13 - itEXPERsT - - Server Headers 13 12 X
BrowserSPY 9 - HIVRE 2 - Site 24x7 13 13 X
CheckHost 1 - JoydeepDeb 13 13 XSQLMap Scanner 1 1 X
1 - JSON Formatter 13 13 XSSL Certificate Tools 12 -
CheckSERP 11 - LucasZ ZeleznY 2 1 XStepForth 12 11 X
CheckShortURL 1 1 XHMetasploit Pro 11 3 XStraightNorth - -
Cloxy Tools 11 - Monitor Backlinks 12 - SubnetOnline 14 13 X
CookieLaw 1 - HNessus 11 - Sucuri Site Check 3 -
CookieMetrix 2 1 XNikto Online 2 2 XSureOak 9 8 X
DNS Checker 1 1 XHNmap 14 - TheSEOTools 1 1 X
DNSTools - - Nmap Online 12 1 XTutorialspots 13 13 X
Dupli Checker 1 - XOnline SEO Tools 12 12 XUrl X-Ray 1 - 12 12 XHOpenVAS 3 - Urlcheckr 10 -
expandUrl 1 - HOWASP ZAP 4 - Urlex - -
13 13 XPentest-Tools 2 1 13 13 X
GDPR Cookie Scan - - Port Checker 10 - W3dt.Net 12 11 X
GeekFlare 12 - Redirect Check 11 10 XWeb Port Scanner - -
Hacker Target 13 - Redirect Detective 2 - XWeb Sniffer 14 -
HTTP Tools 12 12 XReqBin 13 - WebConfs 13 12 X 14 - Resplace 12 - HWebMap 14 1 X
HInsightVM 3 - 13 1 XWhat Is My IP 12 -
1 -
Search Engine Reports
1 1 XHWMap 12 10 X
Figure 8: Correlation between vulnerable fields.
Also the Location field is weakly correlated with the other
fields. This is due to the behavior of redirect checkers. As
a matter of fact, this category of scanning systems focus on
Location, and, in most cases, ignore the other fields. An in-
depth evaluation of the behavior of redirect checkers is given
in the application scenario of Section 6.3.
An argument similar to the previous one for Location also
applies to Status Message. The Status Message is typically
used by scanning systems that carry out availability checks,
e.g., to verify that a web site is up and running.
Finally, for what concerns all the other fields, we observe
an extremely strong correlation. The confirms the proposition
of [20] about the security relevance of the headers that we are
considering. Indeed, most of the scanning systems included in
our experiments report them all. This also highlights that the
exposure of the scanning systems is not field-dependent, e.g.,
when a scanning system is vulnerable via one these fields,
most likely it is also vulnerable via the others.
6 Application Scenarios
In this section, we present three application scenarios for
our methodology. For each scenario, we highlight the sub-
class of vulnerable scanning systems, the vulnerability and
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 23
Figure 9: XSS PoC on Nmap Online.
its impact if an attacker were to use it in the wild. For each
subclass of scanning systems, we chose a representative that
we present as a concrete case study: Nmap Online for as-a-
service scanning systems, Metasploit Pro for on-premise ones,
and CheckShortURL [5] for redirect checkers.
6.1 Scan Attribution
Attack attribution is a hot topic since it is often difficult or
even impossible to achieve. The main reasons are the struc-
ture of the network and some state-of-the-art technologies
that enable clients anonymity. For instance, analysts can use
proxies, virtual private networks, and onion routing to hide
the actual source of the requests from the recipient. How-
ever, an injected browser may be forced to send identifying
data directly inside the HTTP requests, so making network-
level anonymization techniques ineffective. In this section, we
show how to attribute scans using our attacker model through
an application scenario based on Nmap Online [15].
Nmap Online vulnerability
Nmap Online is a web appli-
cation providing some of the functionalities of Nmap. Users
can scan a target with Nmap without having to install it on
their machine. Furthermore, since requests originate from the
Nmap Online server, users can stay anonymous w.r.t. the scan
target. When users start a scan, they select the target IP and
the scan type. The Nmap Online website scans its target and
displays the retrieved information to the user, e.g., server type
and version.
Nmap Online reports suffered from an XSS vulnerability.
Figure 9shows an injected report. The injection occurs on the
Server response header. In this case, the Server field was set
to <script>alert(1)</script>.
Browser hooking
Since there is no guarantee that more
than one scan will occur, we recur to browser hooking, which
5The vulnerability was fixed on March 24, 2020.
can be obtained with a single XSS payload. A hooked browser
becomes the client in a command and control (C2) infrastruc-
ture, thus actively querying the C2 server for instructions. This
allows the attacker to submit arbitrary commands afterward
even when no other scans occur.
An effective way to achieve browser hooking is
through BeEF [2]. In particular, the BeEF C2 client
is injected via the script hook.js. For instance, we
can deploy hook.js by setting the Server header to
<script src=’http://[C2]/hook.js’></script>
where [C2] is the IP address of the C2 server.
The BeEF framework includes modules
for fingerprinting the victim host. For instance, the browser
module allows us to get the browser name, version, visited do-
mains, and even starting a video streaming from the webcam.
Similarly, the host module allows us to retrieve data such
as physical location and operating system details. Some of
these operations, e.g., browser fingerprinting, require no vic-
tim interaction. Instead, others need the victim to take some
actions, e.g., explicitly grant permission to use the webcam.
To overcome these hurdles, attackers usually employ auxil-
iary techniques, e.g., credential theft, implemented by some
BeEF modules, e.g., social engineering. Finally, the overall
fingerprinting process can be automated through the BeEF
autorun rule engine [1].
6.2 Scanning host takeover
On-premise scanning systems, which run on the analyst’s host,
may have privileged, unrestricted access to the underlying
platform. In some cases, on-premise systems are provided
with a user interface that includes both the reporting system
and a control panel. When such a user interface is browser-
based, a malicious scan target can inject commands in the
reporting system and perform lateral movements by triggering
the scanning system controls.
The attack strategy abstractly described above must be
implemented through concrete steps that are specific to the
scanning system. In this section, we show an implementa-
tion of this attack strategy for the popular scanning system
Metasploit Pro. In particular, we show how to perform lat-
eral movements leading to a complete scanning host takeover
through remote code execution (RCE). Finally, we carry out
an impact evaluation.
CVE-2020-7354 and CVE-2020-7355
Metasploit Pro is a
full-fledged penetration testing framework. It has a browser-
based UI that integrates both a scan reporting system and
many controls for running the most common tasks, including
host scanning. Each command is executed by the Metasploit
back-end, which is stimulated through a REST API.
24 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
Figure 10: Stored XSS PoC on Metasploit Pro.
The vulnerability we found affects versions 4.17.0 and
below. It was remediated on May 14, 2020, with patch 4.17.1.
A malicious scan target can inject a Stored XSS payload in
the UI. Multiple pages are vulnerable, e.g.,
Metasploit Pro fetches the Server header and displays
it inside the INFO column with no sanitization. Fig-
ure 10 shows the effect of setting the Server header to
<img src=’x’ onerror=’alert(1)’/>
(as described in
Section 4.3).
Remote code execution
We use the XSS vulnerability de-
scribed above to gain a foothold in the browser on the scan-
ning host. For instance, we can inject a BeEF hook to remotely
interact with the browser (as in Section 6.1). The hooked
browser is the steppingstone to interact with the Metasploit
Pro UI and trigger its controls. Interestingly, Metasploit Pro
includes a diagnostic console, i.e., an embedded terminal that
allows the analyst to run arbitrary commands on the under-
lying operating system.
Although the diagnostic console
is disabled by default, the attacker can activate it through
BeEF. In particular, the hooked browser is forced to perform a
POST HTTP request to
the parameter
. Since the diag-
nostic console is a browser-embedded Metasploit terminal
emulator, the attacker can submit commands from the BeEF
Takeover impact
The Metasploit Pro documentation
clearly states that “Metasploit Pro Users Run as Root. If
you log in to the Metasploit Pro Web UI, you can effectively
run any command on the host machine as root”. This opens
a wide range of opportunities for the attacker. Among them,
metasploit-web- interface-overview
the most impactful is to establish a reverse shell. The reasons
are twofold. First, opening a shell on the scanning host allows
the attacker to execute commands directly on the operating
system of the victim. Thus, attacks are no longer tunneled
through the initial vulnerability, which might become unavail-
able, e.g., if Metasploit Pro is terminated. Second, a reverse
shell works well even when certain network facilities, such as
firewalls and NATs, are in place. Indeed, although these facil-
ities may prevent incoming connections, usually they allow
outgoing ones. Once a reverse shell is established, the attacker
can access a permanent, privileged shell on the victim host.
6.3 Enhanced phishing
The goal of a phishing attack is to induce the victim to commit
a dangerous action, e.g., clicking an untrusted URL or opening
an attachment. In this section, we show how our attacker
model changes phishing attacks, using CheckShortURL as an
application scenario.
Traditional Phishing
A common phishing scenario is that
of an unsolicited email with a link pointing to a malicious
web page, e.g.,
. The phishing site mimics a
reputable, trusted web page. For instance, the attacker may
clone a bank’s web site so that unaware users submit their
access credentials. Another technique is to provoke a reaction
to an emotion, such as fear. This happens, for instance, with
menacing alerts about imminent account locking and malware
infections. Again, if victims believe that urgent action must
be taken, they could overlook common precautions and, e.g.,
download dangerous files.
Defense mechanisms
Most of the examples given above
require the victim to open a phishing URL. Common, un-
skilled users typically evaluate the trustworthiness of a URL
by applying their common sense.
Nevertheless, techniques
such as URL shortening and open redirects [27] masquerade
the phishing URL to resemble a trusted domain.
Some online services may help the user to detect phishing
attacks. For instance, reputation systems and black/white lists,
e.g., Web of Trust
, can be queried for a suspect URL. How-
ever, phishing URLs often point to temporary websites that
are unknown to these systems.
Since browsers automatically redirect without asking for
confirmation, in [27] the authors highlight that victims can
defend themselves by checking where the URL redirects with-
out browsing it. To this aim, several online services, e.g.,
CheckShortURL, do redirect checking to establish the final
destination of a redirect chain. Typically, the chain is printed
in a report that the user inspects before deciding whether to
proceed or not.
10E.g., see
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 25
Figure 11: Phising through CheckShortURL.
Exploiting redirect checkers
Redirect locations are con-
tained in the Location header of the HTTP response asking
for a redirection. According to our attacker model, this value
is controller by the attacker. Thus, if the victim uses a vulner-
able redirect checker, the report may convey an attack to the
user browser. Since the goal is phishing, the attacker has two
possibilities, i.e., forcing the URL redirection and exploit the
scanning system reputation.
In the first case, the attacker delivers an XSS payload such
window.location = ""
. When it is ex-
ecuted, the browser is forced to open the given location and
to redirect the user to the phishing site.
The second case is even more subtle. Since the XSS attack
is delivered by the scanning system, the attacker can perform a
phishing operation and ascribe it to the reporting system. For
instance, the attacker can make the user browser download
a malicious file pretending to be the scanning system pdf
report. In this way, the attacker abuses the reputation of the
scanning system to lure the victim. This can be achieved with
the following payload.
The effect of injecting such a payload in CheckShortURL is
shown in Figure 11.
7 Related Work
In this section, we survey the related literature.
7.1 Attacking the attacker
Although not frequent in the literature, the idea of attacking
the attackers is not completely new. Its common interpretation
is that the victim of an attack carries out a counter-strike
against the host of the aggressor. However, even tracking an
attack to its actual source is almost impossible if the attacker
takes proper precautions (as discussed in Section 6.1). To
the best of our knowledge, we are the first to consider the
response-based exploitation of the attackers scanning systems.
Djanali et al. [9] define a low-interaction honeypot that
simulates vulnerabilities to lure the attackers to open a ma-
licious website. When this happens, the malicious website
delivers a browser exploitation kit. The exploitation relies
on a LikeJacking [29] attack to obtain information about the
attacker’s social media profile. Unlike our approach, their
proposal substantially relies on social engineering and does
not consider vulnerabilities in the attacker’s equipment.
Also, Sintov [28] relies on a honeypot to implement a re-
verse penetration process. In particular, his honeypot attempts
to collect data such as the IP address and the user agent of the
attacker. Again, this proposal amounts to retaliating against
the attackers after identifying them.
In terms of vulnerabilities, some researchers already re-
ported weaknesses in scanning systems. The closest to our
work is CVE-2019-5624 [4], a vulnerability in RubyZip that
also affects Metasploit Pro. This vulnerability allows attack-
ers to exploit path traversal to create a cron job that runs
arbitrary code, e.g., to create a reverse shell. To achieve this,
the attacker must import a malicious file in Metasploit Pro as
a new project. However, as for [9], this attack requires social
engineering as well as other conditions (e.g., about the OS
used by the attacker). As far as we know, this is the only other
RCE vulnerability reported for Metasploit Pro. Instead, apart
from ours, no XSS vulnerabilities have been reported.
7.2 Security scanners assessment
Several authors considered the assessment of security scan-
ners. However, they mainly focus on their effectiveness and
efficiency in detecting vulnerabilities.
Doupé et al. [10] present WackoPicko, an intentionally vul-
nerable web application designed to benchmark the effective-
ness of security scanners. The authors provide a comparison
of how open source and commercial scanners perform on the
different vulnerabilities contained in WackoPicko.
Holm et al. [18] perform a quantitative evaluation of the ac-
curacy of security scanners in detecting vulnerabilities. More-
over, Holm [17] evaluated the performance of network secu-
rity scanners, and the effectiveness of remediation guidelines.
Mburano et al. [23] compare the performance of OWASP
ZAP and Arachni. Their tests are performed against the
OWASP Benchmark Project [13] and the Web Application
Vulnerability Security Evaluation Project (WAVSEP) [6].
Both these projects aim to evaluate the accuracy, coverage,
and speed of vulnerability scanners.
To the best of our knowledge, there are no proposals about
the security assessment of scanning systems. Among the pa-
pers listed above, none consider our attacker model or, in
general, the existence of security vulnerabilities in security
26 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
7.3 Vulnerability detection
Many authors proposed techniques to detect software vulner-
abilities. In principle, some of these proposals can be applied
to scanning systems.
The general structure of vulnerability testing environments
was defined by Kals et al. [19]. Our TEE implements their
abstract framework by adapting it to inject responses instead
of requests. The main difference is our test stub, that receives
the requests from the scanning system under test. We substi-
tute the crawling phase with tainted flow enumeration (see
Section 4.2). During the attack phase, we substitute the pay-
load list with a list of polyglots, which reduces testing time.
Our exploit checker implements their analysis module as we
also deal with XSS.
Many authors have proposed techniques to perform vulner-
ability detection through dynamic taint analysis. For instance,
Xu et al. [32] propose an approach that dynamically monitors
sensitive sinks in PHP code. It rewrites PHP source code, in-
jecting functions that monitor data flows and detect injection
Avancini and Ceccato [3] also use dynamic taint analysis to
carry out vulnerability detection in PHP applications. Briefly,
they implement a testing methodology aiming at maximizing
the code coverage. To check whether a certain piece of code
was executed, they rewrite part of the application under test
to deploy local checks.
These approaches rely on inspecting and manipulating the
source code of the application under test. Instead, we work
under a black-box assumption.
Besides vulnerability detection, some authors even use dy-
namic taint analysis to implement exploit detection and pre-
vention methodologies. Vogt et al. [30] prevent XSS attacks
by combining dynamic and static taint analysis in a hybrid ap-
proach. Similarly, Wang et al. [31] detect DOM-XSS attacks
using dynamic taint analysis. Both these approaches iden-
tify sensitive data sinks in the application code and monitor
whether untrusted, user-provided input reaches them.
Dynamic taint analysis techniques were also proposed for
detecting vulnerabilities in binary code.
Newsome and Song [24] propose TaintCheck, a method-
ology that leverages dynamic taint analysis to find attacks
in commodity software. TaintCheck tracks tainted sinks and
detects when an attack reaches them. It requires a monitoring
infrastructure to achieve this.
Clause et al. [7] propose a generic dynamic taint analysis
framework. Similarly to [24], Clause et al. implement their
technique for x86 binary executables. However, the theoretical
framework could be adapted to fit our methodology.
In principle, the exploit prevention techniques mentioned
above might be used to mitigate some of the vulnerabilities de-
tected by RevOK. However, they do not deal with vulnerabil-
ity detection. Moreover, they require access to the application
8 Conclusion
In this paper we introduced a new methodology, based on a
novel attacker model, to detect vulnerabilities in scanning sys-
tems. We implemented our methodology and we applied our
prototype RevOK to 78 real-world scanning systems. Our ex-
periments resulted in the discovery of 36 new vulnerabilities.
These results confirm the effectiveness of our methodology
and the relevance of our attacker model.
This paper was partially funded by
EU H2020 research project SPARTA (grant agreement
Wade Alcorn. Beef autorun rule engine.
Autorun-Rule- Engine, Accessed March 19, 2020.
Wade Alcorn. The Browser Exploitation Framework,
Accessed March 3, 2020.
Andrea Avancini and Mariano Ceccato. Towards Secu-
rity Testing with Taint Analysis and Genetic Algorithms.
In Proceedings of the ICSE Workshop on Software En-
gineering for Secure Systems, 2010.
Luca Carettoni. On insecure zip handling, Rubyzip and
Metasploit RCE (CVE-2019-5624).
Accessed March 19, 2020.
CheckShortURL. CheckShortURL, Accessed March 23,
Shay Chen. The Web Application Vulnerability Scan-
ner Evaluation Project.
projects/wavsep/, Accessed March 19, 2020.
James Clause, Wanchun Li, and Alessandro Orso. Dy-
tan: a generic dynamic taint analysis framework. In
Proceedings of the International Symposium on Soft-
ware Testing and Analysis, 2007.
MITRE Corporation. ATT&CK - Technical Information
TA0015/, Accessed March 20, 2020.
Supeno Djanali, FX Arunanto, Baskoro Adi
Pratomo, Abdurrazak Baihaqi, Hudan Studiawan,
and Ary Mazharuddin Shiddiqi. Aggressive web
application honeypot for exposing attacker’s identity.
In Proceedings of the 1st International Conference
on Information Technology, Computer, and Electrical
Engineering, 2014.
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 27
Adam Doupé, Marco Cova, and Giovanni Vigna. Why
Johnny can’t pentest: An analysis of black-box web vul-
nerability scanners. In Proceedings of the International
Conference on Detection of Intrusions and Malware,
and Vulnerability Assessment, 2010.
Ahmed Elsobky. Unleashing an Ultimate XSS Poly-
wiki/Unleashing-an- Ultimate-XSS-Polyglot
Accessed March 19, 2020.
OWASP Foundation. OWASP Top Ten.
https:// top-ten/, 2017.
OWASP Foundation. OWASP Benchmark Project. benchmark/
Accessed March 19, 2020.
Satish Gojare, Rahul Joshi, and Dhanashree Gaigaware.
Analysis and Design of Selenium WebDriver Automa-
tion Testing Framework. Procedia Computer Science,
MUNSIRADO Group. Nmap Online, Accessed March
3, 2020.
Web Hypertext Application Technology Working Group.
HTML Living Standard, Last updated March 27, 2020.
Hannes Holm. Performance of automated network vul-
nerability scanning at remediating security issues. Com-
puters & Security, 2012.
Hannes Holm, Teodor Sommestad, Jonas Almroth, and
Mats Persson. A quantitative evaluation of vulnerabil-
ity scanning. Information Management & Computer
Security, 2011.
Stefan Kals, Engin Kirda, Christopher Kruegel, and Ne-
nad Jovanovic. SecuBat: A Web Vulnerability Scanner.
In Proceedings of the 15th International Conference on
World Wide Web, 2006.
Arturs Lavrenovs and F Jesús Rubio Melón. HTTP
Security Headers Analysis of Top One Million Websites.
In Proceedings of the 10th International Conference on
Cyber Conflict (CyCon), 2018.
Arturs Lavrenovs and Gabor Visky. Investigating HTTP
response headers for the classification of devices on the
Internet. In Proceedings of the 7th IEEE Workshop
on Advances in Information, Electronic and Electrical
Engineering (AIEEE), 2019.
Paul Leach, Michael Mealling, and Rich Salz. A univer-
sally unique identifier (UUID) urn namespace. 2005.
Balume Mburano and Weisheng Si. Evaluation of Web
Vulnerability Scanners Based on OWASP Benchmark.
In Proceedings of the 26th International Conference on
Systems Engineering (ICSEng), 2018.
James Newsome, Dawn Song, James Newsome, and
Dawn Song. Dynamic taint analysis: Automatic detec-
tion, analysis, and signature generation of exploit attacks
on commodity software. In Proceedings of the 12th
Network and Distributed Systems Security Symposium,
[25] Nmap project. Nmap, Accessed March 23, 2020.
E. J. Schwartz, T. Avgerinos, and D. Brumley. All You
Ever Wanted to Know about Dynamic Taint Analysis
and Forward Symbolic Execution (but Might Have Been
Afraid to Ask). In Proceedings of the IEEE Symposium
on Security and Privacy, 2010.
Craig A Shue, Andrew J Kalafut, and Minaxi Gupta.
Exploitable Redirects on the Web: Identification, Preva-
lence, and Defense. In Proceedings of the 2nd USENIX
Workshop on Offensive Technologies, 2008.
Alexey Sintsov. Honeypot that can bite: Reverse pene-
tration. In Black Hat Europe Conference, 2013.
SOPHOSLABS. Facebook worm: Likejacking.
31/facebook-likejacking- worm/
, Accessed on
March 19, 2020.
Philipp Vogt, Florian Nentwich, Nenad Jovanovic, Engin
Kirda, Christopher Kruegel, and Giovanni Vigna. Cross
Site Scripting Prevention with Dynamic Data Tainting
and Static Analysis. In Proceedings of the Network and
Distributed System Security Symposium (NDSS), 2007.
Ran Wang, Guangquan Xu, Xianjiao Zeng, Xiaohong
Li, and Zhiyong Feng. TT-XSS: A novel taint tracking
based dynamic detection framework for DOM Cross-
Site Scripting. Journal of Parallel and Distributed Com-
puting, 2018.
Wei Xu, Sandeep Bhatkar, and R Sekar. Practical dy-
namic taint analysis for countering input validation at-
tacks on web applications. Technical Report SECLAB-
05-04, Department of Computer Science, Stony Brook,
28 23rd International Symposium on Research in Attacks, Intrusions and Defenses USENIX Association
A Vulnerability Disclosure
All the vulnerabilities reported in this paper were promptly
notified to the scanning system vendors. We based our re-
sponsible disclosure process on the ISO 29147
Below, we describe each disclosure step in detail and the
vendors feedback.
A.1 First contact
The first step of our responsible disclosure process consisted
of a non-technical email notification to each vendor. We report
our email template below.
De a r < sc a n ni n g s ys t em ve n do r > ,
my n am e is < i den ti f ic ati on an d li nk s >
As p ar t of m y res ea rch a cti vi ty on a
no ve l t hr ea t m ode l , I fo un d t ha t y our
pla tf orm i s mo st l i ke ly vul ne r ab le
to X SS a t ta c ks .
In p arti cu lar , the v ul ne ra bi li ty I
d is c ov e re d m ig h t ex p os e y ou r en d - u se rs
to c o nc r et e r is k s .
Fo r t he se r eas on s , I am c on ta ct in g
yo u to s tar t a re spo ns i bl e d is c lo sur e
pro ce ss. I n t hi s respe ct , I am k in d ly
ask in g yo u to p oin t me to the ri gh t
cha nn el (e . g. , an of fic ia l b ug b oun ty
pro gr am or a se cu r it y o ff ic er to
Ki nd re ga rds
We sent the email through official channels, e.g., contact
mail or form, when available. For all the others, we tried with
a list of 13 frequent email addresses, including security@,
webmaster@, contact@, info@, admin@, support@.
In 5 cases the previous attempts failed. Thus, we submitted
the corresponding vulnerabilities to OpenBugBounty.13
A.2 Technical disclosure
After the vendor answered our initial notification, providing
us with the technical point of contact, we sent a technical
report describing the vulnerability. The report was structured
according to the following template, which was accompanied
by a screenshot of the PoC exploit inside their system.
Th e i ss u e i s a C ro ss - Si t e Sc r i pt i ng
att ac k on y ou r o nl in e v uln er a bi lit y
s ca n ni n g t oo l < s ca n n in g s y st e m na me >.
Th is ex po ses y ou r us er s to a tt ac ks ,
pos si bly l ead in g to d ata l ea k ag e an d
a cc ou n t ta k eo v er .
A mal ic iou s s er ve r c an a ns w er w it h X SS
pay lo ads i ns tea d of it s st and ar d hea de rs.
Fo r e xample , it c ould a nswe r wi th t hi s
( m in im a l ) H T TP r es p on s e :
< mi nim al P oC f or t he sca nn ing s ys te m >
Si n ce y ou r w eb si t e di s pl ays t hi s dat a in
a re por t , t hi s c ode d is pl ays a p op up on
th e u se r p age , b ut an a tt ac ke r c an
i nc lu de a ny J av aS c ri pt c od e i n i t ,
t ak i ng c o nt r o l o f t he u se r b ro w s er ( s ee
ht t p s : // b e e fp r o je c t . c om / ) , an d h en c e
ma ke th em p e rf or m a ct ion s on y ou r
w eb si t e o r st e al p e rs on a l in f or m at i on .
I att ac hed a s cr e en sho t of t he P oC
r un n in g on y o ur p ag e . Th e P oC is
com plet el y ha rml es s , b oth f or yo ur
web si te an d fo r yo u to tes t.
I al so hos te d a ma l ic iou s ( bu t ha r ml es s )
ser ve r her e if you w an t to r epr od uce t he
is s u e : < te s t st u b n et w o r k ad d re s s >
Yo u ca n per fo rm an y sc an y ou w an t
aga in st it ( pl ea s e le t me k no w if i t is
In a few cases we extended the report with additional de-
tails, requested by some vendors. For example, some of them
asked for the CVSSv3
calculation link and an impact evalu-
ation specifically referring their scanning system.
A.3 Vendors feedback
Out of the 36 notifications, we received 12 responses to the
first contact message. All the responses arrived within 2 days.
Among the notified vendors 5 fixed the vulnerability within 10
days. Another vendor informed us that, although they patched
their scanning system, they started a more general investiga-
tion of the vulnerability and our attacker model. This will
result in a major update in the next future. Finally, after fixing
the vulnerability, one of the vendors asked us not to appear in
our research.
14 metrics/cvss/v3-calculator
USENIX Association 23rd International Symposium on Research in Attacks, Intrusions and Defenses 29
... In this paper we present Damn Vulnerable Application Scanner (DVAS), an intentionally flawed network scanner. DVAS allows the user for training against a novel attacker model, recently presented by Valenza et al. [1]. This kind of attack is carried out via malicious HTTP Response messages. ...
... Recently, [1] introduced a novel attacker model that affects HTTP scanners. A scanner is a piece of software that stimulates a remote machine in order to acquire some data, e.g., the type and version of the hosted services. ...
... When a scan is performed, an attacker can inject malicious code through HTTP responses. To confirm the novelty of their attack, the authors of [1] tested 78 existing scanners and found that 36 were vulnerable to this threat. ...
Conference Paper
Full-text available
In this paper, we present Damn Vulnerable Application Scanner (DVAS), an intentionally flawed network scanner. DVAS allows the user for training against a novel attacker model, recently presented by Valenza et al. This kind of attack is carried out via malicious HTTP Response messages. Scan reports can be vulnerable to injection attacks, thus putting the browser of the scanner user at risk. To the best of our knowledge, DVAS is the only environment for practicing under the new attacker model. Without proper training and education, these kinds of flaws are likely to be neglected by developers and security analysts. As a confirmation, here we even report twelve new vulnerabilities that we discovered in existing scanners while developing one of the challenges of DVAS.
Conference Paper
Full-text available
Attackers are most likely to exploit invalidated and unsanitized user input with several attacks such as cross-site scripting (XSS) or SQL injection. Many methods were proposed to prevent those attacks. Some of them were created to learn about pattern and behavior of the attacker. That is honeypot. Honeypot is classified into two types based on the simulation that honeypot can do: low interaction and high interaction.
Full-text available
Nowadays, number of software system has been implemented as web-based applications. These web applications are very complex. It is very difficult to test such complex web applications. Automation testing uses automation tools to reduce human intervention and repeatable tasks. In this paper we have designed and implemented automation testing framework for testing web applications. This new automation testing framework has been implemented using selenium WebDriver tool. Using this framework tester can easily write their test cases efficiently and in less time. Tester need not to study the selenium webdriver tool in detail. This framework is helpful to developer to analyze their code due to screen shot property of framework. This framework produces the customized test report to tester. It is very easy to maintain and repair the test suite for new release of the application using this framework.
Conference Paper
Full-text available
Black-box web vulnerability scanners are a class of tools that can be used to identify security issues in web applications. These tools are often marketed as “point-and-click pentesting” tools that automatically evaluate the security of web applications with little or no human support. These tools access a web application in the same way users do, and, therefore, have the advantage of being independent of the particular technology used to implement the web application. However, these tools need to be able to access and test the application’s various components, which are often hidden behind forms, JavaScript-generated links, and Flash applications. This paper presents an evaluation of eleven black-box web vulnerability scanners, both commercial and open-source. The evaluation composes different types of vulnerabilities with different challenges to the crawling capabilities of the tools. These tests are integrated in a realistic web application. The results of the evaluation show that crawling is a task that is as critical and challenging to the overall ability to detect vulnerabilities as the vulnerability detection techniques themselves, and that many classes of vulnerabilities are completely overlooked by these tools, and thus research is required to improve the automated detection of these flaws.
Most work on DOM Cross-Site Scripting (DOM-XSS) detection methods can be divided into three kinds: black-box fuzzing, static analysis, and dynamic analysis. However, black-box fuzzing and static analysis suffer much from high false negative rates and high false positive rates respectively. Current dynamic analysis is complex and expensive, though it can obtain more efficient results. In this paper, we propose a dynamic detection framework (TT-XSS) for DOM-XSS by means of taint tracking at client side. We rewrite all JavaScript features and DOM APIs to taint the rendering process of browsers. To this end, new data types and methods are presented to extend the semantic description ability of the original data structure, based on which we can analyze the taint traces through tainting all sources, sinks and transfer processes during pages parsing. In this way, attack vectors are derived to verify the vulnerabilities automatically. Compared to AWVS 10.0, our framework detects more 1.8% vulnerabilities, and it can generate the corresponding attack vectors to verify 9.1% vulnerabilities automatically.
This paper evaluates how large portion of an enterprises network security holes that would be remediated if one would follow the remediation guidelines provided by seven automated network vulnerability scanners. Remediation performance was assessed for both authenticated and unauthenticated scans. The overall findings suggest that a vulnerability scanner is a usable security assessment tool, given that credentials are available for the systems in the network. However, there are issues with the method: manual effort is needed to reach complete accuracy and the remediation guidelines are oftentimes very cumbersome to study. Results also show that a scanner more accurate in terms of remediating vulnerabilities generally also is better at detecting vulnerabilities, but is in turn also more prone to false alarms. This is independent of whether the scanner is provided system credentials or not.
Errors in validation of user inputs lead to serious security vulnerabilities. Many web applications contain such errors, making them vulnerable to remotely exploitable input validation attacks such as SQL injection, and cross site scripting. In this paper, we present a dynamic taint analysis technique to detect the input validation attacks. More specifically, our technique is based on tracking flow of taint information from untrusted input into the parts of the generated output (or commands). A unique benefit of our approach is that it can be applied to all of the web application development languages whose interpreters are implemented in C. We demonstrate this ability by applying our technique on web applications which use PHP, and bash scripts. Our technique is implemented as a fully automatic source-to-source transformation. We present experimental evaluation to establish effectiveness of our approach, paying particular attention to its attack detection ability. Experiments demonstrate that our technique detects all the attacks accurately with no false alarms.
Conference Paper
Abstract Cross-site scripting (XSS) is an attack against web applications in which scripting code is injected into the output of an application that is then sent to a user’s web browser. In the browser, this scripting code is executed and used to transfer sensitive data to a third party (i.e., the attacker). Currently, most approaches attempt to prevent XSS on the server side by inspecting and modifying the data that is exchanged,between,the web application and the user. Unfortunately, it is often the case that vulnerable applications are not fixed for a considerable amount of time, leaving the users vulnerable to attacks. The solution presented in this paper stops XSS attacks on the client side by tracking the flow of sensitive information inside the web browser. If sensitive information is about to be transferred to a third party, the user can decide if this should be permitted or not. As a result, the user has an additional protection layer when surfing the web, without solely depending on the security of the web application.