Network scanning is a common task in cybersecurity. For instance, penetration testers often scan a target system during the initial stage of their vulnerability detection process, e.g., for profiling machines and services. On the other hand, attackers scan remote systems looking for exploitation opportunities. Network scans are generally considered harmless for the victim, as they only consist of a few requests that cause no service interruption or degradation. Nevertheless, as shown in [1], scanning is risky for its author. In this paper, we present a general attack framework that takes advantage of network scans for injecting remote systems. In particular, our proposal leverages the widely adopted scanner Nmap [2] for transmitting attack payloads through the scan responses. If the output of Nmap is processed by an injectable application, e.g., a web browser of a SQL DBMS, our payloads are executed and the scanning system gets compromised.
Clearly, when establishing a direct connection, the target server can read the client’s IP address, which might be useful for attribution purposes. However, to avoid it, scan authors can resort to various techniques, depicted in Figure 1. The first scenario consists of a client performing a scan through a proxy server running Nmap. For instance, the client may resort to one among many network scanning web applications such as https://nmap.online/. Also, an attacker might have gained control over a remote server where she can install and run tools. In both cases, the target would attribute the scan operation to the proxy server, rather than the actual author. An alternative approach consists of scanning through the TOR network. Since the trafic goes through a number of relay nodes, the target can only observe the last, exit relay. Under these scenarios, attributing a Nmap scan to its author is, in general, undoable.
For the reasons stated above and since they generate a negligible amount of trafic, network
scans are usually tolerated. Nevertheless, banner grabbing is part of the attackers’ kill chain
and it should be considered a risky operation. In [
In this paper, we present an extension of the attack scenario presented in [
The rest of this paper is structured as follows. Section 2 illustrates our framework. In Section 3, we discuss a usage scenario of NIF. Finally, we survey the related literature in Section 4 and conclude the paper in Section 5.
In this section, we describe our attack framework and its implementation details.
The abstract workflow of our framework is depicted in Figure 2. The scanning platform appears on the left. Briefly, it consists of Nmap and some reporting systems. The reporting system can belong to various categories. For instance, it can be an HTML report or a PDF document. Possibly, the scan result may even be stored in a database.
On the other hand, the NIF platform exposes a frontend service. When a Nmap scan occurs on port P, the NIF service triggers a response generation utility that uses the Nmap service probes (see Section 2.2) and a collection of payloads, e.g., stored in a database. The generated response resembles a legal service banner, but it carries the injection payload. When Nmap processes the injected banner message, the payload is eventually returned to the reporting system.
Nmap service recognition relies on a list of service probes. Each probe amounts to a rule for parsing a service banner. In this way, even if a service is not running on its usual port (e.g., SSH on port 22), Nmap can correctly identify it. For instance, consider the following service probe rule. match ssh m|^SSH-([\d.]+)-OpenSSH[_-]([\w.]+)\r?\n|
p/OpenSSH/ v/$2/ i/protocol $1/ cpe:/a:openbsd:openssh:$2/ The rule states that the received banner message matches an SSH service if it follows the syntax between m|. . . |. The syntax is given through a Perl-compatible regular expression (PCRE). For instance, we can observe that the string SSH-1.2-OpenSSH_v5 matches the PCRE. The second part of the rule tells Nmap how to interpret a successful match. Every segment refers to specific information that Nmap infers from the banner message. In this case, for instance, p/OpenSSH/ is for the product name. More interestingly, v/$2/ tells Nmap that the service version is taken directly from the banner content. In particular, $2 identifies the second capture group parsed by the regular expression, i.e., the part of the string that matches the expression inside the second pair of rounded parentheses. In the previous example, this value is v5. Finally, segments i/. . . / and cpe:/. . . / are for info and platform (e.g., OS and hardware) identification, respectively.
Since Nmap extracts the information matching capture groups and includes it in its output, we can expect these details to be propagated to the reporting system. Hence, they represent the ideal target for placing a malicious payload. For instance, consider the banner SSH-1.2-OpenSSH_PAYLOAD. Nmap would extract from it the product version PAYLOAD.
Clearly, not every capture group is a suitable candidate for placing a payload. As a matter of fact, the payload must match the regular expression between parentheses. As an example, consider the first capture group in the previous rule, i.e., ([\d.]+). Since only digits and the ’.’ symbol can appear there, we cannot use it for any meaningful injection. Nevertheless, since all the matching rules and capture groups are listed in the source code of Nmap, we can easily iflter those that admit payload injection.
As stated above, the first step is finding capture groups that we can instantiate with payloads. For instance, we might look for (.*), i.e., the capture group matching any finite sequence of characters. Performing this search on the Nmap service probe file returns 89 entries such as the following one.
match ftp m|^220 vsFTPd (.*) ready\.\.\.\r\n| p/vsftpd/ v/$1/ Nevertheless, other regular expressions can be used as well. For instance, we might search for (.* and .*), i.e., capture group admitting a preamble or a trail (respectively) made of any sequence of chars. This results in rules such as this one. match ssh m|^SSH-([\d.]+)-OpenSSH_([\w._-]+)[ -]{1,2} Debian[ -_](.*ubuntu.*)\r\n| In this case, the capture group (.*ubuntu.*) can be used for our purposes.
With this approach, we can already identify 153 injectable probes. Nevertheless, more refined searches may be implemented. The basic idea is that one might use diferent charsets for each payload category. For instance, the character ’/’ may be necessary for XSS payloads, but irrelevant for SQLi ones. Thus, we may test each capture group against the charset of a specific injection attack for checking whether it can be injected.
Independently from the used method, NIF is eventually provided with a list of injectable probes. For each probe, the NIF service exposes a service on the corresponding port. When a scan occurs on port P, the payload generation proceeds in the following way. First, a probe PCRE is selected among those that () corresponds to a service running on port P (e.g., FTP if P = 21), and () contains at least an injectable capture group. Briefly, filter () is implemented by using the predefined service mapping included in the source code of Nmap. In particular, the configuration file nmap-services consists of a finite list following the syntax below.
service port/protocol frequency # comment There, service identifies the service, e.g., ftp, port/protocol is for the service port and protocol type, e.g., 21/tcp, frequency denotes the service likelihood, i.e., how often Nmap expects to find the service running on the given port, and comment is free text. Instead, filter () is implemented by considering the specific type of injection attack (given as an input). To check whether a capture group is injectable with a payload for a certain attack, e.g., XSS, we compute the intersection between PCRE of the capture group and a signature PCRE for the attack. Briefly, the signature PCRE is .*C.* where C is the payload charset described in Section 2.2. If the intersection between the two PCRE is not empty, we consider the probe injectable. As an example, consider again the capture group (.*ubuntu.*) discussed above and imagine that C = <>()alert/""123, i.e., a simplified charset for XSS. When computing .*ubuntu.* ∩ .*<>()alert/""123.* we find that, for instance, it includes the string <>()alert/""123ubuntu.
Once the injectable probe is selected, an actual response message that both () follows its syntax and () contains an attack payload must be generated. This is achieved by means of a PCRE generator that, given a regular expression, returns a random string belonging to its language. In particular, the PCRE used is that of the selected probe, where the injectable capture groups are modified as follows. Imagine the capture group PCRE is E and the selected payload is P, we replace E with the intersection E ∩ .*P.*. Again, if we consider the example above, if E = .*ubuntu.* and P = <script>alert(1)</script>, we obtain [[.*ubuntu.*]&&[.*<script>alert(1)</script>.*]]1. The overall response generation flow described above is exemplified in Figure 3. 1Diferent implementations of PCRE may use diferent operators for intersection. Here we refer to the Java implementation using [[ . . . ]&&[ . . . ]].
In this section, we present our implementation, called NIF. Furthermore, we demonstrate NIF through an attack scenario where the adversary establishes remote control over the victim’s browser. All the material presented below is available at https://github.com/iAleKira/ Nmap-Injection-Framework.
NIF is available as an open-source, Java-implemented project consisting of a few components. We briefly describe them below.
Payloads. This package contains a collection of injection payloads. Payloads are stored in each row of text files. Text files are organized according to their type. For instance, xss_payloads.txt contains a collection of XSS payloads. New injection attacks can be implemented by adding payloads’ files to this package. NIF retrieves these payloads when generating malicious responses to Nmap scans.
Filter. The filter utility is a stand-alone Java executable used to extract reversible Nmap probes, as explained in Section 2.2. Filtered probes are stored in a text file that NIF Server can access. Figure 4 shows the output generated by the following command.
java -jar filter.jar "<script>alert(1)</script>" In Figure 4, we report four rules for FTP and one for POP3 (out of 37 total rules). Server. This component is in charge for delivering the attack payloads once receiving a Nmap scan. Briefly, it implements the NIF service and the response generator described in Section 2. The NIF Server instantiates Java sockets listening on the ports associated with the injectable probes, e.g., port 25 for the FTP service.
Limitations. The general approach discussed in Section 2 and the current implementation of NIF mainly difer for a single aspect, i.e., the payload injection strategy. As discussed in Section 2.3, the general strategy is based on computing the intersection between two regular languages, i.e., one for the service probe and one for the injection payload. However, for the time being, NIF only generates payloads belonging to the regular language of the probe. For instance, consider the case where the probe’s regular expression is .*ubuntu.* and the payload is <script>alert(1)</script>. The approach described in Section 2.3 would allow generating, e.g., the response <script>alert(1)</script>ubuntu. However, the current implementation of NIF cannot find this match. Although this reduces the number of potential injection vectors, NIF can already identify several injectable probes for most payloads. We plan to extend NIF with this functionality as part of our future work.
In this demonstration, we show how NIF can be used to inject the victim with an XSS payload
to hijack the target browser. The scenario is depicted in Figure 5. The attacker controls both
the NIF server and a BeEF Command and Control (C&C) server. Briefly, BeEF [
The attacker configures NIF to inject the payload
<script src="HTTP://[IP]:3000/hook.js"></script> where [IP] is the IP address of the BeEF C&C server (exposed on port 3000). NIF identifies four injectable service probes and configures a listening port for each of them. When the victim’s machine scans one of these ports, it receives the payload. If the Nmap report is then flushed into an HTML report, the victim’s browser connects to the C&C server, as discussed above. Figure 6 shows the output of NIF when injecting Nmap under our scenario.
To the best of our knowledge, RevOk [
Active defense refers to a set of cybersecurity measures that involve actively identifying,
preventing, and responding to cyber threats. For a detailed review of the diferent types of
active defense and possible related actions, we refer the interested reader to Glosson [
De Gaspari et al. [
Another method is to directly identify and exploit vulnerabilities in the attacker’s tool suite.
For instance, Dereszowski [
Reports about scanner vulnerabilities are not frequent in the literature. Yet, some authors have considered the security weaknesses of scanners. These works focus on issues such as incomplete scanning, which can leave some vulnerabilities undetected; false positives, which are reported vulnerabilities that do not exist; or performance issues.
For instance, Holm et al. [
Web applications may be vulnerable to several types of injection attacks. One is the command injection attack that involves injecting malicious command-line code. The first formal definition of command injection attacks in the context of web applications is provided by Su and Wassermann [14]. The XML injection attack involves injecting malicious XML code, which can be used to manipulate or access data stored in an XML file, as discussed in [ 15]. The LDAP injection attack is analyzed in depth by Alonso et al. [16]. This technique allows obtaining direct access to the hierarchical database underlying an LDAP tree. Another attack is SQL injection, among the most used techniques to violate web applications. Several authors survey these attacks, e.g., see [17, 18]. In particular, Halfond et al. [19] not only classify SQL injection attacks but compare techniques for detecting and preventing them. Similarly, Kumar and Pateriya [20] survey attacks and defense techniques for injection scenarios. All the injection attacks discussed above are compatible with our approach. As a matter of fact, our methodology treats injection payloads agnostically and an attacker can pick the specific payloads targeting the victim’s infrastructure.
In this paper, we presented a general methodology for embedding injection attacks in Nmap scan responses. Our attack targets systems, e.g., penetration testing frameworks and reporting tools, that import the output of Nmap without proper sanitization. Although a systematic assessment of the impact of our attack strategy is yet to be carried out, we believe that many developers might excessively trust the output of Nmap when it is locally executed. In future work, we plan to experimentally validate this hypothesis by exploiting the tool presented in this paper for implementing a vulnerability detection campaign. Furthermore, such a campaign will be used to measure the impact of our methodology.
This work was partially supported by project SERICS (PE00000014) under the NRRP MUR program funded by the EU - NGEU. application vulnerability testing, in: 2010 IEEE symposium on security and privacy, IEEE, 2010, pp. 332–345. [13] S. Idrissi, N. Berbiche, F. Guerouate, M. Shibi, Performance evaluation of web application security scanners for prevention and protection against vulnerabilities, International Journal of Applied Engineering Research 12 (2017) 11068–11076. [14] Z. Su, G. Wassermann, The essence of command injection attacks in web applications,
Acm Sigplan Notices 41 (2006) 372–382. [15] A. N. Gupta, P. S. Thilagam, Attacks on web services need to secure xml on web, Computer
Science & Engineering 3 (2013) 1. [16] J. M. Alonso, R. Bordon, M. Beltran, A. Guzmán, Ldap injection techniques, in: 2008 11th IEEE Singapore International Conference on Communication Systems, IEEE, 2008, pp. 980–986. [17] A. Sadeghian, M. Zamani, S. M. Abdullah, A taxonomy of sql injection attacks, in: 2013
International Conference on Informatics and Creative Multimedia, IEEE, 2013, pp. 269–273. [18] M. Lawal, A. B. M. Sultan, A. O. Shakiru, Systematic literature review on sql injection attack, International Journal of Soft Computing 11 (2016) 26–35. [19] W. G. Halfond, J. Viegas, A. Orso, et al., A classification of sql-injection attacks and countermeasures, in: Proceedings of the IEEE international symposium on secure software engineering, volume 1, IEEE, 2006, pp. 13–15. [20] P. Kumar, R. Pateriya, A survey on sql injection attacks, detection and prevention techniques, in: 2012 Third International Conference on Computing, Communication and Networking Technologies (ICCCNT’12), IEEE, 2012, pp. 1–5.