2 comments

Sudo and Su Considered Harmful, Sudo/Su Bruteforce Utility

by Javantea
Aug 10, 2010

Sudo and Su Bruteforce 0.1 [sig]

INTRODUCTION

Two years ago I noticed that su and sudo both contain a fatal flaw: administrator passwords. Administrator passwords have found themselves at the core of our security. OpenSSH does not allow root to login by default because on rare occasion administrator passwords can be bruteforced. Nearly all Linux and BSD systems recognize this. Some system administrators still don't recognize this due to business constraints. Users that have insecure passwords can be bruteforced if an attacker knows their name. The common system of first letter and last name or handle as the username gives an attacker a good list of users to bruteforce. How many administrators use the username jsmith? How many administrators use the username admin? Su and sudo may be considered harmful if we consider that usernames can be learned and that passwords can be bruteforced.

Removing the password component, we can compare sudo and su to the Windows Vista and Windows 7 administrator access security model: give a user administrator access when they ask for it. This person must be designated as an administrator by the original owner of the system. This seems obvious and tautological but we have yet to introduce an attacker with two different methods of attack.

An attacker bruteforces ssh because this has become the weakest point of Linux/BSD server security. After a certain amount of time an attacker has a low likelihood of getting a shell. If the attacker spends enough time they will succeed in finding a user with a weak password. AltSci.com had a bruteforceable password on a user account for more than a year. An attacker can use passwords that succeed to attack hosts in ~/.ssh/known_hosts and so forth. If the user has sudo, then the brute force ssh attacker will be able to get administrator privileges. This is no better than the Vista/Win7 security model because the attacker has the password.

If, on the other hand, the attacker gains code execution from a vulnerability that does not reveal the password, sudo and su both prevent the attacker from automatically gaining root privileges. The Vista/Win7 security model gives the attacker administrator privileges as soon as the attack succeeds. However, sudo and su are both vulnerable to trojan if the attacker has code execution access as the user. If the user has no utility to detect rogue processes (netstat, ps and so forth), an attacker can hide as a bash shell. The attacker can inject a trojan into the PATH and gain the user's password. If the user uses sudo often enough, the attacker just has to wait for the user to sudo at which point they also gain root privileges.

If the account that the attacker has gained is rarely logged in or rarely sudo, the attacker can start up a bruteforce utility. Depending on whether the user is in sudoers or the wheel group, sudo or su can be bruteforced with the utilities provided.

Passwords are a weak point in security. The alternative models of authentication are difficult to enforce in the real world, but many work well. SSH has properly implemented public key authentication although they have caused various troubles for admins over the years. Amazon EC2 enforces public key authentication to eliminate bruteforce and default password issues. Recently some hackers have started to use one time passwords. This may become a useful tool to eliminate keylogging and bruteforce attacks in the future. Biometric and other two-factor authentication systems are likely to cause various troubles while they attempt to solve these same issues. I have hope for cheap smart cards becoming integrated into authentication, but not rfid or biometric authentication.

METHODS / TOOLS

su_brute1.py and sudo_brute1.py both use pexpect to automate sudo and su. Pexpect was designed to automate systems like scp, ssh, and telnet on multiple systems where a user either is not available or is uninterested in typing a password each time. A better system would be to use ssh-agent, but there are many use cases that don't support or require public key authentication. OpenCTF at Defcon 18 is one example.

DATA
date; head -n 100 ~/recent/john/rockyou1_order.txt | python ~/recent/sudo/sudo_brute1.py | grep ^data | wc; date
Tue Aug 10 07:23:39 PDT 2010
    102     102    1088
Tue Aug 10 07:27:30 PDT 2010

100 password attempts in 231 seconds.

sudo less /var/log/auth.log
...
Aug 10 07:26:51 dmitry sudo: pam_unix(sudo:auth): authentication failure; 
logname= uid=0 euid=0 tty=/dev/pts/22 ruser=jvoss rhost=dmitry  user=jvoss
Aug 10 07:26:58 dmitry sudo: pam_unix(sudo:auth): authentication failure; 
logname= uid=0 euid=0 tty=/dev/pts/22 ruser=jvoss rhost=dmitry  user=jvoss
Aug 10 07:27:04 dmitry sudo: pam_unix(sudo:auth): authentication failure; 
logname= uid=0 euid=0 tty=/dev/pts/22 ruser=jvoss rhost=dmitry  user=jvoss
Aug 10 07:27:11 dmitry sudo: pam_unix(sudo:auth): authentication failure; 
logname= uid=0 euid=0 tty=/dev/pts/22 ruser=jvoss rhost=dmitry  user=jvoss
Aug 10 07:27:17 dmitry sudo: pam_unix(sudo:auth): authentication failure; 
logname= uid=0 euid=0 tty=/dev/pts/22 ruser=jvoss rhost=dmitry  user=jvoss
Aug 10 07:27:24 dmitry sudo: pam_unix(sudo:auth): authentication failure; 
logname= uid=0 euid=0 tty=/dev/pts/22 ruser=jvoss rhost=dmitry  user=jvoss
Aug 10 07:27:55 dmitry sudo: pam_unix(sudo:session): session opened for user root by jvoss(uid=0)
Aug 10 07:27:55 dmitry sudo: pam_unix(sudo:session): session closed for user root
USAGE
./john --stdout --incremental | python su_brute1.py
python su_brute1.py < rockyou1_order.txt

./john --stdout --incremental | python sudo_brute1.py
python sudo_brute1.py < rockyou1_order.txt

CONCLUSION

Passwords are a low risk system in computer networks but they represent a higher risk than Sendmail, Apache, OpenSSH, OpenBSD, and many other server software systems. Why is this? Bad passwords have 36^6 = 2176782336 or less possible values. Sendmail had a remote exploit in 2006. Apache had a remote exploit in 2009. An attacker can get remote execution via bruteforce in less than 2176782336 tries. An attacker would need to find a Sendmail system unpatched since 2006 to exploit it. An attacker would need to find an Apache system unpatched since 2009 to exploit it. You may argue but it is my opinion that bruteforce attacks are more profitable to an attacker than Apache or Sendmail attacks today. In comparison to IE6, IE7, Firefox, Opera, Safari, Adobe Flash, or PDF readers though, passwords are much lower risk until browser security comes a long way.

Once browser security improves considerably, other services and passwords will take their place at the forefront of insecurity. As a security researcher I have found myself researching this issue before bruteforce becomes a worse issue than browser security. Of course I am not the first researcher or programmer to notice this issue. Allow me to state once again: Sudo and Su may be considered harmful.

If you are interested in working on threat models like the ones presented in this article, there are job openings for intelligent hackers at Seattle firms (not including AltSci Concepts). E-mail me with your résumé and mention this article and I will attempt to get you at least one interview.

Permalink

Comments: 2

Leave a reply »

 
  • Cody

    Re: "If the user has sudo, then the brute force ssh attacker will be able to get administrator privileges. This is no better than the Vista/Win7 security model because the attacker has the password."

    Not entirely correct. That is if and ONLY IF they are allowed to use sudo unrestricted and (specifically they are allowed to do any command with sudo). You do realise that you can restrict the command, I hope? Hint: you can make it so the user can only run a specific command and anything else is denied. Example is that you have two developers on a project that runs under a user 'luser'. You don't set a password on luser but you give the developers (we'll call them loser1 and loser2) access to one command with sudo and one command only:
    sudo su - luser

    There, now where do they get root access from that? Hint: they don't. They get one command: changing to user luser (and luser has no sudo access at all). Further, their uid/gid has now changed and most certainly not to 0. To give another example, you can give the user access to 'sudo su - root' but 'sudo su -' would fail even though 'su - root' and 'su -' are pretty much the same thing (pointing out that you specify not just command but all arguments and anything different specified is denied).

    Re: "As a security researcher I have found myself researching this issue before bruteforce becomes a worse issue than browser security. Of course I am not the first researcher or programmer to notice this issue. Allow me to state once again: Sudo and Su may be considered harmful."

    Browser security isn't really related to this. But I'll humour you for a minute. If sudo and su are so bad, what would you suggest to do instead? Always be logged in as root? Giving every thing setuid exec (of course you could also make it so only root - example - can use ping, by removing its setuid execute bit) ? And speaking of su, you do realise also, I hope, that you can limit this, too (wheel group comes to mind, linux PAM authentication also comes to mind and you mention the former even), so that not every user can su. No, the only thing that is harmful here is weak passwords and that is how it's always been (see below too for a 17 year old example).

    And speaking of that, I find this fairly interesting. In your article you write at one point: "Passwords are a weak point in security." (which is correct) and then later write: "Passwords are a low risk system in computer networks but they represent a higher risk than Sendmail, Apache, OpenSSH, OpenBSD, and many other server software systems." (not always correct e.g., the Morris Worm and also the two can be used together to get root). But aren't those two statements some what contradictory (even if you consider system - local - versus network - remote - because it's only remote until you have a way to get 'local' access, at least in terms of the end result)?

    Do you perhaps remember the old apache phf exploit ? Keep in mind that was in 1996 (and it existed on many systems for a long time, years for sure) and in those days /etc/passwd contained the password hashes (read: no shadowing). And also in those days you typically had telnet as the remote login method (so forget ssh keys!). So all one needed to do is exploit that apache bug, run a dictionary attack on the file (and keep in mind: humans use weak passwords), telnet in once they have a successful login/passwd combination and then exploit some _other_ bug in the system that gives them a root shell - they won't even need sudo or su in those cases. You know, once you have shell access, you are so much closer to root access, because so many more possible attack vectors exist locally, that allow a root shell. In other words: if you have shell access su and sudo are hardly the only concern. Shortly don't give someone shell access if you don't trust them in any of numerous ways or else you're asking for trouble. Something I didn't mention too, is that (and maybe you're getting at this with sudo and su used together) su by itself is not a problem if the root password is strong and everything else is done right (notwithstanding guessing over and over again but an admin not noticing that partly to blame then). And sudo is not really a problem either if you actually use common sense and don't allow them to use sudo su (especially to root or a user that also has a way to easily get root) in the first place.

     
     
  • Javantea

    Hello Cody, many thanks for your help in making this article much better. I agree that sudo is very flexible and that software vulnerabilities are still a problem. I reiterate the two theses of this paper: sudo and su can be bruteforced using the tools provided. Software vulnerabilities are currently more likely to be exploited, but that may change as software security improves. Password-based security must improve or it will become a more prevalent vector for compromise.

    I will eventually write an update that clearly describes the benefits and drawbacks of sudo and su. Passwords actually have a lot to do with browser security. I made the comparison between the two because I am assessing the relative likelihood of being compromised due to a flaw in a security mechanism that you have reason to distrust. We have seen servers exploited, we have seen browsers exploited, and we have seen weak passwords exploited. Whether your computer is compromised by a vuln in a server, a vuln in a browser, or a weak password matters a lot if you are spending a lot of time searching for vulnerabilities in browsers, servers, or passwords.

    There is indeed a solution to passwords that I have yet to propose that has gained a lot of traction in the past few years. I will leave it unnamed because it would be a disservice to discuss it in a comment to a 3-year-old article.

    Your description of the old Apache phf exploit is reminiscent of so many vulnerabilities in web applications today. 18 years go by and the only difference is the names of the software being exploited and the skill required to exploit. These days, attackers have to misuse processes that we have given the task of protecting our systems from them. The programs su and sudo are both designed to allow us to have full control over our systems while limiting attackers' ability to exploit our systems. The question of whether su and sudo are harmful to me comes to whether they succeed at their goal. If I run a piece of software that gets exploited, su and sudo can protect me from an attacker getting root. If my password is weak this goes out the window. On a server I'm running ssh with password authentication enabled, which makes it worse. An ssh bruteforce tool can get past first ssh authentication, then sudo authentication. On the other hand, if I have a strong user password but a weak root password, an attacker with execution access (in the wheel group of course) can compromise the system with su. These systems are not magic and must be evaluated properly. If there is a system to replace sudo and su (and there is), then we should consider migrating our systems from sudo and su to it. Of course passwords will probably not go away but will need to morph from the current state of a password is equal to root.

     
     
  • Leave a Reply
    Your gravatar
    Your Name