Recently, when conducting an (authorized) security review at a small web hosting provider, I ended up as "root" on all their Unix systems within a matter of hours, and did not even need any l33t buffer overflow or the like. Well-meaning system administrators had tried to improve security of their servers, and had unwittingly ended up making life much easier for the bad guys.

Aware of the constant barrages of SSH password guessing attacks that are plaguing the Internet, they had switched to public key (RSA) authentication. This in itself is a good thing. That their system maintenance script user had a password-less SSH-key to allow for automated logins is a less good thing. The key itself was well protected with file system permissions, but somebody someday had also created a TAR archive to back up the maintenance user's environment. Unlike most of the other files, the TAR had permissions set to rw-r--r--, and contained the .ssh folder as well. The RSA key was mine.

Their second security improvement was to introduce "sudo", so that none of their staff had to log in as "root" in the daily course of operations. This again in itself is a good idea. Until I went and checked if any "sudo" privileges had been granted to the "monitor" user whose SSH key I had just filched

monitor@gamlumi:/home/monitor$ sudo -l
User monitor may run the following commands on this host:
    (root) NOPASSWD: /home/monitor/dnsrefresh

Some of you are probably already thinking "Ouch!" now. Yes: The above says that user "monitor" can run the command "/home/monitor/dnsrefresh" with root privileges. In itself nothing to cause sleepless nights, but the "dnsrefresh" file sits in monitor's very own home directory, which means that user "monitor" can replace it. A quick copy of /usr/bin/bash netted the expected root privileges.

Even if you now think "this won't happen to me", maybe it is still a good time to

• check if you have any "automation" or "technial" users configured that use password-less SSH RSA keys .. and if yes, to make doubly sure that the keys are SAFE. Changing the key and revoking the old one from the "authorized keys" just in case probably won't hurt.
• investigate if automation users that use password-less SSH keys can be restricted to the particular command needed. SSH supports the "command=" syntax within the authorized_keys file to solve exactly this problem. Had they used this feature, I would not have been able to log in as "monitor" user
• review your sudoers file to verify that sudo rights are granted only on programs that are owned by root and sit in a directory owned by root

If you have other good tips on how detect security problems with "sudo" or "SSH" configurations as a system administrator before the bad guy do, please send them in and we'll update this diary with a summary of the best.

Update: ISC reader Jim wrote in to recommend the "sudo judo" write-up at ethicalhacker.net, which covers quite a few of the most common sudo security pitfalls.