Re: Security Check Diffs Question

From: Peter Pentchev (roam@orbitel.bg)
Date: 07/24/01


Date: Tue, 24 Jul 2001 20:52:28 +0300
From: Peter Pentchev <roam@orbitel.bg>
To: Jon Loeliger <jdl@jdl.com>

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


Relevant Pages

  • Re: Security Check Diffs Question
    ... >> Hi Folks, ... which cannot point to the same inode. ... > ypchfn changed its inode number, ... This is a signature I've seen before; ...
    (FreeBSD-Security)
  • Re: Security Check Diffs Question
    ... >> ypchfn changed its inode number, ... > change the security script to print the files ctime instead of mtime, ... over it does) would change its inode number. ... few crackers know that they should watch out for this, ...
    (FreeBSD-Security)
  • Re: Finding hardlinks
    ... example "cp -a") tell that two files form a hardlink? ... number will break on filesystems that can have more than 2^32 files (NFS3, ... case of colliding inode numbers). ... --- compare file content? ...
    (Linux-Kernel)
  • Re: Starting a grad project that may change kernel VFS. Early research Re: Starting a grad project t
    ... the hardlink get traversed? ... A hard link is just a second directory entry linking to ... the same inode. ... they navigate into either subdir they see the file size, ...
    (Linux-Kernel)
  • Re: Finding hardlinks
    ... example "cp -a") tell that two files form a hardlink? ... number will break on filesystems that can have more than 2^32 files (NFS3, ... case of colliding inode numbers). ... --- compare file content? ...
    (Linux-Kernel)