Skip to content

Elevating Privileges: Sudo

Having looked at the various methods of assigning privileges in Linux and Windows, lets now look at common methods for elevating them.

The principle of least privilege is great idea, if all users have low privs by default, and only use elevated permissions when they are needed then we have a massive increase to the basic security of the system2

Sudo

The first method for legitimately elevating privileges, and hopefully one you are all familiar with, is Sudo1. You will almost certainly have come across sudo before during the course, when updating the system or running more interesting commands.

Obligatory XKCD Sudo Comic

The most commonly way of using sudo is to create a new group of users who run as standard level accounts, but can run with elevated privileges when needed.

With sudo command members of this group can run a command as root. sudo goes some way towards solving the problem of giving users the ability to have root privileges, without needing to be root, but still leaves us with a dilemma. Sometimes a common program will need to run with elevated privileges, for example if it need to access low level system resources, or privileged information.

For example, as with sudo rights we can view restricted files. In the example below the file is Read only by root. We can see that trying to read the contents of the file as another user gets permission denied. However, sudo lets us run the command as root and view the contents.

dang@dang-laptop /tmp/SudoDemo$ ls -l
total 4
-rwx------ 1 root root 15 Feb  7 15:44 secret.txt

dang@dang-laptop /tmp/SudoDemo$ cat secret.txt
cat: secret.txt: Permission denied

dang@dang-laptop /tmp/SudoDemo$ sudo cat secret.txt
Secret Shizzle

With the correct permissions we can even use sudo to drop a root shell.

dang@dang-laptop /tmp/SudoDemo$ sudo /bin/bash                                                                                                                                                        
[root@dang-laptop SudoDemo]# whoami
root
[root@dang-laptop SudoDemo]#

Viewing the commands you can run as sudo

We can check what commands our user can run using sudo -l This can help us identify potential attack vectors.

In the example below, we can see that the cueh user may run the watch command.

cueh@f4a8c9bcd0e8:~$ sudo -l

[sudo] password for cueh: 
Matching Defaults entries for cueh on f4a8c9bcd0e8:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User cueh may run the following commands on f4a8c9bcd0e8:
    (root) /usr/bin/watch

Configuring Sudo

Through Sudo we can give users temporary root access. However, in the general case this means that the user essentially becomes root for all tasks, (for example its easy enough to type sudo /bin/bash to get a root shell.

One work around for this is to restrict the commands that a particular user can run using Sudo. This would allow us give the user or group the ability to run a command or set of commands as a different user. While this user is normally root, we can also specify any other user on the system.

The configuration for Sudo can be found in /etc/sudoers

Note

There are a lot of other options we can pass Sudo (for example, not requiring a password). While we will cover some of them later, its worth having a read about them in the sudo manpage

Entries in the sudoers file that apply to our user are shown by the command

$ sudo -l

so it is worth being familiar with them.

Adding Users to the sudoers list

If you have ever run a command on a new system you have probably seen this3

[theuser@dang-laptop SudoDemo]$ sudo cat /etc/shadow
[sudo] password for theuser: 
theuser is not in the sudoers file.  This incident will be reported.

Sudo is configured through the /etc/sudoers file. For part that deals with individual user rights looks something like this.

# User privilege specification
root    ALL=(ALL) ALL

This says: "The root user may run ALL commands, from ALL connections, as ALL users". Which maps across to our standard understanding of privileges, root is God, so can run any command on the system.

Depending on your OS you may also have rights for an individual user

dang ALL=(ALL) ALL

Or a group of users

## Uncomment to allow members of group wheel to execute any command
%wheel ALL=(ALL) ALL

Specifying Commands that a User can Run

We can also specify the commands a particular user (or group) can run. For example, we can allow the user to run a specific command with the following config line.

cueh    ALL=/usr/bin/watch

Multiple commands can specified as a comma separated list

cueh    ALL=(ALL) /usr/bin/watch,/usr/bin/less
Important

Notice that we specify the full path to the file. Sudo will throw an error if this is missing

We can see that the output of sudo -l now lists the commands that can be run

[testuser@dang-laptop SudoDemo]$ sudo -l
Matching Defaults entries for testuser on dang-laptop:
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin

User testuser may run the following commands on dang-laptop:
    (ALL) /usr/bin/nano, /usr/bin/less

Tip

This is a great place to start looking for exploits Cross reference the programs that can be run against something like gtfobins, to see if there are known issues.

Allowing Commands to be run without a Password

Sudo can also be configured to allow user to run a command without needing to enter a password.

For example lets allow the cueh user to run both watch and less passwordless

testuser ALL=(ALL) NOPASSWD: /usr/bin/nano, /usr/bin/less

And again see the corresponding change in the output of sudo -l

[testuser@dang-laptop SudoDemo]$ sudo -l
Matching Defaults entries for testuser on dang-laptop:
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User testuser may run the following commands on dang-laptop:
    (ALL) NOPASSWD: /usr/bin/nano, /usr/bin/less

Tip

One interesting side effect of having the NOPASSWD flag is that sudo wont prompt you for a password to run the sudo -l command, if ALL of the commands you can run also don't require a password

Sudo Paths and Variables

By default Sudo will also drop any environment variables (including the PATH) Back to some "safe" defaults.

This means that things like PATH injection or LD_PRELOAD injection will not work, as the system falls back to the safe defaults before running as root.

However, sudo will also allow these safe values to be overwritten, either globally, or for an individual command.

Its worth examining the output of sudo -l to see if any of the unsafe settings have been changed

Example: Allowing users to specify environment variables

There may be occasions where we want sudo to allow the user to specify environment vars. We can allow a user to specify their own environment with:

testuser ALL=(ALL) SETENV: /usr/bin/nano

This is usually pretty dangerous, if you see this come up then its worth a thorough look at what the admin is trying to do.

Fixing the Password Problem with Sudo

Lets look back at our simple use case of changing a password. If there was no other form of Privilege escalation, we could allow users to run the passwd command through sudo.

Recall the example given from before

Example

Lets examine the common task of changing passwords. Evidently the file containing the hashed passwords should be secure, and only accessible by privileged users. However, if a user wants to change their own password we have a problem:

  • Either the unprivileged user needs to be able to access the password list (which makes securing it pointless)
  • Everybody who may change their password needs sudo rights. (Which defeats the point of them in the first place)
  • The user would have to give their password to the systems admin to get it changed (Letting others know your password is also a bad thing)

Lets imagine we have a cueh user, and we want them to use the password. We could add the line:

# User privilege specification
cueh    ALL=(ALL) /usr/bin/passwd

Which says "Allow the cueh user to run /usr/bin/passwd as root".

Note

This is a terrible Idea. DO NOT do this on your own system!!!

However, we have a few problems:

  1. We effectively become the root user when we run sudo passwd, the root user can change ANY other users password, without knowing the original.
  2. We would have to add this command for ALL users on the system.

Discuss

We can fix these flaws in a (mostly) sane way using sudo. Its left as an exercise for you to discuss on the aula.

Summary

Sudo, gives us a way to run commands as a different user (usually root). While this is great for sys admin reasons, if not properly configured (or if we are not careful with the commands we allow) It can leave the system open to exploitation.

While limited Sudo is not appropriate for all commands, it does have its place. Lets imagine we have a small subset of trusted users than need to perform admin tasks. It is much easier to give them the ability to run certain commands via Sudo. However, for commands that need to be executed by all users (or may have undesired side effects of being run as root) we need another approach.

  1. "Sue Dough" or "S.U. Do"? Answers on a postcode to the usual address.. ↩

  2. And thank you Kali Devs for eventually enforcing this too ↩

  3. The incident report does get logged, more paranoid sysadmins will have it email them too. Legend says that you also get automatically added to Santas naughty list. ↩

  4. I don't have any stats, but if I took the number of times I type Sudo for legit reasons VS hacking, legit wins every time. ↩

Back to top