Preventing malware from sniffing the sudo password

Question

I often hear people citing sudo as one of the main barriers to malware infecting a Linux computer.

The most commen argument seems to go along the lines of: Root privileges are required to modify system configuration, and a password is required to gain root privileges, so malware can't modify system configuration without prompting for a password.

But it seems to me that by default on most systems, once malware has infected an admin account, privilege escalation is trivial — the malware just has to wait for the user to run sudo.

What methods exist for malware to gain root privileges when the user runs sudo, and how can we protect against them?

Edit: I'm specifically interested in protecting against a compromised admin account; that is to say, an account which has full root privileges with sudo (e.g. the user's account on a typical desktop system).

Answer 1

Once a piece of malware has gained access to a user's account, it can:

1. Create a bash alias (in the current shell, and in ~/.bashrc) to a command which fakes the [sudo] password for $USER: prompt, and steals the user's password.

alias sudo='echo -n "[sudo] password for $USER: " && \
            read -r password && \
            echo "$password" >/tmp/sudo-password'

2. Similarly, it can place an executable named sudo in ~/.bin, and modify the PATH variable to achieve the same effect: PATH="$HOME/.bin:$PATH"

3. Catch key presses through the X server, watch for the word sudo, then try the text between the next two Enter key presses as the password.

4. A similar thing can be done in any environment (the console, Wayland, X) using e.g. $LD_PRELOAD.

5. If malware infects a shell that uses sudo, and sudo caches credentials, the malware can continouosly check if it is possible to sudo without a password:

while : ; do
    echo | sudo -S echo "test" &>/dev/null && break
    sleep 10
done
sudo echo "We now have root access"

Prevention:

1 & 2. Use \/bin/sudo. The \ ignores aliases, and /bin/… ignores $PATH. Alternatively, add an alias such as: ssudo="\/bin/sudo", and always use ssudo instead of sudo. It seems unlikely that a virus would be clever enough to remap this alias.

3. Avoid typing your password when using X11. Instead, use a virtual console, or Weston.

5. Set timestamp_timeout=0 in /etc/sudoers.

The only way to completely eliminate the chance of the sudo password being sniffed, seems to be to avoid it altogether. Instead, login as root to a virtual console.

According to Alexander Peslyak: "the only safe use for su [and sudo] is to switch from a more privileged account to a less privileged one…"

On a side note, sudo does have some countermeasures:

• sudo reads from tty instead of stdin, so alias sudo='tee -a /tmp/sudo-password | sudo' breaks sudo (but does capture the password).

Answer 2

There is no real protection.

Password protected access to sudo harks back to an era before complex shell environments with commands executed by shims. Once the password has been submitted, there's a window of opportunity in which a shim can execute commands via sudo, without any notification, and with full system control.

If I was intent on access, I'd create a useful shim for bash and zsh and fish, etc. I'd monitor the commands executed. Shortly after a sudo has returned with a status of zero, I'd start issuing "sudo chmod +s /bin/sh" or other nastinesses.

The moment that sudo has been given a satisfactory password, and you have shells that run commands to get a prompt, you're potentially in trouble. There is no protection, other than optimism.

Other answers have focused on protecting the password. As an aggressor, I wouldn't worry about that. I'd focus on the duration after the password has been given, when a password is not needed. That's the most risky time, when the attacker needs to do least to compromise the system completely.

Protecting from it? You'd have to protect your RC files. Inspect any shims or other commands used in command line prompts. Look for co-processes connected to the shell and tools used to maintain the shell environment. Main defences would be host intrusion tools, but that's after-the-fact. Preventing attacks? Only using simple shells without complex automated configuration and active prompts - that's the environment for which sudo was developed.

I used to play games with other devs (1980's) where we'd try to write stuff that would get the terminal that the other dev was using, to insert commands - this is essentially the same problem. And we've made it much easier to embed tools that would do command insertion with no visible trace. :)

Answer 3

Not sure about any methods for unauthorized users to gain root privileges, but I know something you can do to make sudo a bit less dangerous, if you want to say that. sudo allows you to configure granular permissions, in order to define groups of users with specific privileges, and specific commands that certain users can run.

SUDO - GRANULAR CONTROL

• User Section

  This where you can setup groups for the users you will specify commands for. Lets setup an Operations group;

  User_Alias  OPS = bob, jdoe 
  

  This creates the OPS group and puts the users named bob and jdoe into the group

• Cmnd_Alias

  Here we specify specific command sets. You must specify the full path and any command options you want used. Lets setup the Operations group commands;

  Cmnd_Alias OPSCMD = /admin/bin/srvbkup, /admin/bin/test 
  

  This adds the three specified commands to the command group OPSCMD.

• User Privilege Specification

  This is where we will use the groups we have setup so far;

  OPS  ALL=(root)  OPSCMD 
  

  First thing we specify are the users, here we use the OPS group we setup. Then the ALL means that it applies to all servers, this is useful only if you or running sudo over multiple servers each using the same configuration file. Next we specify the user that the Operations group will run the specified commands as, in this case we want them to run as root. Lastly we specify the commands that we want the OPS group to be able to run, specifically we are using OPSCMD group we setup. If you did not want them to enter their password each time they used sudo, then the command specification would rather be NOPASSWD: OPSCMD.

Just harden your sudo policies as much as you don't trust your users :)

Answer 4

If you are interested in a system which you believe might be compromised, run "Rootkit" and use "Tripwire" to check the integrity of the filesystem.

Also would advise you to harden sudo privileges, like you don't need all users to have access all root commands rather give access to specific commands through SUDO.

Answer 5

First of all take a look at /etc/sudoers file.

The syntax will be user MACHINE=COMMANDS format.

For example the root user will have root ALL=(ALL) ALL This means that the root user can run any(all) commands anywhere.

If your entry also has ALL=(ALL) then you are almost equal to a root user. If this is not the case and you only have certain limited privileges, then the attacker/malware can only do as much as your sudo privilege can do.

Tips that can help you :

1. Examine your /etc/sudoers file.
2. Run a security scanner like chkrootkit, rootkit hunter, Config server Exploit scanner, snort etc.
3. Use visudo command to edit and modify the privileges of your sudoers file.
4. Run the scanners again.

Reference: Linux man page of sudoers and sudo man sudoers