From owner-freebsd-security Tue Jul 24 10:53:24 2001 Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.39]) by hub.freebsd.org (Postfix) with SMTP id 6EF3C37B406 for ; Tue, 24 Jul 2001 10:53:16 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 17276 invoked by uid 1000); 24 Jul 2001 17:52:28 -0000 Date: Tue, 24 Jul 2001 20:52:28 +0300 From: Peter Pentchev To: Jon Loeliger Cc: security@freebsd.org Subject: Re: Security Check Diffs Question Message-ID: <20010724205228.A16243@ringworld.oblivion.bg> Mail-Followup-To: Jon Loeliger , security@freebsd.org References: <200107241632.LAA05639@chrome.jdl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107241632.LAA05639@chrome.jdl.com>; from jdl@jdl.com on Tue, Jul 24, 2001 at 11:32:23AM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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: > > 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