How can an attacker gain root next time a compromised account does?

I was reading Ubuntu's documentation about root/sudo when I came across the following:

• Isn't sudo less secure than su?

  The basic security model is the same, and therefore these two systems share their primary weaknesses. Any user who uses su or sudo must be considered to be a privileged user. If that user's account is compromised by an attacker, the attacker can also gain root privileges the next time the user does so.

How can an attacker gain root privileges the next time the user does? Assuming sudo is disabled.

From serverfault Swoogan

• I think the case you are asking about has more to do with privilege escalation via su. Since it may be that only the user's password is compromised, the attacker cannot esacalate until he also has root's password. If the attacker installs a keylogger program or replaces su or something like that, he/she will be able to obtain the root password the next time the privileged user types it.

  From Chad Huneycutt

• sudo -s executes the users .bashrc. If you have access to that users account you can add lines to this bashrc that will be ran as root.

  # ~/.bashrc
  cp /bin/bash /bin/something_else
  chmod 4755 /bin/bash
  

  I'd add something like that in, create a setuid copy of bash, so that I could run it later.

  ---

  Edit: the question now seems to ask about cases where sudo isn't used.

  First trick that comes to mind if i wanted to root privileges from a user using su would be to modify their path.

  # echo $PATH 
  /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
  $ export PATH=/tmp:$PATH
  su
  # echo $PATH 
  /tmp:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
  

  That's running fedora 11 with bash 4. Configs for su, shell environment stuff are pretty much default.

  As you can see, I was able to change the path as the regular user, and this path wasn't reset by su (note su - would have reset it). Change their path in their shell rc, then put my own script into the new directory at the top of the path. Make a few copies (or symlinks) of it with names like ls, cp, mv, things that get ran often.

  #!/bin/bash
  # make a shell for later
  cp /bin/bash /bin/something_else
  chmod 4755 /bin/bash
  # cause more trouble
  ...
  # now run the real command so the user doesn't notice
  PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
  exec $0 $*
  

  Anyway, these are just examples, there's undoubtedly other similar scenarios. I think the point is that accounts which can su or sudo are something to be careful with.

  From theotherreceive

• If a user's password is compromised and that user has sudo privileges, an attacker could run sudo su, and become root.

  Swoogan : Actually, I'm referring to the situation where sudo is not enabled.

  thepocketwade : sorry, I missed that part of the question.
  From thepocketwade

• It's very simple actually. sudo is typically set to cache its authentication so you don't have to enter your password every time you use sudo on a command. I believe the default cache time is something like 5 minutes.

  Thus if the attacker has access to a user account with sudo access, even without knowing their password, they can just wait for the next time the user performs a sudo. The attacker can then run sudo right afterwards and get a root shell.

  I presume this is the scenario they are referring to when they mention "the next time the user does".

  Swoogan : Actually, I'm referring to the situation where sudo is not enabled.

  Jeff Atwood : note that the post says ASSUMING SUDO IS DISABLED!

  Kamil Kisiel : The poster didn't add that part to the question until after I already answered it.
  From Kamil Kisiel

• Although sudo is commonly used together with su command, thinking sudo su is the only way to do is a mistake.

  sudo has many options for setting what to execute by who (ether user of group of users) on which host. A fine-grained sudoers file (or LDAP entry, if sudo-ldap is involved) together with a clever mind of a sysadmin can end up in rules which may not compromise system security even the user account has been compromised.

  let's see a real-word example:

  $ sudo -l
  User exampleuser may run the following commands on this host:
      (root) /opt/xmldns/gen.sh
      (root) /usr/bin/make -C /root/admin
      (root) /usr/sbin/xm list, /usr/sbin/xm dmesg
      (root) /usr/sbin/zorpctl stop, /usr/sbin/zorpctl start, /usr/sbin/zorpctl status
      (root) /etc/init.d/apache status, /etc/init.d/apache stop, /etc/init.d/apache start
      (root) /usr/local/bin/protodump.sh httpreq
      (root) /usr/sbin/xm console
  $ 
  

  If one does not let user sudo-exec su/bash or other shell neither directly (sudo su) nor indirectly (letting an editor spawn with root, which could be used to spawn shell - in this case, root), sudo is a friend of a system administrator and users too.

  Returning to the question in topic, if sudo is disabled and su is the only way becoming root on a system, one would plant a fake su command (for example in ~/.../fakesu) and an alias like alias su='~/.../fakesu' in the rc file of the user's login shell.

  In this case a simple su command (raise hands, who uses /bin/su for invoking) would end up calling the fakesu command, which may capture the password.

  Babu : +1 for the suggestion of only enabling commands that are needed
  From asdmin

• The principle is simple. Sudo only requires the user's password to perform activities as root. If someone was able to break into that user's account, he probably knows the password (or can easily figure it out).

  With su, the case is a bit different, because it requires root password. However, an attacker could change the user's PATH to point to its own version of su (inside tmp or ./bin) that will save the root password somewhere.

  Now you added that sudo is disabled. The link you provided don't talk about that. They mention the case where sudo or su are configured for that user and an attacker uses that as leverage to get root.

  Swoogan : The link I provided says, "Any user who uses su or sudo." I specifically want to know in the case of su since I already know how sudo can be compromised, since it is blindly obvious.
  From sucuri