From owner-freebsd-security Mon Dec 9 23:04:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA21639 for security-outgoing; Mon, 9 Dec 1996 23:04:42 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA21630 for ; Mon, 9 Dec 1996 23:04:40 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Tue, 10 Dec 1996 02:04:38 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id CAA22202; Tue, 10 Dec 1996 02:01:23 -0500 (EST) Received: from nap.io.org(10.1.1.3) by gate.ican.net via smap (V1.3) id sma022184; Tue Dec 10 02:00:56 1996 Received: from localhost (taob@localhost) by nap.io.org (8.7.5/8.7.3) with SMTP id BAA02308; Tue, 10 Dec 1996 01:58:03 -0500 (EST) X-Authentication-Warning: nap.io.org: taob owned process doing -bs Date: Tue, 10 Dec 1996 01:58:03 -0500 (EST) From: Brian Tao Reply-To: Brian Tao To: Karl Denninger cc: freebsd-security@FreeBSD.ORG Subject: Re: URGENT: Packet sniffer found on my system In-Reply-To: <199612100602.AAA05680@Jupiter.Mcs.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Dec 1996, Karl Denninger wrote: > > What program(s) are SUID on the machines in question? On the shell servers, not many. /usr/local/bin/ping is a modified ping binary that disallows the -f, -s and -l flags to non-root users: # find / -fstype ufs -perm -4000 -user root -ls 3848 256 -r-sr-xr-x 1 root bin 122880 Dec 2 12:24 /usr/local/bin/ping 4259 368 ---s--x--x 1 root bin 176128 Nov 5 23:11 /usr/local/bin/screen-3.7.1 4139 832 ---s--x--x 2 root bin 413696 Oct 17 02:21 /usr/local/bin/sperl5.003 4139 832 ---s--x--x 2 root bin 413696 Oct 17 02:21 /usr/local/bin/suidperl 4181 384 -r-s--x--x 1 root bin 188416 Oct 31 12:45 /usr/local/bin/ssh 7845 24 -r-sr-xr-x 1 root bin 12288 Oct 14 21:14 /usr/bin/lock 7880 32 -r-sr-xr-x 1 root bin 16384 Oct 14 21:15 /usr/bin/rlogin 7884 24 -r-sr-xr-x 1 root bin 12288 Oct 14 21:15 /usr/bin/rsh 7902 24 -r-sr-xr-x 1 root bin 12288 Oct 14 21:15 /usr/bin/su 7973 560 -r-sr-sr-x 5 root kmem 274432 Nov 17 13:54 /usr/bin/newaliases 7973 560 -r-sr-sr-x 5 root kmem 274432 Nov 17 13:54 /usr/bin/mailq 7973 560 -r-sr-sr-x 5 root kmem 274432 Nov 17 13:54 /usr/bin/hoststat 7973 560 -r-sr-sr-x 5 root kmem 274432 Nov 17 13:54 /usr/bin/purgestat 7973 560 -r-sr-sr-x 5 root kmem 274432 Nov 17 13:54 /usr/sbin/sendmail 8357 32 -r-sr-xr-x 1 root bin 16384 Oct 14 21:16 /usr/sbin/traceroute 61 368 -r-sr-xr-x 1 root bin 180224 Oct 14 21:09 /bin/rcp > Do they trust any other hosts (.rhosts) for root access (ie: to run backups)? No. > 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. We run ident, login, ntalk, shell and telnet services out of inetd on the shell servers.. On the Web/FTP server, only ftpd is listed (shell access for authorized users is done through ssh). > 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?) No anomalous setuid binaries have been found. I look for any setuid/setgid executable not owned by a regular user. User root is the obvious case, but I'm sure someone could still do damage with a setuid bin or daemon executable. What's the executive summary with sendmail 8.8.4? It sounds like it fixes the same "kill -1" bug that was supposedly closed for 8.8.3? > Are /dev/kmem and /dev/mem secure (640, root/kmem ownerships)? If you can > write to /dev/kmem the game's over. All instances of those devices are mode 640, owned by root.kmem. > 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. I've heard of this with regard to using real VT-xxx terminals, but does xterm have the same weakness? Could someone test this, since I don't know what the escape sequence is. > 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. I would say late night December 8, continuing throughout the day on December 9. This is based on the timestamp of the log files and of the binaries and related scripts. In addition to the log files, there was the packet sniffer itself (named 'b') and a perl script named 'apache' that simply exec'd ./b with the appropriate command line arguments to capture passing logins. > 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. The account containing the log files and the sniffer has been deleted, but there's no telling what account the hacker will use next. If I'm lucky, I will have removed the data before he had a chance to retrieve it himself, but I doubt that would be the case (nearly a day has already passed since the first sniffing runs). I'm going to go through previous advisories to see if there is something I missed. I know I've nabbed sendmail pre-8.8..3, lpr, and older stuff that have been fixed for the 2.2-961014 snapshot. I hope this isn't something new that hasn't made it to the various lists yet... -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't"