Keeping User-Level Access When Locked Out

[InfoSec News <isn () c4i org>]

+------------------------------------------------------------------+
|  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
consent.

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' ...
suggestion.

NOTES:

[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 brian () hackinglinuxexposed com.

--------------------------------------------------------------------
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
linux_security-request () lists onsight com.

Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/

--------------------------------------------------------------------

Copyright 2002, Brian Hatch.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.