[ISN] Keeping User-Level Access When Locked Out

From: InfoSec News (isnat_private)
Date: Thu Nov 21 2002 - 07:14:04 PST

  • Next message: InfoSec News: "[ISN] War with Iraq will mean virus outbreak, hacker says"

    |  Linux Security: Tips, Tricks, and Hackery                       |
    |  Published by Onsight, Inc.                                      |
    |                                                                  |
    |  20-November-2002                                                |
    |  http://www.hackinglinuxexposed.com/articles/20021120.html       |
    This issue sponsored by: Building Linux VPNs
    Building Linux Virtual Private Networks offers concise, step-by-step
    instruction s for building VPNs based on both standard protocols
    (IPSec, SSL, SSH, PPTP) and popular Linux VPN solutions (VTun, cIPe,
    tinc). Through numerous examples and proven practices, you will gain
    important insights into choosing a VPN solution , installing and
    configuring it, setting up routing, configuring firewalls, measuring
    performance, and much more.
    For more information, visit http://www.buildinglinuxvpns.net/
    Keeping User-Level Access When Locked Out
    By Brian Hatch
    Summary: Incomplete user-locking procedures can fail, leaving
    opportunities for them to maintain access to your system without your
    Last week I showed you some of the ways you can lock users out of
    your system. As a reminder, the best plan, regardless what tools you
    use, is to do the following:
      * Remove all files owned by the user from the entire machine. You
        may want to back them up for reference later, but make sure to
        put those backups somewhere only accessible by root.
      * Remove the user's entry from /etc/shadow.
      * Remove any other non Linux native authentication methods, such as
        smbpasswd entries, LDAP entries, or .htpasswd-style entries.
      * Place a '-' in front of the user's entry in /etc/passwd. The user
        will no longer exist, but you still have a convenient place to
        see that it once belonged to that specific account.
      * Remove files associated with the locked user that may not be
        owned by him, for example /var/spool/cron/crontabs/USERNAME.
      * Kill all user processes running under the newly locked userid.
    The above list is pretty thorough, but if anyone thinks of something
    I didn't, please slap me upside the head...
    Anyway, the reason this whole thing came up is because a reader had
    mysterious processes running under a uid that had been locked out.
    The home directory and other files created by the user were long
    gone, and they had completely removed the /etc/passwd entry from the
    system, yet the processes continued.
    It may have been that the locked user had planned ahead and had
    processes running to maintain access ahead of time, or it could be
    that he was actually logged in when the account was deleted.[1]
    The interloper was still able to do everything you can as a normal
    user, such as start processes, create files, download software.
    Surprisingly few actions actually require you have a valid username
    or account -- if you have a uid (and if you're running a process, it
    must be running as someone) that's all the kernel needs to be able to
    do it's job. True, you might have trouble sending email or other
    things that want to find your user information, but those aren't the
    types of activities you're likely to be engaged in when your account
    has been locked.
    So I can't tell you for sure how the user managed to stay on, but
    here are a variety of methods. There are certainly more. Most of
    these are not possible if you remove the /etc/passwd entry, which is
    why it is imperative that you do that rather than simply lock the
    user's password.
    Crontabs and Atjobs
        A user can launch processes via his cronjobs or atjobs. The
        crontab and at files are usually owned by root, so deleting the
        user's files will not affect these. Luckily these will usually
        not run on newer crond and atd daemons because they check for the
        user account before running them.
    Email Triggers
        If the user can still receive email, the .forward or .procmailrc
        files can cause processes to be run, if set up ahead of time.
    Existing Processes
        If a user has processes running when the account is locked, for
        example if the user is still logged in, these can still be used.
        For example the user may run an inbound login service under his
        uid that will last until the next reboot, and can access the
        locked account that way.
    Additional Authentication Measures
        A user who has a locked password but valid account can still log
        in with alternate authentication schemes, such as using SSH
        identities, Samba, Apache .htpasswd files, and anything else not
        controlled by standard /etc/shadow passwords.
    Suid programs
        If you don't delete all files owned by the locked user, he can
        leave set-user-id programs on your system that would allows
        others to assume his uid. If he has compromised an account on
        this system, he can use the suid program to become his old uid,
        which makes tracing his actions much harder.
    Dynamic Web pages
        If a user could create a CGI, PHP script, etc, he could create
        one that runs commands as the webserver user or his id if suEXEC
        is in place. These can be left behind when the user is kicked
        off, and allow him to run commands without logging in at all.
    These are just a few quick examples that let you see how easy it is
    for normal users to keep access to your machine when you lock them
    out improperly. Thanks to all the folks who sent in their
    suggestions, most of which fit in the above categories. The winner of
    a slightly soggy postcard from beautiful Seattle goes out to Hans
    Dornenburg who came up with the most ... shall I say 'creative' ...
    [1] I've been in this situation, where my account was nuked while I
    was still logged in. This was due to an error on the part of another
    administrator who trashed /etc/passwd, but you better believe I
    stayed logged in and because of that we were able to fix the machine.
    Of course this wasn't nearly so bad as when someone moved /usr/lib/
    libc.a and we needed to resort to re-creating it from the command
    line manually...
    Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
    Linux Exposed and Building Linux VPNs. He wields a large cudgel when
    locking down machines and users. A real one, I'm not talking
    figuratively. 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 21 2002 - 10:17:34 PST