Chi Sei per il Kernel

Linux non sa chi sei. Sa solo il tuo numero.

Quando apri una shell, il sistema operativo non lavora con il tuo nome utente - lavora con un intero: il tuo UID. Tutto il sistema di permessi, dai file ai processi, è costruito su questa traduzione. Capire come funziona è il primo passo per capire perché certi attacchi funzionano.

Sistema: Linux (qualsiasi distribuzione) Tools: id, ls, find, chmod, stat - tutti preinstallati Conoscenze: nessuna - si parte da zero

Come funziona il sistema di identità

#

Ogni utente in Linux ha tre identificatori numerici:

• UID (User ID) - chi sei tu
• GID (Group ID) - il tuo gruppo principale
• gruppi supplementari - altri gruppi a cui appartieni

id

# output simulato
uid=1000(barno) gid=1000(barno) groups=1000(barno),4(adm),27(sudo),1001(docker)

Ogni processo che avvii eredita il tuo UID e GID. Quando bash vuole aprire un file, il kernel confronta l'UID del processo con i permessi del file e decide: sì o no.

graph TD
    Utente["Utente: barno\nUID=1000, GID=1000"] --> Processo["Processo bash\nUID=1000, GID=1000"]
    Processo --> Controllo["Kernel: confronta UID/GID\ncon i permessi del file"]
    Controllo --> Sì["Accesso consentito"]
    Controllo --> No["Permission denied"]

Root è semplicemente l'utente con UID=0. Non c'è magia - è solo un numero speciale che il kernel tratta diversamente: i controlli di permesso vengono saltati.

I permessi sui file

#

Ogni file ha tre set di permessi: per il proprietario, per il gruppo, e per tutti gli altri.

ls -la /etc/passwd

# output simulato
-rw-r--r-- 1 root root 2847 Mar 18 09:00 /etc/passwd

Si legge così:

- rw- r-- r--
│  │   │   └── altri (r = leggi, - = non scrivere, - = non eseguire)
│  │   └────── gruppo root (solo lettura)
│  └────────── proprietario root (leggi e scrivi)
└────────────── tipo file (- = file normale, d = directory)

# Vedere i permessi in forma numerica (ottale)
stat -c "%a %n" /etc/passwd

# output simulato
644 /etc/passwd

644 significa: proprietario 6 (rw-), gruppo 4 (r--), altri 4 (r--).

Cos'è il bit SUID

#

Fin qui tutto normale. Il bit SUID è l'eccezione che cambia le regole.

Quando un file eseguibile ha il bit SUID impostato, il processo che lo esegue non usa il tuo UID - usa l'UID del proprietario del file. Se il proprietario è root, il processo gira come root, indipendentemente da chi lo ha avviato.

# Vedi il bit SUID: la 's' al posto della 'x' nei permessi del proprietario
ls -la /usr/bin/passwd

# output simulato
-rwsr-xr-x 1 root root 59976 Nov 24 2022 /usr/bin/passwd

La s in posizione x del proprietario significa: SUID attivo. Questo eseguibile gira con UID=0 per chiunque lo lanci.

graph TD
    Utente["barno UID=1000"] -->|esegue| Passwd["/usr/bin/passwd\nSUID + owner=root"]
    Passwd -->|processo gira con| EUID["EUID=0 root"]
    EUID -->|può scrivere su| Shadow["/etc/shadow\naltrimenti inaccessibile"]

passwd ha bisogno di SUID per funzionare: deve scrivere su /etc/shadow, che è leggibile solo da root. È un caso d'uso legittimo.

Trovare i binari SUID sul sistema

#

# Elenca tutti i file con il bit SUID impostato
find / -perm -4000 -type f 2>/dev/null

# output simulato
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/su
/usr/bin/mount
/usr/bin/newgrp
/usr/bin/gpasswd

-perm -4000 significa "il bit 4000 è impostato" - il 4 davanti è il bit SUID in notazione ottale.

Il GID e il bit SGID

#

Come SUID ma per i gruppi. Un file con SGID gira con il GID del gruppo proprietario invece del GID dell'utente che lo esegue.

ls -la /usr/bin/write

# output simulato
-rwxr-sr-x 1 root tty 14328 Feb 25 2022 /usr/bin/write

La s nella posizione del gruppo: SGID attivo. Il processo gira con GID del gruppo tty.

Sulle directory, SGID ha un comportamento diverso: i file creati dentro ereditano il GID della directory, non quello dell'utente. Utile per cartelle condivise tra team.

Dove si rompe: privilege escalation

#

Un binario SUID root che permette di eseguire comandi arbitrari è un vettore di privilege escalation.

Esempio semplice: find con SUID root (non dovrebbe esistere, ma succede su sistemi mal configurati):

# find può eseguire comandi con -exec
# se ha SUID root, quei comandi girano come root
find /etc/passwd -exec /bin/sh \;

# output simulato
# id
uid=1000(barno) gid=1000(barno) euid=0(root)

L'EUID è 0 anche se l'UID rimane quello dell'utente. Sei root per tutto ciò che riguarda i controlli di accesso.

Il sito GTFOBins cataloga quali binari standard possono essere usati in questo modo quando hanno SUID impostato.

Come impostare e rimuovere SUID

#

# Aggiunge il bit SUID a un file
chmod u+s /percorso/file
# oppure in ottale (4 davanti ai permessi normali)
chmod 4755 /percorso/file

# Rimuove il bit SUID
chmod u-s /percorso/file

# Verifica
ls -la /percorso/file
# deve comparire 's' al posto di 'x' nei permessi del proprietario

Quando il SUID è un rischio

#

Il bit SUID è necessario su pochissimi binari di sistema (passwd, sudo, su, mount). Su tutto il resto è un rischio.

Segnali di allarme:

• Binari SUID fuori da /usr/bin/ e /usr/sbin/
• Binari SUID non appartenenti a nessun pacchetto installato
• Interpreti (python, perl, bash) con SUID impostato
• Editor di testo o strumenti di debug con SUID

# Audit rapido: SUID fuori dai path standard
find / -perm -4000 -type f 2>/dev/null | \
  grep -v -E "^/(usr/bin|usr/sbin|bin|sbin|usr/lib)"

Ogni riga nell'output è qualcosa da esaminare.

exit 0

#

UID e GID non sono dettagli implementativi - sono il confine tra quello che puoi fare e quello che non puoi. Il bit SUID è un'eccezione a quel confine: necessaria in casi specifici, pericolosa ovunque altro.

La privilege escalation via SUID non è un bug del sistema operativo. È il sistema che funziona esattamente come progettato, applicato a una situazione che chi ha configurato il server non aveva previsto.

Concetti correlati: uid-gid-identifiers, linux-permissions-ugo, suid-sgid-sticky Comandi usati: find