Interesting Groups - Linux Privesc
Last updated
Last updated
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
A volte, per impostazione predefinita (o perché qualche software ne ha bisogno) all'interno del /etc/sudoers file puoi trovare alcune di queste righe:
Questo significa che qualsiasi utente che appartiene al gruppo sudo o admin può eseguire qualsiasi cosa come sudo.
Se questo è il caso, per diventare root puoi semplicemente eseguire:
Trova tutti i binari suid e controlla se c'è il binario Pkexec:
Se scopri che il binario pkexec è un binario SUID e appartieni a sudo o admin, potresti probabilmente eseguire binari come sudo usando pkexec.
Questo perché tipicamente questi sono i gruppi all'interno della politica polkit. Questa politica identifica fondamentalmente quali gruppi possono utilizzare pkexec. Controllalo con:
Lì troverai quali gruppi sono autorizzati a eseguire pkexec e per impostazione predefinita in alcune distribuzioni linux i gruppi sudo e admin appaiono.
Per diventare root puoi eseguire:
Se provi a eseguire pkexec e ricevi questo errore:
Non è perché non hai permessi, ma perché non sei connesso senza una GUI. E c'è una soluzione per questo problema qui: https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903. Hai bisogno di 2 sessioni ssh diverse:
A volte, per impostazione predefinita all'interno del file /etc/sudoers puoi trovare questa riga:
Questo significa che qualsiasi utente che appartiene al gruppo wheel può eseguire qualsiasi cosa come sudo.
Se questo è il caso, per diventare root puoi semplicemente eseguire:
Gli utenti del gruppo shadow possono leggere il /etc/shadow file:
So, leggi il file e prova a crackare alcuni hash.
staff: Consente agli utenti di aggiungere modifiche locali al sistema (/usr/local) senza necessitare di privilegi di root (nota che gli eseguibili in /usr/local/bin sono nella variabile PATH di qualsiasi utente e possono "sovrascrivere" gli eseguibili in /bin e /usr/bin con lo stesso nome). Confronta con il gruppo "adm", che è più correlato al monitoraggio/sicurezza. [source]
Nelle distribuzioni debian, la variabile $PATH mostra che /usr/local/ verrà eseguita con la massima priorità, sia che tu sia un utente privilegiato o meno.
Se riusciamo a dirottare alcuni programmi in /usr/local, possiamo facilmente ottenere i privilegi di root.
Dirottare il programma run-parts è un modo semplice per ottenere i privilegi di root, perché la maggior parte dei programmi eseguirà un run-parts come (crontab, quando si effettua il login ssh).
o Quando si effettua il login in una nuova sessione ssh.
Sfruttare
Questo privilegio è quasi equivalente all'accesso root poiché puoi accedere a tutti i dati all'interno della macchina.
Files:/dev/sd[a-z][1-9]
Nota che usando debugfs puoi anche scrivere file. Ad esempio, per copiare /tmp/asd1.txt in /tmp/asd2.txt puoi fare:
Tuttavia, se provi a scrivere file di proprietà di root (come /etc/shadow o /etc/passwd) riceverai un errore di "Permesso negato".
Utilizzando il comando w puoi scoprire chi è connesso al sistema e mostrerà un output simile al seguente:
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 fare ciò, devi catturare 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 puoi trovare la risoluzione di questo schermo in /sys/class/graphics/fb0/virtual_size
Per aprire l'immagine raw puoi usare GIMP, selezionare il **screen.raw ** file e selezionare come tipo di file Dati immagine raw:
Poi modifica la Larghezza e l'Altezza a quelle utilizzate sullo schermo e controlla diversi Tipi di Immagine (e seleziona quello che mostra meglio lo schermo):
Sembra che per impostazione predefinita i membri del gruppo root possano avere accesso a modificare alcuni file di configurazione dei servizi o alcuni file di librerie o altre cose interessanti che potrebbero essere utilizzate per elevare i privilegi...
Controlla quali file i membri root possono modificare:
Puoi montare il filesystem root della macchina host su un volume dell'istanza, così quando l'istanza si avvia carica immediatamente un chroot in quel volume. Questo ti dà effettivamente i privilegi di root sulla macchina.
Finalmente, se non ti piacciono nessuna delle suggerimenti precedenti, o non funzionano per qualche motivo (firewall dell'api docker?), potresti sempre provare a eseguire un container privilegiato e fuggire da esso come spiegato qui:
Docker SecuritySe hai permessi di scrittura sul socket docker leggi questo post su come elevare i privilegi abusando del socket docker.
Di solito i membri del gruppo adm hanno permessi per leggere i file di log situati in /var/log/.
Pertanto, se hai compromesso un utente all'interno di questo gruppo, dovresti assolutamente dare un occhiata ai log.
All'interno di OpenBSD il gruppo auth di solito può scrivere nelle cartelle /etc/skey e /var/db/yubikey se vengono utilizzate. Questi permessi possono essere abusati con il seguente exploit per elevare i privilegi a root: https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
