In molti mi stanno chiedendo in queste ore lumi circa l'alert diramato dapprima dall'Agenzia Francese e di conseguenza dall'Agenzia per la Cybersecurezza Nazionale (ACN) Italiana in questo comunicato.
In questo breve articolo non parlerò (troppo) della vulnerabilità, ma del perchè ci si ritrova con un server esposto.
La vulnerabilità in breve
La CVE-2021-21974 confermata da VMware qui e con un punteggio di 9.8/10 riguarda il servizio SLP, normalmente aperto di default sulla porta 427, che consente di ottenere un accesso permanente e privilegiato sull'hypervisor. Da quando una CVE viene rilasciata in seguito ad un possibile punto di attacco a quando l'attacco diviene realmente applicato nel mondo reale, a volte passa del tempo (altre volte, invece, ci si accorge della vulnerabilità dopo aver concretamente osservato gli attacchi). Motivo per cui oggi, improvvisamente, è esploso il caso.
La vulnerabilità consente di crittografare direttamente le macchine virtuali ignorando totalmente come quanto esse siano protette al loro interno. Aspetto ancor più grave è che potenzialmente i backup fatti dall'Hypervisor (ad esempio con Ghetto o con altri script su volumi direttamente connessi in NFS, iSCSI, etc.), sono anch'essi attaccabili.
Quando ci si ritrova vulnerabili?
Ci si ritrova vulnerabili quando un server VMware viene esposto su internet senza alcuna protezione perimetrale a difesa della macchina. Quando un server VMware viene protetto da un firewall (ma anche da un dispositivo in grado di fare NAT come un router con questa funzionalità attiva), è prassi che i servizi non utilizzati vengano chiusi e non resi accessibili all'esterno. Intendiamoci: l'hypervisor è sacro, va protetto più delle VM in esso contenuto.
Quindi, ricapitolando, per avere un VMware esposto devo:
- Non avere un router con il NAT abilitato (quindi VMware dovrebbe avere direttamente l'IP Pubblico Statico)
- Non avere un firewall
- Aver lasciato il servizio slp attivo (com'è di default)
Una situazione che non dovrebbe accadere in un'azienda con i server in casa ma che è la normalità con i server in cloud.
Perchè si parla di attacco principalmente alla Francia?
Qui c'è un aspetto interessante della vicenda. Non è nulla di geopolitico, semplicemente in Francia c'è uno dei più grandi Cloud Provider Europei.
Quando si acquista un server dedicato, è prassi che il provider metta a disposizione, tra gli altri sistemi operativi, anche VMware. In questo caso esso verrà pubblicato direttamente sull'IP Pubblico Statico che ci è stato riservato.
Solo raramente ci si preoccupa di mettere in sicurezza questo aspetto invece cruciale. Nella stragrande maggioranza dei casi chi acquista un servizio in cloud si culla sul principio, fittizio, per cui il non avere un server in casa significhi automagicamente che esso sia responsabilità di altri. Cosa, ovviamente, assolutamente non vera. Molto raramente assisteremo ad installazioni in cloud con un Firewall Virtuale a protezione del proprio server, oppure ad un sistema di backup realmente sicuro e robusto. Ed è in questa falsa convinzione che si annida poi l'errore spesso fatale.
I più virtuosi attivano lo spazio di backup messo a disposizione dell'operatore, peccato esso sia vulnerabile in quanto gestito dall'hypervisor stesso (oggetto dell'attacco) e quindi totalmente inutile in questo contesto.
Chiudere la vulnerabilità
E' sufficiente dare questi due comandi in ssh sull'hypervisor
/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0
Oppure chiudere la porta 427.
In conclusione
Oggi si parla di servizio SLP, domani sarà un altro servizio e, perchè no, magari un problema su qualcosa che proprio non possiamo chiudere. La sicurezza di un'infrastruttura non è qualcosa solo da correggere di volta in volta, ma va pensata ad un livello globale e più architetturale. Solo realizzando un'architettura robusta otterremo un livello di protezione tale da contrastare la maggior parte di questi eventi senza doverli affannosamente rincorrere nella speranza di non essere tra i primi ad essere beccato.
Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.
