Keeping User-Level Access When Locked Out
By Bri 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.
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.
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.
- 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
- 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.
 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...
Bri 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.
Bri can be reached at firstname.lastname@example.org.
Copyright Bri Hatch, 2002
This is the November 20, 2002 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Securityemail@example.com.