I've attached the paper in PDF format, please have a read and give me your feedback.
Unix Security Basics #1 - Sudo Judo
Audit your sudo rules before someone else does
Sudo allows administrators to permit users to run commands as another user, often as root. Sudo gives the administrator the freedom to assign granular access controls to specific commands. It’s a powerful alternative to setting the suid bit to elevate a user’s privileges. If care is not taken when assigning sudo permissions then you are potentially providing an easy route to root for intruders.
In a malicious attack or a penetration testing scenario shell access to a Unix system as a non-privileged user may be achieved and the next step to elevate their privileges to root. We’ll look at some of the common mistakes administrators make in assigning permissions with sudo. In these examples let’s assume that the user has been given permission to execute the command in question as root, although these techniques will of course also work for elevating privileges to other non-root user accounts.
Enumeration of sudo privileges
Sudo is commonly used to allow server process owners limited root access. An example of this may be to allow the user “nobody” to start a web server listening on a port 80. Later versions of sudo provide the -l switch that will display the currently assigned sudo permissions for a given user. This makes it easy to quickly enumerate the commands that can be run.
$ sudo –l
User luser may run the following commands on this host:
(ALL) /usr/bin/restart_server, /usr/bin/start_server, /usr/bin/stop_server
An attacker can quickly focus on these privileges as a means of elevating their privileges.
This is one of the more common mistakes I have seen in the wild and it’s a bad one. Check the ownership and file permissions of commands and the directories that contain them before you give sudo access to them. If the user has write access to the executable they can alter it to perform actions other than those intended. This comes up particularly often when a user is granted sudo permissions to a shell script used to start a server daemon.
Write access to other files can also present a security hole. Suppose a user has write access to the configuration files for an application where root access has been granted. Can maliciously altering these files lead to a compromise?
Arbitrary command execution
Many commands provide the ability to execute other shell commands and this can be overlooked. Take for example shell escapes from text editors such as vi or from client applications like Oracle SQL*Plus. If you grant permission for a user to execute one of these programs as a different user you’re effectively giving them full access to that user account.
uid=101(user) gid=513(None) groups=101(Users)
$ sudo –u oracle sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Wed Mar 14 09:30:30 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
uid=500(oracle) gid=500(dba) groups=501(orainstall)
The user’s environment is an important area to consider if it is relied upon in any commands executed using sudo. If for example the command in question is a shell script you also need to take into account all of the commands executed within that script. Changing the user’s environment e.g. their $PATH or $HOME variable can mean that a script may perform unexpected actions, especially if absolute paths to commands are not used within the script.
uid=101(user) gid=513(None) groups=101(Users)
$ cat script.sh
#copy the user’s mail to a temp file for some reason
cp /var/spool/mail/$SUDO_USER /tmp/$SUDO_USER.txt
chmod 644 /tmp/$SUDO_USER.txt
$ export PATH=.:$PATH
$ cp /bin/bash cp
$ sudo script.sh
Any environment variable where the value can be altered could cause a security breach. This example is a little contrived but it shows that relying on an insecure PATH variable can lead to unexpected results. The author of this script may have thought that using the variable SUDO_USER was being security conscious since it is set by the sudo command and cannot be easily subverted. Remember kids, always use the full path to commands in your scripts.
Consider all of the side effects a given command may have before granting permission. Commands such as strace allow monitoring of the system calls being made by a process. This is a useful diagnostic tool for attaching to and monitoring the activity of a running process. If you do this it is easy to forget that you are effectively allowing the user to any command they wish.
$ sudo truss –o /dev/null /bin/bash
It is important to remember that a command running as root can access any file on a system. If you provide sudo access to a command that can read or write files then the user can read or write any file on the system. If for example you give sudo access to the tar then the user can perform all manner of tricks to gain root including adding new accounts and changing passwords.
$ sudo tar cvf - /etc/shadow /etc/passwd > passwd.tar
$ sudo tar xvf newpasswd.tar
Shells and Interpreters
Given sudo access to a shell or a language interpreter like Perl or Python is effectively giving full access to the host. That’s just plain stupid. Don’t do it. If you want to use sudo to give someone root shell access then grant them permission to run /bin/su so you get an additional audit trail.
This is by no means an exhaustive list of all the potential flaws that may be introduces but I hope it is food for thought. By far the best way to prevent these kinds of issues is to properly evaluate each sudo privilege you grant and then to get someone else to review it. Many flaws arise from a lack of understanding of the commands used, which is understandable given the potential depth of a single command. Exercise a little common sense however and most of these problems can be avoided.