1,3 Tbps mitigati dal VAC: l’episodio Memcached

Giovedì 1° marzo, alle 02:00 del mattino circa (GMT+1), il nostro VAC ha mitigato un attacco DDoS che ha colpito uno dei nostri clienti, superando 1,3 Tbps e battendo al contempo il record di 1 Tbps detenuto finora da . Alcune ore prima era stato preso di mira Github con un attacco che aveva toccato 1,3 Tbps, lasciando il sito di Github inaccessibile per alcuni minuti.

Questi attacchi massivi avevano qualcosa in comune: sfruttavano i servizi Memcached mal configurati per lanciare i cosiddetti attacchi di amplificazione. È stata sicuramente una settimana ricca di emozioni e indagini...

Figura 1: attacco di 1,3 Tbps contro uno dei nostri clienti completamente mitigato dal VAC

Memcached: una configurazione di default messa sotto accusa

Memchached è una cache distribuita di tipo key/value store: open source. In genere viene utilizzata per conservare i risultati delle query sul database e ridurre i tempi di caricamento di una pagina web dinamica, migliorandone le performance. Questo strumento è largamente utilizzato dai webmaster e da alcuni editori che scelgono di integrare Memcached alla loro soluzione, come ad esempio la webmail Zimbra. Ma per quale motivo un servizio talmente utilizzato si mette improvvisamente a dare i numeri?

Dal 2017, gli esperti in sicurezza informatica della società cinese 360 hanno identificato la possibilità di utilizzare un difetto di configurazione di Memcached per effettuare attacchi DDoS amplificati. Durante l’installazione, Memcached si mette in ascolto, di default, sull’interfaccia pubblica. In assenza di una configurazione di regole a livello del firewall, Memcached resta quindi accessibile a chiunque su Internet attraverso l’IP pubblico di un server. Se il servizio si mettesse in ascolto soltanto sulla porta TCP, il problema si limiterebbe a una violazione della privacy dei dati, considerando che non vi è nessun metodo di autenticazione. Purtroppo il servizio si mette in ascolto anche su una porta UDP ed è qui che la situazione si complica, poiché diventa possibile effettuare un’amplificazione con un fattore capace di raggiungere i 51000, laddove NTP aveva soltanto un fattore di 557.

Attacco di amplificazione: di cosa si tratta?

L’amplificazione è un fenomeno che mira a generare una risposta più grande della richiesta. Di seguito, la Figura 2 mostra un’amplificazione di fattore 2.

Figura 2: lo schema mostra una risposta due volte più grande di una richiesta (fattore di amplificazione di livello 2)

Per sfruttare la piena potenza di tale fenomeno e impiegarlo durante gli attacchi DDoS, gli attaccanti abbinano il metodo di amplificazione al meccanismo di riflessione. La riflessione consiste nell’utilizzare un indirizzo IP appartenente a terzi affinché la risposta venga inviata all’IP usurpato. Infatti, un server risponderà all’IP sorgente di un pacchetto, anche se forgiato artificialmente. La vittima dell’attacco riceve quindi, senza richiesta alcuna, dei pacchetti dal server.

Figura 3: illustrazione di un meccanismo di riflessione combinato con l’amplificazione

La riflessione costituisce una pratica corrente sull’UDP poiché si tratta di un protocollo in modalità connectionless, e ciò significa che, al contrario del TCP, non vi è alcun meccanismo di three-way handshake. Basta quindi inviare un solo pacchetto per ottenere una risposta, mentre per il TCP è necessario almeno uno scambio di 4 pacchetti tra il client e il server affinché questi stabiliscano una connessione. Se l’IP fosse usurpato, la risposta del server (SYN-ACK) giungerebbe alla vittima dell’attacco e chi ha iniziato la connessione non potrebbe confermarla (ACK), impedendo a quest’ultima di stabilirsi e rendendo dunque inefficace qualsiasi appropriazione dell’IP. Per saperne di più, su Wikipedia trovi informazioni sulla connessione TCP.

Piano d’azione definito da OVH

In seguito a questo anomalo aumento di attacchi di amplificazione che si avvalgono di Memcached, abbiamo rapidamente messo a punto un piano d’azione che ci garantisce di resistere in caso di attacchi molto grossi. L’amplificazione è un vettore molto semplice da identificare. Detto ciò, è necessario assicurarsi che i nostri legami di interconnessione con gli altri operatori (peering) non siano saturi in modo da non perdere in termini di qualità di servizio. Il nostro piano d’azione si è dimostrato immediatamente efficace (come mostra la Figura 1) quando uno dei nostri clienti fu vittima di un attacco superiore a 1,3 Tbps, perfettamente intercettato dal VAC senza interruzione di servizio.

Questo piano era inoltre volto a impedire che i nostri clienti soggetti a una configurazione errata del servizio Memcached si trovassero, loro malgrado, coinvolti in attacchi. Per fare ciò avevamo bisogno di:

• comunicare in maniera mirata con i clienti potenzialmente coinvolti per poterli accompagnare nella configurazione del loro servizio mediante una guida;

• agire immediatamente prima che i nostri clienti correggano il problema, individuando gli indirizzi IP OVH potenzialmente coinvolti senza danneggiare la qualità di servizio.

In seguito a un accordo, abbiamo deciso di non bloccare la porta UDP/11211 (la porta utilizzata da Memcached) sulla nostra rete, in quanto può anche essere utilizzata per iniziare delle comunicazioni in qualità di porta client. Il blocco di questa porta potrebbe avere un’incidenza negativa sulla qualità di servizio, in particolare per quanto riguarda i videogiochi online, il VOIP, lo streaming e altri servizi che utilizzano UDP. Abbiamo anche adottato un approccio diverso, che consiste nel mettere sotto mitigazione permanente gli indirizzi IP riceventi un grandissimo numero di richieste Memcached al secondo e quindi identificati come partecipanti ad attacchi DDoS. Eliminando queste richieste in entrata, abbiamo messo al sicuro il servizio del nostro cliente, impedendo che ne fosse coinvolto.

Le indagini condotte

Il 26 febbraio 2018, i primi attacchi da noi osservati erano stati generati da richieste di tipo gets come mostra la Figura 4. Così come la società Cloudflare, abbiamo constatato che questo comando permetteva di leggere una chiave contenente un file zip, protetto da una password e contenente un file gif.

Figura 4: richieste sulla porta UDP/11211 (Memcached) ricevute nei nostri honeypot il 27/02/2018

Ma perché questo file zip si trovava in queste cache? Abbiamo immediatamente pensato che i servizi presi di mira erano stati preparati prima degli attacchi per venire poi utilizzati, e attualmente stiamo cercando di individuarne la fonte. Al momento sappiamo che il servizio Memcached veniva già utilizzato da diversi giorni per effettuare amplificazioni. I grafici in Figura 5 illustrano la banda che attraversa il server di uno dei nostri clienti, utilizzato il 24 febbraio 2018 per inviare attacchi contro l’IP cinese “59.56.19.xxx” (l’ultimo byte è volutamente omesso).

Figura 5: amplificazione constatata tramite la porta UDP/11211 dal server di uno dei nostri clienti il 24/02/2018 (fuso orario GMT+1)

Ci siamo resi conto che questo indirizzo IP veniva regolarmente attaccato da alcune macchine della nostra rete in maniera molto sincronizzata attraverso il fenomeno di amplificazione (LDAP, NTP, SNMP, ecc...), il quale può avere diverse cause: o l’indirizzo IP ospita un servizio preso di mira, oppure si tratta di un IP che è servito come test nella preparazione di attacchi di amplificazione Memcached.

Da un’analisi più attenta, risulta che gli attacchi contro questo indirizzo IP sono generalmente molto brevi: durano alcune decine di secondi o qualche minuto al massimo, mentre gli altri attacchi si protraggono solitamente per diversi minuti. L’attacco più significativo fino ad ora osservato ha avuto una durata di 3 ore. Molti elementi ci inducono a pensare che questo indirizzo IP sia un dstat, cioè un IP che permette di misurare in tempo reale l’efficacia di un DDoS.

Questo ci permette di prendere in considerazione l’ipotesi che gli amministratori del booter (piattaforma DDoS) hanno probabilmente voluto confrontare i loro diversi attacchi di amplificazione attraverso Memcached. Tra i test che sono stati effettuati tutti nella stessa fascia oraria, osserviamo NTP (UDP/123), LDAP (UDP/389), SSDP (UDP/1900) e BitTorrent.

Continuando le nostre ricerche sui forum specializzati DDoS, abbiamo infine trovato una conversazione del tutto esplicita, come presentato nella Figura 6, in cui un utente riconosce che la propria piattaforma DDoS è la prima ad aver messo a disposizione l’amplificazione Memcached.

Figura 6: un utente annuncia pubblicamente di essere l’autore dello script permettendo di eseguire l’amplificazione Memcached

Evoluzione della minaccia

Nell’arco di una settimana le cose sono radicalmente cambiate: sebbene inizialmente l’idea dell’amplificazione Memcached sembrava provenire da un unico booter, anche altri gestori hanno poi rapidamente implementato questa funzionalità per commercializzarla presso i loro clienti. Fin dai primi casi, i nostri honeypot hanno rivelato numerosissimi metodi per sfruttare i servizi Memcached disponibili su Internet, come rappresenta la Figura 7.

Figura 7: ripartizione dei comandi Memchached ricevuti sui nostri honeypot

Su certi servizi, il file zip contenuto nella chiave “a” lascia adesso spazio a una catena “abcdefghij” che si ripete migliaia di volte senza che si noti alcun tentativo di scrittura:

Figura 8: esempio di Memcached con una chiave “a” contenente una parte delle lettere dell’alfabeto ripetuta molte volte

Abbiamo inoltre notato certe chiavi contenenti dei messaggi che chiedevano di pagare 50 XMR, una nota criptovaluta conosciuta anche con il nome di Monéro. Sarà forse un tentativo di riscatto sui database che immagazzinano soltanto dati temporanei? Oppure un metodo per riempire la cache in modo da aumentare il fattore di amplificazione?

Figura 9: chiave “a” di un servizio Memcached contenente un messaggio in cui si chiede di pagare 50 XMR

Se un numero ridotto di servizi Memcached aperti è stato prontamente corretto, ne rimangono ancora tanti che possono essere utilizzati per compiere attacchi. Come il protocollo NTP, sembrerebbe che la minaccia di Memcached sia cominciata per durare nel tempo. Anche se le protezioni messe a punto dai provider hosting hanno drasticamente ridotto il volume degli attacchi, la maggior parte di questi è attualmente inferiore ai 100 Gbps e la correzione della configurazione da parte degli utenti resta comunque la chiave. Tuttavia il caso NTP ci ha mostrato che, perfino 5 anni dopo, alcuni server sono ancora vulnerabili nonostante gli interventi correttivi disponibili.
Pertanto, dopo aver letto questo articolo, verifica lo stato del tuo firewall e i servizi che esponi su Internet.