Justin Fier, Director of Cyber Analysis di Darktrace, pone l’accento sull’ascesa delle botnet IoT; anche i più semplici device diventano parte di un attacco complesso.
All’inizio di quest’anno, Darktrace ha rilevato una nuova botnet sfruttata per un attacco di tipo reflection e amplification su vasta scala contro alcune organizzazioni a livello mondiale, compresi diversi organismi governativi. Anche se già analizzata nel nostro 2017 Threat Report, questa tipologia di attacco è più pertinente che mai alla luce di nuovi hacks più estesi e sofisticati ai dispositivi IoT. È il caso della Botnet Reaper, identificata il mese scorso, che sicuramente farà parlare ancora di sé il prossimo anno.
Questa nuova tipologia di botnet non stava utilizzando computer desktop per sostenere l’attacco,come faceva Srizbi quando inviava 60 miliardi di mail di spam al giorno. In più, stava impiegando tecniche ben distinte anche da quelle di Mirai, che utilizzava DRV e router per generare attacchi DNS DDoS con velocità fino a 1Tbps. Invece, questa botnet stava controllando una grande varietà di dispositivi IoT, persino i pad da disegno. Anche se, complessivamente, i dispositivi coinvolti erano meno rispetto ad altre botnet, attraverso attacchi reflection e amplification usando SNMP, Reaper stava tentando di lanciare un potente attacco denial-of-service.
Tutto è iniziato in modo familiare; uno studio di architettura ha introdotto una funzionalità aggiuntiva di smart drawing nei propri network pad senza avvisare il team IT, e i loro controlli di sicurezza interni non hanno avuto modo di identificare i dispositivi vulnerabili. Come tale, le credenziali dell’utente di questi dispositivi non sono mai state modificate rispetto a quelle preimpostate di fabbrica. Credenziali che quindi, insieme alla loro stringa pubblica per l’autenticazione SNMP, erano disponibili al pubblico su Shodan, che mostrava anche come i dispositivi avessero delle porte aperte per HTTP, HTTPS, Telnet e SIP.
Darktrace ha rilevato la vulnerabilità quando centinaia di indirizzi IP esterni da tutto il mondo hanno iniziato ad effettuare migliaia di connessioni SNMP ai dispositivi usando la porta UDP 161. Oltre il 99 per cento di queste connessioni conteneva almeno una “GetBulkRequest”, un’operazione SNMP utilizzata per il recupero di grandi quantità di dati. In risposta a queste richieste, i dispositivi hanno emesso un numero esponenzialmente maggiore di messaggi “GetResponse”, alcuni dei quali contenevano fino a 397.000 oggetti “GetResponse”. In 64 casi, i dispositivi caricavano oltre 1 MB di dati.
La normale attività di rete di questi dispositivi comportava l’uso occasionale di “GetBulkRequests” e “GetResponses”. Pertanto, questi picchi di attività sono stati considerati altamente anomali dagli algoritmi AI di Darktrace, i quali avevano ormai una profonda comprensione dei comportamenti abituali dei dispositivi. La minaccia è stata rilevata in tempo reale e il team di sicurezza dell’azienda l’ha potuta identificare fin dalle fasi iniziali, durante le quali la visibilità sulla rete di Darktrace ha fornito analisi dettagliate sull’incidente.
L’uso di SNMP versione 2c e “GetBulkRequests” sono segnali rivelatori di un attacco di tipo reflection and amplification, che utilizza risorse minime per generare attacchi di grandi dimensioni. Alla fine, 273.2 MiB di dati avevano lasciato i dispositivi sfruttando la porta 161. I trasferimenti di dati esterni sulla porta 80 indicavano che l’attacco stava andando oltre, e numerosi dispositivi esterni stavano tentando di accedere alle risorse HTTP dei dispositivi, molte delle quali erano file PHP amministrativi.
A seguire trovate un esempio delle risorse alle quali i dispositivi esterni stavano tentando di accedere tramite HTTP: /phpMyAdmin-2.11.1.0/scripts/setup.php /a_remotecontrol.htm /phpMyAdmin-3.1.2.0-all-languages/scripts/setup.php /mysqladmin/scripts.setup.php
Infine, Shodan ha anche rivelato che i dispositivi stavano eseguendo un server SIP accessibile sulla porta 5060. L’analisi dei pacchetti ha mostrato che i dispositivi esterni “dialogavano” con gli altri dispositivi e tentavano di effettuare chiamate VoIP – un comportamento anomalo dell’attaccante che rimane, al momento, inspiegabile.
Gli indirizzi IP di destinazione sono stati probabilmente falsificati. L’invio di centinaia di “GetBulkRequests” dagli IP falsificati delle reti target ha costretto i pad da disegno a rimandare un numero oltre 100 volte superiore di “GetResponses”. Gli IP target appartenevano a siti internet gestiti da società di intrattenimento e design, e persino da enti governativi.
Segnalando le richieste anomale di SNMP non appena sono iniziate, il team di sicurezza dell’azienda è stato in grado di scollegare dalla rete i pad grafici prima che il danno diventasse irreparabile. Se gli attaccanti fossero riusciti a sabotare le reti, l’azienda avrebbe potuto essere soggetta ad azioni legali. A seguito dell’accaduto, l’azienda ha rivisto le proprie policy di sicurezza facendo passi da gigante per proteggere tutti i dispositivi IoT sulla propria rete e ridurre al minimo il rischio di incidenti futuri. Questo esempio testimonia la potenza degli attacchi di tipo reflection and amplification. Non è chiaro quanti e quali altri dispositivi siano stati utilizzati in questo attacco, ma è interessante notare che un numero esiguo di dispositivi IoT in uno studio di architettura abbiano generato una quantità allarmante di traffico.
Visto l’aumento della diffusione dei device IoT, che in molti casi sono distribuiti con preimpostazioni non sicure, l’utilizzo di questa tipologia di botnet è destinato ad aumentare, rendendo la capacità di identificare e rispondere in tempo reale a queste minacce un elemento sempre più fondamentale per le aziende.
Tutto è iniziato in modo familiare; uno studio di architettura ha introdotto una funzionalità aggiuntiva di smart drawing nei propri network pad senza avvisare il team IT, e i loro controlli di sicurezza interni non hanno avuto modo di identificare i dispositivi vulnerabili. Come tale, le credenziali dell’utente di questi dispositivi non sono mai state modificate rispetto a quelle preimpostate di fabbrica. Credenziali che quindi, insieme alla loro stringa pubblica per l’autenticazione SNMP, erano disponibili al pubblico su Shodan, che mostrava anche come i dispositivi avessero delle porte aperte per HTTP, HTTPS, Telnet e SIP.
