+------------------------------------------------------------------+ | 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 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 linux_security-requestat_private 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 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