Allarme sicurezza: Dero trasforma i container Docker in miniere di criptovalute

La recente campagna di cryptojacking che sfrutta il miner DERO rappresenta un’evoluzione sofisticata delle minacce informatiche rivolte agli ambienti Kubernetes mal configurati.

Ecco cosa si è scoperto.

Vettore di accesso iniziale: API Kubernetes esposte

Gli attaccanti individuano cluster Kubernetes con l’autenticazione anonima abilitata (--anonymous-auth=true), una configurazione che, se non gestita correttamente, può concedere accessi non autorizzati.

In alcuni casi, l’uso improprio di comandi come kubectl proxy può esporre l’API Kubernetes, bypassando i meccanismi di autenticazione standard.

Distribuzione del miner: mascheramento e persistenza

Una volta ottenuto l’accesso, gli attaccanti distribuiscono un DaemonSet denominato “proxy-api”, che implementa un pod maligno su ogni nodo del cluster. Questo approccio consente di sfruttare simultaneamente le risorse computazionali di tutti i nodi per il mining della criptovaluta DERO.

Il container utilizzato è basato su un’immagine Docker modificata di CentOS 7, contenente due file principali:

• entrypoint.sh: uno script che avvia il processo di mining.
• pause: il binario del miner DERO, denominato in modo da imitare il container “pause” legittimo utilizzato da Kubernetes per mantenere attivi i pod.

Il binario del miner è offuscato utilizzando UPX e contiene indirizzi di wallet e URL dei pool di mining hardcoded, consentendo l’esecuzione senza parametri di linea di comando, riducendo così la probabilità di rilevamento da parte dei sistemi di sicurezza.

Tecniche di evasione e persistenza

Per eludere i controlli di sicurezza, gli attaccanti impiegano diverse strategie:

• Mascheramento dei nomi: utilizzano nomi di container e DaemonSet che imitano componenti legittimi di Kubernetes, come k8s-device-plugin e pytorch-container, per confondere le analisi manuali e automatizzate.
• Offuscamento del binario: l’uso di UPX rende più difficile l’analisi statica del miner.
• Configurazioni hardcoded: inserendo direttamente nel codice gli indirizzi dei wallet e dei pool di mining, evitano l’uso di parametri esterni facilmente monitorabili.
• Registrazione di domini innocui: per mascherare le comunicazioni con i pool di mining, registrano domini con nomi apparentemente legittimi, come windowsupdatesupport[.]link, che in passato sono stati associati a indirizzi IP di pool DERO noti (wiz.io).

Conflitti tra attori malevoli

In alcuni casi, altri gruppi di attaccanti hanno tentato di prendere il controllo dei cluster già compromessi, rimuovendo i DaemonSet esistenti e implementando i propri miner, come XMRig per il mining di Monero.

Questi attacchi successivi spesso impiegano tecniche più aggressive, come l’uso di pod privilegiati e l’accesso diretto all’host, aumentando il rischio per l’infrastruttura compromessa.

Raccomandazioni per la difesa e mitigazione

Per proteggere le infrastrutture Kubernetes da tali minacce, si consiglia di:

1. Disabilitare l’accesso anonimo: verificare e, se possibile, disabilitare l’autenticazione anonima sull’API Kubernetes.
2. Limitare l’esposizione dell’API: evitare di esporre l’API Kubernetes a Internet pubblicamente; utilizzare VPN o altri metodi sicuri per l’accesso remoto.
3. Monitorare le immagini Docker: utilizzare solo immagini da registri affidabili e monitorare le immagini in uso per rilevare eventuali modifiche sospette.
4. Implementare controlli di sicurezza: utilizzare strumenti di sicurezza che analizzano il comportamento dei container e dei pod, rilevando attività anomale come l’uso eccessivo di risorse o la comunicazione con domini sospetti.
5. Audit e logging: mantenere registri dettagliati delle attività del cluster e analizzarli regolarmente per individuare comportamenti anomali.

Questa campagna di cryptojacking evidenzia la necessità di una configurazione attenta e di un monitoraggio continuo degli ambienti Kubernetes.

La combinazione di tecniche di evasione sofisticate e l’uso di infrastrutture legittime per scopi malevoli rende queste minacce particolarmente insidiose.

Adottare misure preventive e mantenere una postura di sicurezza proattiva è essenziale per proteggere le risorse cloud-native da attacchi simili.