Un attacco automatizzato silente prende di mira server Redis non protetti

Un attacco automatizzato sta circolando attivamente, prendendo di mira server Redis non protetti, compromettendo le macchine sottostanti e lasciando dietro di sé una traccia quasi impercettibile. Questo attacco, scoperto di recente mentre prendeva di mira un singolo Redis honeypot, è stato orchestrato da 10 diversi indirizzi IP provenienti da sei paesi, con oltre 1.200 tentativi di attacco registrati in un solo mese.

La particolarità di questo attacco risiede nella sua capacità di ripristinare tutto esattamente come lo ha trovato. Dopo aver compromesso il server, l'attaccante ripristina il nome del file del database, elimina gli strumenti utilizzati e chiude le connessioni aperte. Al termine dell'attacco, il server sembra sano e i log appaiono normali. Tuttavia, un'analisi più approfondita rivela una nuova riga in /root/.ssh/authorizedkeys che non era presente prima.

L'anatomia dell'attacco

Redis, un sistema di memorizzazione nella cache in memoria, non è stato progettato per essere esposto direttamente a Internet. Tuttavia, configurazioni errate, gruppi di sicurezza mal configurati o la necessità di sviluppatori di renderlo raggiungibile per test rapidi possono esporre il servizio. La configurazione predefinita non ha password e la porta 6379 può essere aperta al mondo.

Quando il nostro honeypot Redis è stato esposto, i primi visitatori sono arrivati in pochi minuti. Questi bot si sono connessi, hanno eseguito il comando INFO per leggere la stringa di versione e si sono disconnessi. Non stavano tentando di violare il server, ma stavano catalogando cosa fosse disponibile e come fosse protetto. Migliaia di queste scansioni avvengono ogni giorno su Internet, silenziose e meccaniche.

La fase di esplorazione

Una seconda ondata di bot ha tentato un comando specifico: config set dbfilename backup.db. Questo comando è un test per verificare se il server Redis permetta di scrivere file su percorsi arbitrari del disco della macchina ospite. I bot non sfruttano questa vulnerabilità, ma registrano l'indirizzo e lasciano la scena, costruendo un elenco di potenziali obiettivi per attacchi successivi.

L'attacco vero e proprio

L'attacco vero e proprio è arrivato come una singola connessione che ha tentato cinque diversi metodi di compromissione in rapida sequenza. Il tutto è durato pochi secondi. L'attacco ha iniziato con il comando FLUSHDB per cancellare il database e ha poi proceduto con i seguenti trucchi:

  • Iniezione cron: reindirizza la directory di salvataggio di Redis a /var/spool/cron/, scrive una chiave il cui valore è una voce cron. Ora l'host scarica ed esegue un binario da un server C2 ogni minuto, con un nome di file generato casualmente per evitare la rilevazione delle firme.
  • Fuga dalla sandbox Lua: una decisione di packaging Debian/Ubuntu ha collegato dinamicamente l'interprete Lua di Redis alla libreria di sistema, rompendo la sandbox. Un comando EVAL carica io.popen, portando a un completo RCE. La CVE-2022-0543 ha quattro anni, ma funziona ancora.
  • Piantagione di chiavi SSH: lo stesso trucco di scrittura di file, puntato a /root/.ssh/authorizedkeys. Una riga, e l'operatore ha accesso root per sempre.
  • Hijacking della replicazione: il comando SLAVEOF dice a Redis di sincronizzarsi dal server dell'attaccante, che serve un oggetto condiviso malizioso mascherato da dump del database. MODULE LOAD lo trasforma in un'estensione Redis che espone system.exec. Questo trucco porta a un completo RCE attraverso il protocollo di replicazione di Redis.
  • Esecuzione diretta: utilizza quel modulo per scaricare ed eseguire il binario tramite la shell.

Cinque metodi, una connessione, pochi secondi. Tuttavia, gli attaccanti non hanno bisogno che tutti e cinque i metodi funzionino. Gli basta che uno solo abbia successo.

La pulizia post-violazione

Dopo aver eseguito i suoi comandi, il bot ha iniziato a pulire le tracce. Ha disconnesso il server di replicazione, eliminato la libreria condivisa maliziosa dal disco, scaricato il modulo da Redis e ripristinato il nome del file del database originale. Poiché Redis è spesso utilizzato per dati effimeri come sessioni, code e limiti di velocità, un database cancellato potrebbe non destare allarme. Semplicemente, sembra un riavvio.

L'attacco è ottimizzato per rimanere nascosto dopo la violazione. Ogni traccia forense è invertita. L'unica artifact lasciata dietro è una chiave SSH pubblica, una riga in un file che la maggior parte degli amministratori non legge mai, indistinguibile da una voce legittima. Anche se si trova il malware, si uccide il processo e si elimina la voce cron, la chiave è ancora presente. Accesso root, su richiesta, per sempre. O fino a quando qualcuno non audita manualmente authorizedkeys, cosa che è rara.

Le botnet coinvolte

L'operatore della chiave SSH: Un attacco sofisticato a singolo operatore che prende di mira server Redis non protetti. Tenta cinque diversi metodi di RCE. Nel corso di un singolo mese, il nostro singolo Redis honeypot ha registrato oltre 1.200 tentativi di attacco da 10 diversi indirizzi IP provenienti da sei paesi. La maggior parte includeva tentativi di RCE: sfruttamento del sandbox Lua e hijacking della replicazione mirati all'esecuzione arbitraria di comandi sull'host. Diversi server C2, diversi nomi di binari, ma la stessa sequenza, lo stesso payload Lua, la stessa chiave SSH pubblica. Un singolo operatore, con fonti in rotazione e nomi di file randomizzati. La chiave è l'unica costante.

Il traffico è arrivato in onde distinte. Il livello di base era di circa 15 a 20 tentativi al giorno da due o tre fonti. Poi, senza preavviso, un'onda colpiva, con un singolo IP che si connetteva centinaia di volte in un pomeriggio, una volta ogni 69 secondi. In totale, oltre 300 tentativi in poche ore. Abbiamo visto tre o quattro onde al mese, ciascuna durata da due a sei ore, ciascuna da una diversa IP sorgente. Poi silenzio fino alla prossima onda.

La botnet MGLNDD

Una operazione separata che si connette periodicamente a server Redis esposti, inviando un singolo comando di formato (MGLNDD54.147.241.42_6379) per eseguire una sorta di "appello" - verificando se il server Redis fa già parte della loro botnet. Opera da VM Azure utilizzando indirizzi IP AWS, senza mai ripetere la stessa sorgente due volte.

L'operatore della chiave SSH e la botnet MGLNDD condividono lo stesso territorio di caccia ma si ignorano completamente a vicenda. Due operazioni separate stanno lavorando nello stesso territorio. Un port Redis esposto non è semplicemente preso di mira da un attaccante, ma da un intero ecosistema.

Le implicazioni per la sicurezza

Questo attacco è silente. La finestra tra "Lo configurerò più tardi" e la macchina silente compromessa non è di giorni o ore, ma di secondi. Dopo l'attacco, tutto sembra funzionare normalmente: il server è in linea, l'applicazione funziona, i dashboard sono verdi. L'unica traccia è una chiave SSH, paziente e persistente, in attesa di essere utilizzata.

L'ecosistema delle minacce a Redis

La scoperta di queste campagne di attacco rivela un ecosistema complesso di minacce che prendono di mira i server Redis esposti. Oltre all'operatore della chiave SSH e alla botnet MGLNDD, esistono altre entità malintenzionate che operano nello stesso spazio. Questo indica una tendenza preoccupante: i server Redis non protetti sono diventati un obiettivo primario per più gruppi criminali, ciascuno con le proprie tecniche e obiettivi.

Il ciclo di vita di un attacco

L'analisi di queste campagne mostra un ciclo di vita tipico degli attacchi a Redis. Inizia con una fase di ricognizione, durante la quale i bot scansionano Internet alla ricerca di istanze Redis vulnerabili. Questa fase è seguita da tentativi di sfruttamento, che possono includere più metodi di compromissione contemporaneamente. Infine, gli attaccanti cercano di mantenere l'accesso il più a lungo possibile, spesso attraverso l'impianto di chiavi SSH.

L'evoluzione delle tecniche di attacco

Le tecniche osservate indicano un'evoluzione delle capacità degli attaccanti. L'uso di più metodi di compromissione contemporaneamente suggerisce che gli attaccanti stanno diventando più sofisticati e stanno adattando le loro tattiche in base alle difese che incontrano. Inoltre, l'uso di infrastrutture cloud come AWS e Azure per nascondere le origini degli attacchi dimostra un livello crescente di professionalità.

Le implicazioni per gli amministratori di sistema

Per gli amministratori di sistema, queste scoperte sottolineano l'importanza di proteggere adeguatamente i server Redis. Misure come la protezione delle porte, l'uso di password forti e la configurazione corretta dei gruppi di sicurezza possono fare una differenza significativa. Inoltre, è cruciale monitorare attentamente i server Redis per rilevare eventuali attività sospette e rispondere rapidamente a eventuali compromissioni.

Le implicazioni per gli sviluppatori

Per gli sviluppatori, queste scoperte sottolineano l'importanza di seguire le best practice di sicurezza quando si lavora con Redis. Questo include l'uso di client Redis sicuri, la protezione delle credenziali e la limitazione delle autorizzazioni. Inoltre, gli sviluppatori dovrebbero essere consapevoli dei rischi associati all'esposizione di Redis a Internet e dovrebbero prendere le necessarie precauzioni per mitigare questi rischi.

Le implicazioni per le organizzazioni

Per le organizzazioni, queste scoperte sottolineano l'importanza di avere una strategia di sicurezza complessiva che includa la protezione dei server Redis. Questo può includere la formazione dei dipendenti, l'implementazione di politiche di sicurezza rigorose e l'investimento in strumenti di sicurezza avanzati. Inoltre, le organizzazioni dovrebbero essere consapevoli del fatto che i server Redis non protetti possono essere utilizzati come punto di ingresso per attacchi più ampi e dovrebbero prendere le necessarie precauioni per prevenire tali scenari.

Le implicazioni per la comunità della sicurezza

Per la comunità della sicurezza, queste scoperte sottolineano l'importanza di collaborare per contrastare le minacce a Redis. Questo può includere la condivisione di informazioni sulle campagne di attacco, lo sviluppo di strumenti di sicurezza avanzati e la promozione di best practice di sicurezza. Inoltre, la comunità della sicurezza dovrebbe essere consapevole del fatto che i server Redis non protetti possono essere utilizzati come punto di ingresso per attacchi più ampi e dovrebbe lavorare per prevenire tali scenari.

Le implicazioni per il futuro

Queste scoperte suggeriscono che gli attacchi a Redis sono destinati a diventare più comuni e sofisticati. Gli amministratori di sistema, gli sviluppatori e le organizzazioni devono essere proattivi nella protezione dei loro server Redis e nella risposta alle minacce. La comunità della sicurezza deve continuare a collaborare per contrastare queste minacce e promuovere best practice di sicurezza. Solo attraverso un approccio collaborativo e proattivo possiamo sperare di mantenere al sicuro i nostri sistemi e dati.

Risorse per ulteriori informazioni

Per ulteriori informazioni su come proteggere i server Redis, gli amministratori di sistema possono consultare la documentazione ufficiale di Redis e le linee guida di sicurezza. Gli sviluppatori possono trovare utili risorse come il progetto GitHub ThalesGroup/dd-honeypot, che fornisce strumenti per il rilevamento e l'analisi delle attività sospette. La comunità della sicurezza può trovare utili risorse come il database CVE, che fornisce informazioni su vulnerabilità note.

Nota Editoriale e Disclaimer

Le guide e i contenuti pubblicati su GoYou sono frutto di attività di ricerca e analisi indipendente, a scopo informativo, educativo e di approfondimento.

GoYou non costituisce una testata giornalistica né un prodotto editoriale ai sensi della Legge n. 62/2001 e non svolge attività di informazione in tempo reale.

Il progetto GoYou non fornisce consulenza professionale, tecnica, legale o finanziaria e declina ogni responsabilità per l’uso improprio delle informazioni pubblicate.

Nel settore Crypto, ogni investimento comporta rischi: si invita il lettore a informarsi sempre in modo autonomo prima di assumere qualsiasi decisione.