Aethra Botnet
Che cosa hanno in comune un vecchio file di log, WordPress, una “manciata” di router e degli ISP italiani?
All’apparenza nulla ma lasciatemi spiegare tutto dall’inizio e vedrete come, partendo da un evento poco significativo si possano scoprire elementi quantomeno interessanti.
You can read this article in English here.
Venerdì 13 Febbraio 2015: stavo effettuando ordinaria manutenzione sul mio sito personale quando analizzando le statistiche e I log mi accorsi di un pattern ricorrente e quantomeno “strano”:
Chiunque abbia mai gestito un sito WordPress può riconoscere in questo estratto di log, il classico comportamento di una botnet che sta eseguendo un attacco bruteforce contro l’interfaccia amministrativa del sito. In questo caso, la botnet, tentava solo combinazioni di password per l’username ‘admin’.
Generalmente mi sarei limitato a bloccare gli indirizzi IP inserendoli nella black-list del WAF (Web Application Firewall) risolvendo il problema.
In questo caso però, un dettaglio ha attirato la mia attenzione: tutti gli IP coinvolti nell’attacco (migliaia) provenivano da range simili.
Una volta risolti gli IP ho fatto un ulteriore scoperta,tutti gli ISP coinvolti erano Italiani (salvo due eccezioni) e nello specifico si trattava di:
- Fastweb
- Albacom, ora BT-Italia
- Clouditalia
- Qcom
- WIND
- BSI Assurance UK
Continuando a seguire il “filo rosso”, sono giunto al dettaglio che legava tutti gli IP coinvolti, i device erano tutti modem/router Aethra (BG1242W, BG8542W ecc).
Benissimo o forse no, tutti i device coinvolti nell’attacco utilizzavano (e tuttora utilizzano) le credenziali di default (blank:blank).
Non è possibile determinare agevolmente se gli attacchi provengono direttamente dai device o dai PC ad essi connessi, ma è presumibile pensare che siano coinvolti direttamente i router.
Un piccolo appunto, dall’interfaccia web è possibile sapere con esattezza tutti i dispositivi connessi, gli IP per cui il device sta NATtando e le varie configurazioni.
L’interfaccia è vulnerabile a varie reflected XSS – per esempio nel campo username del form di login, nel campo source host di ping, mtrace ecc ecc -a HTML5 cross-origin resource sharing (seppur in parte mitigato) e a CSRF.
GET /cgi-bin/AmiWeb?path=/&operation=login&username=%3Cscript%3Ealert%28%27vsec%27%29%3B%3C/script%3E&password=&transaction=vnFS4Ztv_3@ HTTP/1.1 Host: 93.61. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 X-Requested-With: XMLHttpRequest Connection: keep-alive
Arrivato a questo punto ho deciso di capire la portata della botnet e ricorrendo a Shodan ho estratto ulteriori informazioni:
Esistono parecchi dispositivi Aethra sparsi in tutto il mondo (~12000), di cui ben 10866 localizzati in Italia; filtrando per tipologia sono circa 8000 dispositivi Aethra Telecommunications PBX, il dispositivo coinvolto in questo specifico attacco.
I dispositivi Aethra (che comprendono ben 104 modelli spaziando da SIP/2.0 a Aethra Videoconference VegaX3_Series_4 System) coinvolgono 254 provider unici in giro per il mondo in cinquanta nazioni diverse.
Questi i dati più rilevanti:
I modem presi in considerazione sono venduti quasi esclusivamente per contratti Business, quindi grazie alla ricerca WHOIS, si può mettere in relazione il dispositivo vulnerabile e l’organizzazione che ne è in possesso. Il che potrebbe facilitare attacchi mirati nel confronto di queste specifiche aziende.
Dalle stime iniziali abbiamo potuto identificare che il 70% dei dispositivi risulta vulnerabile (password di default), pertanto stimando 8400 dispositivi con contratti business (ADSL 1Mbps upload / fibra ottica 10Mbps) hanno un output power massimo compreso tra 8400 Mbps e 84000 Mbps, circa 1-10 Gigabyte al secondo, utilizzabile per attacchi DDoS.
Tutto questo prima che l’11 Dicembre 2015 Fastweb fosse messa al corrente della problematica, successivamente abbiamo instaurato un bel rapporto tra Bug Hunter e Vendor che ha permesso all’ISP di patchare e risolvere la problematica in soli 7 giorni lavorativi e di aggiornare le statistiche per quanto riguarda l’esposizione e il totale dei dispositivi presenti.
Risulta infatti che le nostre stime iniziali, (effettuate utilizzando solo Shodan) fossero riduttive ed in parte errate;
Fastweb conta circa 40000 dispositivi, ma di questi, soltanto il 4% possedeva credenziali di default, con output power compreso tra 1.7 e 17 Gbps (secondo una copertura media in fibra).
Well done Fastweb.
Ora il problema rimangono tutti i dispositivi BT Italia poiché compongono la nostra statistica iniziale che pare rimasta immutata e i dispositivi ancora vulnerabili.
Vorrei divagare un attimo e prevenire una domanda che altrimenti mi verrebbe posta in seguito: “Come mai ne parli solo ora?”
Dalla nascita del progetto VoidSec promuoviamo la responsible disclosure come metodo predefinito per la pubblicazione delle vulnerabilità. La responsible disclosure permette di minimizzare il rischio concreto per gli utenti finali, dando il tempo ai reparti dedicati di mitigare le vulnerabilità. Non apprezzo le full disclosure e ove possibile mi piacerebbe agire responsabilmente, secondo le nostre policy.
Questa è la timetable degli avvenimenti:
- 13 Febbraio 2015: riconoscimento del bruteforce e successive indagini; una mia fonte si mette in contatto con delle risorse in BT-Italia.
- 25 Febbraio 2015: jrivett prova a contattare più volte BT Italia:
- Invia mail all’indirizzo abuse predisposto da albacom.net, tutti I tentativi vengono “rimbalzati”, mailbox piena…
- Invia mail al contatto tecnico preposto da Albacom.net, ignorato.
- Tweetta il problema sull’account di BT, I tweet vengono immediatamente eliminati.
- Durante questo periodo, escono numerosi articoli riguardanti la botnet utilizzata dai LizardSquad durante i famosi attacchi ad XBOX live e Play Station Network.
Krebs on Security scrive:
“Il codice che sfrutta i dispositivi vulnerabili risalirebbe agli inizi del 2014. Oltre ad infettare i dispositivi, il malware scansiona internet alla ricerca di altri dispositivi che consentano l’accesso tramite credenziali di default. La botnet non è composta esclusivamente da home router alcuni dei dispositivi appaiono, infatti, essere router commerciali appartenenti ad università e aziende.”
Penso che per la tipologia di dispositivi coinvolti,i router Aethra possano aver contribuito ampliamente alla botnet e alla sua espansione.
- 2 Marzo: gli attacchi proseguono ed BT viene messa al corrente dell’accaduto dal mio contatto.
- 15 Aprile: gli attacchi iniziano a ridursi per poi riprendere nelle settimane seguenti.
- 1 Maggio: Sono passati tre mesi, nessuna risposta pervenuta alla mia fonte.
- 11 Dicembre: (11 mesi dopo) Secondo le nostre policy decido di procedere con una full disclosure, non ho motivo di credere che gli attacchi si siano interrotti ma piuttosto che si siano ridotti d’intensità e che abbiano cambiato obiettivi.
- 11 Dicembre: Fastweb viene messa al corrente delle vulnerabilità, vengono concordati alcuni giorni di delay per permettere all’ISP di correggere il problema.
- 22 Dicembre: responsible disclosure e lieto fine, almeno per quanto riguarda Fastweb
- 27 Gennaio 2016: a seguito di un costruttivo dialogo con Aethra Telecommunications viene rilasciato il seguente comunicato.
Tra gli sviluppi successivi:
- Recuperare il firmware per ricercare ulteriori vulnerabilità e/o exploit specifici.
In passato ci siamo già imbattuti in BT Italia e non era andata meglio: McDonald’s Wi-fi Login System
di VoidSec