Breaking Out Of A sudo Shell
Breaking Out Of A sudo Shell
I’ve been meaning to write this up for a while, but had a post go by on one of the SecurityFocusmailing lists that motivated me to get it done. The post asked, “How do you restrict sudo so a user can not delete the whole hard drive?”. The short answer is, it is extremely difficult.
Sudo is a security tool used within the UNIX and Linux world. It permits the Administrator to restrict access to high-level commands. It differs from the su command in that su immediately gives the user root level access. Sudo permits the Administrator to fine-tune which root commands can actually be accessed. In addition, sudo creates an audit trail of all executed commands.
The problem with sudo is that it has no visibility when a tool permits a command shell to be spawned. This means a user can misbehave on the system while generating an audit trail, which makes it appear they have done nothing wrong.
Try it yourself
I’m going to walk you through an example so you can experience exactly what I mean. You will need a Linux system for this. If you don’t have one handy, Backtrack should work just fine. The test system I’m using is based on Fedora but they are pretty similar.
Step #1: Add yourself to the users group
Use your favorite text editor to edit the /etc/group file. Look for the “users” group and add your account name. In this example I’ve added the account name “cbrenton”.
users:x:100:cbrenton
Step #2: Create a sudousers entry
Next we need to edit the /etc/sudoers file to define what the users group is permitted to do. We need to use visudo for this, which is a text editor based on the vi editor. If you are comfortable with vi, type in the command “visudo” and add this line to the end of the file:
%users ALL=/usr/bin/less
If you do not know vi, I’ll give you the exact commands. Remember everything is case sensitive:
visudoGo <– lower case letter O%users ALL=/usr/bin/less
Step 3: Monitor sudo activity
Open a second terminal window and use “su -” to assume root privileges. Type in the command:
tail -f /var/log/secure
This will permit us to monitor all sudo activity.
Step 4: Run a sudo command
Back in the first terminal window type in the command:
sudo less /etc/hosts
You will be prompted for your password (your password, not root’s password). Once you type in your password you should see the contents of the /etc/hosts file. In the second terminal window you should now have a log entry similar to the following:
Aug 18 16:07:58 fubar sudo: cbrenton : TTY=pts/4 ; PWD=/home/cbrenton ;USER=root ; COMMAND=/usr/bin/less /etc/hosts
So we can see date/time, who executed the command, which terminal they were on, what directory they were in, what permissions level they were using, and what command they executed including any command line switches (in this case a file specification). So far, so good.
Step 5: Bust a shell
In the first terminal window (running the less command) type in:
!
You should now be looking at a root command prompt. To verify you are in fact root, type in the command:
whoami
Note that typing in the command “whoami” did not generate a security log entry. In other words, once we spawned a command shell with the less command, we can do anything we want and sudo will not log it.
Step 6: Additional verification
In the first terminal window where “less” is in the background, type in the command:
top
This will print out statistics about the running system.
In the second terminal window note the terminal in use. In the above example log entry the terminal is “TTY=pts/4″ but yours might be different. Make a note of the terminal. Now, in this second window press:
-C
to kill the tail command. Now run the command:
ps ax | grep ‘pts/4′
Replacing “pts/4″ with whatever terminal name you noted. You should receive output similar to the following:
17330 pts/4 Ss 0:00 bash18392 pts/4 S 0:00 less /etc/hosts18410 pts/4 S 0:00 /bin/bash18432 pts/4 S+ 0:00 top
This tells us that we have two shells running on that terminal. The first is looking at the hosts file while the second is running the top command. So the system does actually see that we are playing around within the second shell, its just that sudo can not log it.
Some other root level commands you can try that will not harm anything:
iptables -Lifconfiglsof -i
When you are convinced you have full root access, go back and check the log to verify that sudo has not logged anything:
tail /var/log/secure
When you are done with the shell in the first terminal window, type in:
exitq
What have we learned?
We’ve learned that we cannot permit users to have full sudo access to the system and actually maintain an audit trail of what they do. Access has to be restricted to tools that do not support invoking a shell. If we are unsure, its a simple matter of checking the man pages. Try this:
man less/shell
The command “man less” brings up the manual for using the “less” command. Pressing the backslash key brings up the search function. When we type in the word “shell” and press the enter key, man jumps to the first instance of the string “shell” and highlights every instance. Note the section man jumped to discribes how less can invoke a shell. Now we know we cannot permit sudo access to the command “less”. A better option may be the command “cat” which does not support invoking a shell.
Another possibility is to simply use a different tool. For example the tool op was specifically designed to address some of the security shortcomings in sudo, including the ability to control shell access.
Exec Summary
Sudo is a great security tool provided you use it wisely. One of the most common mistakes made with sudo is using it to permit access to all root level tools. Sudo can generate an effective audit trail, but only if it is limited to tools which do not have shell capability.
Comments