TCP Idle Scanning using network printers

1 downloads 0 Views 560KB Size Report
Jan 22, 2013 - Idle Scan (or zombie scan) is a stealthy port scanning method, which ... zombie, the attacker utilizes the Identification field in the IP-Header ...
TCP Idle Scanning using network printers Mathias Morbitzer ([email protected]) January 22, 2013

Supervisor: Erik Poll

Executive Summary To analyze which services are provided by a target, an intruder will often use port scanning. The TCP Idle Scan can be used by the intruder to perform a port scan without sending an IP packet containing his real IP address directly to the target. Instead, he uses the IP address of a third host, the idle host, and utilizes the Identication eld in the IPv4 header (IPID) to retrieve the results of the scan. Such an idle host has to fulll certain requirements, which are not to produce trac on its own as well as assignment of the IPID in a predictable and global way. This research proves that most network printers fulll those requirements. In order to conduct this research, 50 dierent network printers in a large university network have been analyzed. Those printers consisted of 38 dierent types, which have been analyzed on how they assign their IPIDs. Altogether, nearly 90% of all tested printers assigned their IPIDs in a predictable way so that they could be used as idle hosts within the TCP Idle Scan. As a proof of concept, a script has been written which performs the port scan. The reason for making my own implementation was that no available tool supported the TCP Idle Scan with the printer to be tested. In the future, one might want to determine if the TCP Idle Scan is also feasible in IPv6.

Compared to IPv4, the IPID does not exist anymore in

IPv6. Still, there is an extension header for IPv6 which would provide the header with an Identication eld necessary for the scan. I conclude that although being discovered 15 years ago, the TCP Idle Scan can still be used by an attacker as long as the right device is used as idle host. Finding such a device might be not that easy though. For a short-term prevention of the attack, it is advisable to implement mechanisms against IP spoong in network. On the long term, it is essential that all devices which are capable of networking assign their IPID in a non-predictable way.

1

1. Introduction When an intruder receives access to a network, it is important for him to see which systems are connected to this network, and which kind of services those systems are oering [5].

After having gathered this valuable information, the intruder can decide

about his next target. In order to nd out which services are provided by a system, an often used technique is port scanning, as described for example by Erickson [5] or Zhang et al. [20]. In the usual approach for port scanning, connection requests are sent to various ports on a target computer to evaluate which services are running, and which are not [16]. However, this method is easy to detect and to be traced back to the intruder.

To

act less noisy, dierent methods for port scanning exist, all providing advantages and disadvantages [11]. One of those methods is the TCP Idle Scan, which will be introduced in Section 2.3. With this port scanning technique, the intruder uses the help of a third computer, the so called idle host, to remain undetected. This idle host must fulll certain requirements. Section 3 analyses why network printers might have all the criteria to act as such hosts. Afterwards, a short overview on available literature is given, and then practical tests are conducted and their results are analyzed. After giving a short overview of how this research could be continued in the future, the paper is concluded.

2. Background In order to be able to understand how the TCP Idle Scan works, it is rst necessary to give some background on specic details regarding the Internet Protocol (IP) as well as on the Transmission Control Protocol (TCP).

2.1. Internet Protocol According to Tanenbaum, the Internet Protocol (IP) is the glue that holds the whole Internet together [18, Page 432]. The protocol is designed to deliver packets from its source to its destination, no matter if those are located in the same network. A detailed description of the whole protocol would go beyond the scope of this paper, it can be found for example in the work of Tanenbaum [18]. For this paper, the important part of the protocol is the layout its packages use in the protocol's currently most used version, IPv4, as shown in Figure 1. Special attention should be paid to the 16 bit long Identication eld, also called IPID. If it is necessary to fragment a packet on its way due to certain limitations such as hardware, operating system, protocols or other reasons, this eld is used by the receiver to determine which fragments of a packet belong together [18]. This Identication value can be either assigned incrementally, randomly, or in any other way. Section 2.3 shows in which way any predictable assignment can be misused.

2

Figure 1:

The IPv4 (Internet Protocol) header (taken from A. Tanenbaum, Computer Networks [18])

(a) Successful

(b) Unsuccessful

(c) Unexpected

Figure 2: The TCP three way handshake

2.2. Transmission Control Protocol three way handshake The Transmission Control Protocol (TCP) is a reliable protocol which works on top of the IP protocol. In order to communicate via TCP, a connection must be established between two participants, usually referred to as client and server [8]. In order to establish this connection, a three way handshake is executed. First, the client sends to the server a TCP segment which contains the control bit SYN (for synchronize). After receiving that, the server, when willing to open a connection, answers with a segment containing the control bit SYN as well as the ACK bit (for acknowledge). To nish the handshake, the client answers with an segment containing the set ACK bit. Now that the connection is established, data can be exchanged [8].

The procedure is

illustrated in Figure 2a. If the server does not want to open a connection (for example because the service requested by the client is not available), it answers with a segment containing the control

3

bit RST (for reset), see Figure 2b. The handshake was unsuccessful. When a segment with a SYN and an ACK bit is received without having previously sent a segment containing the SYN bit, a host will also answer with a segment containing the control bit RST, as shown in Figure 2c [8].

2.3. TCP Idle Scan In order to nd out which services are provided on a specic host and can be attacked without revealing his own IP address, an intruder can execute the TCP Idle Scan, which makes use of the properties of IP and TCP mentioned in the previous sections. The TCP Idle Scan (or zombie scan) is a stealthy port scanning method, which allows an attacker to scan a target without the need of sending a single IP-Packet containing his own IP address directly to the target. Instead, he uses the IP address of a third host, the idle host (also known as zombie host) for the scan. To be able to retrieve the results from the zombie, the attacker utilizes the Identication eld in the IP-Header (IPID), mentioned in Section 2.1. While the idea of this technique was rst introduced by Salvatore Sanlippo in 1998 [13], the rst tool for executing the scan was created by Filipe Almeida in 1999 [2]. The technique is described by Lyons [12] as follows: 1. To scan a port on the target host, the attacker rst sends a TCP segment with the set SYN- and ACK-ag to the idle host. As the host is not expecting this segment, it will answer with a segment containing the RST-ag, and also its IPID. 2. Afterwards, the attacker sends a segment with a SYN-ag to the target host, dedicated to the port he wants to scan, and sets as source IP-address the spoofed IP-address of the idle host. Due to this spoofed address, the target will answer to the idle host, not to the attacker. 3. If the port is closed, a segment with an RST-ag will be sent to the idle host. If the scanned port on the target is open, the host will send a segment containing SYN- and ACK-ag to continue the TCP three-way handshake (Section 2.2). 4. In case of receiving a segment with an RST-ag, the idle host will not execute further actions.

But if a segment with the SYN- and ACK-ag is received, it

will answer by sending a segment with the RST-ag, as the previous one was not expected. For this answer, the host will use its next available IPID. 5. To get the result of the scan, the attacker sends now again a segment with the SYN- and ACK-ag to the idle host. In case the port is closed, the received IPID will have increased once compared to the previously received IPID, while for an open port, it will have increased twice. Figure 3 shows the TCP Idle Scan in a schematic manner.

4

Figure 3: TCP Idle Scan

3. Printers as idle hosts While the idle scan technique is very stealthy, it is hard to nd a suitable idle host. Among others, the host has to fulll the following requirements: 1. It should not create trac by itself. This would disturb the scanning-process, as the attacker would not be able to determine if an increase in the idle hosts IPID has been caused by answering to the target or by independent trac. (Hence the name idle host.) 2. The IPIDs assigned by the idle host need to be predictable. Also, the generation of the IPIDs should be done globally, and not on a per-host-basis.

Otherwise,

the attacker will not be able to recognize via the IPID if a package was sent to a dierent host. Most computing systems are not suitable as idle host, as they either create trac on their own and/or use non-predictable IPIDs. Newer operation systems like recent Linux

5

kernels as well as Windows Vista and later assign their IPID randomly [5]. For Linux, the patch for this was provided by the inventor of the TCP Idle Scan, Sanlippo, in 1999 [14]. Therefore, devices using such operating systems are not suitable as idle hosts. In comparison, network printers mostly do not create trac on their own. Additionally, I conjecture that the operating systems used for printers are not as sophisticated, and therefore they are likely not to use IPID randomization or other non-predictable assigning methods.

4. Related research While there is scientic literature on how to detect TCP Idle Scans [4] [17], literature on the scan itself remains very limited.

The best source of information is the book

Nmap Network Scanning: The Ocial Nmap Project Guide to Network Discovery and Security Scanning, written by Lyon [12], the author of the port scanner Nmap [10]. Most contents of the book were also published in the free Nmap reference guide [11]. In the book Hacking: the art of exploitation [5], Erickson also gives an explanation of the TCP Idle Scan using Nmap. Another publication about the TCP Idle Scan has been made by Kamerling [9]. Dierent from Lyon and Erickson, this document makes use of the network security tool Hping [15], written by Sanlippo.

Kamerling also refers to Bellovin [3], who mentioned the

danger of predictable sequence numbers already in 1989. Although Bellovin was covering TCP, the attack introduced by him was also enabled by predictable sequence numbers.

5. Practical Tests 5.1. Setup In order to analyze how printers behave in practice, tests have been conducted in a large university network. The part of the university which was analyzed educates around 1800 students, has 950 employees and up to 100 network printers. Within this network, 50 dierent printers have been tested, consisting of 38 dierent types. While the most common manufacturer was HP with a total of 48 devices, the experiment also contained one printer from the brand Xerox as well as one from Ricoh. The year the devices were manufactured ranged from 1996 to 2010.

A detailed list of the tested devices can be

found in Table 1. To carry out the experiment, ICMP echo requests [18], also known as pings, have been sent to the network printers. Considering Figure 3, this would be step one in the scanning process. While Figure 3 shows a fragment with a SYN- and ACK-ag in the rst step, the ICMP echo requests have been chosen for the practical tests instead because fragments with SYN- and ACK-ag (without prior fragments) were blocked by a rewall. However, as long as the idle host answers with a packet which contains its IPID, this step can be varied. In the received replies, the IPIDs of the packages have been analyzed with the network trac analyzer Wireshark [6].

6

Table 1: List of tested printers

1

Type

Year

Assignment of IPID

HP Business Inkjet 2250

1996

Incremental by 2

HP Color LaserJet 2600N

2005

Incremental

HP Color LaserJet 2605DN

2006

Incremental by 9

HP Color LaserJet 3525

2001

Incremental

HP Color LaserJet 4600

2002

Incremental by 2

HP Color LaserJet 4700

2009

Incremental by 2

HP Color LaserJet CM2320fxi MFP

2008

Random

HP Color LaserJet CP1510

2005

Incremental

HP Color LaserJet CP2020

2009

Random

HP Color LaserJet CP3525DN

2008

Incremental

HP LaserJet 1020

2005

Incremental

HP LaserJet 1300N

2003

Incremental by 2

HP LaserJet 2050

2008

Incremental

HP LaserJet 2055

2010

Incremental

HP LaserJet 2200

2002

Incremental by 2

HP LaserJet 2420

2005

Incremental by 2

HP LaserJet 2430

2005

Incremental

HP LaserJet 3700N

2004

Incremental

HP LaserJet 4100

2001

Incremental by 2

HP LaserJet 4200

2003

Incremental by 2

HP LaserJet 4250

2004

Incremental by 2

HP LaserJet 4350

2004

Incremental by 2

HP LaserJet 4-4M Plus

2002

Incremental

HP LaserJet 5000

2007

Incremental

HP LaserJet 500 Color M551

2009

Incremental

HP LaserJet 5100

2010

Incremental by 2

HP LaserJet 6P-6MP

1996

Incremental

HP LaserJet P2015

2007

Incremental by 2

HP LaserJet P2015DN

2007

Incremental by 9

HP LaserJet P3005

2007

Incremental

HP LaserJet P4010

2008

Incremental

HP LaserJet P4015DN

2010

Incremental

HP LaserJet P4510

2008

Incremental

HP LaserJet P4515N

2009

Incremental

HP OceJet Pro 6500A Plus

2010

Random

HP OceJet Pro 8500A

2010

Random

RICOH Acio MP 5000

2010

Incremental

Xerox Phaser 8560DN

2007

Incremental

7

Since it is also important that the device used as idle host in the TCP Idle Scan does not only assign its IPIDs in a predictable way, but also on a global and not on a perhost-basis, a second connection to the network was created from a dierent device. Like with the rst connection, ICMP echo requests were sent via this connection. This was necessary to determine if the fact that the idle host has to send an IP packet to a dierent device inuenced the IPID sequence received on the rst device. The whole procedure was as follows: 1. Send three ICMP echo requests from the rst device to the idle host (Step one in Figure 3). In between the requests, wait two seconds. 2. Wait again two seconds. 3. Send three ICMP echo requests from the second device to the idle host (Step four in Figure 3). In between the requests, wait two seconds. 4. Wait again two seconds. 5. Send three ICMP echo requests from the rst device to the idle host (Step six in Figure 3). In between the requests, wait two seconds. The pauses of two seconds are inserted for a more realistic behavior. While doing the actual scan, an attacker would also have to wait to give the target time to answer to the idle host (Step four in Figure 3), and the idle host the possibility to respond to the target (Step ve in Figure 3).

5.2. Results In the results, 34 out of the 38 dierent printers which were tested delivered predictable sequences for the IPID. 20 of those 34 devices created an incremental sequence, 12 created a sequence incremented by two. The other two devices incremented their IPID by nine. It is also important to mention that none of the tested devices created its IPIDs on a per-host-basis, but all of them did this globally. With being manufactured in 2008 or later, the four devices delivering a random sequence belong to the newest of the tested devices. One might expect that newer devices are better than older devices with respect to using unpredictable IPIDs. However, that is not the case, as shown by the results of the tested devices. Similar to the age of the device, there also seems to be no noticeable connection between the type of the product (like HP LaserJet) and the results. In total, nearly 90% of the tested network printers were suitable to be used as idle host by an attacker doing a TCP Idle Scan. That the predictability of the IPID sequence, along with the global assignment of IPIDs, which was done by all tested devices, enables an attacker to execute this scan in practice, will be shown in the next section.

8

5.3. Proof of concept To create a proof of concept, a separate network has been created, containing an attacker PC, a target, and a network printer from Table 1. This network setup is equal to the one in Figure 3.

The chosen printer was a HP LaserJet 4200, which increments its

IPID globally by two.

Besides of ensuring not to conict with the daily processes in

the network, another reason for creating a separate network was that IP spoong, which would be necessary for step 3 of the TCP Idle Scan, see Figure 3, was disabled within the university network. Creating the separate network turned out to be a bigger issue as expected. At rst, it was attempted to assign the printer a new IP address at startup via a DHCP server running at the target machine. Unfortunately, for an unknown reason, the printer did not receive an IP address, although tests with dierent machines were successful. Afterwards, a static IP address was assigned to the printer. Similar to the previous attempt, it was not possible to reach the printer via the network for unknown reasons. In the nally working attempt, the printer stayed in its regular setup, so that the IP address was assigned to the printer from its usual DHCP server. Afterwards, the network cable was unhooked and connected to the new network, in which the attacker PC and the target were assigned IPs in the same subnet as the network printer. The initial proof of concept was planned to be done with the port scanner Nmap [10]. Unfortunately, the scan reported an error at each attempt. The exact error can be found in Listing 1.

Listing 1: Error message returned by proof of concept

1 2 3

Idle scan using zombie (:443); Class: Incremental Idle scan is unable to obtain meaningful results from proxy (). I'm sorry it didn't work out. QUITTING! An analysis of this error concluded that Nmap only works for idle hosts which increment their IPID by one, which was not the case for the printer to be tested. Another test was attempted with the tool idlescan, written by Almeida [1] [2]. Due to the age of the tool, it was not possible to get it working on a modern Linux system.

2

Therefore, a script was written in BASH , which makes use of the tool Hping to execute the TCP Idle Scan. The full script can be found in Appendix A. First, the script uses Hping to send a ICMP echo request to the idle host, and stores the IPID of the reply (Step one and two in Figure 3). In the second step, a connection request is sent to the target, with the spoofed IP address of the idle host (Step three). After giving the idle host time to answer the target (Step ve), another ICMP echo request is sent to the idle host to obtain its current IPID (Step six and seven). Compared to the TCP Idle Scan implemented in the port scanner Nmap, the written script allows the user to state the expected IPID incrementation as parameter. For the

2

Bourne Again SHell

9

printer used in the proof of concept, this was the value two.

Using the script, open

and closed ports could be determined correctly without sending an IP packet with the attackers real IP address to the target.

6. Future Work Improving the BASH script for idle scanning. The script in its current state is

enough for a proof of concept. To actually provide a full tool for port scanning, various improvements could be made. For example, at the moment the expected incrementation of the IPID needs to be provided by the user. Instead, various packages could be send to the idle host, and the incrementation could be determined by the script itself. Also, in its current state, the script only supports scanning of a single port. Functionality to scan multiple ports could be implemented in the future.

6.1. TCP Idle Scan in IPv6 The TCP Idle Scan was shown to be stealthy and practical if the right device is used as idle host.

With the slowly approaching upgrade of IPv4 with IP version 6 (IPv6),

one will not be able to conduct the scan as previously anymore. In comparison to IPv4, no fragmentation is done by routers along the path anymore in IPv6, but only by the end nodes [19].

Hence, there is no Identication eld in the IPv6 header, as it is not

needed . In order to still execute a similar type of port scan, there could be the following possibility: During a presentation in 2011, Gont [7] mentioned that the TCP Idle Scan could still be executed in IPv6 by using the IPv6 extension header for fragmentation. Like in IPv4, this provides IPv6 with an Identication eld in its packets, which could be used in a similar way as in the current idle scan. Additionally, the RFC 2460 for IPv6 [19] states the following:

For every packet that is to be fragmented, the source node generates an Identication value. [19, Page 18] This means, compared to IPv4, the Identication value in IPv6 is not used (and increased) for each packet sent, but only for those which require fragmentation. Therefore, if an attacker is the only one in a certain timeslot requesting fragmented packets, the scanning process should not get disturbed by the idle host creating other trac, as long as this other trac does not require fragmentation.

This would eliminate one of the

biggest weaknesses of the TCP Idle Scan, which requires the idle host to be idle. In the future, I will research if the TCP Idle Scan can be adopted to IPv6, and what inuences this would have on its advantages and disadvantages.

7. Conclusion At rst, one should mention that the manufacturing date of the printers in Table 1 was ascertained by analyzing the date of reviews found on the internet. This method turned

10

out to be much faster than the option of nding manuals or data sheets for every single printer and lter the manufacturing year out of them, but is not as accurate. Second, it is to mention that the printers in Table 1 have mostly been only discovered logically, via the network. Physical detection was not necessary as the incrementation of the IPID could also be analyzed via the network, and the list of printers which was received by the technical support of the university contained all other necessary information. Despite this list, it turned out that physically locating those printers in such a large organization is often not that easy. Over time, locations of printers could change without the technical support being notied, or other modications might occur. It is also surprising to see the amount of dierent types of network printers, as one might expect that a bigger amount of one specic type of printer is purchased at once in a bigger organization. This highlights the fact that it can be hard for a bigger company to keep track of all its networking devices, which could all potentially act as idle hosts. A time-consuming solution for physically locating all network printers in an organization this size would be to walk from room to room, record all ndings, and sum them up afterwards. Apart from those non-technical discoveries, the research conducted in this paper has shown that although the idea of the TCP Idle Scan was presented 15 years ago, there are still devices which can be used for this type of scan. Among all the network printers tested, nearly 90% assigned their IPID in a predictable way. The most common strategy was using an incremental Identication value, though a not negligible amount of over 35% incremented by two, or sometimes nine. It is not clear to me why increasing by two or nine is done.

Although it could be

an approach of trying to improve security, this way of assigning hopefully happens for other, maybe technical reasons.

Still, it is possible with this method to fool the port

scanner Nmap, and therefore stop non-advanced intruders from using the scan, as there are no other available and working tools. In the case of advanced intruders, the only real eective measurement is to assign the IPID randomly. If this is not supported by the printer, measurements against IP-spoong should be taken. A hard task for an intruder in a big network is to spot printers and other interesting devices among all available devices. For this research, a list of the printers and how to logically nd them on the network was provided by the Computer & Communications Department of the university. An intruder will have a harder time locating those devices, and scanning randomly the network would be noisy and would also eliminate the sense of nding an good idle host for scanning. This paper can be concluded with the statement that although the randomization of the IPID is done by every mainstream operating system, network printers are lagging behind in this respect. Therefore, it is advisable for manufactures of all devices which provide networking, not only of computers, to assign the Identication eld of the IPHeader in a non-predictable way in order to prevent an attacker from using them for the TCP Idle Scan.

11

Acknowledgments I would like to thank Peter van Campen and Ben Polman from the Computer & Communications Department of Radboud University, who provided me with a list of existing network printers as well as helpful information about the university network and this way made my research a lot easier.

References [1] Filipe Almeida. idlescan.

http://www.ciar.org/ttk/tools/network-scanners/,

1999. [Online; Request on January, 18th of 2013]. [2] Filipe Almeida.

1999/Dec/58,

idlescan (ip.id portscanner).

http://seclists.org/bugtraq/

1999. [Online; Request on October, 9th of 2012].

[3] Steven M. Bellovin. Security Problems in the TCP/IP Protocol Suite. Computer

Communications Review, pages 3248, 1989. [4] Roya Ensa, Jong Chun Park, Deepak Kapur, and Jedidiah R. Crandall. Idle port scanning and non-interference analysis of network protocol stacks using model checking.

In Proceedings of the 19th USENIX conference on Security, USENIX Secu-

rity'10, pages 1717, Berkeley, CA, USA, 2010. USENIX Association. [5] Jon Erickson. Hacking: the art of exploitation, 2nd edition. No Starch Press, San Francisco, CA, USA, second edition, 2008. [6] Wireshark Foundation. Wireshark. Go deep.

https://www.wireshark.org/,

2012.

[Online; Request on November, 16th of 2012]. [7] Fernando

Gont.

Hacking

IPv6

Networks

-

Talk

at

Hack

In

http://www.gont.com.ar/talks/hip2011/ fgont-hip2011-hacking-ipv6-networks.pdf, 2011. [Online; Request on Paris

2011

Conference.

October, 9th of 2012]. [8] Information Sciences Institute, University of Southern California. RFC 793: Transmission Control Protocol.

https://www.ietf.org/rfc/rfc793.txt, 1981.

[Online;

Request on November, 12th of 2012]. [9] Erik

J.

Kamerling.

hping2idle.htm,

The

Hping2

Idle

Host

Scan

.

http://www.ouah.org/

2001. [Online; Request on November, 27th of 2012].

[10] Gordon Lyon. Nmap - Free Security Scanner For Network Exploration and Security Audits.

http://www.nmap.org/,

[11] Gordon Lyon.

2012. [Online; Request on October, 9th of 2012].

Nmap Reference Guide.

http://nmap.org/book/man.html,

[Online; Request on November, 26th of 2012].

12

2012.

[12] Gordon Lyon. The Ocial Nmap Project Guide to Network Discovery and Security

Scanning. Nmap Project, 2012. [13] Salvatore Sanlippo.

1998/Dec/79,

New TCP scan method.

http://seclists.org/bugtraq/

1998. [Online; Request on October, 9th of 2012].

[14] Salvatore Sanlippo.

1999/Oct/263,

predictable ip->id patch.

http://seclists.org/bugtraq/

1999. [Online; Request on January, 15th of 2013].

[15] Salvatore Sanlippo. Hping - Active Network Security Tool.

org/,

http://www.hping.

2006. [Online; Request on October, 9th of 2012].

[16] William Stallings. Network Security Essentials - Applications and Standards (4. ed.,

internat. ed.). Pearson Education, 2010. [17] Stuart Staniford, James A. Hoagland, and Joseph M. McAlerney. Practical automated detection of stealthy portscans. Journal of Computer Security, 10(1-2):105 136, July 2002. [18] Andrew Tanenbaum. Computer networks. Prentice Hall PTR, 2003. [19] The Internet Society. RFC 2460: Internet Protocol, Version 6 (IPv6) Specication.

https://tools.ietf.org/rfc/rfc2460.txt,

1998. [Online].

[20] Hai Zhang, Xuyang Zhu, and Wenming Guo.

TCP portscan detection based on

single packet ows and entropy. In Proceedings of the 2nd International Conference

on Interaction Sciences: Information Technology, Culture and Human, ICIS '09, pages 10561060, New York, NY, USA, 2009. ACM.

A. Source code Listing 2 shows the BASH script which uses the tool Hping for a proof of concept.

13

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

#!/bin/bash zombie=$1; target=$2; port=$3; inc=$4;

#hping can only be executed as root if [ $(whoami) != "root" ]

then echo "must be executed as root"; exit −1; 

#all necessary parameters? if [ $# −ne 4 ]

then echo "usage: $0 " exit −2; 

#

get the IPID from the idle−host ipid=$(hping3 −1 −c 1 $zombie 2>/dev/null | grep ip=$zombie | cut −d" " −f4 | cut −d"=" −f2)

#send a packet to the target−host on the target port, in the name of the zombie − ignore the output hping3 −a $zombie −S $target −p $port −c 1 2>/dev/null 1>/dev/null

#wait a second, so that the idle host has enough time to answer the target sleep 1

#get again the IPID from the idle host

ipid2=$(hping3 −1 −c 1 $zombie 2>/dev/null | grep ip=$zombie | cut −d" " −f4 | cut −d"=" −f2)

# if

check on how much the IPID incremented from the rst to the second time (( ipid = ipid + $inc)) [ $ipid −eq $ipid2 ] then echo "Port is closed" #it incremented once? So port is closed

else (( ipid = ipid + $inc)) if [ $ipid −eq $ipid2 ]

then echo "Port is opened" #it incremented twice? So the idle host sent another packet, the port is open

43

else

44 45 46 47

Listing 2: Proof of Concept





echo "Error in communication" #something

else? That's an error

14