Radware , operativa nel campo della sicurezza informatica, ha individuato un nuovo bot, denominato BrickerBot , il cui scopo è quello di interrompere permanentemente il funzionamento dei dispositivi IoT vulnerabili, al fine di negare a malintenzionati la possibilità di condurre attacchi DDoS .
L’azione malevola del bot si è svolta in quattro ondate di attacchi: a partire dal 30 marzo le honeypot di Radware hanno intercettato 1895 tentativi di attacco in quattro giorni , da parte di Brickerbot.1 . Questi attacchi provenivano da dispositivi Ubiquiti dei quali è stato compromesso il demone Dropbear SSH . Una successiva versione del malware, nota come Brickerbot.2 , ha condotto poi un’ulteriore serie di attacchi provenienti, questa volta, dalla rete TOR. I ricercatori di Radware ne hanno poi individuato una terza versione ( Brickerbot.3 ), e una quarta ( Brickerbot.4 ), che hanno effettuato rispettivamente 1118 e 90 tentativi di attacco sfruttando ancora una volta il software Dropbear .
Allo stesso modo di Linux.wifatch BrickerBot scansiona la rete alla ricerca di router Linux e dispositivi IoT con il servizio Telnet attivo autenticato tramite credenziali predefinite e note . Si tratta dello stesso meccanismo utilizzato anche da Mirai , botnet IoT già nota come responsabile degli attacchi verso il provider Dyn.com che hanno compromesso la disponibilità dell’intera Rete lo scorso ottobre.
Tuttavia, mentre il comportamento di Linux.wifatch era quello di mettere in sicurezza il dispositivo vulnerabile, questo nuovo “malware vigilante” ne effettua il brick, danneggiando il firmware in modo permanente.
Si tratta dunque di un attacco PDoS (Permanent Denial-of-Service) che si articola nelle seguenti fasi, ampiamente documentate nelle note di sicurezza rilasciate da Radware:
1. Scrittura di dati casuali sulla memoria flash o a stato solido, con l’obiettivo di danneggiarla
2. Disabilitazione dei timestamp TCP
3. Impostazione del numero massimo di thread del kernel a 1
4. Rimozione del default gateway
5. Azzeramento delle regole di filtraggio e NAT sul firewall
6. Aggiunta di una regola per scartare i pacchetti in uscita
7. Cancellazione dei file di sistema
8. Riavvio del dispositivo
Inoltre il bot si avvale di circa 86 payload per la compromissione di device e protocolli specifici .
La redazione di Bleeping Computer ha approfondito la vicenda rintracciando il probabile autore del bot, presente su Hack Forums dallo scorso gennaio con il nickname janit0r .
Dalla email inviata da quest’ultimo si evincono le reali ragioni dell’attacco: l’obiettivo di janit0r è quello di sensibilizzare l’industria IoT al fine di ottenere un cambiamento radicale negli standard di sicurezza relativi a questo settore.
Un fine puramente etico, quindi, stimolato sia dalla volontà di impedire a malintenzionati di costruire botnet IoT (come quella che ha portato al già citato “venerdì nero di Internet”) che dal desiderio di punire direttamente i produttori arrecando loro un danno diretto. Ciò che fa discutere la comunità è l’approccio: come è stato fatto notare da Victor Gevers , ricercatore noto per aver contrastato i ransomware che prendevano di mira MongoDB , ci sono modalità di contrasto meno drastiche della distruzione di apparati altrui.
L’impatto di questo attacco, devastante quanto imprevedibile, può essere infatti molto più grave di quanto ci si aspetti: nel caso delle telecamere Sricam AP003, ad esempio, non è stato possibile rimettere in funzione il dispositivo neppure a seguito di un ripristino alle condizioni di fabbrica.
Lo stesso CERT Nazionale ne descrive la potenziale gravità in una nota , suggerendo agli utenti di disabilitare l’accesso Telnet e di modificare sempre le credenziali predefinite .
Patrizio Tufarolo
Ti potrebbe interessare
2 mag 2017