NASIRC BULLETIN #95-01 January 24, 1995 Internet Attacks: IP-Address Spoofing and Session Hijacking =========================================================== __ __ __ ___ ___ ____ ____ /_/\ /_/| /_/ / _/\ /_/| / __/ \ / __/\ | |\ \| || / \ \ | /\/ | || | /\ \/ | | \/ | ||\ \ || / /\ \ \ \ \ | || |_\/ /\ | | | || \ \|| / /--\ \ \ /\_\\ | || | |\ \ \ | \_/\ |_|/ \_|//_/ \_\/ \/__/ |_|/ |_| \_\/ \___\/ NASA Automated Systems Incident Response Capability =========================================================== NASIRC has received information about attacks in which intruders exploit inter-system trust relationships via specially-crafted Internet Protocol packets. These packets masquerade as being from a trusted host within your local domain, yet may originate externally to your domain, and may pass through your firewall or gateway routers. It is important to note that this has NOTHING to do with source-routed packets (which you should not permit). This attack method was first suggested by Robert T. Morris in 1985, and was expanded upon by Steve Bellovin, however no attacks using it have been publicly reported until now. "The attacker can then pick any IP source address desired, including that of a trusted machine on the target's local network. Any facilities available to such machines become available to the attacker." (1) Technical details of the attack may be found in the papers written by Morris and Bellovin. A Weakness in the 4.2BSD Unix TCP/IP Software Morris, Robert T. AT&T Bell Laboratories Murray Hill, New Jersey 07974 A copy of this paper may be found at: ftp://ftp.research.att.com/dist/internet_security/117.ps (1) Security Problems in the TCP/IP Protocol Suite Bellovin, S.M. AT&T Bell Laboratories Murray Hill, New Jersey 07974 A copy of this paper may be found at: ftp://ftp.research.att.com/dist/internet_security/ipext.ps SYSTEMS AFFECTED: Any network service which relies on the IP source-address to authenticate a connection. Examples of this are the Berkeley-style remote login commands: "rsh", "rlogin" and "rcp", SunRPC, NFS, clients and servers using the X-windows protocol and anything which relies exclusively on TCP-wrappers for authentication. All reported attacks have targeted Unix systems, however there is nothing inherent in the attack which restricts it to one operating system. THE PROBLEM An intruder may craft a packet with a destination address of a target machine, and a (false) source address of another (trusted) system within your domain. The target system will respond to that packet since it appears to originate from the trusted system. Though the packets that the target system generates in response will be sent to the real trusted system within your domain, it is not necessary for the intruder to see them since the protocols are so well-defined that it is possible (within limits) to accurately predict what those packets will be. The trusted system would normally respond to these unexpected packets received from the target, however the intruder may either wait for the trusted system to be down, or conduct a denial-of-service attack against it. Once a connection is established, for example to a password-less login protocol such as "rlogin", the intruder may use it to install a trojan login mechanism which will allow them to login interactively from the untrusted attacking system. Note that this technique may bypass firewalls and strong authentication methods such as one-time passwords. DETECTION If you are able to monitor network traffic on the 'external network' side of your external interface, look for packets whose source and destination addresses are both within your local domain. The presence of such packets indicates that you are under attack. Note that if you have an unusual network configuration, such as disjoint segments of your local address-space, such packets may exist legitimately. This method will not detect variants of this attack, such as: * If the attacker is already within your local domain, the spoofed packets will not pass through your external interface. or * If they spoof a trusted host outside your local domain, there will be no way to discriminate such packets from legitimate packets from the external host. (You should not permit your users to include in their '.rhosts' files the names of systems outside of your administrative control.) If you can monitor your network on the internal side of your router, look for packets with an internal source address and the ethernet source address of your router. This will work only if your internal domain consists of one segment, not divided by internal routers. PREVENTION The best method of preventing the IP spoofing problem is to install a filtering router that restricts the input to your external interface (known as an input filter) by not allowing a packet through if it has a source address from your internal network. In addition, you should filter outgoing packets that have a source address different from your internal network. How you accomplish this will vary according to what hardware connects your local network to any external network. Not all routers allow filter-rules which will implement this restriction. Routers that support this feature are * Cisco - RIS software version 9.21 and later * Bay Networks/Wellfleet routers, version 5 and later * Cabletron with LAN Secure * NSC Firewalls that are not susceptible to this attack include * TIS proxy firewalls If your vendor's router does not support filtering on the inbound side of the interface or there will be a delay in incorporating the feature into your system, you may filter the spoofed IP packets by using a second router between your external interface and your outside connection. Configure this router to block all packets on the outgoing interface connected to your original router if the packets have a source address of your internal network. For this purpose, you can use a filtering router or a UNIX system with two interfaces that support packet filtering. If you need more information about your router or about firewalls, please contact your vendor directly. If you are unable to reconfigure your network connection rapidly, you should disable any network services which you do not require if they use the IP source-address for authentication. =========================================================== RELATED PROBLEM: Session Hijacking observed under SunOS In the current attacks which have prompted this bulletin, the intruders have used a tool called "tap" to insert a streams module into the kernel, which allows them to take over existing Telnet and/or other TCP connections open to other systems. This is, in fact, a completely separate issue from IP-address spoofing, however we mention it here because it has in practice been observed in conjunction with such breakins. THE PROBLEM In taking over the existing connections, intruders can bypass one-time passwords and other strong authentication schemes by tapping the connection after the authentication is complete. If the 'hijacked' connection is a 'root' login, the attacker may install trojan versions of system programs, to allow them to login without using "tap". If the connection hijacked by "tap" is directed to a different system, it will allow the attacker to compromise that system in addition to the one on which the "tap" attack took place. DETECTION When an intruder attaches to an existing Telnet or other TCP connection, the rightful owner may detect unusual behavior (i.e., commands appearing that were not typed, blank windows that no longer respond). Encourage your users to immediately report any such activity. PREVENTION The installation of tap requires root access. The best methods for preventing a root compromise is to keep current with all security patches and to enforce appropriate control of privileged accounts and passwords. "tap" is installed using SunOS loadable module support. If you do not require loadable modules you can prevent use of "tap" by disabling this system feature. To disable loadable modules, go to the directory: /sys/`arch -k`/conf Edit the kernel configuration file. This file will normally be named for your host name, in upper-case. Comment out the following line with a "#" character: options VDDRV # loadable modules Then, within this directory, build and install the new kernel. Assuming your system is named "gewt". /etc/config GEWT cd ../GEWT make cp /vmunix /vmunix.orig cp vmunix / sync; sync Reboot your system to run the new kernel. Note that intruders have been known to regenerate their own kernels and reboot systems to install the functionality they desire. The authenticity of the running kernel should be verified after any unexplained system reboots. _____________________________________________________________________________ ---------------------------------------------------------------------------- If you have any questions about this bulletin, please contact the NASIRC helpdesk. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= NASIRC ACKNOWLEDGES: ARPA/CERT, Uwe Ellermann, Gene Spafford, DOE/CIAC, Steve Bellovin =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= =============================================================== For further assistance, please contact the NASIRC Helpdesk: Phone: 1-800-7-NASIRC Fax: 1-301-441-1853 International: +1-301-441-4398 STU III: 1-301-982-5480 Internet Email: nasirc@nasa.gov 24 Hour/Emergency Pager: 1-800-759-7243/Pin:2023056 WWW: http://nasirc.nasa.gov/NASIRC_home.html =============================================================== This bulletin may be forwarded without restriction to sites and system administrators within the NASA community. The NASIRC online archive system is available via anonymous ftp. You will be required to enter your valid e-mail address as the "password". Once on the system, you can access the following information: ~/bulletins - NASIRC bulletins ~/information - various informational files ~/toolkits - automated toolkit software The contents of these directories is updated on a continuous basis with relevant software and information; contact the NASIRC Helpdesk for more information or assistance. ----------------- PLEASE NOTE: Users outside of the NASA community may receive NASIRC bulletins. If you are not part of the NASA community, please contact your agency's response team to report incidents. Your agency's team will coordinate with NASIRC, who will ensure the proper internal NASA team(s) are notified. NASIRC is a member of the Forum of Incident Response and Security Teams (FIRST), a world-wide organiza- tion which provides for coordination between incident response teams in handling computer-security-related issues. You can obtain a list of FIRST member organizations and their constituencies by sending email to docserver@first.org with an empty "subject" line and a message body containing the line "send first-contacts".