Date: Tue, 24 Jul 2001 20:52:28 +0300 From: Peter Pentchev <roam@orbitel.bg> To: Jon Loeliger <jdl@jdl.com> Cc: security@freebsd.org Subject: Re: Security Check Diffs Question Message-ID: <20010724205228.A16243@ringworld.oblivion.bg> In-Reply-To: <200107241632.LAA05639@chrome.jdl.com>; from jdl@jdl.com on Tue, Jul 24, 2001 at 11:32:23AM -0500 References: <200107241632.LAA05639@chrome.jdl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 24, 2001 at 11:32:23AM -0500, Jon Loeliger wrote:
> Hi Folks,
>
> This morning, on a machine that's been up for 33 days,
> I suddenly saw these /etc/security diffs:
>
> <host> setuid diffs:
> 20,22c20,22
> < 8047 -r-sr-xr-x 6 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/chfn
> < 8047 -r-sr-xr-x 6 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/chpass
> < 8047 -r-sr-xr-x 6 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/chsh
> ---
> > 8047 -r-sr-xr-x 5 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/chfn
> > 8047 -r-sr-xr-x 5 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/chpass
> > 8047 -r-sr-xr-x 5 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/chsh
This means that there were 6 files hardlinked to inode 8047, now there are
only five. One of the links was removed and probably replaced with something
else, which cannot point to the same inode.
> 53,55c53,55
> < 8047 -r-sr-xr-x 6 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/ypchfn
> < 8047 -r-sr-xr-x 6 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/ypchpass
> < 8047 -r-sr-xr-x 6 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/ypchsh
> ---
> > 8270 -r-sr-xr-x 1 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/ypchfn
> > 8047 -r-sr-xr-x 5 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/ypchpass
> > 8047 -r-sr-xr-x 5 root wheel 32184 Nov 20 06:01:52 2000 /usr/bin/ypchsh
ypchfn changed its inode number, and its link count. This means that
somebody performed an unlink() (delete) on ypchfn, and then created
a new ypchfn with the same size, timestamp, permissions and stuff,
but still a new file - and that's where the hardlink count + inum
tracking of /etc/security kicked in and alerted you.
> So, how paranoid am I here? How concerned am I?
Very much. Probably enough to back up all the data files on the system
and reinstall from scratch.
> What compromised of my system just took place?
Somebody obtained root privileges and installed a new file in place
of ypchfn.
> Couple things to notice:
>
> - The files now take fewer 512K blocks,
> but their sizes are the same?
Not fewer 512K blocks; fewer number of links to the same inode,
meaning one of the links was removed.
> - Most of the inodes staid the same. Exact same.
> Are these hard linked files? Should be, right?
Yep, all the {yp}ch{fn,pass,sh} files are hardlinks to one binary.
> - The inode for ypchfn changed!
> It's no longer hard linked, right?
No longer hardlinked to the same inode, but a separate file.
> No form of disk restructuring, fsck, defrag, etc, was initiated by me.
>
> Note that:
>
> www 181 # cmp /usr/bin/{ypchpass,ypchfn}
> /usr/bin/ypchpass /usr/bin/ypchfn differ: char 25, line 1
Figures. If someone went to the trouble of creating a separate file..
> Here is a `strings /usr/bin/ypchfn`:
>
> www 182 # strings /usr/bin/ypchfn
> /usr/libexec/ld-elf.so.1
> FreeBSD
> libcrypt.so.2
> _DYNAMIC
> _init
> __deregister_frame_info
> crypt
> strcmp
> _fini
> _GLOBAL_OFFSET_TABLE_
> __register_frame_info
> libc.so.4
> strerror
> execl
> environ
> fprintf
> __progname
> __error
> setgid
> __sF
> execv
> getpwuid
> getpwnam
> atexit
> exit
> strchr
> execvp
> setuid
> _etext
> _edata
> __bss_start
> _end
> 8/u
> QR2cc.wsLFbKU
> root
..and just as somebody else pointed out, the last two lines look like
a 13-character DES-encrypted password hash and a username. I think
that the 'new' ypchfn either replaces root's password, or asks for
a password and gives a root shell if the user enters the password
corresponding to that hash.
> If someone didn't hack my system, I took a disk hit and lost
> part of that file, right?
I very much doubt the normal ypchfn would contain a password hash
and a well-known username, in that order, on two consecutive lines..
> What other log files am I disecting or where else am I poking
> for further evidence?
>
> Am I blowing away the bogus(?) /usr/bin/ypchfn and re-making
> it a hard link to the others again?
No, you back up all the data on your system, and reinstall it
from scratch. Like, now. And keep in mind that even files without
the 'executable' bit set might not qualify as data, if they are
some kind of interpreted scripts (e.g. PHP3 web scripts).
G'luck,
Peter
--
This sentence claims to be an Epimenides paradox, but it is lying.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010724205228.A16243>