Il servizio dockerd di norma non dovrebbe essere accessibile per l’amministrazione direttamente via rete ed è fortemente sconsigliato che lo sia in quanto questo canale non è previsto né crittografato né autenticato. Eppure una rapida ricerca su Shodan rileva 618 istanze docker (tra l’altro in maggioranza rispondente alla medesima versione) in ascolto sulla porta standard per questo meccanismo di accesso. 

Siamo di fronte ad una evidente misconfiguration che consente l’accesso pubblico al demone di gestione dei container docker di tutte queste infrastrutture che abbiamo rilevato, e questo pone due possibili rischi di sicurezza: il primo e più drammatico è la possibilità di ottenere il privilegio amministrativo della macchina che ospita dockerd (mediante alcuni exploit noti che sfruttano capacità amministrative proprie di docker), mentre il secondo è la costruzione di un nuovo container predisposto alle finalità dell’attaccante, in maniera occulta ed efficace. 

Naturalmente la seconda ha un più ampio spettro di applicazioni, in quanto tale sfruttamento punta alla risorsa di calcolo e non all’appropriazione di un sistema. Ed è proprio quello che è osservabile nella campagna che gli analisti hanno chiamato Autom, dal nome di un software che si vede agire all’interno del container durante le fasi di attacco. 

L’attacco segue uno schema ormai ben noto: mediante la comunicazione via rete attraverso la porta 2375 avviano una nuova istanza di immagine alpine:latest (che qualsiasi organizzazione che utilizzi docker autorizzerebbe) da cui eseguono il download di un software denominato autom.sh (da cui il nome dell’attacco) da alcuni server (ormai ben identificati). Per mantenere la persistenza sul container così avviato, creano un nuovo utente con tanto di password e home directory, lo aggiungono alla lista sudoers (consentendo tutto come qualsiasi utente, quindi anche amministrativo) ed infine si assicurano una comunicazione via ssh e protetta da password (per non essere più visti evitano di riutilizzare il canale con porta 2375). Una volta preparato così l’ambiente, l’obiettivo finale degli attaccanti è quella di minare criptovaluta. 

Questa attività parte effettivamente al momento del download di un ulteriore script denominato log_rotate.bin; questo creerà una nuova attività cron ogni 55 minuti, attività capace di minare criptovaluta a favore (ovviamente) degli agenti di minaccia. 

Dal 2019 (data del primo avvistamento di un tale attacco) le tecniche di attacco non sono poi cambiate così tanto (dal punto di vista della procedura applicata), ma sono costantemente migliorate le tecniche di offuscamento rispetto ai sistemi di difesa (principalmente mediante iterazioni su codifica base64), così come sono stati tentati differenti approcci di evasione (disabilitando il firewall di sistema, NMI watchdog, e così via). 

Data la continua evoluzione, il riconoscimento degli aggressori in fase di delivery è sempre cosa ardua, ma certamente è possibile migliorare la difesa operando direttamente sul luogo del misfatto, con analisi dinamica delle immagini dei container (in sandbox) o più semplicemente con un monitoraggio efficace sulle attività operate dal container (uso CPU, download eseguiti, ecc). 

Tweet