Introduction
The nature of computing has changed so rapidly in the last few years that by the beginning of the 21st century many techniques common to hackers working in the 1980s or even early 1990s have become obsolete overnight. Consider the Internet connection, once only available to students, academics, and dedicated hackers. Many ex-students, having experienced the Internet while at university, would continue to use the Internet from their home by dialling into a university dial-up connection and using a legitimate account, or hacking at the password until they got an account. Once inside the machine they had all the speed and bandwidth of a UNIX or VMS box, with the added advantage of global Internet connectivity at the price of a local call. The use of Internet dial-ups spread amongst the underground hacking fraternity very quickly, with articles appearing in PHRACK and LOD/H teaching UNIX commands and TCP/IP protocols very early on.
The rise of the global Internet to the status it enjoys today was fuelled by two things which happened about the same time. The first was the birth of the Internet Service Provider (ISP), who by purchasing a T1 line, routers and modems, could offer Internet Dial-up Services to anyone with a computer, a modem and phone line for a small monthly outlay. The second was the invention of HyperText Markup Language (HTML), the basic language used to build the World Wide Web (WWW), and which made Internet navigation a simple "point and click" exercise understandable by anyone. Prior to this the Internet was navigated using the standard UNIX TCP/IP tools, such as telnet or ftp, which relied on the use of a command line. Packages to read email were pretty basic, LISTSERV lists and USENET were the forum for communication between people with collective interests, and "anonymous" ftp servers hosted shared programs and textfiles.
Because of this change in emphasis, many hackers have never had to scan for carriers, work on the finer points of phone phreaking or enjoy a late-night trashing session. Instead they have begun by using the Internet from the very beginning, and have had the time to thoroughly explore and colonize the World Wide Web. Whether you are an ordinary user or wannabe hacker on the Internet, you need to know how to protect yourself, as the moment you show your nick on an IRC channel like #hack or #phreak you will be making yourself a target for all sorts of mischief.
If you are an Internet user who wants to learn about hacking network protocols and services, you must learn to assess security risks for yourself, rather than being placed in a state of Fear, Uncertainty and Doubt (FUD) by yet another "hacker menace" article in the media. Either way, using the information in this chapter will help you to understand the low level protocols that make up the Internet, the higher level services that transport data across the Internet, and how these are commonly compromised and protected, while hopefully encouraging you to explore further still.
Introduction to TCP/IP
TCP/IP protocol architecture is divided into four basic layers, like layers of a cake, each layer depending on the layer underneath. As data is sent from a computer it is moved down through layers of the stack, each layer adding its own control information called a "header" to the data it receives from the layer underneath it, a process called "encapsulation". Once the information arrives, the reverse procedure takes places, as each layer reads the header and removes it before passing the remaining information up the stack.
Figure 2: TCP/IP transport layers are like layers of a cake
Figure 3: Encapsulation works as data moves down the TCP/IP "stack"
Layer 1: Network Access Layer
The Network Access Layer defines the physical transmission of signals along the network, working at the hardware level so that the network device knows how the binary information can be sent and received. It is capable of encapsulating data into "packets" or "frames", the form capable of being transmitted across the network, and when used on a Ethernet LAN provides the mapping from the IP address to the hardware address of the Ethernet card. Using a low-level protocol called Address Resolution Protocol (ARP), the IP Layer maps the MAC address, a unique address consisting of six hexadecimal characters, 00:E0:7D:72:25:AB, to an IP address.
A computer uses ARP to find computers on a network by keeping a table of MAC and IP addresses mappings, enabling it to communicate with the remote computer by embedding the correct MAC address into the low-level IP packets. If the ARP software gets a request for a computer whose IP address is not in the ARP cache, it broadcasts a message to every host on the LAN asking for the computer with the missing IP entry to identify itself, and when the remote computer gets the ARP request it sends back a packet containing the missing MAC address so that the ARP cache now contains both the IP address and the MAC address of the missing computer.
You can spot ARP traffic on the network if you are using a network sniffer. Try flushing your ARP cache on a LINUX box and then monitor network traffic as the ARP packets fly across the net to rebuild the cache. End users never need to worry about ARP, MAC addresses and the Network Access Layer, and even most systems administrators never need to worry about it. A good understanding of low-level network access protocols will aid your hacking attempts, and understanding the difference between ETHERNET_802.3, ETHERNET_802.2 and ETHERNET_II frame types is vital when running a heterogeneous network where interoperability between different systems is mission critical.
Layer 2: Internet Layer
The Internet Layer sits above the Network Access Layer and is provides the basic packet delivery service used by the layers above it by encapsulating the information into packets called "datagrams". Internet Protocol (IP) is a "connectionless" protocol, meaning that it doesn't wait for the destination host to say "hello" before sending any datagrams to it, but sends datagrams anyhow. This might seem a bit crazy, but any handshaking and error checking is done by the next layer up, which means that all IP has to do is take the segments handed down from the Transport Layer, encapsulate them into datagrams and pass them down to the Network Access Layer to be encapsulated into the correct frame type for onward transmission. Another advantage of IP is that all TCP/IP routing can be done at the IP level, rather than at the Transport or Application Layer.
IP delivers the datagram by looking at the IP Destination Address in the header of the datagram, and checks the IP address is on the local network. All it has to do is deliver it, because it knows the MAC address through ARP resolution. If the IP Destination Address is a non-local address, the IP Layer needs to pass the datagram to a "router" or "gateway" to the non-local address. The IP software on any computer has been configured with a number of different "routes" that are going to enable the datagram to arrive at a non local address, according the IP address in the datagram. Any datagrams with a non-local network address will be sent to an external router which might or might not be on the non-local address of the IP address inside the packet. Once the external router receives the packet, it looks at the destination address in the datagram header and whether the address is local. If it is, it sends it to that computer, otherwise it looks at its own list of routes and sends it to yet another external router where the process continues.
Eventually the IP datagram should be routed into the correct network segment where it can be delivered to the destination machine as the destination address in the header is now a local network address. On the way through all these routers and gateways, the IP packet could end up being "fragmented" into smaller datagrams for onward transmission, which when received by the destination machine have to be re-assembled by the IP Layer before being passed up to the Transport Layer. When the IP Layer sends the packet up to the Transport Layer it must ensure that the data portion of the datagram is passed to the correct protocol of the Transport Layer, which it does using the Protocol Number embedded in the datagram header.
Figure 4: IP packet structure
Layer 3: Transport Layer
The Host to Host Transport Layer in TCP/IP is responsible for passing data between the Applications Layer and the Internet Layer, and consists of two main protocols, Transport Control Protocol (TCP) and User Datagram Protocol (UDP).
Transport Control Protocol, the "TCP" in TCP/IP, is a connection-based protocol with full handshaking providing a reliable delivery service with error detection and correction at both ends. TCP creates a connection between machines by using a three-way handshaking dialogue before sending any actual data. An originating host wishing to connect to a target host will start by sending a TCP segment with the Synchronize Sequence Numbers (SYN) bit set, and which contains the TCP sequence number the originating host wishes to use. The target responds by sending a segment with the SYN and Acknowledge (ACK) bit set, and which also contains the TCP sequence number the target wishes to use. Now that both hosts have established communication and agreed on the sequence number of the segments they are exchanging, the originating host can send a final segment containing its own ACK of the target's sequence number and data transfer can start. This SYN/ACK sequence can be used for an attack on an Internet host, an exploit that will be covered in more detail later.
Once TCP has received the data, it can then be passed on to the Application Layer, but TCP needs to ensure that the data is passed to the correct application, so when it passes the segment to the Application Layer above it also passes the "port number" (see below) from the Destination Port part of the TCP segment.
Figure 5: TCP packet structure
User Datagram Protocol (UDP) is different from TCP in that no connection is established between the originating host and the target host prior to the sending of data - packets are sent regardless. UDP is often described as an "unreliable connectionless" protocol, which means that there it does not have any mechanism for establishing a connection via handshaking, nor any form of error detection and correction. If an application requires handshaking, or error detection and correction, this has to be provided at the Application Layer, rather than inside the Transport Layer when UDP is used.
Figure 6: TCP uses a three-way handshake to make a connection
Layer 4: Applications Layer
The final layer in the TCP/IP stack is the Applications Layer, where programs actually do something with the data received. There are many applications that use the TCP/IP, and the TCP Layer is responsible for sending the data to the correct application. Application processes, also known as "network services", are all identified by "port numbers" which are contained in the header of the TCP or UDP packet, and this makes it easy for TCP to route each segment to the correct applications by looking at a single 16-bit field in the segment. In order to make communication between computers using TCP/IP simple, early UNIX systems assigned ports to a list of "well known services", reserving ports below 1024 as "privileged" ports. Most implementations of TCP/IP do not allow non-privileged users to use these ports, so to access ports that would normally be unavailable you should install a decent operating system like LINUX.
Here is a list of a few of the "well known" ports, along with the corresponding network service on the other side of the port. Remember a service is only a program that accepts TCP/IP data sent to that port - this is important for reasons that become apparent later this chapter. The examples below will be useful when we start to explore further by manually logging into the ports of a target computer, a process known as "port scanning". If you require a fuller list of port assignments, look in a file called /etc/services on a UNIX/LINUX box or C:\WINDOWS\SERVICES on a TCP/IP enabled Win95 box.
Service Port Number Description ECHO 7 Echo of input NETSTAT 15 Network Statistic Service FTP 21 File Transfer Protocol TELNET 23 Network Terminal Protocol SMTP 25 Simple Mail Transfer Protocol FINGER 79 finger Service HTTP 80 HyperText Transfer Protocol (WWW)
Table 5.1: Some "well known" ports and the services behind them
IP Addressing Concepts
Each IP address is composed of a sequence of 4 "octets" or bytes, either written in decimal, that is 199.0.0.166, or more unusually in hex. The value of the bytes in the IP address enables network and hosts mapping according to the value of the initial octet. The difference in the initial octet leads to different "classes" of networks, each with a different number of potential hosts. Here is a quick description of how it all breaks down, but to really understand the Internet addressing scheme, you need a reasonable grasp of binary to decimal conversion (some octal wouldn't hurt either!), which was covered in Chapter 2.| Class | Address Range | Networks | Hosts |
| A | 1.0.0.0 to 126.0.0.0 | 126 | 16,777,214 |
| B | 127.1.0.0 to 191.254.0.0 | 16,384 | 65,534 |
| C | 192.0.0.0 to 192.233.255.254 | 2,097,151 | 254 |
| D | 223.0.0.0 to 255.0.0.0 | n/a | n/a |
Table 5.2: IP address classes, with address ranges and numbers of networks and hosts addressed
No host or network part IP address can consist of all 1s or all 0s, and the first three bits determine the class of the IP address. If the first three bits of the first octet is "000", then the first byte is the network address, and the next three bytes the host address, making it a Class A address. If the first three bits of the first octet are "100", then the first two octets are the network address, and the next two bytes the host address, meaning it is a Class B address. If the first three bits of the first octet are "110", then the first three bytes are the network address, and the last byte the host address, meaning it is a Class C address. The joker in the pack is the special Class D address, where the first three bits of the first octet are "111". These addresses are reserved for future experiments in "multicasting" where groups of networks, or groups of computers are all sent datagrams simultaneously.
Figure 7: Diagram showing IP addressing relationships
DNS Addressing Concepts
You might be wondering by now how all these IP addresses correspond to the Internet addresses that we all type into our browsers while surfing the web, and the answer is the Domain Name System (DNS). In the early days of the ARPANET, all computers had a list of host names and IP addresses of all other computers connected to the net in a file. This list was manually updated, and every time a new host or network joined the net, the list had to be circulated around to all the other hosts on the net. While this might be practical for a few hundred hosts on the ARPANET, the expansion into the present day Internet, with millions of hosts, would have been impossible without the creation of the DNS to provide host address lookup.
The DNS is a distributed database designed to make the problem of making host name to IP address mappings easier than the older hosts file system. It also provides some redundancy if a single computer holding part of the database, called an Internet "nameserver", should fail for some reason. The DNS system divides the Internet into a number of top level "domains", such as org, com and edu, and underneath each top level domain are a number of "sub-domains", rather like the branches of an upside-down tree with the computer hosts being the individual leaves of the tree. The Internet name of your computer is determined by traversing the branching structure up from your host computer to the top level domain. So to find the Internet name of "fred" we move up the tree to the domain "flint" and then to the top level domain of "edu", giving the full name of the host as "fred.flint.edu". The tree structure of the DNS guarantees that there are no "name collisions" on the Internet. By inheriting the domain names as we move up from the leaves of the tree, names such as "fred.flint.edu", "fred.whitehouse.gov" and even "fred.rocky.edu" are possible.
Figure 8: Diagram illustrating how DNS relationships work
Looking after pieces of the tree are DNS "nameservers" that divide the DNS naming space into "zones", and which contain all information about a zone, except information that is "delegated" to nameservers in other sub-domains. DNS software is in two parts, the nameserver itself that contains the database, and the "resolver" that looks for names not in the database. If your nameserver doesn't know the IP of the computer, it knows another nameserver that does. Making a DNS query means that your computer asks the nameserver nearest you for an address resolution, and if the local nameserver hasn't got the information you require it will then go away and ask other nameservers, which ask other nameservers until you get an answer or the message comes back "cannot resolve hostname". When adding a system or network to the Internet, systems administrators have to provide and keep up to date all the necessary information to enter their system records into the DNS system. When connecting to the Internet, it is important to set up your TCP/IP networking correctly so that your host can find the DNS nameserver, or you will have to type IP addresses to connect to anything. The diagram below illustrates the flow of data as a remote host resolves the address "fred.flint.edu".
Figure 9: DNS address resolution works by asking nameservers in other domains repeatedly, until the address resolves
Connecting to the Internet
When you connect to the Internet via your ISP you are not using a NIC and LAN, so what use is all this talk of TCP/IP, packets and "layers of the cake" to anyone sitting at home? Communication using a phone line and a modem is so unlike the normal packet-based communications that two special protocols, Serial Line Internet Protocol (SLIP) and Point to Point Protocol (PPP), were created. These protocols enable a host to connect to the Internet by passing layers down through the TCP/IP stack until it reaches the Network Access Layer, which is the PPP Layer controlling the modem. It then sends the data to the remote computer via the modem, and when the remote system gets the data it is passed back up from the PPP software to the upper layers of the TCP/IP stack, just like any other IP data.
Setting up a computer to dial into the Internet is a simple matter these days, but you need to pay attention to the data you provide. In the early days of ISPs, you were given a permanent IP address for your machine, but the shortage of addresses means that addresses are now assigned to your computer via a process that uses a server on the ISP's network called a Dynamic Host Control Protocol (DHCP) server which hands out IP addresses. When you initially log in to your ISP, one of the first things that happens is your computer sends a DHCP request to the server provided by your ISP, which then responds by handing out an unused IP address from the list of IP addresses. Other TCP/IP settings which you might need to make to connect to your ISP are the DNS server to resolve names, a Network News Transport Protocol (NNTP) server to get USENET news, a Post Office Protocol (POP) mail server, and Simple Mail Transport Protocol (SMTP) mail server to send email. The last thing that you might find useful is your ISP's "proxy" server or "webcache" that keeps copies of everything requested from the web by your ISP's customers, meaning that popular items are retrieved more quickly.
If you are using an ISP from home, don't think that you have any privacy. ISPs can read your mail, watch you web browse, and keep a record of all your connections, weird packets and other shenanigans coming out of your host. Anyone who chooses to do something a bit black-hat could have problems ranging from having their account cancelled to possible prosecution. THINK BEFORE YOU TRY ANYTHING FROM THIS BOOK. Rushing off to the Internet and messing around with lots of hosts will show up in the logs, the owners will complain to your ISP and they could withdraw your Internet connection, or worse. Anyone can explore as much as they want, but they should make sure that they are not crossing the line between legal and illegal hacking, and they should take care not to bring real hackers into disrepute by cracking or damaging systems.
Some Standard TCP/IP tools
The most powerful set of tools at your disposal will be standard tools that come with most TCP/IP installations. The tools designed to enable easy connectivity from machine to machine, checking of network paths, performing reverse DNS lookups, route tracing and gathering of network statistics can all be used to check the security of your machine, or to compromise a machine's security.
A good understanding of TCP/IP protocols and standard tools used to utilize them is a necessary prerequisite for any attempt at hacking or protecting a machine on the Internet, or indeed any TCP/IP LAN. Learning how these commands can be used to exploit system insecurities is a lot harder than just running a standard package such as SATAN or ISS against your target, but far more rewarding in the long run, as you begin to learn about the inner workings of TCP/IP. It will also give you the practical experience you need if you decide to code new exploits into programs you can run against the systems you administer.
The "Telnet" Terminal Emulation Program
Once upon a time all computers would have terminals attached to them, physically "hard wired" into the machine, and when using the Internet to connect to a remote computer you need a standardized way of connecting and pretending to be a terminal that is physically attached to the computer. On the Internet "telnet" may be the standard tool for remote connection to other machines, but it is also one of the most useful tools in the Internet hacker's toolbox. Telnet is a client program that by default makes a connection to the telnet service on port 23, enabling the telnet daemon to process a connection session between hosts. Because of its ease of connectivity, telnet can be used in any number of ways to check system security and explore TCP/IP networking further. If you telnet to your local LINUX box without any port numbers, you will be presented with a login prompt, but try telnetting into your local LINUX box using port 15 and you might see a display something like this:
Trying 199.0.0.111...
Connected to slack.homeworx.org.
Escape character is '^]'.
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (State) User
tcp 0 0 *:676 *:* LISTEN root
tcp 0 0 *:netbios-ssn *:* LISTEN root
tcp 0 0 *:nntp *:* LISTEN root
tcp 0 0 *:auth *:* LISTEN root
tcp 0 0 *:sunrpc *:* LISTEN root
tcp 0 0 *:pop3 *:* LISTEN root
tcp 0 0 *:www *:* LISTEN root
tcp 0 0 *:finger *:* LISTEN root
tcp 0 0 *:time *:* LISTEN root
tcp 0 0 *:uucp *:* LISTEN root
tcp 0 0 *:telnet *:* LISTEN root
tcp 0 0 *:ftp *:* LISTEN root
tcp 0 0 *:chargen *:* LISTEN root
tcp 0 0 *:netstat *:* LISTEN root
tcp 0 0 *:daytime *:* LISTEN root
tcp 0 0 *:systat *:* LISTEN root
tcp 0 0 *:discard *:* LISTEN root
tcp 0 0 *:echo *:* LISTEN root
tcp 0 0 *:printer *:* LISTEN root
tcp 0 0 *:shell *:* LISTEN root
tcp 0 0 *:login *:* LISTEN root
tcp 0 0 *:2049 *:* LISTEN root
udp 0 0 *:674 *:*
udp 0 0 *:netbios-ns *:*
udp 0 0 *:sunrpc *:*
udp 0 0 *:time *:*
udp 0 0 *:chargen *:*
udp 0 0 *:daytime *:*
udp 0 0 *:discard *:*
udp 0 0 *:echo *:*
udp 0 0 *:ntalk *:*
udp 0 0 *:talk *:*
udp 0 0 *:syslog *:*
udp 0 0 *:2049 *:*
Active UNIX domain sockets
Proto RefCnt Flags Type State Path
unix 2 [ ] SOCK_STREAM CONNECTED /dev/log
unix 2 [ ] SOCK_STREAM CONNECTED
unix 2 [ ] SOCK_STREAM CONNECTED /dev/log
unix 2 [ ] SOCK_STREAM CONNECTED
unix 1 [ ACC ] SOCK_STREAM LISTENING /dev/printer
unix 1 [ ACC ] SOCK_STREAM LISTENING /dev/log
Table 5.3: Output from netstat command running on port 15
If you have a look at the list of well-known ports in the discussion of TCP/IP earlier, you will see that port 15 is occupied by a service called "netstat", a program which is designed to give out network statistics to anyone who queries the port. The output from netstat is useful in determining the status of a computer's network connections, showing what is connected and from where the connection is coming. This particular example shows quite clearly that slack is used by users from both redhat6 and win95, and that the services telnet and ftp are in use. It also shows clearly that we have connected to the netstat port and the computer from which we are connecting and smart systems administrators tend to log this type of connection nowadays. Here is a sample from the file /var/log/messages on the LINUX target "slack", and it shows very clearly where the connections came from.
11:14:55 slack netstat[210]: connect from win95.homeworx.org
Table 5.4: Logfiles clearly show where a cracker is connecting from
Like many tools developed on the Internet, netstat has been developed with open, co-operative computing in mind, but with the rise of security awareness more and more systems administrators are choosing to turn services like netstat off by commenting out the line in /etc/services or equivalent. It's not hard to see why. The netstat service can tell a black-hat cracker what other computers are on the network, some of which could be "trusted" hosts and open to further exploitation. It also lists services that are running on the target computer, allowing a cracker to explore and attempt to compromise those services by researching old vulnerabilities that could be exploited further.
Now that the would-be cracker has a list of your connections and services, they can use another tool to find out who is using the computer at that time. The "finger" program was designed to give out information about users, and can be used to get the usernames currently logged onto a remote site. If you haven't got a finger program fear not, because all finger does is connect to the finger service on port 79, so by firing up our copy of telnet and connecting directly to port 79 we can type in any arguments that would normally have been put onto the command line when invoking the finger program. Let's have a quick look at the relevant finger arguments before continuing
| Description | Command |
| To find a user on the local computer | finger user |
| To find a user on a remote computer | finger user@host |
| To find who is logged in on a remote computer | finger @host |
| Another way to do the above, more info | finger -l @host |
Table 5.5: Useful arguments of the "finger" command
Start off by invoking a telnet connection to the remote computer using port 79. Once connected, we can enter the commands or usernames directly to the finger daemon, find out who is logged into the computer, information about them and then try a few default users to see if they have accounts for possible exploitation.
redhat6~]$ telnet slack 79 Trying 199.0.0.111...Connected to slack.homeworx.org. Escape character is '^]'. @ [] Login Name Tty Idle Login Time Office fred owner p0 2 Mar 10 13:15 (win95.homeworx.org) root root p1 1 Mar 10 14:44 (redhat6)
Table 5.6: Output from fingerd when queried about all currently logged-in users by entering "@"
Let's start by seeing which users are on the system by connecting to port 79 and entering "@". Immediately we can confirm the information from netstat that there are users on the system connected from win95 and redhat6, and see what their user names are. Currently there are two users logged in "fred" and "root", and once a cracker knows that root is logged in they know that the systems administrator is around somewhere. Let's check that by connecting again and seeing what is happening.
[hb@redhat6 ~]$ telnet slack 79 Trying 199.0.0.111...Connected to slack.homeworx.org. Escape character is '^]'. root Login: root Name: root Directory: /root Shell: /bin/bash On since Fri 10 14:44 ( ) on ttyp1 from redhat6 1 hour 25 minutes idle No mail. No Plan.
Table 5.7: Output from fingerd when queried about the systems administrator by entering "root"
From this we can see that root has not touched his computer for 1 hour and 25 minutes, so maybe it's lunchtime or something. We can now complete the task by trying to find more information on the currently logged-in users. Let's start by looking at the other currently logged-in user, "fred".
[hb@redhat6]$ telnet slack 79 Trying 199.0.0.111...Connected to slack.homeworx.org. Escape character is '^]'. fred Login: fred Name: owner Directory: /etc/local Shell: /bin/tcsh On since Fri 10 13:15 ( ) on ttyp0 from win95.homeworx.org 1 minute 34 seconds idle No mail. No Plan.
Table 5.8: 0utput from fingerd when queried about currently logged-in user "fred"
Now let's see if there are some default UNIX users on the system, such as "uucp", "guest" and "postmaster". Finding default account usernames can be useful for a cracker in gaining access to the system, so it makes sense to see if any of them still have userids.
[hb@redhat6 ~]$ telnet slack 79 Trying 199.0.0.111...Connected to slack.homeworx.org. Escape character is '^]'. guest Login: guest Name: guest Directory: /dev/null Shell: /dev/null Never logged in. No mail. No Plan. [hb@redhat6 ~]$ telnet slack 79 Trying 199.0.0.111...Connected to slack.homeworx.org. Escape character is '^]'. uucp Login: uucp Name: uucp Directory: /var/spool/uucppublic Shell: /bin/sh Never logged in. No mail. No Plan.
Table 5.9: Example output from fingerd when the user's allowed to login to the system
Here we have two good guesses and one bad guess at default user accounts. Operating systems are often shipped with default users with default passwords to make setting up easier. If the systems administrator doesn't know about the default accounts, or forgets to turn them off, then anyone who can get hold of a list of default accounts and passwords can log into the target computer. A systems administrator should make sure that any default passwords on accounts on systems that they adminster are deleted or disabled.
[hb@redhat6 ~]$ telnet slack 79 Trying 199.0.0.111...Connected to slack.homeworx.org. Escape character is '^]'. postmaster finger: postmaster: no such user.
Table 5.10: Example output when the user isn't on the system
Finally, we have an example where the user account isn't on the system. A cracker finding this won't waste time trying to crack an account that doesn't exist. While trying this out, make sure that you play around with special characters such as "!", "$", "*", as well as control characters, and also see what happens if you give finger more input than it would normally take. Anything over 256 characters could have interesting results if the programmer has forgotten to trap this as an error condition for example, so play around and see what you can find out about the finger daemon program on your computer. Note that in many cases the systems administrator is logging all connections to the finger daemon. A log like the one below will alert a systems administrator that someone at win95.homeworx.org was connecting to the finger service repeatedly, possibly with nefarious intent. Any cracker who is thinking of using this for black-hat activities would be aware that the host they use to attach to the finger service will be logged by the remote computer.
Table 5.11: Excerpt from system logs showing finger daemon connections.Mar 12 11:28 slack in.fingerd: connect from win95.hx.org Mar 12 11:28 slack in.fingerd: connect from win95.hx.org Mar 12 11:29 slack in.fingerd: connect from redhat6
Anyone can use the telnet program to explore and probe your system and networks, check the security of your finger daemon, SMTP daemon, HTTP server, or whatever. It really all depends on what software is running on the target, what the objective is and, of course, what colour hat the hacker is wearing that day. As a systems administrator you should be aware of these types of probes, and familiar with the logfile entries that will alert you to a possible attack. Make sure that you check your logs regularly for any signs that someone might be messing around with the ports on your systems, and learn to recognise any logfile entries that indicate system probes and possible cracking attempts.
Packet InterNet Groper ("ping")
TCP/IP network connectivity needs more than just the ability to send packets and open connections. It also requires methods that allow for network flow control, error reporting on unreachable hosts and networks, route redirection and connectivity checking functions. In TCP/IP this function is performed by Internet Command Message Protocol (ICMP) packets containing ICMP messages. The ICMP type field id code determines both the type and format of the ICMP packet.
| Type Field | ICMP Message Type |
| 0 | Echo Reply |
| 3 | Destination Unreachable |
| 4 | Source Quench |
| 5 | Redirect |
| 8 | Echo Request |
| 11 | Time Exceeded for Datagram |
| 12 | Parameter Problem on Datagram |
| 13 | Time-stamp Request |
| 14 | Time-stamp Reply |
| 17 | Address Mask Request |
| 18 | Address Mask Reply |
Table 5.12: ICMP message types
ICMP messages are encapsulated inside IP datagrams, so if we disregard the IP header, the ICMP header looks like this. Encapsulating ICMP messages inside IP messages means that the IP Layer becomes responsible for transmission of ICMP messages, rather than relying on higher levels of the TCP/IP stack to operate. This feature of ICMP allows all sorts of amusing and fun things to be done with ICMP.
Figure 10: ICMP packet header
The commonest tools built around ICMP messages in the Packet InterNet Groper ("ping") command are designed to test connectivity from any host to a remote computer. The ping command works by sending a 64-byte ICMP "ICMP_ECHO" packet to the remote host, and waiting for an "ICMP_ECHOREPLY" back. Each packet has a sequence number to identify itself, and the time of transmission of the packet is encoded in the data portion of the packet, so response times can be calculated if the packet returns successfully. If the ping fails, it sometimes prints a message giving you some clue as to why it has failed, but mostly it just reports 100 per cent packet loss.
[hb@redhat6 ~]$ ping slack PING slack.hx.org from 199.0.0.166 : 56 data bytes 64 bytes from 199.0.0.111: icmp_seq=0 ttl=255 time=1.9 ms 64 bytes from 199.0.0.111: icmp_seq=1 ttl=255 time=0.9 ms 64 bytes from 199.0.0.111: icmp_seq=2 ttl=255 time=0.9 ms 64 bytes from 199.0.0.111: icmp_seq=3 ttl=255 time=0.9 ms 64 bytes from 199.0.0.111: icmp_seq=4 ttl=255 time=0.9 ms --- slack.homeworx.org ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.9/1.1/1.9 ms
Table 5.13: Normal use of ping command to check network connectivity
You would expect a tool like this to be useful for a white-hat hacker, but not much use to a black-hat cracker, but unfortunately you would be wrong. There are three main ways in which ping can be used to cause problems on a system. These problems can vary from just causing the target to have slow response times, right up to complete Denial of Service either by crashing the computer or TCP/IP stack. A cracker can also use TCP/IP itself to prevent the target communicating with the rest of the Internet by exploiting ICMP messaging.
Causing "Ping Flooding"
Some versions of the ping program enable a "flood" of pings to be sent very quickly to the remote computer. Originally designed to enable quick testing of network bandwidth, ping flooding can cause the target computer to respond continually to the ICMP_ECHO packets, and as the TCP/IP stack normally runs at a higher priority than other parts of an operating system, low priority elements such as the user programs run more slowly. This kind of attack is even more devastating when run from several computers on a network, or if the host for the attack runs more quickly and has better bandwidth in its Internet connection so that it can run multiple ping floods simultaneously.
Table 5.14: This little "ping flood" from the faster host forced slack onto its knees.[hb@redhat6 hb]# ping -f slack PING slack.hx.org from 199.0.0.166 : 56 data bytes.. --- slack.hx.org ping statistics --- 12449 packets transmitted, 12437 packets 0% loss round-trip min/avg/max = 0.9/3.7/8.6 ms
Sending Oversized Packets - the "Ping of Death"
When pinged with a packet greater than 65536 bytes some systems will have problems dealing with a packet that size, as an IP packet of 65536 bytes is illegal. Unfortunately a fragmented IP packet could easily exceed this, and when the fragments are reassembled at the other end into a complete packet it overflows the buffer on some systems. This leads to a variety of unwanted system nastiness that can cause kernel panic, reboot, shutdown and complete system failure. The only solution to the so-called "ping of death" is to install patches that fix the overflow problem inside the TCP/IP stack. Trying to hide the vulnerable system behind a firewall with all ICMP messaging turned off is no guarantee, as anything that sends an IP packet could be used to crash TCP/IP or the system kernel. There are many variations to this attack, as most systems had similar vulnerabilities at one time, and it is quite possible to find modified ping software that exploits the bug in different ways according to the target computer's operating system. A systems administrator should always apply the most modern versions of TCP/IP software available, to prevent any cracker exploiting this system vulnerability.
Using ICMP_UNREACH to "Nuke" Network Connections
Remember the part at the start of this chapter about ICMP messages being used for testing connectivity and also for error reporting? Well, we have seen ICMP messages used by the ping program to test connectivity using ICMP_ECHO, and all the ping program does is send an ICMP message to a host. But what if the ping program were modified to send another ICMP message, for example ICMP_NET_UNREACH or ICMP_HOST_UNREACH? Anyone with the source code for the ping program and a modicum of C programming skill can modify the ping program to do exactly that, so there are many "nuke" programs on the Internet.
Figure 11: During ICMP "nuking", evil host zz.zz.zz.zz sends messages to xx.xx.xx.xx pretending to be yy.yy.yy.yy, saying "this network is unreachable"
Using a "nuke" program is very easy, and works on the following principle. Suppose that a cracker is at host zz.zz.zz.zz in the diagram, and they know that host xx.xx.xx.xx and host yy.yy.yy.yy have active connections between them and want to disrupt the connection. Using the nuke program, the cracker sends many ICMP packets from host zz.zz.zz.zz to host xx.xx.xx.xx, each one containing the ICMP_NET_UNREACH message and containing the IP address of host yy.yy.yy.yy as the originator. The IP Layer in the TCP/IP stack has no option but to believe what it is being told, and that the network is unreachable, due to some unspecified problem. Because of the way that IP works, the connection between host xx.xx.xx.xx and yy.yy.yy.yy is now dropped, effectively denying any services from xx.xx.xx.xx to yy.yy.yy.yy and vice versa.
DNS Search with "nslookup" or "dig"
If anyone needs to explore the domains and hosts in the DNS, they should use "nslookup" or "dig". If they haven't got either of these, the tools can be downloaded, or a web site can be used that hosts nslookup such as www.network-tools.com. If you remember the explanation of DNS earlier, you know that performing a DNS search means asking the nameserver to resolve the address, and nslookup allows you to dig into the DNS database and also see which nameservers are being queried. Here is an example of a DNS lookup on the domain "carltonbooks.co.uk". It resolves the IP address, tells us about local nameservers, and is helpful enough to give an email address as contact, enough information to get any self-respecting black-hat cracker started. For any legitimate Internet user, nslookup is vital for determining the domain name for any IP address they might have, for finding contacts on a site in order to complain about spam, or for checking their own DNS records to make sure that names resolve correctly.
Table 5.15: Example DNS lookup of Carlton Books.DNS LOOKUP Results for: carltonbooks.co.uk Server: ns.consumer-info.org Address: 209.207.246.162 carltonbooks.co.uk primary nameserver = dns.compd.co.uk responsible mail addr = stewart.carltonbooks.co.uk serial = 960819023 refresh = 28800 (8 hours) retry = 7200 (2 hours) expire = 604800 (7 days) default TTL = 86400 (1 day) carltonbooks.co.uk nameserver = dns.compd.co.uk carltonbooks.co.uk nameserver = dns1.red.net carltonbooks.co.uk internet address = 195.74.134.2 carltonbooks.co.uk MX preference = 10, mail exchanger = mail.carltonbooks.co.uk
Checking Routes with "traceroute"
Remember the discussion about how IP routes datagrams from your host to another host on the Internet? The program "traceroute" traces that route between your host and any other host on the Internet, identifying any routers or gateways it passes through on the way. While traceroute is designed for debugging routing errors, traceroute is a great tool for identifying the IP addresses of the other computers sitting between a cracker and their target. Here's an example using carltonbooks.co.uk as the domain. Let's see what a cracker can find out about the route from network-tools.com to carltonbooks.co.uk.
Figure 12: Example of traceroute extending the TTL field while sending packets across gateways. Each gateway decrements the TTL field by one before sending it on, until it hits the destination
The program traceroute works by sending packets with short "Time-To-Live" (TTL) values, incrementing the TTL value by one after every few packets. As packets pass through gateways the TTL is decremented until it reaches zero, and at that point the gateway which has the packet will generate an ICMP_EXC_TTL or "time exceeded" message, which is sent back to the originating host. So, by incrementing the TTL by 1 each time, traceroute can determine where the packet was when the TTL reached zero, get the name of the gateway and build up a list of all the gateways which the packet passes through to reach the remote host. When the packet reaches the remote host, the use of an invalid port number guarantees that the host will generate an ICMP_PORT_UNREACH or "Unreachable Port" message, and when this arrives at the computer running traceroute, the entire route is complete. Of course if the traceroute program fails to reach the target remote host, then it's time to start wondering why, and getting in touch with the systems administrator of the remote host and find out whether it is down for maintenance, or a router on the way is incorrectly configured.
Table 5.16: Example use of traceroute to get routing information to a remote host.TraceRoute from 209.207.246.165 to 195.74.134.2 -------------------------------------------------------------- IP Time TTL Host -------------------------------------------------------------- 1 209.207.129.1 0 200 Valid name, no data record -------------------------------------------------------------- 2 157.130.15.229 0 101 serial1-0-1.gw3.dca3.alter.net -------------------------------------------------------------- 3 152.63.32.78 10 101 108.atm3-0.xr2.dca1.alter.net -------------------------------------------------------------- 4 146.188.161.154 0 46 194.atm3-0.tr2.dca1.alter.net -------------------------------------------------------------- 5 146.188.136.218 0 46 101.atm6-0.tr2.nyc1.alter.net -------------------------------------------------------------- 6 146.188.179.33 10 46 198.atm6-0.xr2.nyc4.alter.net -------------------------------------------------------------- 7 146.188.178.113 10 46 188.atm8-0-0.gw1.nyc4.alter.net -------------------------------------------------------------- 8 157.130.6.234 30 46 nacamar-gw.customer.alter.net -------------------------------------------------------------- 9 194.112.25.248 100 99 atm4-0.lon0.nacamar.net -------------------------------------------------------------- 10 194.162.231.225 101 99 fe5-0.linx1.nacamar.net.uk -------------------------------------------------------------- 11 194.162.231.237 151 99 11-port.linx3.nacamar.net.uk -------------------------------------------------------------- 12 195.74.128.254 110 99 hw-th-gw.hw.red.net -------------------------------------------------------------- 13 195.74.128.253 120 99 custll01-rednet.hw.red.net -------------------------------------------------------------- 14 195.74.134.1 2383 99 host1.completelydigital.co.uk -------------------------------------------------------------- 15 195.74.134.2 1892 245 host2.completelydigital.co.uk
This information tells us that in order for the packet to reach the original address 195.74.134.2, the datagram passed through the servers at alter.net before being routed across the Atlantic to the London Internet Exchange (LINX), before being passed through 195.74.134.1, which looks like the primary gateway for the whole of the network behind it. Once a cracker has this information, they can now start to probe the defences of any computers they find in the target network. If you are a legitimate Internet user traceroute is an invaluable tool for resolving host unreachable errors, by allowing you to step through the routes taken until the point of failure is found.
If anyone was thinking of using telnet to connect to any of the ports of any of the machines in this list then they should think very hard before they do such a thing. The owners of busy routers and gateways do not take kindly to people probing their defences by attempting to log into well-known ports, and they will almost certainly be logging this kind of activity. We have already seen the example of logs earlier this chapter, and if that is not enough to deter anyone, they should go back to Chapter 1 and read the section on hacker ethics and legal penalties before donning their black hat, as ill-advised port scanning could cause their ISP to yank their account or garner them unwanted attention from the legal authorities
Conclusion
In this chapter a basic TCP/IP tutorial has led to exploration of TCP/IP services using telnet to perform manual "port scans", logging into a remote computer on possible ports, and gathering information on users' networks. These are some of the most basic techniques of cracking, and taking time to understand these fundamental principles will pay dividends later. Chapter 7: Hacking the Web is going to extend this idea even further, as we learn how crackers attach to services offered by remote hosts, and then attempt to seek out and exploit any vulnerabilities inside the service programs in an attempt to gain access. In the meantime, get hold of a good book on TCP/IP, and some Requests for Comments (RFC) covering the services you are interested in, play around with your own machine and build yourself a TCP/IP LAN. You will soon realize that there is much more to learn.
