************************************************************************** Security Bulletin 9502 DISA Defense Communications System January 24, 1995 Published by: DDN Security Coordination Center (SCC@NIC.DDN.MIL) 1-(800) 365-3642 DEFENSE DATA NETWORK SECURITY BULLETIN The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security Coordination Center) under DISA contract as a means of communicating information on network and host security exposures, fixes, and concerns to security and management personnel at DDN facilities. Back issues may be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5] using login="anonymous" and password="guest". The bulletin pathname is scc/ddn-security-yynn (where "yy" is the year the bulletin is issued and "nn" is a bulletin number, e.g. scc/ddn-security-9502). ************************************************************************** + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ! ! ! The following important advisory was issued by the Automated ! ! Systems Security Incident Support Team (ASSIST) and is being ! ! relayed unedited via the Defense Information Systems Agency's ! ! Security Coordination Center distribution system as a means ! ! of providing DDN subscribers with useful security information. ! ! ! + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Automated Systems Security Incident Support Team _____ ___ ___ _____ ___ _____ | / /\ / \ / \ | / \ | | / Integritas / \ \___ \___ | \___ | | < et /____\ \ \ | \ | | \ Celeritas / \ \___/ \___/ __|__ \___/ | |_____\ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bulletin 95-01 Release date: 23 January 1995, 4:00 PM EST (GMT -4) SUBJECT: IP Spoofing Attacks and Hijacked Terminal Connections. SUMMARY: Attacks have been reported on the Internet in which intruders create packets with spoofed source IP addresses to exploit local trusted relationships (i.e. impersonate hosts in site's internal network). Applications and/or devices that rely on the authenticity of a packet's source IP address for access control can be tricked into accepting forged, unauthorized packets by this technique. This attack methodology has been widely publicized in the national media and various Internet discussion forums. This attack methodology does not involve source routing. It should be noted that blocking source routed packets does not solve this problem. Sites that currently "firewall" their external connection(s) should also note that if their firewall (including filtering routers and bridges) relies on the source address of inbound packets for access decisions, they will also be susceptible to this spoofing technique. Inbound interface filtering can help alleviate this problem depending on how the firewall implements the site's security protection policy. In addition to the IP spoofing, intruders using the current attack pattern are dynamically modifying the kernel of a Sun 4.1.X system once root access is obtained. This activity is separate from the IP spoofing attack, and can be used to take control of any open terminal or login session on the compromised system. BACKGROUND: This section contains a summary of both the IP spoofing technique being used to gain root access on a system and the tool being used to take over open terminal and login connections after root access is gained. Note: While the current attack methodology involves the two phases described above, intruders can use IP spoofing to gain root access for any purpose; similarly, they can highjack terminal connections regardless of their method of gaining root access. IP spoofing. To gain root access, intruders create packets with spoofed source IP addresses that appear to be from hosts on the targeted site's internal network. It is possible to route packets through filtering-router firewalls if they are not configured to filter incoming packets whose source address is in the local domain. It is important to note that the described attack is possible even if no reply packets can reach the attacker. Examples of router configurations that are vulnerable include: - routers to external networks that support multiple internal interfaces - routers with two interfaces that support subnetting on the internal network - proxy firewalls where the proxy applications use the source IP address for authentication The IP spoofing attacks are similar to those described in two papers: 1) "Security Problems in the TCP/IP Protocol Suite" by Steve Bellovin, published in _Computer Communication Review_ vol. 19, no. 2 (April 1989) pages 32-48 2) "A Weakness in the 4.2BSD Unix TCP/IP Software," by Robert T. Morris. Both papers are available by anonymous FTP from ftp.research.att.com: /dist/internet_security. Bellovin paper: ipext.ps.Z Morris paper: 117.ps.Z Services that are vulnerable to the IP spoofing attack include SunRPC & NFS BSD UNIX "r" commands anything wrapped by the tcp daemon wrappers - site dependent; check your configuration X windows other applications that use source IP addresses for authentication Hijacking tool. Once the intruders have root access on a system, they can use a tool to dynamically modify the UNIX kernel. This modification allows them to hijack existing terminal and login connections from any user on the system. 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. For example, a legitimate user connects to a remote site through a login or terminal session; the intruder hijacks the connection after the user has completed the authentication to the remote location; the remote site is now compromised. (See BACKGROUND for examples of vulnerable configurations.) Currently, the tool is used primarily on SunOS 4.1.x systems, however the system features that make this attack possible are not unique to Sun. IMPACT: Spoofing IP addresses can lead to unauthorized remote root access to systems behind a filtering-router firewall. In taking over existing TCP connections, intruders can bypass authentication schemes by taking over the session after the user has been successfully authenticated. ATTENTION: This includes bypassing one time passwords and other strong authentication schemes previously considered to be extremely resistant to attack. RECOMMENDED SOLUTION: Detection and prevention. A. Detection IP spoofing. If you monitor packets using network-monitoring software such as netlog, look for a packet on your external interface that has both its source and destination IP addresses in your local domain. If you find one, you are currently under attack. Netlog is available by anonymous FTP from assist.mil in /pub/tools/netlog-1.2.tar.gz and from net.tamu.edu in /pub/security/TAMU/netlog-1.2.tar.gz, MD5 checksum: XX <> Another way to detect IP spoofing is to compare the process accounting logs between systems on your internal network. If the IP spoofing attack has succeeded on one of your systems, you may get a log entry on the victim machine showing a remote access; on the apparent source machine, there will be no corresponding entry for initiating that remote access. Hijacking tool When the intruder attaches to an existing terminal or login connection, users may detect unusual activity, such as commands appearing on their terminal that they did not type or a blank window that will no longer respond to their commands. Encourage your users to inform you of any such activity. In addition, pay particular attention to connections that have been idle for a long time. Once the attack is completed it is difficult to detect, however the intruders may leave remnants of their tools. For example, you may find a kernel streams module designed to tap into existing TCP connections. B. Prevention IP spoofing. 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 in order to prevent a source IP spoofing attack from originating from your site. The following vendors have reported support for this feature: Bay Networks/Wellfleet routers, version 5 and later Cabletron - LAN Secure Cisco - RIS software all releases of version 9.21 and later Livingston - all versions If you need more information about your router or about firewalls, please contact your vendor or ASSIST. If your vendor's router does not support filtering on the inbound side of the interface or if 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, on the outgoing interface connected to your original router, all packets that have a source address in your internal network. For this purpose, you can use a filtering router or a UNIX system with two interfaces that supports packet filtering. NOTE: Disabling source routing at the router does not protect you from this attack, but it is still good security practice to do so. Hijacking tool. There is no specific way to prevent use of the tool other than preventing intruders from gaining root access in the first place. If you have experienced a root compromise, see the next section for general instructions on how to recover. Recovery from a UNIX root compromise 1. Disconnect from the network or operate the system in single- user mode during the recovery. This will keep users and intruders from accessing the system. 2. Verify system binaries and configuration files against the vendor's media (do not rely on timestamp information to provide an indication of modification). Do not trust any verification tool such as cmp(1) located on the compromised system as it, too, may have been modified by the intruder. In addition, do not trust the results of the standard UNIX sum(1) program as we have seen intruders modify system files in such a way that the checksums remain the same. Replace any modified files from the vendor's media, not from backups, -- or -- reload your system from the vendor's media. 3. Search the system for new or modified setuid root files. find / -user root -perm -4000 -print If you are using NFS or AFS file systems, use ncheck to search the local file systems. ncheck -s /dev/sd0a 4. Change the password on all accounts. 5. Don't trust your backups for reloading any file used by root. You do not want to re-introduce files altered by an intruder. ASSIST would like to thank the CERT Coordination Center and Joe Sirrianni, DISA Center for Information Systems Security for information contained in this bulletin. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ASSIST is an element of the Defense Information Systems Agency (DISA), Center for Information Systems Security (CISS), that provides service to the entire DoD community. Constituents of the DoD with questions about ASSIST or computer security security issues, can contact ASSIST using one of the methods listed below. Non-DoD organizations/institutions, should contact their Forum of Incident Response and Security Teams (FIRST) (FIRST) representative. To obtain a list of FIRST member organizations and their constituencies send an email to docserver@first.org with an empty "subject" line and a message body containing the line "send first-contacts". ASSIST Information Resources: To be included in the distribution list for the ASSIST bulletins, send your Milnet (Internet) e-mail address to assist-request@assist.mil. Back issues of ASSIST bulletins, and other security related information, are available from the ASSIST BBS at 703-756-7993/1154 DSN 289-7993/1154, and through anonymous FTP from assist.mil (IP address 199.211.123.11). Note: assist.mil will only accept anonymous FTP connections from Milnet addresses that are registered with the NIC or DNS. ASSIST Contact Information: PHONE: 800-357-4231 (or 703-756-7974 DSN 289), duty hours are 06:00 to 22:30 EDT (GMT -4) Monday through Friday. During off duty hours, weekends and holidays, ASSIST can be reached via pager at 800-791- 4857. The page will be answered within 30 minutes, however if a quicker response is required, prefix the phone number with "999". ELECTRONIC MAIL: Send to assist@assist.mil. ASSIST BBS: Leave a message for the "sysop". Reference herein to any specific commercial product, process, or service by trade name, trademark manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by ASSIST. The views and opinions of authors expressed herein shall not be used for advertising or product endorsement purposes. **************************************************************************** * * * The point of contact for MILNET security-related incidents is the * * Security Coordination Center (SCC). * * * * E-mail address: SCC@NIC.DDN.MIL * * * * Telephone: 1-(800)-365-3642 * * * * NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST, * * Monday through Friday except on federal holidays. * * * **************************************************************************** PLEASE NOTE: Some users outside of the DOD computing communities may receive DDN Security bulletins. If you are not part of the DOD community, please contact your agency's incident response team to report incidents. Your agency's team will coordinate with DOD. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained by sending email to docserver@first.org with an empty subject line and a message body containing the line: send first-contacts. This document was prepared as an service to the DOD community. Neither the United States Government nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government. The opinions of the authors expressed herein do not necessarily state or reflect those of the United States Government, and shall not be used for advertising or product endorsement purposes.