************************************************************************** Security Bulletin 9532 DISA Defense Communications System August 3, 1995 Published by: DISN Security Coordination Center (SCC@NIC.DDN.MIL) 1-(800) 365-3642 DEFENSE INFORMATION SYSTEM NETWORK SECURITY BULLETIN The DISN SECURITY BULLETIN is distributed by the DISN 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 DISN 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/disn-security-yynn (where "yy" is the year the bulletin is issued and "nn" is a bulletin number, e.g. scc/disn-security-95313131). ************************************************************************** + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ! ! ! 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 DISN subscribers with useful security information. ! ! ! + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -----BEGIN PGP SIGNED MESSAGE----- <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Automated Systems Security Incident Support Team _____ ___ ___ _____ ___ _____ | / /\ / \ / \ | / \ | | / Integritas / \ \___ \___ | \___ | | < et /____\ \ \ | \ | | \ Celeritas / \ \___/ \___/ __|__ \___/ | |_____\ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bulletin 95-29 Release date: 31 July, 1995, 4:00 PM EDT (GMT -4) SUBJECT: IP Spoofing Attacks. SUMMARY: ASSIST has received information about numerous recent IP spoofing attacks directed against Internet sites internationally. A large number of the systems targeted in the IP spoofing attacks are name servers, routers, and other network operation systems, and the attacks have been largely successful. Refer to ASSIST 95-01 for information about protecting systems, detecting IP spoofing attacks, and recovery from root compromises. This message provides information about additional actions that can be taken. BACKGROUND: Intruders create packets with spoofed source IP addresses to gain unauthorized access to networked systems. The IP spoofing exploits applications that use authentication based on IP addresses and leads to unauthorized user and possibly root access on the targeted system. Examples of exploited applications are the rsh and rlogin services. 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 configurations that are potentially 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 IMPACT: Remote users can gain unauthorized access, including root. RECOMMENDED SOLUTIONS: It is possible to check network traffic for indications of the IP spoofing attacks, however you should consider the following issues before taking action. Technical and performance issues: * There may be too many "false positives". Two causes of which are mobile IP and misconfigurations; there may be other causes as well. * The feasibility of installing network monitors may depend on network topology. * It is not clear how many monitoring machines you would need to pinpoint the problem. * When the tcpdump and snoop scripts were tested on a dedicated Sun IPX connected to a T1, the impact on performance was only marginal. Long-haul tests with similar scripts do not have performance problems either. * Anything above a T1 is going to cause some performance problems (applications like tcpdump and snoop do not work very well at all on DS3 or FDDI interfaces). Legal issues: * For the U.S., the Digital Telephony Bill of 1994 is relevant; in particular, check the amended provision found at 18 U.S.C. 2511(2) (a) (i), which permits an electronic communications service and its employees to ...intercept, disclose, or use that communication in the normal course of... employment while engaged in any activity which is a necessary incident to the rendition of...service (i.e. use to keep the system operational) or to the protection of the rights or property of the provider of that service (i.e. use to protect against fraud, waste, and abuse).... * Sites are strongly urged to consult with appropriate counsel for legal guidance on analyzing packet header information, analyzing traffic content to detect unauthorized activity, and analyzing internal traffic and customer-bound traffic. There are several classes of packets that you could watch for. The most basic is any TCP packet where the network portion (Class A, B, or C or a prefix and length as specified by the Classless Inter- Domain Routing (CIDR) specification) of the source and destination addresses are the same but neither are from your local network. These packets would not normally go outside the source network unless there is a routing problem, worthy of additional investigation, or the packets actually originated outside your network. The latter may occur with Mobile IP testing, but an attacker spoofing the source address is a more likely cause. For a NAP or NSP, the interface into which a packet arrived indicates the direction of the source of the attack. The packet's destination address indicates the "trusted" host involved in an attack. That information suggests which hosts may be under attack. There are public domain and vendor provided tools available for checking your networks for IP spoofed packets. Among them are Argus, tcpdump, and snoop. Argus 1.5 - --------- Argus is an IP network transaction-auditing tool developed at the Software Engineering Institute of Carnegie Mellon University. The Argus 1.5 distribution includes scripts that perform simple network administrative tasks, one of which is IP spoofing detection. The data that Argus generates makes it possible to analyze network activity and performance in ways that have not been possible before. For example, you can answer questions such as, "Were there any IP spoofing attempts into our firewall network over the past 8 hours?" The developers of Argus have made the tools available from ftp://ftp.sei.cmu.edu/pub/argus-1.5 If you have any questions, comments, or suggestions, please send mail to argus@sei.cmu.edu. Scripts - ------- Even though the Internet is now "classless," meaning that the old notion of class A, B, and C addresses is being replaced with a prefix and length notation, the scripts may be useful to some service providers. In the recently noted IP spoofing incidents, the scripts would have shown the spoofed packets, however a potential problem is that these scripts may either show other packets labeled as spoofed or not show true spoofed packets due to CIDR. A standalone machine running tcpdump or equivalent should be able to run these scripts without affecting the performance of the local net. It may be possible to configure routers to do this check directly, but this has not been tested as of yet. Scripts for Checking Networks - ----------------------------- The following scripts were tested on a recent version of tcpdump and snoop (192.9.200.0 would be replaced by the site's local net, IP): --- script for tcpdump --- #!/bin/sh tcpdump 'tcp and not dst net 192.9.200.0 and ( (ip[12]&0x80=0 and ip[12]=ip[16]) or (ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or (ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18]) )' (Note this only seems to work with tcpdump-3.0.2 and libpcap-0.0.6 currently.) --- script for snoop --- #!/bin/sh snoop 'tcp and not net 192.9.200.0 and ((ip[12]&0x80=0 and ip[12]=ip[16]) or (ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or (ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18]))' (Note that this does not appear to work with Solaris 2.3 machines.) To more accurately analyze network traffic, it is useful to first describe the network topology; for example: ---------------- | INTERNET | ---------------- | ---------- | | NETWORK | ---------------- | MONITOR | | ROUTER | ---------- ---------------- | | | | - ------------------------------------------------------- | | | MAC-A MAC-B MAC-C - --------- --------- --------- |ROUTER | |ROUTER | |ROUTER | - --------- --------- --------- | | | | | | | | | | | | | | | | | | | | | | | | | | | Ca Cb Cc Cd Ce Cf Cg Ch Ci (MAC-A, MAC-B, and MAC-C refer to the ethernet addresses of the router interfaces attached to the same network as the network monitor machine.) In this case, the machine used to check network traffic could be any machine capable of running tcpdump, snoop, or any other packet capture and analysis software. This machine could be programmed so that any packets that match the following expression are displayed. tcp and ( not ether src MAC-A and ( src net Ca or src net Cb or src net Cc ) not ether src MAC-B and ( src net Cd or src net Ce or src net Cf ) not ether src MAC-C and ( src net Cg or src net Ch or src net Ci ) ) This expression looks at the source address of each packet and identifies those that did not originate from the correct interface. This example should be extensible to take CIDR into account. For example, if the CIDR specification of network Ca is 192.9.200/21, then the sub-expression: src net Ca should be replaced with: ip[12:4]&0xfffff800=192.9.200.0 ASSIST would like to thank the CERT Coordination Center 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 issues, can contact ASSIST using one of the methods listed below. Non-DoD organizations/institutions, contact the 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-607-4710, 327-4710, 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. If your system is not registered, you must provide your MILNET IP address to ASSIST before access can be provided. ASSIST Contact Information: PHONE: 800-357-4231 (or 703-607-4700 DSN 327), 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". ASSIST uses Pretty Good Privacy (PGP) 2.6.2 as the digital signature mechanism for bulletins. PGP 2.6.2 incorporates the RSAREF(tm) Cryptographic Toolkit under license from RSA Data Security, Inc. A copy of that license is available via anonymous FTP from net-dist.mit.edu (IP 18.72.0.3) in the file /pub/PGP/rsalicen.txt, and through the world wide web from http://net-dist.mit.edu/pgp.html. In accordance with the terms of that license, PGP 2.6.2 may be used for non-commercial purposes only. Instructions for downloading the PGP 2.6.2 software can also be obtained from net-dist.mit.edu in the pub/PGP/README file. PGP 2.6.2 and RSAREF may be subject to the export control laws of the United States of America as implemented by the United States Department of State Office of Defense Trade Controls. The PGP signature information will be attached to the end of ASSIST bulletins. 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. - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAi4uZ40AAAEEAM1uraimCNeh5PtzX7KoGxC2u8uMTdl8V5sujk3MHbWvCuOM W0FqDy5s9iwfQLZWzJ7cbM6L0mNOj8eJGoz7TqGKZDDRFlKAwg0x8joleZLC2gXw FVdF/g6Mdv7ok7heoa+Y//YMeADnsSrmzqLCnhFbKYffww3EbdH6sbnW3Io9AAUR tB9BU1NJU1QgVGVhbSA8YXNzaXN0QGFzc2lzdC5taWw+iQCVAwUQL1xx7tH6sbnW 3Io9AQEBYwP9FvIJbnKjtMLUj8ghd6hophSx8WZnfQsOmZX/BbX8vKz1a5BkBn4q ANvW+uKGdUlE8LLMEm1PD59Cihcb3OoWDOU8zIOIErvry4eqa+LzEXV8nnBdes+A a1MCMGSz+K3OaP78lQ7JCGoY9TXTWIelfAdBVBG4VQcSQRn8tjRdG2e0KEFTU0lT VCBUZWFtIDxhc3Npc3RAYXNzaXN0Lmltcy5kaXNhLm1pbD6JAJUCBRAuLnHoh0Y9 0jC+b6kBAU0TA/4yXSL7K6tcfVm9ACnP4crCoutFM2w10e7YKxD850ajhWrh6rI9 O+sjU5WObqiPJ7sZHdEw/KARzPSijH/5h8HlyYa6ClksWxYuymzCsUYYJctdjcGr uakfXgYQ1TkkyUfNrN5G90NuRK/vTRe7bkmyGNYjN9Njac1Q18WVF59Chg== =d5rP - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBMB01kNH6sbnW3Io9AQGcggP/RSFdT0wzyF0QSQ36e3dQaRqdKGA7qqNU Nkx50Esf+fO2+LdFuxq82TNJSsKl3VVP6vHMytVcm7/UKhuOyfS6Lu7sNjwaQ/zY KSqZCs6WS0RKUHmPH34raOx0LhopQgE3ZsW47kPSJNYjY55/p/Ag+JXLADliowZF Gfg2+iG5FZs= =3pYw -----END PGP SIGNATURE----- **************************************************************************** * * * The point of contact for NIPRNET 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 DISN 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.