skip to main | skip to sidebar
15 commenti

Nuove frontiere degli attacchi informatici: oscurare un sito tramite le webcam

Ultimo aggiornamento: 2016/10/05 8:05.

Siamo ormai abituati agli attacchi informatici messi a segno tramite virus, siti falsi o documenti che rubano password. Ma pochi giorni fa KrebsOnSecurity, il sito del popolare esperto di sicurezza informatica Brian Krebs, è stato oscurato con una forma di attacco decisamente insolita: sono state utilizzate centinaia di migliaia di telecamere connesse a Internet.

Insieme a router, videoregistratori digitali e altri dispositivi connessi (la cosiddetta Internet delle cose), queste telecamere sono state infatti infettate in massa e comandate dagli aggressori in modo da generare un traffico enorme verso il sito di Krebs: l'equivalente informatico di migliaia di persone che tentano di telefonare contemporaneamente allo stesso numero. In gergo tecnico si chiama distributed denial of service o DDOS.

Si tratta di uno degli attacchi più grandi mai effettuati: le stime parlano di 620 gigabit al secondo. Per dare un senso a questa cifra, immaginate di trasmettere a qualcuno via Internet settanta film al secondo (stimando un gigabyte per film). Ed è stato probabilmente un assaggio di quello che vedremo nel prossimo futuro: pochi giorni dopo, un servizio di hosting francese, OVH, è stato attaccato ancora più massicciamente con 1100 gigabit al secondo. E Ars Technica segnala numerosi altri casi di oscuramenti effettuati tramite webcam.

L’oscuramento del sito di Brian Krebs, spina nel fianco di molti criminali online per via delle sue inchieste che fanno i loro nomi e cognomi, ha messo in ginocchio persino le risorse di una delle più grandi aziende per la distribuzione di contenuti via Internet, Akamai, che aveva difeso gratuitamente Krebs dagli attacchi subiti in passato ad opera di questi criminali. Al suo posto è subentrato Google, che ha sopportato l’attacco nell’ambito del proprio Project Shield per la difesa dei giornalisti dalla censura online. In effetti un DDOS è una forma di censura: se nessuno ti può leggere, è come se tu non avessi scritto nulla.

Il problema principale di questi attacchi è che la loro potenza di fuoco è difficile da mitigare e resta attiva a lungo perché gli oggetti connessi a Internet, a differenza dei computer, non vengono quasi mai aggiornati per correggerne le falle e per i loro proprietari è difficile rendersi conto di essere complici di un’aggressione online. Questi oggetti, inoltre, non hanno antivirus che permettano di fare una loro scansione alla ricerca, appunto, di virus o simili o di proteggerli da intrusioni. E con la crescente popolarità dell’Internet delle Cose (insicure), possiamo aspettarci altri attacchi spacca-Internet come questi.

Tutto quello che possiamo fare noi utenti per evitare di diventare complici inconsapevoli di questi assalti è cambiare le password predefinite dei dispositivi che colleghiamo a Internet: sarebbe già un grande miglioramento, visto che non lo fa nessuno, a giudicare dal numero di oggetti digitali accessibili tramite le loro password standard, e oltretutto metterebbe anche noi al riparo da eventuali atttacchi di ficcanaso. Alcuni dispositivi, però, sono realizzati in modo talmente insicuro da non consentire cambi di password: in questi casi l’unica soluzione è scollegarli o isolarli da Internet, se possono funzionare senza essere online. Benvenuti nell’Internet delle Cose.


Fonti aggiuntive: The Inquirer, Motherboard

Invia un commento
I commenti non appaiono subito, devono essere tutti approvati da un moderatore. Lo so, è scomodo, ma è necessario per tenere lontani scocciatori, spammer, troll e stupidi: siate civili e verrete pubblicati qualunque sia la vostra opinione; gli incivili di qualsiasi orientamento non verranno pubblicati, se non per mostrare il loro squallore.
Inviando un commento date il vostro consenso alla sua pubblicazione, qui o altrove.
Maggiori informazioni riguardanti regole e utilizzo dei commenti sono reperibili nella sezione apposita.
NOTA BENE. L'area sottostante per l'invio dei commenti non è contenuta in questa pagina ma è un iframe, cioè una finestra su una pagina di Blogger esterna a questo blog. Ciò significa che dovete assicurarvi che non venga bloccata da estensioni del vostro browser (tipo quelle che eliminano le pubblicità) e/o da altri programmi di protezione antimalware (tipo Kaspersky). Inoltre è necessario che sia permesso accettare i cookie da terze parti (informativa sulla privacy a riguardo).
Commenti
Commenti (15)
Non sarebbe opportuna una legislazione che obblighi chi mette in commercio "cose" collegabili ad internet ad adottare una procedura di installazione che non permetta di utilizzare come definitiva una pw predefinita?
Tristemente MOLTI di questi dispositivi non permettono il cambio della password di amministrazione.

Mia personale esperienza: ho dovuto installare a casa di parenti una serie di ipcam. Quando sono andato a configurarle non ti dico il mio sbigottimento quando ho visto che la password di amministrazione di default (un banale admin:admin) non era modificabile. Ho dovuto fare io stesso un piccolo hack dell'interfaccia web per poterla cambiare.
La cosa é molto più grossa di quanto si é raccontato finora e riguarda anche il comportamento di diversi operatori (AS) americani ed alle loro azioni di mitigate della problematica. Nello specifico, c'è una grave questione che riguarda alcuni annunci sul BGP.

Qui un veloce recap:

http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/

La questione legata a Krebs ed alle reazioni dei vari providers non é ancora finita ed é ancora in discussione nella mailing-list del NANOG (l'associazione degli Internet Service Providers Americani).

Saluti.
in effetti, in questi giorni (per la precisione il 27/09/2016 dalle 13.04.00 alle 17.26.13), ho notato un'attività molto insolita dall'indirizzo ip 218.65.30.4: stando ai log, questo ip ha provato 2997 volte ad entrare come utente root via ssh.
Per chi fosse interessato all'IOT, nei log dei tentativi (miseramente falliti) di accesso, ecco la lista dei nomi utente più utilizzati (così potete disabilitarne l'accesso via ssh, in modo da arginare molti potenziali problemi) ed il numero di tentativi:

# User, count
root, 3267
admin, 308
pi, 78
user, 69
support, 68
radio, 55
test, 55
ubnt, 55
ftpuser, 41
guest, 32
git, 25
PlcmSpIp, 24
minecraft, 22
ts3, 19
ftp, 19
info, 16
operator, 16
apache, 16
ts3server, 15
hadoop, 15
oracle, 15
steam, 12
manager, 12
administrator, 11
centos, 10
download, 10
openerp, 10
postgres, 10
backup, 10
nagios, 10
demo, 10
test1, 10

E le pagine apache più richieste:

# request_uri, Count
/cache/global/img/gs.gif, 12
/css/spinner.css, 9
/testproxy.php, 7
/reader/about/, 6
/cgi/common.cgi, 6
/stssys.htm, 6
/command.php, 6
/HNAP1/, 5
/jmx-console/HtmlAdaptor, 4
/admin/config.php, 3
/admin/i18n/readme.txt, 3
/azenv.php, 3
/manager/html, 3


Per quanto riguarda l'hacking delle telecamere, ho dovuto (spiacevolmente) constatare che le mie foscam tentano in tutti i modi di comunicare con l'esterno.
Al momento, la non-soluzione che ho trovato è stata l'impostare un indirizzo di un router inesistente nelle impostazioni di rete.
Quindi, se è vero che l'utente è pigro, anche alcune case produttrici ci mettono il loro.
Anche se metti una pass sono dispositivi che non vengono mai aggiornati e quindi nell'arco di poco li bucherebbero comunque in modo massivo.

Il problema sarebbe facilmente risolvibile creando una rete "trusted" in cui un dispositivo per potersi connettere ha bisogno di autorizzazioni specifiche (che possono essere concesse di default) ma che poi possono essere revocate da remoto in caso di abusi.

Ma è un tabù parlarne perché lo spauracchio dello scenario distropico non ne consente di ragionarne serenamente, non conta l'implementazione, le tutele, le garanzie; conta quello che potenzialmente potrebbe essere (però mai sentita una polemica sui root server dei DNS, guarda te), quindi teniamoci spam e attacchi DDOS da terabyte/s, intanto io mi vado a ripassare le differenze tra anarchia e libertà perché ancora non credo di averle capite.
Ma mettere le webcam su una subnet isolata dal resto e usare una VPN?
Fx, il problema è che la sicurezza assoluta non esiste. Tutto lì. Fai un sistema più sicuro? Qualcuno più furbo te lo buca. Vuoi evitare i DDoS? Non puoi semplicemente perché la rete è fatta per portare dati. Non è rendendo illegali i coltelli che eviti gli accoltellamenti.
Una volta si diceva "telecamere a circuito chiuso", forse è il caso di tornarci.
Quantomeno ad un gruppo di telecamere cablate (es. di un edificio), che fanno capo ad UN SOLO terminale collegato ad internet, ben protetto sia da accesso fisico che da remoto.
Lupo: giro il concetto che volevo esprimere così. Reti cellulari. Per essere connesso devi essere registrato e avere un identificativo unico. Vi fossero dei flood di telefonate su un numero specifico da parte di un tot di cellulari ad es. infettati da un malware... puoi segarli dalla rete, risolvendo in un attimo questa sorta di attacco DDoS verso il numero in questione.

In altri termini, non è un sistema più sicuro. E' un layer in più, per centralizzare quello che anche già oggi potresti fare (escludere nodi) solamente ISP per ISP, in modo cioè poco pratico.

Pensa che bello... questi passano mesi a costruire le botnet e al primo attacco, in pochi minuti, butti offline tutti i nodi che la compongono. E rimangono offline finché, un po' per volta, i legittimi proprietari non si fanno vivi per chiedere l'unban dopo aver dichiarato di aver messo in sicurezza il dispositivo.
Era abbastanza prevedibile come cosa, nel senso sono connessi ad internet, sono vulnerabili era solo questione di tempo...
Fx, sarebbe impossibile per questioni legali. Ci vorrebbe il nulla osta della magistratura come minimo, e ogni paese dovrebbe implementare una legge ad hoc, senza contare che semplicemente potresti non essere in grado di mettere in sicurezza i dispositivi.
Beh in realtà un'altra possibile precauzione che si può prendere con qualunque tipo di dispositivo IoT è utilizzare una porta non standard per il forward.
So che fa molto STO, ma è una difesa efficace contro gli attacchi automatizzati, ovvero praticamente tutti.

Se poi siamo Hacking Team e qualcuno vuole entrare per forza beccherà anche la porta non standard, ma diciamo che non è la preoccupazione tipica di un utente comune;)
@Alx:
Ma ci sono elementi che portino a pensare che le due storie sarebbero collegate? L'indagine di Krebs su BackConnect e l'attacco ai suoi danni?

L'unica "coincidenza" è il fatto che avesse scritto un articolo su BackConnect il giorno stesso che ha ricevuto l'attacco, ma non mi sembra che faccia necessariamente pensare a una reazione immediata di BackConnect, anzi... un'azienda di quel livello sapeva benissimo che prima o poi l'articolo sarebbe tornato online (ed era stato già ripreso da altri, la stessa Dyn) e avrebbe semmai generato effetto Streisand.
E poi significherebbe che BackConnect per anni ha portato avanti un piano per impadronirsi delle botnet con la scusa di combatterle, per poi usare tutto questo lavoro... per buttare giù il sito di Kerbs per mezza giornata?
@Tukler
Errore mio, quella che ho esposto é soltanto un piccolo aspetto della questione.
Come é nato il DdoS:

E' stata allestita un architettura C2 per il controllo della Botnet.
La Botnet é basata su dispositivi IoT/IoE linux-based e si suppone che il vettore d'entrata sia stato la default login/password + qualche exploit in grado di far fare RCE arbitrario dentro la macchina.
Nel frattempo é emerso il malware utilizzato: un toolkit derivato da Ddos.87 chiamato Mirai.
E' un eseguibile ELF secco, e questo ci forza a pensare che scrivere una botnet in grado di utilizzare le utenze di default delle telecamere (ed altri dispositivi IoT) non sia stato abbastanza. Un binario come quello può essere eseguito solo previo Exploit ed esecuzione come payload, il che coinvolge una probabile zero-day per linux che ha effettivamente interessato tutte le macchine che sono state parte del DdoS (e già questa é una cosa gravissima).

Ora, l'avere un RCE non-disclosed e l uso di un malware ri-adattato per l'occasione su uno pre-esistente fà pensare a qualcosa di fortemente pre-meditato e ingegnerizzato sul lungo termine. Qualcosa in genere realizzabile squisitamente da chi é nell'ambiente della cybersicurezza, e solo oltre un certo livello.

Poi c'è tutta la questione inerente a quanto precedentemente detto.
Un DdoS da 1Tb/s verso un blog di sicurezza.
Google che si rivela come fornitore di servizi Shield (perché per avere Project Shield bisogna prima di tutto essere hostati su Google Cloud Platform e far parte del relativo programma).
Molti AS che temendo per la propria bandwidth segano l'AS del target lato BGP (creando appunto un problema di accountability non indifferente).
L'azione portata avanti con un malware ad-hoc e con vettore non ancora noto (a differenza di tutto il resto).

In questo caso c'è di tutto insomma, é molto più grande e complicato di quanto si immagini.

@Alx:
E' un eseguibile ELF secco, e questo ci forza a pensare che scrivere una botnet in grado di utilizzare le utenze di default delle telecamere (ed altri dispositivi IoT) non sia stato abbastanza. Un binario come quello può essere eseguito solo previo Exploit ed esecuzione come payload, il che coinvolge una probabile zero-day per linux che ha effettivamente interessato tutte le macchine che sono state parte del DdoS (e già questa é una cosa gravissima).

Non capisco, questa è una tua supposizione o mi puoi dare delle fonti che approfondiscano questa ipotesi?
Da quel che ho letto Mirai carica il payload sui dispositivi che hanno Telnet aperto, quindi direi che le credenziali bastano e avanzano.
Se volessero usare altri vettori (si pensa che il codice pubblicato ora sia parziale o finto) basterebbe usare vulnerabilità stranote dei server web non aggiornati o delle applicazioni web di tanti dispositivi.
Perché deve esserci per forza una vulnerabilità zero day di Linux?

Ora, l'avere un RCE non-disclosed e l uso di un malware ri-adattato per l'occasione su uno pre-esistente fà pensare a qualcosa di fortemente pre-meditato e ingegnerizzato sul lungo termine. Qualcosa in genere realizzabile squisitamente da chi é nell'ambiente della cybersicurezza, e solo oltre un certo livello.

Appunto, è per questo che mi sembra molto improbabile che qualcuno usi tutto questo per fare un ddos di mezza giornata a un blog.
A me da l'idea di un attacco impressionante dal punto di vista della quantità, ma non particolarmente sofisticato.

Google che si rivela come fornitore di servizi Shield (perché per avere Project Shield bisogna prima di tutto essere hostati su Google Cloud Platform e far parte del relativo programma).

Non capisco cosa intendi con questo.

Molti AS che temendo per la propria bandwidth segano l'AS del target lato BGP (creando appunto un problema di accountability non indifferente).

Questo è interessante, è successo in questo caso?