tabbysable/poc-2020-8558Informazioni su Kubernetes CVE-2020-8558, incluso un exploit di prova di concetto.
CVE-2020-8558 è una vulnerabilità di Kubernetes che è stata pubblicata perché kube-proxy inaspettatamente rende i servizi dell'host in ascolto su localhost disponibili ad altri sulla rete. Pongo l'enfasi su inaspettatamente perché questa vulnerabilità è dovuta a un difetto di progettazione (svista), non a un difetto di implementazione (bug). Il codice fa esattamente quello che dice di fare, ma tutti noi non abbiamo riconosciuto le implicazioni di sicurezza di quella decisione.
Per consentire ai processi host di accedere ai servizi NodePort tramite l'indirizzo 127.0.0.1 (localhost), kube-proxy imposta l'impostazione sysctl net.ipv4.conf.all.route_localnet=1. Secondo la documentazione del kernel, questa impostazione fa sì che il kernel "non consideri gli indirizzi di loopback come marziani" – una conseguenza è che potrebbero essere accessibili da altri nodi sulla rete. È un grosso problema se hai servizi sensibili non autenticati la cui unica protezione è essere legati a localhost!
Al momento della scrittura, la comunità di Kubernetes sta ancora elaborando il modo migliore per affrontare la CVE-2020-8558. Le due scelte ovvie sono smettere di impostare il sysctl route_localnet in primo luogo, o bloccare i pacchetti localnet instradati in modo inappropriato usando iptables. Una correzione che utilizza quest'ultima strategia è già stata rilasciata in kubelet >= 1.18.4, 1.17.7 o 1.16.11. Puoi anche applicarla tu stesso facendo riferimento al problema Kubernetes per questa CVE, linkato di seguito.
Perché impostare net.ipv4.conf.all.route_localnet=1 merita un ID CVE? Principalmente perché viola la nostra intuizione sulle reti IP.
Almeno dall'RFC 1122 del 1989, i pacchetti dalla rete localhost 127.0.0.1/8 sono stati trattati in modo speciale, vietati di apparire 'fuori da un host'. (Contattami su Twitter se conosci un riferimento precedente alle proprietà speciali di 127/8.) Qualsiasi host conforme all'RFC ha essenzialmente una regola firewall implicita e non rimovibile che blocca l'accesso esterno ai servizi legati a 127.0.0.1 (e altri IP in quella rete – prova a fare ping a 127.127.127.127 se non l'hai mai fatto!) Siamo arrivati a dipendere e ad aspettarci quel comportamento. Spesso eseguiamo servizi sensibili senza autenticazione o crittografia, e li leghiamo a localhost per sicurezza. Ad esempio, backend HTTP in chiaro, il key-value store redis, e la porta non sicura del server API di Kubernetes (ormai obsoleta) sono solitamente protetti da intrusioni in questo modo. Siamo così abituati a questo comportamento che è una parte radicata del nostro senso intuitivo di cosa significhi essere un host IP. Visto in questa luce, è comprensibile che numerosi esperti possano aver trascurato questo difetto per così tanto tempo.
Come funziona?
Chiamiamo 'nodo' qualsiasi entità con un indirizzo IP. I pacchetti IP vengono inviati da un nodo all'altro, identificati dall'indirizzo IP di origine e destinazione nell'intestazione del pacchetto. Ogni nodo IP è un router (chiamato gateway nell'RFC1122) o un host. La differenza principale è che quando un host riceve pacchetti destinati all'indirizzo di qualcun altro, li ignora. Un router consulta la sua tabella di routing e ritrasmette (inoltra) i pacchetti nel tentativo di avvicinarli alla loro destinazione finale. Un host conoscerà alcuni nodi connessi localmente; per accedere ad altri nodi, deve inviare i suoi pacchetti a un router connesso localmente. Queste connessioni locali possono essere punto a punto (come un collegamento PPP o alcune reti virtuali) o a mezzo condiviso (come Ethernet).
La tua casella di posta può essere concettualizzata come un collegamento punto a punto tra la tua casa e l'ufficio postale locale. Per instradare un pacchetto su un collegamento punto a punto, l'host deve solo applicare l'indirizzo di destinazione corretto e trasmettere il pacchetto. (Questo avviene al Livello 3 del modello OSI.) Per instradare un pacchetto su un collegamento a mezzo condiviso, l'host deve prima costruire un circuito punto a punto virtuale attraverso il mezzo condiviso. Nelle reti Ethernet/IP, questo viene fatto da ARP, al livello 2 del modello OSI. Essenzialmente, se puoi trasmettere un pacchetto ARP, puoi dire a un altro host 'Ehi, sono qui' e ti crederà. (Quando questo viene fatto in modo inappropriato, si chiama avvelenamento della cache ARP.) Poi puoi comunicare mettendo gli indirizzi Ethernet di origine e destinazione appropriati sui tuoi pacchetti.
Un nodo normale non trasmetterà mai un pacchetto con indirizzo di destinazione 127.0.0.1, a causa dell'RFC 1122. Se un nodo normale riceve un pacchetto con indirizzo di destinazione 127.0.0.1, lo ignorerà (lo scarterà), sempre a causa dell'RFC 1122. Impostare net.ipv4.conf.all.route_localnet=1 cambia le cose – permette ai pacchetti 127.0.0.1 di essere inviati e ricevuti come se non fossero speciali.
Quindi, se un attaccante ha una connessione locale a un nodo target con net.ipv4.conf.all.route_localnet=1, può inviargli un pacchetto con 127.0.0.1 come indirizzo di destinazione, e quel nodo target risponderà appropriatamente come se 127.0.0.1 fosse un indirizzo del tutto normale. I due modi più comuni per avere una connessione locale a un nodo target oggi sono essere sulla stessa rete Ethernet (dominio di broadcast) del target, o essere un container in esecuzione sul target.
Nota che quando configurato normalmente, Linux non permetterà al nodo attaccante di trasmettere pacchetti normali destinati a 127.0.0.1. Questo può essere aggirato riconfigurando il nodo Linux dell'attaccante (se ha accesso root), o forgiando pacchetti usando un raw socket. I raw socket richiedono solo la capacità del kernel Linux CAP_NET_RAW, che è concessa per impostazione predefinita ai container non privilegiati. Questo significa che un container non privilegiato controllato dall'attaccante è in grado di sfruttare la CVE-2020-8558.
In breve, se stai usando kube-proxy o stai facendo cose intelligenti con net.ipv4.conf.*.route_localnet, sei esposto. Dovresti dedicare del tempo alla modellazione delle minacce per determinare quanto sia rischiosa quell'esposizione per te e pianificare una strategia di mitigazione appropriata.
Fondamentalmente, ogni host Linux con net.ipv4.conf.all.route_localnet=1 impostato è vulnerabile. Se quella vulnerabilità è interessante per un attaccante dipende da diversi fattori:
Per valutare la CVE-2020-8558, devi immaginare attaccanti con varie capacità e rispondere a queste domande dal punto di vista di quegli attaccanti. (Il libro di Adam Shostack 'Threat Modeling: Designing for Security' descrive questo processo in grande dettaglio.) Due attaccanti rilevanti che dovresti sicuramente considerare sono un attaccante con un nodo sulla tua rete Ethernet e un attaccante che può eseguire codice in un pod non privilegiato sul tuo host. Potrebbero esserci altri attaccanti interessanti che dovresti considerare, a seconda del tuo ambiente e delle tue esigenze.
Per illustrare, ecco un esempio parzialmente elaborato:
L'host è certamente accessibile a entrambi gli attaccanti; lo abbiamo assunto in ogni caso.
I pacchetti possono essere filtrati o meno. Dovrai verificare. In molti ambienti cloud e reti on-prem strettamente gestite, i pacchetti vengono bloccati se la destinazione IP non corrisponde alla destinazione Ethernet prevista dalla rete. Questo da solo potrebbe essere la fine del gioco per l'attaccante-con-un-nodo. Se tutti i tuoi nodi hanno regole firewall locali appropriate (come quelle fornite da un kubelet aggiornato), ciò farà fallire entrambi gli attaccanti.
Probabilmente ci sono più servizi interessanti di quanto pensi. Ovviamente, la porta non sicura del server API di Kubernetes è un bersaglio molto invitante e dovresti disabilitarla se puoi. Indaga su tutti i processi che si legano a indirizzi IP nella rete 127.0.0.0/8: hanno un'autenticazione robusta? Se no, potrebbero essere esposti tramite CVE-2020-8558. Anche se tutti i tuoi servizi localhost normali sono sicuri, quelli effimeri possono essere una preoccupazione. Ad esempio, il port forwarding SSH è spesso usato per bypassare restrizioni di rete per scopi temporanei autorizzati. Per impostazione predefinita, le porte inoltrate via SSH sono legate a localhost in modo che l'accesso temporaneo sia consentito solo agli utenti autorizzati. Con la CVE-2020-8558, quei port-forward 'sicuri' sono disponibili anche ai tuoi attaccanti.
Supponendo che tu abbia root su una macchina Linux nello stesso dominio di broadcast del target, le seguenti impostazioni di configurazione ti permetteranno di sfruttare la CVE-2020-8558:
ip addr add 127.0.0.2/8 dev lo
ip addr del 127.0.0.1/8 dev lo
ip route add 127.0.0.1/32 via YOUR-TARGET-HERE
sysctl net.ipv4.conf.all.route_localnet=1
Poiché alcuni servizi importanti (tosse, tosse, systemd-resolved) girano su un indirizzo 127.0.0.0/8, ne aggiungiamo uno nuovo per evitare di rompere l'host. Poi, l'host deve dimenticare il suo indirizzo predefinito 127.0.0.1/8. Successivamente, istruiamo il kernel a instradare il traffico per 127.0.0.1 attraverso il filo al tuo target, che sa come accedere a 127.0.0.1. Infine, impostiamo il famigerato sysctl che altrimenti bloccherebbe questa configurazione dal funzionamento.
Semplice script Python per testare la CVE-2020-8558 inviando pacchetti raw. Potrebbe essere un one-liner con scapy, ma volevo aggiungere un po' più di comfort. Invia un pacchetto a 127.0.0.1 tramite il tuo target e controlla se c'è una risposta.
Script Python per sfruttare la CVE-2020-8558 permettendo a normali applicazioni client TCP o UDP di comunicare con un IP localhost remoto tramite pacchetti forgiati. Esegui questo script, poi usa qualsiasi normale client TCP o UDP (es. kubectl o nc) per connetterti al tuo fakedestination (198.51.100.1 di default).
Nota che il fakedestination deve essere un indirizzo IP che non risponde mai ai pacchetti e la tua rotta verso di esso deve essere attraverso la stessa interfaccia con cui accedi al tuo target. Nel caso usuale, sia fakedestination che target saranno accessibili tramite la tua interfaccia gateway predefinita, e non sarà un problema.
Poiché questo script usa raw socket per inviare e ricevere i pacchetti 'localhost', funziona bene all'interno di un normale container non privilegiato.
Problema Kubernetes per questa CVE su GitHub
Documentazione sysctl IP del kernel
Adam Shostack: Threat Modeling
Un ringraziamento a Ian Coldwater, Brad Geesaman, Duffie Cooley e Laurent Bernaille. Grazie per i pensieri, i consigli e le risate, a tutti. Honk the planet!