operating system and application in use.
The services detected as listening may suffer from vulnerabilities which may result from two reasons:
- Mis-Configuration of the service
- The version of the software is known to have security flaws
If identified, these vulnerabilities can lead to unprivileged access gained by the attacker.
We will further discuss port scanning types, techniques, and tools.
- Port Scanning Types:
With this type of scan we use the basic TCP connection establishment mechanism. To open a connection to an interesting port on the targeted machine:
- A SYN packet is sent to the target’s system interesting port.
- Now we wait to see what type of packet is sent back from the target.
- If a SYN/ACK packet is received it usually means the port is in a LISTENING state.
- If a RST/ACK packet is received, it usually means the port is not LISTENING and the connection will RESET.
- We finish the three-way handshake (if SYN/ACK packet was received) by sending an ACK.
- A connection is terminated after the full connection establishment process has been completed.
This kind of scan is easily detected. Inspecting the target system log will show a number of connections and error messages immediately after each one of them was initiated.
This is also called half open scanning. This type of scan differs from TCP connect() scan because we do not open a full TCP connection. You send a SYN packet to initiate the three-way handshake and wait for a
response. If we receive an SYN/ACK it indicates the port is LISTENING. If we receive an RST/ACK it indicates a NON-LISTENING port.
If we do receive a SYN/ACK packet we immediately tear down the connection by sending a RESET.
Because the TCP three-way handshake was not completed some of the sites will probably not log these scanning attempts.
Chris Klaus was one of the first people to write a paper about stealth scans. In a paper called
“stealth scanning – Bypassing Firewalls/SATAN Detectors”
9, he describes a technique which intentionally violates the TCP three- way handshake.
This technique is what people refer to today as “half-open” scanning.
Today, some people use the “stealth” term to mean NULL flags (no flags or code bits set).
“Stealth” can also be defined as a scanning technique family, doing one of the following:
- Pass through filtering rules.
- Not to be logged by the targeted system logging mechanisms.
- Try to hide themselves at the usual site / network traffic.
- Explicit Stealth Mapping Techniques
The frequently used explicit mapping techniques are:
This scan intentionally disregards the TCP three-way handshake. We send a SYN/ACK packet, which is step two in the TCP three- way handshake, while there is no SYN packet sent for step one.
Sending SYN/ACK packet to a closed port:
Because TCP is stateless, it knows no SYN has been sent, which is the first step in the three-way TCP handshake. TCP figures this packet must be a mistake and sends a RESET to tear down the connection. This is what we wished for any kind of response to give away the existence of the system and the fact that the probed port is closed.
If we send the SYN/ACK to an open port, it will ignore any such packet
The FIN scan uses the FIN packet as the probe. The hacker sends a FIN packet to a targeted port on a probed system and waits for a response11.
XMAS is a scanning type, which sends a TCP packet with the URG, ACK, PST, RST, SYN and FIN flags set. All the TCP flags are set.
Null scan is a scanning type, which sends a TCP packet that turns off all flags. The probed system should send back a RESET to all closed ports.
According to RFC 793 this should work against every implementation of TCP regardless of the operating system it runs on. Life is not always simple. Windows, CISCO, BSDI, HP/UX, MVS & IRIX have a broken TCP implementation – they send RESETs to open ports as well.
A group of techniques, which gathers information about hosts or networks that, are unreachable. By having a clue about what is not there we make assumptions about where things are.
Routers will give away internal architecture information of a network, even if the question they were asked does not make any sense.
A router looks at the IP address and makes decisions based on that. The RESET, which is out of place, is not taken into any consideration. The router will report addresses that do not
exist with host (or net) unreachable or time exceeded message.
The probing computer sends answers to domain questions that were never asked. The goal here is to get ICMP unreachable messages for a host or a subnet that do not exist.
- Proxy Scanning / FTP Bounce Scanning
The FTP protocol supports the following scenario:
Attacker.com connects to an FTP server, which has a world writable directory, and establishes a control communication connection. The attacker can then ask the FTP server to initiate an active server data transfer process and send a file anywhere on the Internet, presumably to a user data transfer process.
Hobbit wrote a post to Bugtrack on July 12 1995 where he described this kind of attack.
Under the “other possibilities” section,
He wrote that this protocol flaw
“Can be used to post virtually untraceable mail and news, hammer on services of various sites, fill up disks, try to hop firewalls, and generally be annoying and hard to track down at the same time”.
This method can be used to scan TCP ports from a “proxy” FTP server.
This scan is rather slow. Some FTP servers disable the “Proxy” feature, but there are still many who do not, making this kind of scanning still available.
- TCP Reverse Ident Scanning
The ident protocol (RFC 141316) is used to determine the owner username of a particular TCP connection by communicating with port.
This involves opening a full TCP connection to the target machine port.
The scanning method gives the attacker information that helps determine which server to attack.
If a certain server is running as “root”, and one of its services was compromised, attackers can gain instant root access. So it is more common that in a group of services that can be attacked, the services which are at the highest privilege will be attacked first.
b) Port Scanning Techniques
Many commercial intrusion detection systems and firewalls are looking for sequential connection attempts. When the pattern is matched a port scan is reported.
Randomizing the sequence of ports probed may prevent detection.
Intrusion detection systems can determine if a specific IP tries to port scan the network they are defending. It is done by analyzing the network traffic over a certain amount of time.
The amount of time is called the site detection threshold.
Some hackers are very patient and can use network scanners that spread out the scan over a long period of time.
If the attacker can guess the detection threshold of its target, he can reduce the chances of detection to a minimum or even to no detection at all, as long as he doesn’t include a signature with his packet that alerts the intrusion detection system in other way.
All IP packets that carry data can be fragmented.
If we need to send information using TCP and to fragment our data, normally the destination port and source port along with the flags field will be “travelling” at the first packet sent.
RFC 79117 defines the minimum and maximum sizes of fragments.
In the case of TCP the 8 octets of data (minimum fragment size) are enough to contain the source and destination port numbers. This will force the TCP flags field into the second fragment.
Some filtering devices and intrusion detection systems may incorrectly reassemble or completely miss portions of the scan. They may assume that this was just another segment of traffic that has already passed through their access list.
Some network scanners include options for Decoys or spoofed addresses in their attacks.
It would appear to the attacked network / host that the host(s) you specified as decoys are scanning them as well. This will drive intrusion detection systems into thinking that the target network is being port scanned by all the hosts, and determining who the real attacker is, will
be nearly impossible.
One way that helped intrusion detection systems detect the decoy hosts in the past was the TTL (Time to Live) field values in the scanned packets. If all the incoming packets TTL values have the same value, it is likely that they were generated in the same “factory”.
If the attacker is using nmap intrusion detection systems cannot use this method since nmap generates random TTL fields between 51- 65.
Probing a few target systems from a single IP within a certain amount of time will usually turn on the alarm of the intrusion detection systems.
We have already discussed a way to try to bypass this – using slow scans. But even a slow scan can sometimes be detected.
When a group of attackers are working together to achieve a common goal, trying to get unauthorized access on a targeted network for example, we call this – coordinated attacks.
Coordinated attacks can be used to target a single host or even an entire network.
If multiple IPs probe a target network, each one of them probes for a certain service on a certain machine in a different time period, and therefore it would be nearly impossible to detect these scans.
When coordinated attack efforts are aimed at a certain host, the detection (if any at all) is dependent on the time period these probes take place.
Coordinated attacks, when intelligently launched, are the most discrete way of probing a target. Most of them are still undetected.
(D) Operating System Detection
Because many security holes are operating system dependent, identifying which operating system runs on the target host / machine is of major importance.
An attacker can scan a range of IPs for opened TCP and UDP ports and the operating system type. Then he can put the list aside for a while.
When a security hole that is operating system dependent is discovered, all the attacker has to do is pull the list and look for a matching information.
Some services can be used to identify an operating system. The TELNET service is the most notable example. If a system provides the TELNET service, just by telneting to the box and looking at the welcome banner we can, in most cases, identify the operating system:
[root@pooh] # telnet 192.168.1.13
Debian GNU/Linux 2.1 target.domain.com
target login:
Other services have banners that give the same information, for example the mail server:
220 target.domain.com ESMTP Sendmail 8.9.3/8.9.3/Debian/GNU; Thu, 28 Oct 1999 09:56:32 +0200
Today, an increasing number of systems keep their banners turned off or make their banners display forged information.
Some applications leak information. A good example is the SYST command on FTP servers and IIS server:
[root@pooh] # telnet 192.168.1.17
get
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/4.0
Date: Thu, 28 Oct 1999 08:29:46 GMT
Content-Type: text/html
Content-Length: 87
<html><head><title>Error</title></head><body>The parameter is incorrect. </body></html>
The Host information record is a pair of strings identifying the host’s hardware type and the operating system.
www IN HINFO “Sparc Ultra 5” “Solaris 2.6”
This is an old technique that is rarely effective today because administrators avoid using this record.
- TCP/IP Stack Fingerprinting
Stack fingerprinting is a technique that uses distinct variations in TCP stack implementation to determine the type of a remote operating system.
The idea is to send “specific” TCP packets to the target IP and observe the response. The response will be unique to a certain group or individual operating system(s). The response varies because one vendor’s IP stack implementation is not the same as another. This comes from different interpretation of specific RFC guidelines when vendors wrote their TCP/IP stack.
The tools often used for stack fingerprinting are Queso written by Savage, and Nmap. Nmap has a larger database of responses of operating systems than any other tool. In order to get maximum reliability, Nmap needs at least one port opened at the target host.
The definite information source of the subject is Fyodor’s article “Remote OS Detection via TCP/IP Stack Fingerprinting”.
- Types of Probes Used to Determine the Operating System Type
A FIN packet is sent to an open port. RFC 793 states that the correct behavior is not to respond to the FIN packet.
Many stack implementations will respond with a RESET. This group includes:
Windows, BSDI, CISCO, HP-UX, MVS, and IRIX with a RESET.
Here, a SYN packet with an undefined flag set is sent to the targeted host.
Machines running the Linux operating system with kernel prior to 2.0.35 will keep the flag set in their response.
Some operating systems will RESET the connection when getting this kind of probe.
- TCP Initial sequence number sampling
Finding patterns of the initial sequence numbers chosen by the TCP implementations when responding to a connection request.
We can divide the answers into four groups:
• Traditional 64k (older UNIXs)
• Random increment (FreeBSD, DG-UX, IRIX, new versions of Solaris)
• True “random” (Linux)
• Time dependent modules (MS Windows)
To enhance performance some operating systems set the “Don’t fragment bit”.
Monitoring this behavior can give the attacker more information about the targetoperating system.
Some stack implementations have a unique initial window size on their returned packets.
In some cases IP stacks even differ in the value they use for the ACK field.
For example, sending a FIN|PSH|URG to a closed port. Most implementations will set the acknowledgement number in the returned packet to be the same as the sequence number received. Windows responds with an ACK field that is the sequence number+1.
- ICMP error Message Quenching
RFC 1812 25 suggests limiting the rate at which various error messages are sent.
Only a few operating systems are known to follow this RFC.
An attacker can use this to send UDP packets to a random, high UDP port and count the number of unreachable messages received within a given amount of time.
ICMP error messages should quote a small amount of information from the ICMP message that caused the error.
The information is quoted when the PORTUNREACHABLE message is received inthe IP header + 8 bytes, with almost all the implementations. Solaris sends more information than is needed and Linux even more.
- ICMP Error Message Echoing Integrity
When sending back an ICMP error message, some stack implementations may alter the IP header.
If an attacker examines the types of alternation that have been made to the headers, he may be able to make certain assumptions about the target operating system.
When an ICMP PORT UNREACHABLE message is sent, an attacker can examine the type of service field.
Nearly all implementations use 0 for this value, Linux uses 0xC0.
Different stack implementations handle overlapping fragments differently. This was pointed out by Thomas Ptacek and Tim Newsham in their paper “Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection”.
Some implementations will either overwrite the old data portions with the new data or vice versa, when the fragments are reassembled.
RFC 793 defines the TCP options. RFC 1323 26 defines the more advanced TCP options.
• Not all hosts implement TCP options
• When sending a query with an option set to a targeted host, the target host will set the option in the reply only if it supports it.
• We can test all the options at the same time if we send one packet that includes all the options.
When you examine the response packet, you look at the Options field for Options that were set. These are the supported options.
Some operating systems support all the advanced options while others support very
few.
(E) Firewalking:
Firewalking is a technique used to gather information about a remote network protected by a firewall.
The technique is being used for two purposes:
- Determining the rule set or ACL of a firewall or other packet-filtering device (mapping open ports on a firewall).
- Mapping a network behind a firewall. When a firewall’s policy is to drop ICMP ECHO Request/reply this technique is very effective.
How does Firewalking work?
It is using a trace route-like packet filtering to determine whether or not a particular packet can pass through a packet-filtering device.
Since trace route is dependent on the IP layer (TTL field), any transport protocol can be used the same way (TCP, UDP, and ICMP).
For Firewalking we need two pieces of information in advance:
- The IP address of the last known gateway before the firewalking takes place
- The IP address of a host located behind the firewall.
The first IP address serves as our waypoint. The second IP address is used as a destination to direct the packet flow.
If we try to trace route the machine behind a firewall and get blocked by an ACL filter that prohibits the probe, we can only determine what the last gateway which responded was probably the firewall. The firewall then becomes a waypoint for further investigations. We try again to traceroute the same machine, this time we use a different traceroute-like probe using a different transport protocol. If we get a response we can conclude the following:
- That particular traffic is allowed by the firewall
- We know a host behind the firewall
If we are continuously kept blocked by the ACL filters at out waypoint, we know that this kind of traffic is blocked.
Trying to pass packets on all ports and protocols through the firewall and monitor the response, will produce the ACL.
Sending packets to every host behind the packet-filtering device can generate an accurate map of a network’s topology.
