RFC 1535 discusses vulnerabilities to this algorithm. Here is an example that illustrates the vulnerability:

% head -1 /etc/resolv.conf
domain mftg.notreal.com
% nslookup inv.mftg.notreal

At this point, the resolver first tries to look up this line:

mftg.notreal.com.mftg.notreal.com

This fails. Next, the resolver tries this:

mftg.notreal.com.notreal.com

This also fails. At this point, the resolver sees that only two parts remain to the domain part, and it quits, causing the nslookup to fail.

A hacker within the NotReal company could apply for the domain com.notreal.com, perhaps claiming that the domain oversaw the communications department. If the hacker owned the name server for this domain, the hacker could respond to the second resolver request. At this point, the hacker could start feeding false information to the resolver, perhaps permitting trust-based attacks using .rhosts to succeed.

The appropriate way to solve this problem is by explicitly listing a search list in the resolv.conf file to specify the exact domain search algorithm.

Investigating IP Spoofing

Although SATAN does not specifically investigate IP spoofing, it scans for vulnerabilities involving remote shell access and other services that can be exploited using IP spoofing as the next logical step.

Overview

The Internet is based on version 4 of IP. This version of IP does not include any provision for source authentication. If a version 4 IP packet arrives at a network destination, the upper layers of the network stack must be invoked to perform authentication.

Many applications are designed to trust a packet based on the IP address of the sender. These applications believe that if the packet was able to route itself to this destination, and reply packets are able to route themselves back to the source, the IP address of the source must be valid. (This is assuming that IP source routing is turned off.) These applications, if using TCP above IP, further believe that if the remote sender is able to continue a conversation on the TCP level, the connection is valid. Both of these assumptions are dangerous.

Exploiting It

In early 1995, CERT released an advisory on IP spoofing that addressed the following two problems:

•  Routers were permitting spoofed IP packets to cross over firewalls.

•  Spoofed IP packets were exploiting rshd/remshd by predicting TCP sequence numbers.

The first problem was caused by router misconfigurations. A router that connects an internal network to the Internet has at least two network ports. Imagine a router that had four ports, one of which is connected to the Internet. If a packet arrives from an internal IP address and is destined for another internal IP address, the router sends it to the correct destination port. If the packet arrives from the Internet, source restrictions prevent it from going to the internal network. For example, the firewall does not allow an external user to invoke the rsh/remsh service on an internal system by screening all requests to the shell TCP port originating from an external address.

Some routers, however, did not keep information on the port source of the IP packet. All the IP packets from all the ports were loaded into a single queue and then processed. If the packet indicated an IP source address from an internal network, that packet was approved for forwarding. Therefore, an external user just had to indicate an internal IP address to send the packet across the router.

By itself, this problem might be perceived to lead only to single packet attacks. The intruder would find it difficult to carry on a TCP connection because the internal host would be sending reply TCP packets to the internal address specified by the intruder’s fake packet. The intruder would not be able to acknowledge these packets because the intruder would not know what sequence number was in the packet.

This is when the second problem added to the vulnerability. The intruder used a TCP-oriented service, such as FTP, that was permitted to cross the router. The intruder connected to the target system and then disconnected. The hacker used the knowledge of the TCP sequencing algorithm to predict the sequence number of the packet that would be sent in response to the subsequent incoming TCP connection request. The hacker then sent the appropriate TCP connection request to the login or shell port. At this point, the target system responded to the SYN packet with a SYN ACK packet that was sent to the real internal host corresponding to the address the intruder indicated. The external system, however, has flooded this internal host with initialization packets, causing its response time to slow down drastically. As a result, this internal host does not send a RST but instead disregards the packet, and the external hacker blindly sent an ACK with the predicted sequence number to the target system. The target system assumed that the ACK that arrived originated from the internal host because it carried the correct ACK number and IP address. At this point, the intruder could send the normal data packets for the login or shell protocol, beginning attacks on these services.

Any service that relies on IP authentication is vulnerable to the attack described here. However, other attacks that exploit IP address authentication are also possible.

The rlogind and remshd servers approve access based on a hostname that is sent in the protocol. This hostname, which should match an entry in .rhosts or /etc/hosts.equiv, is specified by the client. Until a few years ago, no additional verification was made by the servers. Now, most servers take the IP address of the incoming connection and do a reverse lookup using the resolver getnamebyaddr() call.

This call attempts to contact the DNS server and find the name corresponding to the IP address. If these match, access is granted. If the DNS server exists outside the administrative domain of the user, verification of the identity of the client is not certain. The DNS server could have a contaminated cache containing faulty PTR records that point to the hacker’s own name server. The DNS server could be administered by the hacker and therefore provide untrusted information.

The ftpd server bounce problem, discussed earlier, also permits users to hide the true IP source of the connection by actually using the IP address of the system running the ftpd for the source of TCP connection. This vulnerability simplifies routing problems for the hacker.