sudo is not your friend

[Gitsnik]

Considering the advent of Ubuntu systems, and our own precious Backtrack rolling that particular way, I thought I would do an early release of a tool I have been working on for a while - partly because it may benefit the community, and mostly because my expect skills are not as strong as they used to be and I can't get this operational.

The basic premise is thus: Ubuntu is secure right? You don't run as admin and any malware that access' your desktop can only wipe your stuff, not the system (as if this is less important to me, but it illustrates the need for good backups). You use sudo to run you nmap scans or maybe start your airodump script, so you're safe. Right?

Wrong

The key to this puzzle is, in fact, the very tool people use to keep themselves safe. Some notes on sudo basics:

• "sudo -s", "sudo sh" or "sudo su -" or variants will grant you a root shell.
• sudo grants you a small amount of time before it "expires", which means you only have to type your password once and you have a while to run root commands at your hearts content
• sudo is not tied to a single console, you can open 18 different Xterms and run it just fine

A, well, flaw I noticed in sudo (if it can be called thus) resides in the 3rd point - sudo does not actually check what console I am operating in. If I am on my desktop, and I type "sudo nc -l 5", anyone who is ssh'd into my box can then type "sudo ./install_rootkit.sh". Further, I can write an expect script (as yet unpublished), to attempt this command (or another such as "sudo -s" for as long as I like) - while the password is being requested, sudo seems to fail to report the attempt (perhaps this is a logging feature I have merely never noticed).

The upside of this? A pentester, or anyone else really, can abuse the sudo powers to gain root on a linux desktop (or server) as easily as if it were vulnerable to sock_sendpage(). The only thing required is some patience.

A note to anyone who wants to try a PoC for this: I presume that my cron/expect combination is not setting up a proper environment, so doing it that way is not a choice. But there is nothing that stops one from running it & and just waiting.

And you thought malware couldn't hurt you.

Implementation I leave up to those of you who have coding practice, but please feel free to PM me a sample code block if you have written one.

[Barry]

So is this for different users, or the same user? Say if Bob was physically logged in and sudo'd something, and Joe was ssh'd in, could Joe then sudo something without a pass?

[lupin]

Originally Posted by Gitsnik

A, well, flaw I noticed in sudo (if it can be called thus) resides in the 3rd point - sudo does not actually check what console I am operating in. If I am on my desktop, and I type "sudo nc -l 5", anyone who is ssh'd into my box can then type "sudo ./install_rootkit.sh".

You are saying that the sudo no password timeout isnt locked to the same process that was used to authenticate? Yes, I think I had noticed that but it never really triggered in my mind as a problem - I suppose all you need to do is run something that monitors for sudo in the list of running processes and triggers your own sudo process after you see it.

Probably best to set the sudo timestamp timeout to 0 on systems where you think your sudo-authorised user accounts may be compromised. You would also have to wonder if even a sudo install configured like that would be subject to a race condition...

[Gitsnik]

Originally Posted by Barry

So is this for different users, or the same user? Say if Bob was physically logged in and sudo'd something, and Joe was ssh'd in, could Joe then sudo something without a pass?

No this is for the same user, a way of proving (if you will) that just because your web browser is running as you (and not root), doesn't make you secure from malware or a pentester getting root.

Lupin has it right - same user, but different hosts/sessions/etc. My first thought for this after I identified it was actually a way to keep my Nematodes bouncing up to root as soon as possible without giving them the passwords - from there the implication for pentesting or other purposes was obvious.

The obvious thought is, if you have this sort of access, just write your own sudo and re-write the path variables, but I was looking for something a little less intrusive.

[lupin]

Actually I tried this just then in Ubuntu jaunty and sudo commands issued in two different consoles for the same user account each prompted for a password when run within 30 seconds of each other. Subsequent sudo commands in each console ran without prompting. I was quite sure I had experienced the same symptoms you described though. Maybe its a version/configuration thing... (version is 1.6.9p17, configuration is the Ubuntu default)

[thorin]

This follows my experience as well. I notice it most when I'm working in a terminal window and launch screen. Even if I've just finished doing some sudo actions at the terminal when I launch screen and try to sudo something I'm prompted again for my password.

[Virchanza]

Originally Posted by Gitsnik

• "sudo -s", "sudo sh" or "sudo su -" or variants will grant you a root shell.

Just to clarify a little further: It's possible for the "root password" to be different to the "sudo password for a particular user".

If you want to get a root shell, then the following command will ask you for the "root password":

su

whereas the following will simply ask you for your normal user's "sudo" password:

sudo sh

The both give you a root shell. It's not particularly relevant but I just thought it was worth mentioning. I discovered this one day when I had changed my own normal user's password but I hadn't change the root password. Therefore "sudo" worked fine, but my password wasn't accepted when I simply did "su" because it was looking for the "root password". Took me a few minutes to cop what was going on.

[lupin]

Originally Posted by Virchanza

Just to clarify a little further: It's possible for the "root password" to be different to the "sudo password for a particular user".

Strictly speaking, there is no "sudo password". In its default configuration sudo prompts non root users for their own password (the one associated with their account as stored in /etc/shadow) IF password authentication is required. Sudo can also be configured to prompt for the root password. So by default, if you are trying to run a command as root, and your user is permitted to run that command as root in sudoers AND password authentication is required, you have to enter your users password. If you are trying to run a command as a different user lupin, and you are permitted to do so in sudoers and password authentication is required, you again have to enter your users password.

su prompts for the password of the user who you are trying to become in the login session. If you are trying to become root (which is the default for su), you get prompted for the root password. If you are trying to become user lupin, you get prompted for lupins password.

[Barry]

Originally Posted by lupin

Strictly speaking, there is no "sudo password". In its default configuration sudo prompts non root users for their own password (the one associated with their account as stored in /etc/shadow) IF password authentication is required. Sudo can also be configured to prompt for the root password. So by default, if you are trying to run a command as root, and your user is permitted to run that command as root in sudoers AND password authentication is required, you have to enter your users password. If you are trying to run a command as a different user lupin, and you are permitted to do so in sudoers and password authentication is required, you again have to enter your users password.

su prompts for the password of the user who you are trying to become in the login session. If you are trying to become root (which is the default for su), you get prompted for the root password. If you are trying to become user lupin, you get prompted for lupins password.

Linux 101.

[Gitsnik]

Originally Posted by lupin

Maybe its a version/configuration thing... (version is 1.6.9p17, configuration is the Ubuntu default)

I've actually been testing with that version on my devnetwork, but not on Jaunty.

Either way it's a "feature" that I have used to good effect now at least 5 or 6 times, and not just on Linux systems, also on BSD's and OS X. At least it's been configured out or patched or whatever on Ubuntu.