Eavesdropping and Information Gathering | Maximum Mac OS X Security

Try as we might, if information leaves our hands, it is no longer within our ability to protect it. If we place a letter in the mailbox and an unscrupulous individual removes it without our knowledge, there's very little we can do about it. Of course, there's always a possibility of tracking the individual down later, but, for the most part, we have to rely on faith in our fellow human beings and hope that our mail won't be in the wrong place at the wrong time. Alternatively, we can develop secret coding systems and write all our letters in code, but when we send the message, it still needs to go through the postal service and is still out of our control. It may even be intercepted by someone with a decoder ring who can break our code.

Network security is very much analogous to the postal system. We hope that information reaches its destination without being intercepted, but it's very possible that someone can and will sneak a peak somewhere along the route.

This chapter discusses two types of "nonattacks" that, while not directly harmful to your system, ultimately may place it in risk of compromise:

Sniffing A sniffer works by actively listening to all network traffic rather than data specifically addressed to the computer on which it's running. In doing so, it can record conversations on critical machines such as mail, file, and database servers. Modern sniffers even provide password parsing filters to create a ready-to-use list of usernames and passwords pulled from the traffic stream.
Scanning Scanning, like sniffing, does not directly target a computer's weakness. Instead, it attempts to identify the active services a computer is running. Attackers typically scan entire networks to locate potential target machines. As soon as the targets are located, a real attack can begin.

The reaction of many administrators to these threats is one of indifference. Sure, they sound bad, but what are the chances that they'll actually happen to you? How many people are talented enough to write the code to do this sort of thing? The answers may startle you. First, chances are extremely high that any Internet-connected machine will be scannedit's a virtual certainty . If an exploit can be found or an account hacked, it's very likely that a sniffer will be used. Second, no talent, programming, or networking experience is required to eavesdrop on a network. For example, consider this information:
```
 140.2.82.82:2100 -> 140.254.xx.xx:110         pop3 USER: kinder PASS: sef1221 216.2.29.89:61020 -> 140.254.xx.xx:110                pop3 USER: defi PASS: camping 164.1.35.174:58137 -> 140.254.xx.xx:110               pop3 USER: jmiller PASS: dogg119 128.1.202.3:4656 -> 140.254.xx.xx:110         pop3 USER: thalheimer PASS: ggghhh 
```

These are (obviously) a collection of POP passwords, but where did they come from? The answer is a piece of software that works like this:

You start it.
You tell it to record passwords.
You take the recorded password file and go.

The user doesn't need to know anything other than how to run a program. In this example, the four collected passwords were taken from an idle network at roughly 2:00 a.m. over a period of about 10 seconds. The sniffer can run from any machine on the same network as the traffic that is to be watched. With the advent (and poor security) of wireless networks, the potential sniffer could be someone with a laptop sitting in a car outside your building.

The good news is that the same information gathering techniques that attackers use to crack your network can also be used to help secure it. Sniffers can be used to monitor network traffic for signs of attack (see Chapter 18, "Alarm Systems: Intrusion Detection"), whereas portscanning can identify potential targets for attackers as well as identify users who may be violating your security policies.

The majority of this chapter will be spent exploring the available information-gathering software for Mac OS X and demonstrating its use.

The Five-Minute TCP/IP Primer

Scanners and sniffers have migrated from the realm of tools for administrators to menu-driven utilities accessible by novices. Although a background in networking isn't necessary, it's still helpful in interpreting the results of the applications that are examined shortly. Let's take a look at what TCP/IP is (and isn't) now.

TCP/IP is the protocol suite that powers the Internet. It was designed by the DoD to be a robust communications standard for linking multiple individual networks into what was originally called the ARPANET. These original LANs were built through the government's standard " lowest bidder" contracting method, and subsequently were incapable of speaking to one another. TCP/IP was designed to link these systems regardless of their operating systems and communications mediums. Over time ARPANET expanded to universities and finally grew to what we know as the Internet.

The OSI ( Open Standards Interconnect) Network Model is often used to describe networks. This works particularly well for TCP/IP in that it shows how the different protocols within the TCP/IP suite work with one another and with the physical devices used to generate the actual data transmission.

There are seven layers to the OSI model, as shown in Figure 7.1, each building on the one before it.

Figure 7.1. The OSI model is made up of seven layers.

graphics/07fig01.gif

Physical

The lowest of the layers, the Physical layer, is composed of the hardware that connects computers and devicesnetwork cards, wiring, and so on. For wireless networks, this includes the AirPort card and the carrier frequency of the 802.11a/b/g network. Everything that makes communication possible is included in the Physical layer, except for the actual data transmission standards. TCP/IP does not yet come into play at this layer.

Data Link

The Data Link layer defines a means of addressing and communicating with other network devices connected via the same Physical layer. For Ethernet networks, each device has a unique factory-assigned "MAC" (media access control, not Macintosh!) address and communicates with other devices by dividing data into chunks called frames . Each frame contains a source and destination MAC address, a type, a data payload, and a CRC value for error checking.

Other Data Link methodologies such as SLIP and PPP use different addressing standards, but operate in much the same manner.

This layer works to handle packet collisions and signaling errors as it sends data across the Physical layer. It is still very low level, however, as we have yet to touch TCP/IP, which technically starts at the next layerthe Network layer.

Network

The Network layer introduces the "IP" (Internet Protocol) in TCP/IP. An IP address provides a higher-level protocol that maps between the Data Link layer's addresses (MAC addresses for an ethernet) and an "arbitrary" user assigned addressthe Address Resolution Protocol (ARP). By creating a standard addressing scheme that isn't dependent on the underlying hardware, the Network layer also makes possible routing of information from one network (perhaps using an entirely different Physical and/or Data Link standard) to another.

Besides handling high-level addressing, the Network layer introduces the IP packet header. An IP packet header contains source and destination IPs along with additional information for routing and error checking. The packet payload itself is formed by the higher-level layers, but each TCP/IP packet must include the IP header information to reach its destination. An interesting notion that is also handled within this layer and carried as part of the IP header is packet fragmentation . Although this might sound like a "bad" thing, packets must often be fragmented as they move across different Data Link layers that define different data sizes for transmission. By dividing data into the appropriately sized chunks for each Data Link layer, the Network layer can bring together many physically dissimilar networks.

Within the Network layer, the Internet Protocol defines a mechanism for transmitting and receiving information about errors and routing to be communicated between devices. This is known as the ICMP, the Internet Control Message Protocol. ICMP messages can be transmitted to inform clients of routing information, errors in transmission, or other network problems. The most typical "human" use of ICMP is to ping another host to see whether it is reachable :

 %  ping gateway.poisontooth.com  PING gateway.poisontooth.com (10.0.1.1): 56 data bytes 64 bytes from 10.0.1.1: icmp_seq=0 ttl=255 time=3.673 ms 64 bytes from 10.0.1.1: icmp_seq=1 ttl=255 time=5.479 ms 64 bytes from 10.0.1.1: icmp_seq=2 ttl=255 time=2.581 ms 64 bytes from 10.0.1.1: icmp_seq=3 ttl=255 time=2.548 ms 64 bytes from 10.0.1.1: icmp_seq=4 ttl=255 time=2.514 ms --- gateway.poisontooth.com ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 2.514/3.359/5.479 ms

ICMP packets, although useful for determining device and network status, are not a foolproof means of diagnosing network conditions. Many firewalls are configured to block ICMP packets because they can be used as remote attackers to probe a network's state.

More information about the Internet Protocol can be found in RFC 791: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc0791.html.

Transport

At the transport layer of the network model fall the protocols that are used to move most data from one machine to another via the Internet Protocol. Although the primary focus in this chapter is on the TCP and UDP protocols, there are actually dozens of protocols that piggyback on top of IP. You can see a list of many of these protocols by viewing the contents of /etc/protocols , or visiting http://www.iana.org/assignments/protocol- numbers .

Most TCP/IP communication is performed (surprise!) by TCP, the Transmission Control Protocol. The purpose of TCP is to provide reliable data transmission and maintain a virtual "circuit" between devices that are communicating. It is responsible for ensuring that all packets arrive in order and reach their destinations successfully. It accomplishes this by providing a sequence number with each packet it sends, and requiring that an acknowledgement (ACK) is sent by the destination computer with each packet successfully received. If an ACK is not sent by the receiver within a reasonable amount of time, the original packet is retransmitted.

Another popular protocol in the TCP/IP suite is UDP. Unlike TCP, which requires that each packet be received and acknowledged , UDP's purpose is to send information as quickly as possible. Streaming video, games , and other noncritical Internet applications use UDP to provide the "best possible" time-sensitive information given current network conditions. For example, while watching streaming video of a live telecast, it makes little sense to stop playback because a few frames were lost here or there. Instead, UDP sends a continuous stream of data and the remote receiver gets as much of it as it can. There, obviously, is a loss of quality on poor network connections, but the end result is better than having to wait for each and every packet to be verified and acknowledged.

TCP and UDP packets contain within their information a set of ports . A port can be considered a virtual outlet on your computer that other machines can "plug into" to receive a particular service. Ports are identified by a number, which, in turn , can be mapped to the service that the port provides. For example, common ports used by the Mac OS X services include

FTP21 and 20
SSH22
HTTP80
Appleshare over TCP/IP548

A list of the ports and the services that typically run on them is provided in the file /etc/services on your computer. To make a connection, a remote machine opens an arbitrary network port on its end, then connects to a known service port on the remote computer. By specifying a port along with the data being sent, the Transport layer protocols achieve multiplexing , or the ability to have multiple simultaneous connections. The port numbers, along with the source and destination addresses, make up a socket.

During the lifetime of a TCP/IP connection, there are multiple states that can exist. These are defined in RFC 793 (http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc0793.html):

LISTEN . Waiting for a connection request.
SYN-SENT . A connection request has been sent and the device is waiting for an acknowledgement.
SYN-RECEIVED . The connection acknowledgement is received and the device is waiting for a final confirmation.
ESTABLISHED . A connection exists and data can be transmitted and received.
FIN-WAIT-1 . Waiting for a connection to be terminated or an acknowledgement of its request to terminate a connection.
FIN-WAIT-2 . Waiting for a connection termination request from the remote device.
CLOSE-WAIT . Waiting for a termination request from an upper network layer.
CLOSING . Waiting for a connection termination acknowledgement from remote device.
LAST-ACK . Waiting for the final acknowledgement of connection termination.
TIME-WAIT . Waiting for a given timeout to be sure that a termination acknowledgement has been received.
CLOSED . Connection is closed.

Some denial of service attacks take advantage of the acknowledgement wait states that exist in TCP/IP connections by "starting" to open connections, then not following through with the appropriate termination or acknowledgements, resulting in the remote device having to wait for a connection timeout before its network resources can be released.

Session

The OSI model defines the Session layer as being responsible for maintaining point-to-point communications between devices. In TCP/IP, this is handled directly by the TCP/UDP and the use of sockets. These protocols span both the Transport and Session layers of the OSI model, so we're left with the real "meat" of TCP/IP communications: the Presentation and Application layers.

Presentation

The TCP/IP Presentation layer is where most of what we consider Internet protocols (not to be confused with the Internet ProtocolIP) are found. Protocols such as POP, HTTP, IMAP, and so on are implemented at this layer and generally consist of a network "language" for exchanging information. For example, the SMTP, which runs on port 25, receives incoming messages after an intermachine exchange similar to this:

 %  telnet poisontooth.com 25  Trying 10.0.1.250... Connected to carrot3.poisontooth.com. Escape character is '^]'. 220 NOTE: Port scans are logged.  HELO client0.poisontooth.com  250 poisontooth.com we trust you client0.poisontooth.com  MAIL FROM: jray@poisontooth.com  250 jray@poisontooth.com sender accepted  RCPT TO: ray.30@osu.edu  250 ray.30@osu.edu will relay mail from a client address  DATA  354 Enter mail, end with "." on a line by itself  This is a test message.  250 1810071 message accepted for delivery

In this example, the SMTP responds to the commands HELO, MAIL FROM, RCPT TO, and DATA . Each protocol's language varies depending on its purpose, and many cannot be as easily read as SMTP. Nevertheless, this is where most of the "important" information about what is taking place on your network can be gleaned, and is the primary focus for most network sniffers.

Application

The Application layer "hides" everything that falls underneath it. This layer is made up of the applications that use the Presentation layer protocols. This includes your Web browser (Chimera or Mozilla, of course), Apple's Mail application, and so on.

From here on out, we're going to be looking at the tools that can be used to listen in on the traffic on your network. Most of these utilities require that you run them as the superuser so that they can place your network card in promiscuous mode. Normally a networked computer passes information up the TCP/IP stack only if the packets are addressed specifically to that machine or are broadcast to the entire network. In promiscuous mode, all traffic will be visible to the computer, regardless of how it is addressed.

SWITCHED NETWORKS AND EAVESDROPPING

Switched networks are the de facto standard for modern LANs. They utilize switches rather than hubs to provide connections to multiple machines. A switch caches the MAC addresses it sees on a given port (known as an ARP cache), and forwards traffic for only those addresses to the port. Machines that are located on different switch ports cannot see one another's traffic. This makes network monitoring a bit troublesome using legitimate tools unless you can monitor traffic upstream from the switch. There are ways around this problem, such as overflowing a switch's ARP cache so that it "gives up" and passes all traffic like a hub. These techniques, however, are often disruptive to other network devices and are not a transparent means of eavesdropping.

CAUTION

The remainder of this chapter assumes that you've read through the TCP/IP introduction and have spent some time reading through the appropriate RFCs. TCP/IP, like many subjects in this book, is not a 5- or 10-, or even 100-page topic. We're attempting to give you the tools and background to get started and understand what you're seeing, not to become a network technician in 35 pages. For more information on TCP/IP, you may want to read Special Edition Using TCP/IP , by John Ray, from Que Publishing.

Top