SUDO vulnerability (2/2)

Jonathan Fabrizio - 27/02/12

In a previous post, I showed how a trojan horse can become root by the use of sudo. According to it's configuration, sudo may ask password only once and does not ask password again for a predefined period of time. Malicious software can became root silently.
To exploit this vulnerability, I wrote a program that invokes silently sudo until sudo does not ask password. To succeed, this program must be launched in the correct terminal before the correct user invokes sudo (or right after). This means, the threat is rather low. I complete here the previous post with (too) simple tricks to increase chance to become root (simply to show that even the threat is low, it must not be neglected). To finish, I give simple advice to prevent you from being attacked by such program...

The context

Our initial trojan horse is efficient but it has low chance to succeed as it must be excuted in the same terminal than admin operation. As it is resident, it is also clearly seenable with simple commands like top or ps. It will be easily detected...

Installation

If a program want to exploit this vulnerability, it can not expect to be launched in the same terminal even if it stays resident and waits. To improve chance to become root, it would be better to start automaticly in each terminal. Then it could be efficient to detect default shell and modify default script like .bashrc to automaticly start at the beginning of every terminal. Once the user invokes sudo, the programme becomes root. Even configuration scripts of the graphical user interface can be targeted. As soon as it becomes root, it can remove the entry in .bashrc (or other) to hide the presence of the trojan horse.

Stealth

As the trojan is now resident in every terminal, it has more chances to reach its goal. However, the threat remains poor: the user can detect the presence of the program execution esaily. If the trojan is resident and wait to become root, it can not hide itself correctly (as it is not root yet) - but it can try to.
The user can detect it's presence by the use of command like ps or top. The idea is that a user use more ps that it open shell initialisation files. Then it is possible to hide - only for the targetted user - the execution of the trojan horse. For that we will hook ps or top commands. Following lines are added in shell initialisation script (and adapted to the user shell):

function ps() { `which ps` "$@" | grep -v "trojan_name" ;}

This command hook the ps command and now ps command display all lines that do not contain the name of the trojan horse (the name of the trojan must be choosen cleverly). Obviosly if the user see these lines in initialization script, the trojan horse will be detected and then these lines must diseapear immediatly when the trojan reach root privileges. The same hook can also be done for top command...

function top() { `which top` "$@" | grep -v "trojan_name" ;}

These tricks are not very clever and there is surely much more powerfull things to do. This post is only a POC.

Protection

I hope, with these few lines, I convince that the threat is not as low as it seems. The best way to protect against this sudo vulnerability is to tell sudo to ask password every time. To do so, edit /etc/sudoers by using sudo visudo and add the line:

Defaults	timestamp_timeout=0

And the password will be asked every time. If you really want to perform multiple admin operations, you can invoke sudo -i

Conclusion

We have seen a simple way to use sudo to become root. This threat is low as this implies the system (a user account) has already been corrupted but this threat must not be neglected especially as the solution to protect the system is very simple.

Viewed 4757 times