--------------------------------------------------------------------------- CERT Summary CS-95:01 July 26, 1995 As part of our ongoing efforts to disseminate timely information about Internet security issues, the CERT Coordination Center is pleased to announce the CERT Summary. CERT Summary will be distributed periodically to call attention to the types of attacks currently being reported to the CERT Coordination Center. The summary will include pointers to sources of information for dealing with the problems. --------------------------------------------------------------------------- Recent Activity The majority of incidents reported to the CERT Coordination Center in recent weeks fall into three categories: 1. IP Spoofing: We have seen a surge in IP spoofing. In recent weeks, we have received more than 170 reports of IP spoofing attacks or probes, many of them resulting in a successful break in. Several sites believed incorrectly that they were blocking such packets. Others planned to block them but hadn't yet done so. We urge you to take the time to review CERT Advisory CA-95:01, "IP Spoofing Attacks and Hijacked Terminal Connections," which has details on this type of attack and how to prevent it. Vulnerability to IP spoofing attacks is NOT limited to any specific router or OS vendor. This advisory is available from ftp://info.cert.org/pub/cert_advisories/CA-95:01.IP.spoofing ftp://info.cert.org/pub/cert_advisories/CA-95:01.README 2. Packet Sniffers: We receive new reports daily that describe sniffers installed on compromised hosts. These sniffers, which are used to collect account names and passwords, are frequently installed using a kit. Further information on packet sniffers is available from ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://info.cert.org/pub/cert_advisories/CA-94:01.README Once root is compromised on a system, the sniffer kit can be activated to collect account names and passwords. Note that even if sniffing capabilities are disabled by recompiling and rebooting the kernel, we have received reports of intruders re-enabling these capabilities by recompiling and rebooting systems. Pay particular attention to every system reboot. In the attacks that we have seen, intruders frequently install (as root) Trojan horse system software that is available with the sniffer kit. Further information on the Trojan horses that we have seen is available from ftp://info.cert.org/pub/cert_advisories/CA-94:05.MD5.checksums ftp://info.cert.org/pub/cert_advisories/CA-94:05.README 3. NFS Attacks: We have seen a large increase in the number of attacks and probes against weaknesses within NFS. Again, many of these are successful. Programs to automate such attacks have become widespread. Please review CERT Advisory CA-94:15, "NFS Vulnerabilities," and its associated README file. They are available from ftp://info.cert.org/pub/cert_advisories/CA-94:15.NFS.Vulnerabilities ftp://info.cert.org/pub/cert_advisories/CA-94:15.README A successful attack usually results in the intruders gaining root access. Intruders have been targeting machines with vendor-licensed source code. They appear to be in search of the code for system software with the view to creating and installing copies containing Trojan horses on compromised systems. If you manage systems that contain vendor-licensed source code, pay particular attention to the "Security Measures" section of the advisory. ------------------------- New Trojan Horse Programs Once root has been compromised on a system, we are finding new Trojan horses installed in the inetd and in.rexecd daemons. These Trojan horses allow an intruder to gain access at a later time, bypassing most firewall and TCP wrapper configurations. Do not rely on checksums determined by the sum(1) program because intruders are creating files whose checksums match those of the vendor-distributed versions. Do not rely on time stamps of these files either because intruders are setting these to previous values as well. We recommend that you use a known clean version of cmp(1) to make a direct comparison of the binaries and the appropriate distribution media. Alternatively, you can check the MD5 results on suspect binaries against a list of MD5 checksums from known good binaries. Ask your vendor to make MD5 checksums available for their distribution binaries. You can also consult the following for some additional information on MD5: ftp://info.cert.org/pub/cert_advisories/CA-94:05.MD5.checksums ftp://info.cert.org/pub/cert_advisories/CA-94:05.README In addition, tools such as Tripwire can archive MD5 checksums of known good binaries when used immediately after a system installation. If you use Tripwire, you should regularly maintain the checksums on removable or read-only media. For more details on Tripwire and MD5, see the CERT security checklist: ftp://info.cert.org/pub/tech_tips/security_info We are also seeing Trojan horses introduced into shared object libraries. Examples are /usr/lib/libc.so.* and /usr/kvm/libkvm.so.* on SunOS-based machines. Although we have only received reports of SunOS-based machines being altered, the techniques used by intruders are applicable to other systems that use shared object libraries. These libraries are being modified so that the presence of certain directories and processes cannot be detected with vendor-provided programs or public domain programs built to use shared object libraries. This means that ANY program using these shared libraries will act in the manner described by the intruder without the intruder necessarily having to modify the program itself. The Trojan horse daemons previously described typically become "invisible" to programs such as ps once the kvm shared object library has been modified. Similarly, the directories used by intruders for building these daemons are "invisible" once the libc shared object library has been modified. Again, do not rely on checksums using sum(1) or time stamps to detect altered files. Use a known clean version of cmp(1) or a strong checksum technique such as MD5 to verify your files against the appropriate distribution. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org), or PEM (contact CERT staff for details). Internet e-mail: cert@cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT advisories and bulletins are posted on the USENET news group comp.security.announce. If you would like to have future advisories and bulletins mailed to you or to a mail exploder at your site, please send mail to cert-advisory-request@cert.org. Past CERT publications, information about FIRST representatives, and other information related to computer security are available by anonymous FTP from info.cert.org. --------------------------------------------------------------------------- Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University.