From owner-freebsd-security Mon Dec 9 22:03:13 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA16879 for security-outgoing; Mon, 9 Dec 1996 22:03:13 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA16871 for ; Mon, 9 Dec 1996 22:03:11 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id AAA06914; Tue, 10 Dec 1996 00:02:23 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id AAA01281; Tue, 10 Dec 1996 00:02:22 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id AAA05680; Tue, 10 Dec 1996 00:02:21 -0600 (CST) From: Karl Denninger Message-Id: <199612100602.AAA05680@Jupiter.Mcs.Net> Subject: Re: URGENT: Packet sniffer found on my system To: taob@io.org (Brian Tao) Date: Tue, 10 Dec 1996 00:02:21 -0600 (CST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: from "Brian Tao" at Dec 10, 96 00:15:52 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I happened across an interesting little process today on a few of > ous servers. It appears to be the "sniffit" packet sniffer found in > the Linux RootKit. I can mail the binary to anyone who wants to > analyse it. Yuck. > I'd like to know how he was able to run the process as root. The > binary is *not* setuid, and a "ps auxo ruser" shows the real owner is > also root. The three servers I found it running on have 2.2-961014 > installed, upgraded to sendmail 8.8.3. The two shell servers have had > all but six setuid root binaries chmod 500'd. The Web/FTP server does > not grant shell access. Is there something with Apache 1.1.1 or > wu-ftpd I don't know about that allows a user to execute arbitrary > code as root? I noticed lpr still had its setuid bit on the FTP > server, but afaik, there is no way to tell wu-ftpd to run arbitrary > programs as root. We are running wu-ftpd 2.4(1). > > Any ideas how root access was available so easily? > -- > Brian Tao (BT300, taob@io.org, taob@ican.net) What program(s) are SUID on the machines in question? Do they trust any other hosts (.rhosts) for root access (ie: to run backups)? If so: Is your DNS secure (ie: do you run both primary and secondary for forward AND reverse on YOUR network, and were these machines compromised?) Current versions of FreeBSD check the .rhosts file for stupid things (like being world or group writeable). You can enhance this somewhat by refusing to honor any .rhosts that's not mode 400 (this is a fairly trivial change to the libraries and probably worth it). What is in /etc/inetd.conf that runs things as root? Anything listed as root in there may as well be SUID root; add them to the list of suspects. When did you upgrade to sendmail 8.8.3, and are you SURE that someone hadn't planted a "root shell" somewhere first? That particular exploit was so trivial to use that it would the first place I'd be suspicious of. (do you scan all writable disks, and any mounted remote without "nosuid", for SUID programs with "find -perm -4000 ...." or equivalent regularly? If so, how long ago was the last *successful* scan that showed no anomalies?) Are /dev/kmem and /dev/mem secure (640, root/kmem ownerships)? If you can write to /dev/kmem the game's over. Ditto for all physical disk devices and partitions for the same reason. Finally, a stupid one -- do you always run "mesg n" when signed in or SU'd as root? One of the oldest tricks in the book is to use ANSI sequences to send this: "cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4711 /tmp/sh" Then send "up cursor" and "transmit line" (!) Cute, and it DOES work. If done properly you'll barely see it flash by before its erased on your tube (by the following "erase line" sequence) -- and you're SCREWED. The equivalent of this is a favorite on *ANY* OS if you can find someone stupid on a privileged terminal with an ANSI-style (ie: VT100) terminal. Its amazingly effective, which is why you need to be DAMN sure you always have write permission OFF whenever you're operating as an admin. Yes, even on the physical console. The problem with these kinds of compromises is finding out when the original violation took place. Without some kind of clue to this you're on a hunt for the cause of an event you don't well understand, which is not a good position to be in. Regular suid scans help; if you can nail down that an existing root utility was the culprit as of (x) date then you have a limited list of suspects. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 33 Analog Prefixes, 65 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal