Quello che è stato etichettato il più grande attacco DDoS mai svelato si è abbattuto contro i server del sito di sviluppo software GitHub alle 17:21 UTC dello scorso mercoledì.
Gli attacchi DDoS di grandi dimensioni sono ormai eventi occasionali negli ultimi anni, ma le statistiche su quest’ultimo erano memorabili, raggiungendo un picco di 1350 gigabit al secondo con un follow-up che raggiungeva i 400 gigabit al secondo.
L’attacco record precedente era sul provider DNS Dyn nel 2016, il cui picco stimato di 1000 gigabit al secondo ha causato un’interruzione a servizi come Netflix, Twitter e, curiosamente, GitHub.
Secondo GitHub Engineering, l’interruzione della scorsa settimana è durata nove minuti.
Alle 17:21 UTC il nostro sistema di monitoraggio della rete ha rilevato un’anomalia nel rapporto tra il traffico in ingresso e in uscita e ha informato l’ingegnere reperibile e altri nel nostro sistema di chat. … Considerato l’aumento della larghezza di banda del traffico in entrata a oltre 100 Gbps in una delle nostre strutture, è stata presa la decisione di trasferire il traffico ad Akamai.
Buone notizie: la difesa di mitigazione DDoS ha funzionato come previsto, ma il tema interessante dell’attacco si è rivelato non essere affatto le sue dimensioni, ma ciò che ha alimentato il suo straordinario volume.
L’attacco ha sfruttato l’amplificazione, una tecnica che abbiamo visto prima in precedenti mega incidenti DDoS, questa volta colpendo un bersaglio chiamato Memcached.
Memcached è una tecnologia popolare progettata per accelerare l’accesso ai siti che eseguono grandi database di applicazioni Web registrando i dati nella RAM per un accesso rapido.
Per impostazione predefinita, consente connessioni esterne non autenticate sulla porta UDP 11211, il che significa che gli aggressori sono stati in grado di generare grandi quantità di traffico semplicemente inviando a server lasciati in questo debole stato un semplice comando “stats” da un indirizzo IP falsificato.
Le risposte delle statistiche Memcached risultano enormi, ha dichiarato GitHub:
Il fattore di amplificazione è fino a 51.000, il che significa che per ogni byte inviato dall’attaccante, vengono spediti fino a 51 KB verso il bersaglio.
Ciò è paragonabile a precedenti attacchi di amplificazione come l’assalto al DNS del 2013 alla Spamhaus, che ha aumentato le risposte da 50 a 300 gigabit al secondo.
Un anno dopo è stato il turno del protocollo NTP con un attacco da 400 gigabit al secondo alla società di hosting OVH francese che ha sfruttato un tasso di amplificazione di 500 volte.
Le compagnie di mitigazione sembrano aver sospettato che si stesse preparando qualcosa di spiacevole, il che potrebbe spiegare perché la divisione Prolexic di Akamai ha potuto intervenire così rapidamente.
Fortunatamente, non è così difficile smettere di utilizzare i firewall perimetrali per bloccare la l’UDP sulla porta denominata o disabilitare completamente l’UDP su un server Memcached.
Eppure, come per i precedenti attacchi di amplificazione, il problema di fondo è ancora una volta un’infrastruttura scarsamente protetta – le stime del numero di server Memcached vulnerabili ammontano a circa 100.000, quasi tutte negli Stati Uniti e in Cina.
Akamai ha avvertito:
Akamai ha assistito ad un notevole aumento nella scansione di server Memcached aperti sin dalla divulgazione iniziale.
E:
A causa delle capacità di riflesso di Memcached, è altamente probabile che questo attacco record non resti a lungo il più grave.
Qualcuno dovrà ora persuadere i proprietari di tutti quei server Memcached vulnerabili a chiudere tali punti deboli o rischieranno l’intervento dei grandi ISP.
Forse questa volta gli aggressori stavano testando qualcosa di nuovo. È stato anche suggerito che si trattasse di un attacco ransom perché sembrava esserci una richiesta incorporata di moneta virtuale Monero.
La nostra speranza speranza è che la velocità con cui è stato represso l’attacco dissuaderà i cattivi dal dare seguito.