baldassarrefe/fep3370-advanced-ethical-hackingSfruttamento DHCP con DynoRoot (CVE-2018-1111)
Questo progetto dimostra una vulnerabilità nota delle macchine Fedora e RedHat legata a un'implementazione lato client non sicura del Dynamic Host Configuration Protocol (DHCP). Un server DHCP malevolo può creare offerte DHCP con un payload malevolo che viene eseguito in una shell root sulla macchina vittima.
La vulnerabilità è attribuita a Felix Wilhelm ed è nota come CVE-2018-1111 o "DynoRoot".
Il Dynamic Host Configuration Protocol (DHCP) è un componente spesso trascurato nei sistemi in rete. Il suo ruolo è consentire la configurazione dinamica dei computer host che si collegano a una rete esistente. Il caso d'uso più comune è assegnare un indirizzo IP agli host appena connessi e informarli delle rotte esistenti per accedere ad altre reti. È possibile specificare opzioni aggiuntive, ad esempio l'indirizzo di un server DNS locale e la zona che serve, o la posizione di un file di avvio.
Analizziamo il protocollo a quattro fasi che viene seguito quando un nuovo host vuole unirsi a una rete dopo essersi connesso fisicamente tramite una connessione ethernet o wireless.
DISCOVER sulla rete.OFFER, contenente: indirizzo IP, subnet mask della rete, indirizzo del router e altre opzioni.REQUEST, richiedendo ufficialmente di prendere in affitto l'indirizzo IP offerto.ACK, indicando che al client è permesso utilizzare l'indirizzo IP per un determinato periodo di tempo.Dopo lo scambio iniziale, il client può rinnovare il lease semplicemente inviando un altro messaggio REQUEST. Il server verificherà l'esistenza di un lease con l'indirizzo IP e MAC del client e risponderà con un ACK.
Sessione DHCP (figura da Wikimedia Commons, sotto licenza CC BY-SA 4.0).
Alcune cose da notare:
DISCOVER e richiedere immediatamente un indirizzo con REQUEST. Ciò è comune in scenari in cui il client si è già connesso alla rete in passato e ricorda l'indirizzo precedente. In questo caso, il server verifica la disponibilità dell'indirizzo e invia un ACK alla richiesta, oppure, se il lease non è disponibile, invia un NACK.RELEASE per informare il server che l'indirizzo è ora disponibile. Tuttavia, ciò non è obbligatorio dal protocollo e il server raccoglierà periodicamente i lease scaduti.REQUEST in broadcast e invalideranno l'offerta.La vulnerabilità si trova in /etc/NetworkManager/dispatcher.d/11-dhclient, che viene eseguito dal client per analizzare e impostare le opzioni ricevute tramite DHCP.
declare è un builtin di bash che, se usato senza argomenti, elenca tutte le variabili dichiarate.grep filtra tutte le variabili relative a DHCP.while read opt itera sulle variabili DHCP una per una, esegue un po' di parsing e stampa una riga come export new_optionname=value per ogni opzione.eval.```bash
eval "$(
declare | LC_ALL=C grep '^DHCP4_[A-Z_]=' | while read opt; do
optname=${opt%%=}
optname=${optname,,}
optname=new_${optname#dhcp4_}
optvalue=${opt#*=}
echo "export $optname=$optvalue"
done
)"<!-- omit in toc -->
#### Funzionamento normale
In situazioni normali, il codice funzionerebbe perfettamente e analizzerebbe le nuove opzioni DHCP.
Ad esempio, il seguente codice:```bash
DHCP4_OPTION_ONE=42
DHCP4_OPTION_TWO="bla bla"
declare | LC_ALL=C grep '^DHCP4_[A-Z_]*=' | while read opt; do
optname=${opt%%=*}
optname=${optname,,}
optname=new_${optname#dhcp4_}
optvalue=${opt#*=}
echo "export $optname=$optvalue"
done
Stampa queste due istruzioni export da valutare tramite eval:```bash
export new_option_one=42
export new_option_two='bla bla'
<!-- omit in toc -->
#### Iniezione di codice
Tuttavia, a causa del `eval` non sicuro, è possibile iniettare comandi bash:```bash
DHCP4_OPTION_ONE="x'& echo Hacked! #"
DHCP4_OPTION_TWO='bla bla'
eval "$(
declare | LC_ALL=C grep '^DHCP4_[A-Z_]*=' | while read opt; do
optname=${opt%%=*}
optname=${optname,,}
optname=new_${optname#dhcp4_}
optvalue=${opt#*=}
echo "export $optname=$optvalue"
done
)"
Risulterà nella valutazione di echo Hacked!:```text
[1] 1541
Hacked!
### Fonti
- [Voce nel database Exploit](https://www.exploit-db.com/exploits/44890)
- [Annuncio RedHat](https://access.redhat.com/security/vulnerabilities/3442151)
- [Post sul blog di Tenable](https://www.tenable.com/blog/advisory-red-hat-dhcp-client-command-injection-trouble)
- [Repository GitHub](https://github.com/kkirsche/CVE-2018-1111)
- [Annuncio su Twitter](https://twitter.com/_fel1x/status/996388421273882626?lang=en)
## Configurazione
La configurazione minima per dimostrare l'exploit consiste in due sole macchine: la macchina `victim`
che esegue Fedora 28 e una macchina `attacker`. In questa configurazione, l'attaccante deve semplicemente fornire un
servizio DHCP e attendere la connessione della vittima.
<figure style="text-align:center">
<img src="https://raw.githubusercontent.com/baldassarrefe/fep3370-advanced-ethical-hacking/HEAD/media/network_simple.svg" style="max-width:400px;" width="90%"/>
<figcaption>Configurazione minima per l'exploit.</figcaption>
</figure>
Una configurazione più realistica collocherebbe le macchine su una rete privata, dove una terza macchina, il
`gateway`, è configurata come server DHCP benigno e come gateway verso Internet esterno.
In questa configurazione, l'attaccante deve impedire alla vittima di connettersi al server DHCP legittimo
prima di sperare di eseguire l'attacco.