MCI Telecommunications internetMCI Security Group Report Name: iMCI MIIGS Security Alert Report Number: iMCISE:IMCISDC:112696:01:P1R1 Report Date: 11/26/96 Report Format: Formal Report Classification: MCI Informational Report Reference: http://www.security.mci.net Report Distribution: iMCI Security, MCI Internal Internet Gateway Security (MIIGS), MCI Emergency Alert LiSt (MEALS) (names on file) ---------------------------------------------------------------------------- --- ____________________________________________________________________________ ____ The San Diego Supercomputer Center (SDSC) and the Pacific Institute of Computer Security (PICS) have detected "in the wild" and analyzed an automated attack related to the problems with rpc.statd as discovered from source code analysis by Andrew Gross and alluded to by CERT Advisory CA-96.09.rpc.statd. This advisory is furnished by SDSC, PICS and the San Diego Regional Information Watch (SDRIW) as a public service to the Internet community. CERT is aware of this problem, and is reportedly working with vendors to deal with this issue. However, there is increasing evidence that this attack is becoming widespread, is not easily detected by most monitoring, and required access to vendor source code to verify that the symptoms did indeed constitute an attack. Therefore, SDSC, PICS and SDRIW have decided to make this information available independently of the CERT channels, so that users may look for this attack on their systems and take steps to protect their systems. I. Description As reported in the CERT Coordination Center Advisory CA-96.09.rpc.statd, there is a vulnerability in some versions of rpc.statd (rpc.statd is also known as statd on some systems). At the time of that advisory, there had been no reports of this vulnerability being exploited. At that time, it was believed that the vulnerability was limited to being used to remove any file that the root user can remove or to create any file that the root user can create. In this attack, rpc.statd is passed information causing it to create a file that has *machine code* inserted into the *filename* of the file. This filename is sufficiently long that a buffer overflow occurs, placing arbitrary machine code onto the stack, which is then executed. This "grappling hook" is specific to each cpu type and operating system combination. The grappling hook causes a root shell to be started, connected to the network socket of the rcp.statd process. II. Impact Remote users using this exploit will receive a root shell on the machine where rpc.statd runs. *At this time*, the attack that was seen would only be successful on *unpatched* Solaris 2.4 and previous versions, although (unsuccessful) attacks have been observed on other system types. Reverse engineering of this attack has proven that other operating systems are vulnerable to similar, if not identical, attacks, with only a different "grappling hook" required. Attacks against other operating systems have been demonstrated in the PICS laboratory. III. Solution *It is hoped* that *most* vendors have fixed this problem properly with their patches that addressed the Advisory, however, without source of the patches, or statements from the vendors, we cannot be sure. The proper fix is to prohibit "/" in the pathnames of the files created by rpc.statd, AND check the lengths of the strings and buffers involved before doing the copy. Just changing the buffer size or (C language) storage type is insufficient. Install vendor patches (where available) as described in CA-96.09.rpc.statd and CA-96.09.README, although as noted above, this may not completely close this vulnerability. The Advisory may be found at: ftp://ftp.cert.org/pub/cert_advisories/CA-96.09.rpc.statd and the README may be found at ftp://ftp.cert.org/pub/cert_advisories/CA-96.09.README IV. Detecting an attack The following signature information is provided for general information only. It details one specific implementation of this attack method. Existence of the signature information does not mean that the attack was successful, only that it was tried. Non-existence of the signature information does not mean that the attack hasn't been tried; the attackers can easily remove the files after gaining access (and leaving other trap doors). There is no obvious way to determine if the attack was successful, other than system logs, tripwire databases, and cryptographic checksums of critical software. IV.A. Unusual files in "/tmp" You can look for traces of this exploit by examining the /tmp directory for filenames that begin with .nfs, and that have long filenames that are not printable ASCII characters. The .nfs* files should only exist in filesystems that are NFS-mounted, which would be very unusual for a "/tmp" filesystem. Note that the exploit software could (and probably will) be changed to create this file in any directory writable by "root". Here is a sample of what you may see (with the long lines wrapped): % ls -l /tmp/.nfs* total 280 --w------- 1 root 0 Sep 4 07:27 .nfs09???D???H???$???$???$???$????? ????????? ??? ??? ??? `?? O?*???*???*???*???#???#???????? P?*`???c??? 6????????? ? ??????????? ??????? ??????? )?????????? ??????? ??????#???#???? ;????????????? ????????????#??????????XbinXsh?tirdwr????? ??? ??? ??? ??? The fact that the file is zero-length is of no help, as the assembly-code "grappling hook" is encoded in the *filename*, not the file contents. IV.B System logs If you aren't running tcp_wrappers and the "logging portmapper", you will likely never even see the attack in any normal system logs. However, if you do have these packages, you *may* see sweeps of your network, with some hosts being probed for RPC services (rpcinfo -p), followed by probes of services that are active (rpc.mountd, rpc.statd, etc.) If you are running Solaris 2.5 (with patched statd) you *may* see system log messages similar to this: Sep 4 10:15:37 hostname statd[130]: attempt to create "/var/statmon/sm //../../../../../../../../../../../../../../../../../../../../../../../../.. /../ ../../../../../../../../../../../../../../../../../../../../../../../../../. ./.. /../../../../../../../../../../../../../../../../../../../../../../../../../ ../. ./../../../../..//../../../../../../../../../../../../../../../../../../../. ./.. /../../../../../../../../../../../../../../../../../../../../../../../../../ ../. ./../../../../../../../../../../../../../../../../../../../../../../../../.. /../ ../../../../../../../../../../../../../tmp/.nfs09 D H $ $ $ $ ` O * * * * # # P *` c 6 ) # # ; # XbinXsh tirdwr " V. Acknowledgments Information in this bulletin was produced by Andrew Gross, Henry Ptasinski, and Tom Perrine. San Diego Supercomputer Center: http://www.sdsc.edu Pacific Institute of Computer Security: http://www.sdsc.edu/GatherScatter/GSspring96/perrine.html San Diego Regional Information Watch: http://www.sdriw.org VI. Disclaimers Copyright 1996 San Diego Supercomputer Center. The material in this security alert may be reproduced and distributed, without permission, in whole or in part, by other security incident response teams (both commercial and non-commercial), provided the above copyright is kept intact and due credit is given to SDSC. This security alert may be reproduced and distributed, without permission, in its entirety only, by any person provided such reproduction and/or distribution is performed for non-commercial purposes and with the intent of increasing the awareness of the Internet community. ===============================================================