Accessible TCP ports can be identified by port
scanning target IP addresses. The following nine different types of
TCP port
scanning are used in the wild by both attackers and security
consultants:
- Standard scanning methods
-
- Vanilla connect( ) scanning
- Half-open SYN flag scanning
- Stealth TCP scanning methods
-
- Inverse TCP flag scanning
- ACK flag probe scanning
- TCP fragmentation scanning
- Third-party and spoofed TCP scanning methods
-
- FTP bounce scanning
- Proxy bounce scanning
- Sniffer-based spoofed scanning
- IP ID header scanning
What follows is a technical breakdown for each TCP port scanning
type, along with details of Windows and Unix-based tools that can
perform scanning.
4.2.1 Standard Scanning Methods
Standard scanning methods, such as
vanilla and half-open SYN scanning, are extremely simple direct
techniques used to identify accessible TCP ports and services
accurately. These scanning methods are reliable but are easily logged
and identified.
4.2.1.1 Vanilla connect( ) scanning
TCP connect(
) port scanning is the most simple type
of probe to launch. There is no stealth whatsoever involved in this
form of scanning because a full TCP/IP connection is established with
TCP port one of the target host, then incrementally through ports
two, three, four, and so on.
TCP/IP's reliability as a protocol,
vanilla port scanning is a very
accurate way to determine which TCP services are accessible on a
given target host. Figures Figure 4-2 and Figure 4-3 show the various TCP packets and their flags,
as they are sent and received by the attacker and the host he is
scanning.
In Figure 4-2, the attacker first sends a SYN probe
packet to the port he wishes to test. Upon receiving a packet from
the port with the SYN and ACK flags set, he knows that the port is
open. The attacker completes the three-way handshake by sending an
ACK packet back.
Figure 4-2. A vanilla TCP scan result when a port is open
If, however, the target port is closed, the attacker receives an
RST/ACK packet directly back, as shown in Figure 4-3.
Figure 4-3. A vanilla TCP scan result when a port is closed
As before, the attacker sends a SYN probe packet, but the target
server responds with an RST/ACK. Standard connect(
) scanning in this way is a reliable way to identify
accessible TCP network services. The downside is that the scanning
type is extremely simple and hence easily identified and logged.
4.2.1.1.1 Tools that perform connect( ) TCP scanning
nmap can perform a TCP connect(
) port scan using the -sT flag. Other
very simple scanners exist; one such as pscan.c,
which is available as source code from many sites, including Packet
Storm (http://www.packetstormsecurity.org).
For Windows, Foundstone's
SuperScan is an excellent port-scanning utility
with good functionality. It's available from
http://www.foundstone.com/knowledge/scanning.html.
|
4.2.1.2 Half-open SYN flag scanning
Usually, a three-way handshake is initiated to synchronize a
connection between two hosts; the client sends a SYN packet to the
server, which responds with SYN and ACK if the port is open, and the
client then sends an ACK to complete the handshake.
In the case of
half-open
SYN port scanning when a port is found to be listening, an RST packet
is sent as the third part of the handshake. Sending an RST packet in
this way abruptly resets the TCP connection, and because you have not
completed the three-way handshake, the connection attempt often
isn't logged on the target host.
Most intrusion detection systems (IDS) and other security programs,
such as portsentry, can easily detect and prevent
half-open SYN port-scanning attempts. In cases where stealth is
required, other techniques are recommended, such as FIN or TTL-based
scanning, or even using a utility such as
fragroute, to fragment outbound probe packets.
Figures Figure 4-4 and Figure 4-5
outline the packets sent between the two hosts when launching a SYN
port scan and finding either an open and a closed port.
In Figure 4-5, a SYN probe packet is sent to the target
port; a SYN/ACK packet is received indicating that the port is open.
Normally at this stage, a connect( ) scanner sends
an ACK packet to establish the connection, but this is half-open
scanning so instead, a RST packet is sent to tear down the
connection.
Figure 4-4. A half-open SYN scan result when a port is closed
Figure 4-4 shows that when a closed port is found,
a RST/ACK packet is received, and nothing happens (as before in Figure 4-3). The benefit of half-open scanning is that a
true three-way TCP handshake is never completed, and the connection
doesn't appear to be established.
Figure 4-5. A half-open SYN scan result when a port is open
Nowadays, all IDS and personal firewall systems can identify SYN port
scans (although they often mislabel them as SYN flood
attacks due to the number of probe packets). SYN scanning
is fast and reliable, although it requires raw access to network
sockets and, therefore, privileged access to Unix and Windows hosts.
4.2.1.2.1 Tools that perform half-open SYN scanning
nmap can perform a SYN
port
scan under both Unix and Windows environments using the
-sS flag. Many other Unix half-open port scanners
exist, including strobe, which is available in
source form from many sites including Packet Storm (http://www.packetstormsecurity.org).
|
A second SYN port scanner worth mentioning is the
scanrand component of the
Paketto Keiretsu suite by Dan
Kaminsky.
Paketto Keiretsu contains a number of useful networking utilities
that are available at http://www.doxpara.com/read.php/code/paketto.html.
The
scanrand tool is very well designed, with
distinct SYN probing and background listening components so that you
can launch the quickest possible scans. Inverse SYN cookies (using
the HMAC SHA1 hashing algorithm) tag outgoing probe packets, so that
false positive results become nonexistent (because the listening
component registers only SYN/ACK responses with the correct
cryptographic cookies). Example 4-3 shows
scanrand identifying open ports on a local
network in less than one second.
Example 4-3. Using scanrand to quickly scan the local network
# scanrand 10.0.1.1-254:quick UP: 10.0.1.38:80 [01] 0.003s UP: 10.0.1.110:443 [01] 0.017s UP: 10.0.1.254:443 [01] 0.021s UP: 10.0.1.57:445 [01] 0.024s UP: 10.0.1.59:445 [01] 0.024s UP: 10.0.1.38:22 [01] 0.047s UP: 10.0.1.110:22 [01] 0.058s UP: 10.0.1.110:23 [01] 0.058s UP: 10.0.1.254:22 [01] 0.077s UP: 10.0.1.254:23 [01] 0.077s UP: 10.0.1.25:135 [01] 0.088s UP: 10.0.1.57:135 [01] 0.089s UP: 10.0.1.59:135 [01] 0.090s UP: 10.0.1.25:139 [01] 0.097s UP: 10.0.1.27:139 [01] 0.098s UP: 10.0.1.57:139 [01] 0.099s UP: 10.0.1.59:139 [01] 0.099s UP: 10.0.1.38:111 [01] 0.127s UP: 10.0.1.57:1025 [01] 0.147s UP: 10.0.1.59:1025 [01] 0.147s UP: 10.0.1.57:5000 [01] 0.156s UP: 10.0.1.59:5000 [01] 0.157s UP: 10.0.1.53:111 [01] 0.182s
Due to the way scanrand sends a deluge of SYN
probes and then listens for positive SYN/ACK responses, the order in
which the open ports are displayed will look a little odd. On the
positive side, scanrand is lightning fast; it
allows specific ports (e.g., common backdoors) to be identified in
seconds even across large networks, as opposed to minutes or hours
with a bulkier tool such as nmap.
4.2.2 Stealth TCP Scanning Methods
Stealth scanning methods involve
idiosyncrasies in the way TCP/IP stacks of target hosts process and
respond to packets with strange bits set or other features. Such
techniques aren't effective at accurately mapping
the open ports of some operating systems but do provide a degree of
stealth and are sometimes not logged.
4.2.2.1 Inverse TCP flag scanning
Security mechanisms such as firewalls and IDS usually detect
SYN packets being sent to sensitive
ports of target hosts. Programs are also available to log half-open
SYN flag scan attempts, including
synlogger
and
courtney.
Probe packets with strange TCP flags set can sometimes pass through
filters undetected, depending on the security mechanisms deployed.
Using half-open SYN flags to probe a target is
known as an inverted
technique because responses are sent back only
by closed ports. RFC 793 states that if a port
is closed on a host, an RST/ACK packet should be sent to reset the
connection. To take advantage of this feature, attackers send TCP
probe packets with various TCP flags set.
A TCP probe packet is sent to each port of the target host. Three
types of probe packet flag configurations are normally used:
- A FIN probe with the FIN TCP flag set
- An XMAS probe with the FIN, URG, and PUSH TCP flags set
- A NULL probe with no TCP flags set
Figures Figure 4-6 and Figure 4-7
depict the probe packets and responses generated by the target host
if the target port is found to be open or closed.
Figure 4-6. An inverse TCP scan result when a port is open
Figure 4-7. An inverse TCP scan result when a port is closed
The RFC standard states that, if no response is seen from the target
port, the port is open, or the server is down. This scanning method
isn't necessarily the most accurate, but it is
stealthy; it sends garbage to each port that usually
won't be picked up.
For all closed ports on the target host, RST/ACK packets are
received. However, some operating platforms (such as those in the
Microsoft Windows family) disregard the RFC 793 standard, so no
RST/ACK response is seen when an attempt is made to connect to a
closed port. Hence, this technique is effective against most
Unix-based operating systems.
4.2.2.1.1 Tools that perform inverse TCP flag scanning
nmap can perform an
inverse TCP
flag port scan under both Unix and Windows environments, using the
following flags:
- -sF
-
For a scan with only the FIN flag set on probe packets
- -sN
-
For a NULL scan with no TCP flags set on probe packets
- -sX
-
For an Xmas tree scan with all TCP flags set
vscan is another Windows tool you can use to
perform inverse TCP flag scanning. The utility
doesn't require installation of WinPcap network
drivers; instead it uses raw sockets within Winsock 2 (present in
Windows 2000, XP, and 2003). vscan is available
at http://host.deluxnetwork.com/~vsniff/vscan.zip.
4.2.2.2 ACK flag probe scanning
A stealthy technique documented by Uriel Maimon in
Phrack
Magazine, Issue 49, is that of identifying open
TCP ports by sending ACK probe packets
and analyzing the header information of the RST packets received from
the target host. This technique exploits vulnerabilities within the
BSD derived TCP/IP stack and is therefore only effective against
certain operating systems and platforms. There are two main ACK
scanning techniques that involve:
- Analysis of the time-to-live (TTL) field of received packets
- Analysis of the WINDOW field of received packets
These techniques can also check filtering systems and complicated
networks to understand the processes packets go through on the target
network. For example, the TTL value can be used as a marker of how
many systems the packet has hopped through. The
firewalk filter assessment tool works in a
similar fashion, available from http://www.packetfactory.net/projects/firewalk/.
4.2.2.2.1 Analysis of the TTL field of received packets
To analyze the TTL field data of received
RST packets, an
attacker first sends thousands of crafted ACK packets to different
TCP ports, as shown in Figure 4-8.
Figure 4-8. ACK probe packets are sent to various ports
Here is a log of the first four RST packets received using the
hping2 utility:
1: host 192.168.0.12 port 20: F:RST -> ttl: 70 win: 0 2: host 192.168.0.12 port 21: F:RST -> ttl: 70 win: 0 3: host 192.168.0.12 port 22: F:RST -> ttl: 40 win: 0 4: host 192.168.0.12 port 23: F:RST -> ttl: 70 win: 0
By analyzing the TTL value of each packet, an attacker can easily see
that the value returned by port 22 is 40, whereas the other ports
return a value of 70. This suggests that port 22 is open on the
target host because the TTL value returned is smaller than the TTL
boundary value of 64.
4.2.2.2.2 Analysis of the WINDOW field of received packets
To analyze the WINDOW field data of received RST
packets, an attacker sends thousands of the same crafted ACK packets
to different TCP ports (as shown in Figure 4-8).
Here is a log of the first four RST packets received, again using the
hping2 utility:
1: host 192.168.0.20 port 20: F:RST -> ttl: 64 win: 0 2: host 192.168.0.20 port 21: F:RST -> ttl: 64 win: 0 3: host 192.168.0.20 port 22: F:RST -> ttl: 64 win: 512 4: host 192.168.0.20 port 23: F:RST -> ttl: 64 win: 0
Notice that the TTL value for each packet is 64, meaning that TTL
analysis of the packets isn't effective in
identifying open ports on this host. However, by analyzing the WINDOW
values, the attacker finds that the third packet has a non-zero
value, indicating an open port.
The advantage of using ACK flag probe scanning is that detection is
difficult (for both IDS and host-based systems, such as personal
firewalls). The disadvantage is that this scanning type relies on
TCP/IP stack implementation bugs, which are prominent in BSD-derived
systems but not in many other modern platforms.
4.2.2.2.3 Tools that perform ACK flag probe scanning
nmap supports
ACK flag probe scanning, with the
-sA and -sW flags to analyze
the TTL and WINDOW values respectively. See the
nmap manpage for more detailed information.
hping2 can also sample TTL and WINDOW values,
but this can prove highly time consuming in most cases. The tool is
more useful for analyzing low-level responses, as opposed to port
scanning in this fashion.
hping2 is available from http://www.eaglenet.org/antirez/hping2.html
and http://www.hping.org.
4.2.3 Third-Party and Spoofed TCP Scanning Methods
Third-party port scanning methods allow
for probes to be effectively bounced through vulnerable servers to
hide the true source of the network scanning. An additional benefit
of using a third-party technique in this way is that insight into
firewall configuration can be gained by potentially bouncing scans
through trusted hosts that are vulnerable.
4.2.3.1 FTP bounce scanning
Hosts running outdated FTP services can relay numerous TCP
attacks, including port scanning. There is a flaw in the way many FTP
servers handle connections using the PORT command
(see RFC 959 or technical description of the PORT
feature) that allows for data to be sent to user-specified hosts and
ports. In their default configurations, the FTP services running on
the following platforms are affected:
- FreeBSD 2.1.7 and earlier
- HP-UX 10.10 and earlier
- Solaris 2.6/SunOS 5.6 and earlier
- SunOS 4.1.4 and earlier
- SCO OpenServer 5.0.4 and earlier
- SCO UnixWare 2.1 and earlier
- IBM AIX 4.3 and earlier
- Caldera Linux 1.2 and earlier
- Red Hat Linux 4.2 and earlier
- Slackware 3.3 and earlier
- Any Linux distribution running WU-FTP 2.4.2-BETA-16 or earlier
The FTP bounce attack can have a far more devastating effect if a
writable directory exists because a series of commands or other data
can be entered into a file and then relayed via the
PORT command to a specified port of a target host.
For example, someone can upload a spam email message to a vulnerable
FTP server and then send this email message to the SMTP port of a
target mail server. Figure 4-9 shows the parties
involved in FTP bounce scanning.
Figure 4-9. FTP bounce port scanning
The following occurs when performing an FTP bounce scan:
- The attacker connects to the FTP control port (TCP port 21) of the vulnerable FTP server that she is going to bounce her attack through and enters passive mode, forcing the FTP server to send data using DTP (data transfer process) to a specific port of a specific host:
QUOTE PASV 227 Entering Passive Mode (64,12,168,246,56,185).
- A PORT command is issued, with an argument passed to the FTP service telling it to attempt a connection to a specific TCP port of the target server; for example, TCP port 23 of 144.51.17.230:
PORT 144,51,17,230,0,23 200 PORT command successful.
- After issuing the PORT command, a LIST command is sent. The FTP server then attempts to create a connection with the target host defined in the PORT command issued previously:
LIST 150 Opening ASCII mode data connection for file list 226 Transfer complete.
If a 226 response is seen, then the port on the target host is open. If, however, a 425 response is seen, the connection has been refused:LIST 425 Can't build data connection: Connection refused
4.2.3.1.1 Tools that perform FTP bounce port scanning
nmap for both Unix and Windows can effectively
perform an FTP bounce port scan, using the -P0 and
-b flags in the following manner:
nmap -P0 -b username:password@ftp-server:port <target host>
4.2.3.2 Proxy bounce scanning
Attackers bounce
TCP attacks through open proxy servers.
Depending on the level of poor configuration, the server will
sometimes allow a full-blown TCP port scan to be relayed. Using proxy
servers to perform bounce port scanning in this fashion is often time
consuming, so many attackers prefer to abuse open proxy servers more
efficiently by bouncing actual attacks through to target networks.
ppscan.c, a publicly available Unix-based tool to
bounce port scans, can be found in source form at:
- http://www.dsinet.org/tools/network-scanners/ppscan.c
- http://www.phreak.org/archives/exploits/unix/network-scanners/ppscan.c
4.2.3.3 Sniffer-based spoofed scanning
An innovative half-open SYN TCP port
scanning method was realized
when jsbach published his spoofscan Unix-based
scanner in 1998. The
spoofscan tool is run as root on a given host to
perform a stealthy port scan. The key feature that makes this scanner
so innovative is that it places the host network card into
promiscuous mode and then sniffs for responses on the local network
segment.
The following unique benefits are immediately realized when using a
sniffer-based spoofing port scanner:
- If you have superuser access to a machine on the same physical network segment as the target host or a firewall protecting a target host, you can spoof TCP probes from other IP addresses to identify trusted hosts and to gain insight into the firewall policy (by spoofing scans from trusted office hosts, for example). Accurate results will be retrieved because of the background sniffing process, which monitors the local network segment for responses to your spoofed probes.
- If you have access to a large shared network segment, you can spoof scans from hosts you don't have access to or that don't exist (such as unused IP addresses within your local network segment), to effectively port scan remote networks in a distributed and stealthy fashion.
The beauty of this method is that the attacker is abusing his access
to the local network segment. Such techniques can even be carried out
to good effect in switched network environments using ARP redirect
spoofing and other techniques. spoofscan is
available at
http://examples.oreilly.com/networksa/tools/spoofscan.c.
4.2.3.4 IP ID header scanning
IP ID header scanning (also known as
idle or dumb scanning) is
an obscure scanning technique that involves abusing implementation
peculiarities within the TCP/IP stack of most operating systems.
Three hosts are involved:
- The host, from which the scan is launched
- The target host, which will be scanned
- A zombie or idle host, which is an Internet-based server that is queried with spoofed port scanning against the target host to identify open ports from the perspective of the zombie host
IP ID header scanning is extraordinarily stealthy due to its blind
nature. Determined attackers will often use this type of scan to map
out IP-based trust relationships between machines, such as firewalls
and VPN gateways.
The listing returned by the scan shows open ports from the
perspective of the zombie host, so you can try scanning a target
using various zombies you think might be trusted (such as hosts at
remote offices or DMZ machines). Figure 4-10 depicts
the process undertaken during an IP ID header scan.
Figure 4-10. IP ID header scanning and the parties involved
hping2 was originally used in a manual fashion
to perform such low-level TCP scanning, which was time consuming and
tricky to undertake against an entire network of hosts. A white paper
that fully discusses using the tool to perform IP ID header scanning
by hand is available from http://www.kyuzz.org/antirez/papers/dumbscan.html.
nmap supports such IP ID header scanning with
the option:
-sI <zombie host[:probe port]>
Example 4-4 shows how nmap uses
this functionality to scan 192.168.0.50 through
192.168.0.155.
Example 4-4. Using nmap to perform IP ID header scanning
# nmap -P0 -sI 192.168.0.155 192.168.0.50 Starting nmap 3.45 ( www.insecure.org/nmap/ ) Idlescan using zombie 192.168.0.155; Class: Incremental Interesting ports on (192.168.0.50): (The 1582 ports scanned but not shown below are in state: closed) Port State Service 25/tcp open smtp 53/tcp open domain 80/tcp open http 88/tcp open kerberos-sec 135/tcp open loc-srv 139/tcp open netbios-ssn 389/tcp open ldap 443/tcp open https 445/tcp open microsoft-ds 464/tcp open kpasswd5 593/tcp open http-rpc-epmap 636/tcp open ldapssl 1026/tcp open LSA-or-nterm 1029/tcp open ms-lsa 1033/tcp open netinfo 3268/tcp open globalcatLDAP 3269/tcp open globalcatLDAPssl 3372/tcp open msdtc 3389/tcp open ms-term-serv Nmap run completed -- 1 IP address (1 host up)
|
vscan is another Windows tool that can
perform the same inverse IP ID scanning. As discussed earlier, the
vscan utility doesn't require
installation of WinPcap network drivers. Instead, it uses raw sockets
within Winsock 2 (present in Windows 2000, XP, and 2003).
vscan is available at http://host.deluxnetwork.com/~vsniff/vscan.zip.
Figure 4-11 shows the vscan
utility in use, along with its options and functionality.
Figure 4-11. vscan used to launch an IP ID header scan
0 comentarii:
Trimiteți un comentariu