Dimostrazione di vulnerabilità su Ubuntu 9.04

Per un corso sulla sicurezza IT, voglio dimostrare agli studenti l'escalation dei privilegi. Per fare ciò, ho consultato l' exploit/linux/localelenco nel Metasploit Framework, trovando (tra gli altri) exploit/linux/local/sock_sendpagedall'agosto 2009.

Ho impostato una VM con Ubuntu Server 9.04 a 32 bit ( http://old-releases.ubuntu.com/releases/9.04/ubuntu-9.04-server-amd64.iso ) da aprile 2009. uname -rMi dà 2.6.28-11-generic. Secondo la descrizione dell'exploit

Si ritiene che tutte le versioni di Linux 2.4 / 2.6 dal maggio 2001 siano interessate: 2.4.4 fino alla 2.4.37.4 inclusa; 2.6.0 fino a 2.6.30.4 compreso

Quindi sembra che il server Ubuntu che ho impostato dovrebbe essere adatto per la dimostrazione. Tuttavia, non sono riuscito a farlo funzionare.

Ho aggiunto un utente (normale) sul server e l'accesso SSH funziona. Dall'interno del Metasploit Framework, posso creare una sessione SSH usando auxiliary/scanner/ssh/ssh_login. Tuttavia, quando eseguo l'exploit, ottengo

[*] Writing exploit executable to /tmp/mlcpzP6t (4069 bytes)

[*] Exploit completed, but no session was created.

Non ottengo ulteriori informazioni, nemmeno quando si imposta DEBUG_EXPLOITsu true. /tmpè scritto, anche all'interno della sessione SSH Metasploit:

$ sessions -c "touch /tmp/test.txt"
[*] Running 'touch /tmp/test.txt' on shell session 1 ([redacted])

$ sessions -c "ls -l /tmp"
[*] Running 'ls -l /tmp' on shell session 1 ([redacted])

total 0

-rw-r--r-- 1 [redacted] [redacted] 0 2016-03-28 09:44 test.txt

Ho anche provato a impostare WriteableDirla directory home dell'utente sul server, ma senza alcuna modifica. Cosa mi sto perdendo qui? Questa versione del server Ubuntu (che non ho deliberatamente aggiornato!) Non è vulnerabile?

La versione 9.04 è stata supportata fino al 23 ottobre 2010. La vulnerabilità che hai riscontrato è stata segnalata nell'agosto 2009. Sembra ragionevole che, dal momento che la versione era ancora attuale e supportata al momento, l'ISO è stato patchato e ciò che hai scaricato era una versione che è non più vulnerabile.

Inoltre, sembra che tu abbia dimostrato abbastanza bene che non è vulnerabile. Dopo tutto, hai provato l'exploit e sembra che abbia fallito.

Perché non provi un nuovo exploit? Qualcosa come CVE-2013-2094 che dovrebbe influenzare anche Ubuntu , per esempio.

Questo non risponde alla tua specifica domanda, ma ti dà più scelte di esc private per mostrare ai tuoi studenti ...

Potresti anche prendere in considerazione le seguenti due configurazioni errate dell'amministratore che potrebbero portare a esc privata su 'nix (ci sono molti altri modi per configurare in modo errato una casella' nix che potrebbe consentire esc privata, quindi ti preghiamo di considerare questo un appetito) ....

1. binari suid e guid di proprietà di root / root group ( find / -uid 0 -perm -4000 -type f 2>/dev/nulle find / -uid 0 -perm -2000 -type f 2>/dev/null) e vedere se sono scrivibili in tutto il mondo per consentire all'utente con privilegi limitati di cambiarli; la cartella in cui esistono è scrivibile dall'utente con un basso livello di privacy, per una possibile iniezione del percorso della libreria. Che dire delle librerie che usano - sono quelli in grado di essere cambiato: controllare i valori di qualsiasi DT_RPATHe DT_RUNPATHintestazioni ELF entro i binari utilizzando uno dei seguenti comandi:

   • objdump -x ...
   • readelf -a ...
   • scanelf (da PaX)
   • elfdump (dal sole)
   • readelf -a binary | grep PATH

2. sudoers difetti

   • NOPASSWD - Un utente malintenzionato locale potrebbe utilizzare questo accesso per inoltrare i propri privilegi all'interno del sistema operativo quando l'utente dimentica di bloccare lo schermo

   • File eseguibili mancanti nei sudatori: alcuni file eseguibili nel /etc/sudoersfile non esistono. Se gli eseguibili vengono creati, possono essere eseguiti tramite sudo come root, il che consentirebbe l'escalation dei privilegi.

   • Voci orfane dei sudatori: il /etc/sudoersfile può contenere un numero di voci orfane per le quali non esiste un account corrispondente configurato nel /etc/passwdfile. Se un utente fosse creato con uno dei nomi orfani, fornirebbe all'utente un mezzo per inoltrare i privilegi all'accesso root completo.

   • Alcuni programmi non devono essere simili a vi, utilizzare :eo Ctrl o utilizzare :wper accedere /etc/shadow.

   • Comando errato / errato utilizzato nel file sudoers - lo vedo spesso httpdin sudoers - quindi prova come un utente con privilegi limitati con accesso sudo per eseguire solo quel comando ( sudo -lo sudo -llmostrerà cosa può fare un utente): sudo /usr/bin/httpd -t /etc/shadowe guarda l'errore.

   • i permanenti di file di comandi e file menzionati nei sudoer sono deboli - vedi il mio precedente paragrafo sui binari di bit suid e guid di proprietà di root