Date: Tue, 10 Dec 1996 01:58:03 -0500 (EST) From: Brian Tao <taob@io.org> To: Karl Denninger <karl@Mcs.Net> Cc: freebsd-security@FreeBSD.ORG Subject: Re: URGENT: Packet sniffer found on my system Message-ID: <Pine.BSF.3.95.961210011814.1328D-100000@nap.io.org> In-Reply-To: <199612100602.AAA05680@Jupiter.Mcs.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961210011814.1328D-100000>