[ISN] Identifying a deleted account.

From: InfoSec News (isnat_private)
Date: Wed Nov 13 2002 - 23:36:54 PST

  • Next message: InfoSec News: "[ISN] Security UPDATE, November 13, 2002"

    |  Linux Security: Tips, Tricks, and Hackery                       |
    |  Published by Onsight, Inc.                                      |
    |                                                                  |
    |  13-November-2002                                                |
    |  http://www.hackinglinuxexposed.com/articles/20021113.html       |
    Identifying a deleted account.
    By Brian Hatch
    Summary: Locking out old and suspect users is a good thing, but it's
    imperitive that you keep a log of locked users to be able to
    investigate anyhting they've left behind.
    Warning: Anyone who hasn't heard, the latest BIND bug has come to
    light. This time it affects the 4.x and 8.x streams. ISC has not
    released patches to the public yet, in spite of the fact that they
    have to their prefered (paying) users. You have three options: wait
    around until they make good on their promise to support the public,
    upgrade to BIND 9.x, or better yet switch to somtheing else. Now's an
    excellent time to switch to DJBDNS. See http://
    www.hackinglinuxexposed.com/articles/20020716.html for a multi-part
    article to show you how you can transition with no downtime
    Ok, now onto this week's column.
    Last week I extoled the virtues of keeping an audit trail. This
    actually came up because a reader was confused about some processes
    that were running under a no-longer existing userid:
      $ ps -ef |grep john
      1091     23699 20893  0 Oct 3 ?        00:05:24 /tmp/.j/john n88o9
      jdoe      8430 23702  0 10:07 pts/7    00:00:00 grep john
    The first entry is a john-the-ripper[1] process running under userid
    1091. The second is simply the grep command run by jdoe. Checking /
    etc/passwd to see who user 1091 reveals nothing, unfortunately:
      $ grep 1091 /etc/passwd
    At some point the user had been deleted[2] from the system, but his
    processes remained. Not good. Unfortunately, they had no records of
    who originally used this account. There are many ways that a user can
    be deleted, be it manual changes or using the deluser program.
    Deluser removes entries from /etc/passwd and /etc/shadow entirely,
    rather than just locking the account by giving it a locked password.
    [3] It takes default settings from /etc/deluser.conf, which can be
    overidden by command-line arguments. The settings allow you to decide
    how you want files owned by the user to be handled.
    |   Command-line   |  deluser.conf  |            meaning            |
    |      switch      |    variable    |                               |
    |--remove-home     |REMOVE_HOME     |Delete the user's home         |
    |                  |                |directory from the system      |
    |                  |                |Remove all files owned by the  |
    |--remove-all-files|REMOVE_ALL_FILES|user from the entire machine,  |
    |                  |                |similar to running 'find /     |
    |                  |                |-user username | xargs rm -f'  |
    |                  |                |Before removing files, tar up  |
    |                  |                |the files to be deleted. The   |
    |--backup          |BACKUP          |tarball is saved in the current|
    |                  |                |directory (so run it from /root|
    |                  |                |or other hidden place) as      |
    |                  |                |username.tgz[4]                |
    In general, it's a good idea to remove the files, because you never
    know what they may have hidden around. You do need to be careful, of
    course. Say a user was maintaining part of your website, you wouldn't
    want to delete those files blindly. Thus many administrators will not
    use the delete files options for deluser and will delete them
    manually, to make sure important files remain.
    So, how can you determine who used to be userid 1091? If you don't
    delete any files when you lock accounts, you can check /home itself:
      # find /home -maxdepth 1 -nouser -ls
      drwxr-xr-x   22 3775     users        4096 Oct 16 20:41 chris
      drwx--x--x   42 1120     users        4096 Nov 12 10:39 maddie
      drwxr-xr-x    3 1843     users        4096 Jul 18  2001 reegen
      drwxr-xr-x    3 1354     users        4096 Jul 19  2001 ryan  
    Here you can infer the original username since it usually matches /
    home/directoryname. Unfortunately, the account-locking procedure on
    this machine is to nuke the home dir, so no dice here.
    But, how about non-home directory files, for example mail spools
    which are named after their owner?
      # find /var/mail -nouser -ls
      -rwxr-xr-x    1 3775     users       83712 Jan 23  5:20 chris
    Nope, still no userid 1091. Looks like the other files were deleted
    too. An exhaustive search of the filesystem only turned up the
    password cracking files in /tmp/.j, and none of those indicated who
    actually owned them.
    If we knew the username, we could search the machine for tarballs
    named username.tar.gz, username.tgz, username.tar.bz2, and so on, in
    hopes that the original files owned by the locked user are tarred up
    somewhere. The name of the file should indicate the username, but the
    data contained within it should also do the trick. Even if it didn't
    have the username in the filename itself, we can do a file listing of
    the tarball:
      $ tar tzvf unknown_user.tar.gz
      -rw------- bob/1009        175 2001-12-26 23:34:54 home/tom/.bash_history
      -rw------- bob/1009        668 2001-09-12 19:06:27 home/tom/.viminfo
      -rw------- bob/1009        614 2001-09-12  3:21:16 home/tom/.bashrc
    and here we'd see that 'bob' was the original owner. Unfortunately,
    no luck finding an archive on the machine. They did not use --backup
    in general when running deluser. (This has been corrected.)
    So, the filesystem itself led nowhere. However we still had other
    places we could look, such as the system logs. We searched for the
    userid 1091 in all the logs, hoping to corrolate the userid with a
    username. Perhaps a retrieval of email via POP, a login with SSH,
    etc. Unfortunately, their log rotation scripts only kept the last
    three weeks of logs, which meant older logs were lost forever.
    On a whim, I thought about checking for the userid in the email
    spools of local users. Since the system uses Postfix, and it logs the
    userid (but not username) of each mail sent from it, there was a
    chance the user had sent email to other folks on this system that was
    still stored.
      # cd /var/mail
      # grep "from userid 1091" *
      john:Received: by localhost (Postfix, from userid 1091)
      sandy:Received: by localhost (Postfix, from userid 1091)
      sandy:Received: by localhost (Postfix, from userid 1091)
    Huzzah! It seemed that this user had, at some point, sent emails to
    other folks on this machine. We merely pulled up the email headers
    that originated from userid 1091 and checked to see who they were
      Received: by localhost (Postfix, from userid 1091)
            id C823155F13; Tue, 18 Sep 2001 16:59:03 -0700 (PDT)
      From: mystery_user
    The "From:" lines all matched, and the recipients indicated that they
    did believe that these emails were legitimate because they were part
    of continuing conversations with the locked individual.
    So, we were eventually able to determine with some certainty who the
    locked individual was, but it was painful and time consuming.
    I have a very simple trick I employ to be sure I can always match up
    a userid with an account, even if the account is locked. Rather than
    deleting the /etc/passwd entry, you instead prefix it with a minus
    sign, ala
      $ grep '^-' /etc/passwd
      -frank:x:3005:2000:Frank En Stein:/home/frank:/bin/poponly
      -joel:x:3007:2000:Joel Scambray:/home/joel:/bin/bash
      -amar:x:3012:2000:Amar B:/home/amar:/bin/bash
    None of these users actually exist - the minus sign means 'remove
    this user/userid from the list' by abusing a bit of NIS trickery:
      $ finger frank
      finger: frank: no such user
    Yet you can easily see who the user was, their home directory, and
    shell. Should you need to re-enable the user later, you have their
    prefered shell and everything at your fingertips.
    Unfortunately, this method is not compatible with deluser, so you
    need to either forgo deluser and perform file/home directory deletion
    yourself, or you need to re-add the line back in when you're done.
    However it provides a simple trail that will let you know who used to
    be on the system. You can even include extra data in the GECOS field
    if you wish:
      $ grep '^-' /etc/passwd
      -bob:x:4204:200:Bob, LOCKED 2002/12/31, left company:/home/bob:/dev/null
    Unfortunately the question remained - how did the user keep his
    access to the system? Something for next week.
    [1] http://www.openwall.com/john/
    [2] This machine is a public shell server, and has many userids
    greater than 1091. Users are deleted every so often for breaking the
    AUP, as this one must have. You might argue that a cracker broke root
    and started using 1091 because it doesn't exist, but that proved not
    to be the case as we learned later.
    [3] This is a good thing. There are many ways a user can maintain
    access to their account even without knowing their password.
    [4] or username.tar.gz, username.tar.bz2, etc, depending on your
    Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
    Linux Exposed and Building Linux VPNs. He offers Linux accounts to
    anyone he trusts. The average number of accounts on his machines is
    somewhere between 2 and 3. Counting his own, and root. Brian can be
    reached at brianat_private
    This newsletter is distributed by Onsight, Inc.
    The list is managed with MailMan (http://www.list.org). You can
    subscribe, unsubscribe, or change your password by visiting
    http://lists.onsight.com/ or by sending email to
    Archives of this and previous newsletters are available at
    Copyright 2002, Brian Hatch.
    ISN is currently hosted by Attrition.org
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.

    This archive was generated by hypermail 2b30 : Thu Nov 14 2002 - 02:37:13 PST