More recently, a break-in occurred on January 22, 1995, at SLAC. According to Les Cottrell, assistant director for SLAC's computing-services department, monitoring programs detected the intruder entering a system located behind a protected firewall gateway at approximately 10 p.m. It was later determined that the intruder hid, in the midst of the operating system, a program to covertly monitor SLAC's internal network and accumulate accounts and account passwords in a file system, possibly for later retrieval.
Around 10 a.m. the next day, system administrators spotted this attempt at subversion, cut off external network access to the facility, and proceeded to conduct a postmortem examination determining the degree of damage introduced. ``After two days of work'' said Cottrell, ``we're only partially recovered, but we'll have much of the network online by tomorrow.'' Interestingly, the systems subverted are used only for scientific research, so the general informational value is limited.
The fact that the intruder tripped common monitoring devices while employing sophisticated intrusion mechanisms makes even the experts scratch their heads. According to Cottrell, ``the funny thing about this attack is that it had the characteristics of both a novice and an expert cracker.''
The intruder apparently gained access behind the network firewall by using a technique known as ``IP source-address spoofing.'' Each packet on the Internet has a destination address (the target host where the packet is to be sent) and a source address (to be used in sending back acknowledgment of the receipt of the packet to the source host). Unlike a telephone connection (which can reliably record a call's source), there is no source-address validation mechanism on the Internet. Thus, the source-address information can easily be forged by the sender. While this implies that the sender can only send information (since the return acknowledgments will be sent to the true source machine being spoofed), this leaves a hole big enough for an intruder to crawl through. This is analogous to crashing a invitation-only party by lying about your name. By a simple artifice, you can gain access through the protected doorway of a firewall.
The details of this technique were actually documented in a report prepared by Robert Morris (father of the infamous Robert Morris of Internet-worm fame) at AT&T Bell Labs in 1985. (You can retrieve this document via anonymous ftp from research.att.com.) The technique relies upon the use of two mechanisms: 1. Blinding the true source machine to the fact that someone is using its address; and 2. communicating the appropriate acknowledgment to the target machine by anticipating the appropriate response.
When sending off an initial request for connection containing the forged source address, an intruder must temporarily blind the machine whose address is being forged by sending a large number of false connection requests. The true source host is overwhelmed with these requests, and it misses the acknowledgment from the target machine confirming the original connection packet. If this isn't done, the true source host will detect the response from the target host, consider it a pointless anomaly, and send a request to terminate the connection --- thus thwarting the cracker.
Since a response has been sent from the target machine, it must still be acknowledged by the cracker even though the cracker has not received the sequence number sent as part of the acknowledgment. So the next message must contain not only the instructions or commands to be executed by the target host, but also a forged source-host acknowledgment. Since most implementations of TCP are based on the Berkeley implementation (complete with flaws), the acknowledgment-sequence number can be reliably predicted. Once this forged acknowledgment --- piggybacked with the data --- is received and accepted by the target machine, the commands are executed and the target machine is now subverted, allowing the cracker access at a minimal level.
Once past the firewall and inside, the cracker exploits the Berkeley trusted-host mechanism (originally the Purdue University PNET mechanism) to gain further access. Berkeley host files were implemented as a convenience to site administrators who needed to work with many machines at a time. By eliding account authentication on machines within a trusted set, you avoid the need to type in the same password over and over again, either when a single user is on many machines, or when programs launched at night by the computer must interact with multiple machines and require an administrator to manually type in account access. Thus, even though this mechanism is valuable to site administrators (and is one that many do not wish to forgo), it also is an ideal way for hackers to gain access to the more sensitive areas of the system by appearing to be a trusted host --- without even knowing the actual secrets.
In fact, a superior mechanism which more carefully deals with trusted hosts is available as part of MIT's Kerberos security package. Unfortunately, it has yet to become universally used, partially due to the difficulty of changing over all sites, but also, interestingly enough, due to the intransigence of existing government agencies concerned with universal DES encryption (if everything were encrypted, they couldn't tell the ``interesting'' packets from the majority of mundane ones). Ironically, it is the security experts who have created this most insecure of situations.
The importance of these new attacks is that they graphically demonstrate the vulnerability of facilities which were considered to be safe from penetration. Since firewalls are the preferred method of keeping out intruders, the fact that they can be subverted may significantly impact the commercialization of the Internet.
The key weakness in this series of attacks is that these firewalls make their decision on information which can be trivially forged by the sender. For example, it is a simple programming exercise to appear to send commands from the host ``whitehouse.gov.'' ``It's another example of current network security problems that firewalls just don't solve,'' says Don Stevenson, project leader of network security for SunSoft's Solaris.
The recent CERT advisory discusses how to determine if a system is under attack in certain cases and how to deal with them, primarily by recommending that the system monitor for spoofed inside packets coming from outside the firewall. However, says Cottrell, ``our firewall was keeping out these kinds of packets, so this wasn't how the intruder gained access.''
Unfortunately, this recommendation does not deal with genuine source addresses coming through the firewall (which can be discovered and used by the same technique). ``Short of denying all network service, you can't ultimately stop this problem,'' says Stevenson.
The root of this decade-old problem is that IP doesn't allow a way to validate the source address. This could possibly be fixed by experimentally adding an extension to the ICMP protocol responding to a questioning host --- essentially a simple ``call back'' (as has been done by the telephone company for years). In addition, since the initial sequence number is predictable (because it is chosen in a nonrandom fashion) the code could easily be changed to randomize this number. Finally, the Internet service daemon (inetd) could be changed to prevent exhaustive searches by multiple failed-connection attempts. One change might require a one-second delay after a burst of connection attempts. This has the side effect of notifying the users and administrators that an attack may be in progress (by slowing the system) and allowing a trap to be set. (All these security fixes are available via anonymous ftp for 386BSD systems from bsdserver.ucsf.edu.)
While these fixes stop up the holes, other holes not yet anticipated may develop over time. As such, longer-term approaches must also be examined. Role-based security is one solution for simple network-level security. With role-based security, even if someone spoofs the machine (thus getting around authentication procedures), they still cannot gain access to sensitive materials so marked, nor can they gain access to sensitive kernel and systems files. In fact, role-based security could be extended with alternative network-authentication procedures to detect intrusions as new kinds of attacks are launched (for example, someone subverts the routing functions of the Internet). Role-based security is the beginning of a scalable policy for network security (see ``Role-Based Network Security,'' due for publication in Dr. Dobb's Journal, May 1995).
However, says Stevenson, ``the long-term hope for a solution may be in the work being done on IPng, where encryption and authentication procedures for the Internet may become standardized.'' This new version of the Internet protocols is needed for many other reasons besides security (see ``Polymorphic Protocols,'' Dr. Dobb's Journal, January 1994), but has been long delayed. While there have been security options developed for IP by the Defense Department (for use with satellite relays), these are not easily adaptable to commercial needs.
In the escalating measure/countermeasure war of network security, it would appear that even ideal security measures cannot forever stave off new mechanisms which exploit ever-more-obscure methods of gaining access. However, it will be very difficult to evolve a network with over three million hosts (and growing). As such, this new series of incursions should be considered a wake-up call to developers, government, and vendors to cooperate on creating a truly viable information superhighway.