10

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).

  • For an example of the kind of thing I'm looking for, see my answer. I'm hoping someone can elaborate on some of the security risks raised there (or any others they can think of), and provide ways of mitigating them. – Zaz Aug 13 '14 at 13:23
  • You ask for something like UAC or a secure attention sequence in Windows. Unixy systems don't have that. The way to go for (would be) admins is not to use their accounts for silly things. A couple of things you mention in your own answer can be guarded against with role based and mandatory access control systems such as SELinux or Grsecurity. There you can establish policies that non-root writable binaries cannot be executed, so no trojans at that level. Btw, if you don't trust X, then don't trust the system at all, for X runs with superuser privileges. – countermode Aug 15 '14 at 21:36
  • Thanks, I'd looked into SELinux, but it seems to be designed more for big installations, requiring a lot of time for the administration and setup; I was hoping for something a bit simpler. I'm a developer, so strict policies regarding running programs is not really an option either. – Zaz Aug 15 '14 at 21:49
  • "X runs with superuser privileges" — What? On a default install of X, startx works just fine as a normal user. In fact, I'm running X as a normal user right now. – Zaz Aug 15 '14 at 21:51
  • Yes the learnig curve is steep. Have a look at Grsecurity, it is simpler but yet powerful. ~ Privileges of X: on my box the X server is SUID root and runs a root. – countermode Aug 15 '14 at 22:45
9

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).
| improve this answer | |
  • sudo asks from the users password, so the malware would capture the password of the user it had already gained access to. – rob Aug 6 '14 at 14:00
  • 3
    @rob: It actually depends on how you've got sudo configured, but either way, the malware now has the password required to sudo, so if the user has root access, so does the malware. – Zaz Aug 6 '14 at 14:03
3
+100

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. :)

| improve this answer | |
1

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 :)

| improve this answer | |
  • Sorry if I wasn't clear in the question, but I'm interested in protecting against compromised admin accounts, that is to say, accounts that have full root privileges with sudo. Specifically, I am thinking about normal desktop systems. – Zaz Aug 6 '14 at 15:16
1

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.

| improve this answer | |
0

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

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.