From mjg59@srcf.ucam.org Fri Apr 11 01:30:19 2003
Date: Fri, 11 Apr 2003 01:30:19 +0100
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: cert@cam.ac.uk
Cc: soc-srcf-committee@lists.cam.ac.uk, sysadmins@srcf.ucam.org,
	computing@cusu.cam.ac.uk, admins@raq626.uk2net.com,
	unix-support@ucs.cam.ac.uk
Subject: kern.srcf.ucam.org compromised
Message-ID: <20030411003019.GA13598@srcf.ucam.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.3i
Status: RO
Content-Length: 2048
Lines: 37

Around 20:35 it was noticed that certain users were unable to log into 
kern.srcf.ucam.org (www.srcf.ucam.org). Further investigation revealed 
evidence of the machine having been compromised by a ptrace exploit (the 
kernel was unpatched due to the absence of an official Debian update for 
stable systems, and stability issues associated with the existing patch) 
run by a local user.

The user was discovered to have logged in from raq626.uk2net.com -
attempts to contact uk2.net to appraise them of the situation were
unsuccessful due to the lack of advertised phone or security contacts.
The user was successfully contacted, and noted that he had not
participated in the attack. He then successfully contacted the admin of
raq626.uk2net.com, who discovered evidence that this machine had also
been compromised. It is therefore assumed that the attacker had obtained
the user's password from the compromised machine, and used this to
access kern.

Once the attacker had gained root privileges, a suid wrapper to /bin/ssh 
was produced and hidden in his home directory as ~/.s. As root, the user 
then downloaded openssh3.1 and applied the attached patch which appears 
to merely allow attempting a login as the user "foo" to result in a root 
login that isn't recorded. This sshd was copied over the existing system 
sshd and sshd restarted. The new sshd was not linked against libpam, 
which resulted in /etc/motd not being echoed and users with MD5 
passwords being unable to log in. This resulted in rapid detection, and 
sshd has now been disabled.

Process accounting logs do not show any evidence of the kernel being 
modified in any way, and the ethernet interface does not appear to be in 
promiscuous mode. The admins currently have no reason to believe that 
other user accounts were compromised in any way, nor any reason to 
believe that network traffic on the CUSU network is being sniffed. 
Further investigation will take place in the morning when people have 
actually had some sleep.

-- 
Matthew Garrett | mjg59@srcf.ucam.org