venerdì 30 maggio 2014

Uccidere usando un computer

Consiglio caldissimamente la lettura di questo post:

Computers now run our cars. It's now possible for a hacker to infect your car with a "virus" that can slam on the brakes in the middle of the freeway. Computers now run medical devices like pacemakers and insulin pumps, it's now becoming possible assassinate somebody by stopping their pacemaker with a bluetooth exploit.
...
So let's say I've found a pacemaker with an obvious BlueTooth backdoor that allows me to kill a person, and a year after notifying the vendor, they still ignore the problem, continuing to ship vulnerable pacemakers to customers. What should I do? If I do nothing, more and more such pacemakers will ship, endangering more lives. If I disclose the bug, then hackers may use it to kill some people.

Spesso chi si occupa professionalmente di sicurezza tende ad ingigantire i pericoli, nel proprio interesse. Non è questo il caso. Si tratta di problemi reali, concreti, descritti da una persona (Robert Graham) molto, molto credibile.

Penso che chiunque si occupi di IT, non necessariamente di informatica o di sicurezza, dovrebbe leggere questo post e meditare con calma su ogni singolo paragrafo.

Full post: http://blog.erratasec.com/2014/05/can-i-drop-pacemaker-0day.html

giovedì 29 maggio 2014

Usiamo tutti il mouse nello stesso modo ?

Molta gente ritiene di no. Molta gente sta cercando di utilizzare i pattern di uso del mouse come una sorta di proprietà biometrica degli utenti, utile per verificarne l'identità o per aumentare il grado di certezza ottenibile dalla presentazione di credenziali o altri strumenti.

L'idea è che se il pattern di utilizzo del mouse osservato per l'utente "bartoli.alberto" ogni tanto cambia in modo sensibile, allora è molto probabile che siano in corso accessi fraudolenti per quello username.

Questa tecnica è molto interessante e molto promettente, in particolare se può essere applicata in modo sistematico, automatico e su larga scala. Il che è precisamente quello che abbiamo iniziato a fare con l'ultimissimo lavoro del Machine Learning Lab.

Questo lavoro ha beneficiato del contributo di molte persone nei mesi scorsi, tra i quali un tesista magistrale. Gli autori del paper sono quelli che hanno sviluppato l'algoritmo "definitivo" ed effettuato l'analisi "definitiva".

giovedì 22 maggio 2014

Ebay ed il furto delle password sui server


Ne abbiamo parlato proprio ieri pomeriggio a lezione ​ (ancora la mia sfera di cristallo...)​ :
  • quando l'autenticazione del client si basa su password, il server deve avere copia della password; il segreto del client cioè deve essere noto anche al server;
  • quindi un attaccante o un impiegato disonesto può, in linea di principio, prelevare la password dal server;
  • il che crea uno scenario in cui il client può pagare il costo delle inefficienze / responsabilità del server ​​(quando il client si autentica tramite smart card / crittografia a chiave pubblica le cose sono radicalmente diverse: il server non conosce il segreto del client, può solo verificare che il client effettivamente conosce quel segreto) ​.
Queste cose accadono davvero:

Ebay vittima di un attacco hacker: “Gli utenti cambino la password”
 
Il sito di vendita on line vittima di una cyber imboscata. Ma rassicura: «I dati finanziari non sono stati compromessi». Perdono i titoli in Borsa
 
Clip Betterhttp://www.lastampa.it/2014/05/21/tecnologia/ebay-v…
 
View Now
 
Clip Better
Get it now
Penso che la dimensione di questo problema non sia ben nota, pertanto ho pubblicato una raccolta di aneddoti: http://bartoli-alberto.postach.io/tag/password​. ​ Dateci un'occhiata, vedrete che il problema è davvero enorme e reale: non si tratta di una mera curiosità teorica o possibilità ipotetica (purtroppo nell'elenco compare oggi come data di pubblicazione di ogni notizia, non compare quella vera). Quell'elenco di notizie comprende solo intrusioni nei server, non comprende i furti di password tramite altre tipologie di attacco (phishing, keylogger sui client etc).

Per inciso, alla domanda che mi è stata fatta ieri "se le password sono memorizzate sul server in una forma non invertibile ed il client invia la password nella stessa forma (tecnica utilizzata di frequente, come vedrà chi farà Reti II), allora anche prelevando le password dal server non si riescono ad usare", ho dimenticato di rispondere nel modo più ovvio: "l'attaccante ha tutto il tempo che vuole per trasformare tutte le possibili password nella forma non invertibile e vedere se ne ha indovinato qualcuna". Questa è la tecnica che si usa di solito, esistono software appositi equipaggiati di dizionari di "possibili password" che provano tutte quelle password e le loro variazioni più comuni (tipo cambiare le i in 1 etc). Inutile dire che funziona alla grande. Potrei pubblicare molte notizie su questa faccenda ma per oggi basta così...

martedì 20 maggio 2014

Espressioni regolari, intrusion detection e tesi di laurea

Un lavoro tratto da una tesi di laurea magistrale svolta di recente nel Machine Learning Lab è stato accettato per la presentazione ad una conferenza internazionale molto prestigiosa. Ancora una volta mi chiedo perché molti studenti in gamba preferiscano fare tesi di laurea in cui l'obbiettivo è fare qualche finestra colorata con qualche bottone altrettanto colorato usando una delle N tecnologie esistenti al momento...ma questo è un altro discorso.

Difficile spiegare sinteticamente di cosa si tratti. Ci provo.

Molte organizzazioni sono dotate di "Intrusion detection systems", sistemi che analizzano tutto il traffico in ingresso ed uscita alla ricerca di pattern indicativi di attività fraudolente. I pattern sono moltissimi. Un modo compatto per descrivere questi pattern consiste nell'utilizzo di "espressioni regolari". Ad esempio:

 ^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.(?:[A-Z]{2}|com|org|net|edu|gov|mil|
biz|info|mobi|name|aero|asia|jobs|museum)$ 

è una espressione regolare che could be used to identify email addresses from any two-letter country code top level domain, and only specific generic top level domains. Un sistema di intrusion detection deve spesso applicare centinaia di espressioni regolari ad ogni singolo pacchetto e deve essere in grado di farlo "at line speed", cioè in tempo reale su ogni singolo pacchetto---un sistema che avvisa di attività fraudolente con un ritardo di ore o di giorni non è inutile ma neanche molto utile. Sono state quindi proposte molte soluzioni per rendere questo procedimento veloce ed efficiente, molte delle quali consistono nell'implementazione dei sistemi di valutazione delle espressioni regolari su hardware dedicato.

Noi abbiamo fatto una cosa radicalmente diversa: invece di ottimizzare la valutazione delle regole esistenti, abbiamo trasformato l'insieme di regole in un insieme diverso, molto più piccolo ed "equivalente sul traffico di interesse" (dettagli nel paper). In questo modo siamo riusciti a ridurre la dimensione dell'insieme di regole del 75% (!).

Post sul sito del  Machine Learning Lab.


venerdì 16 maggio 2014

"Perché i MAC non prendono i virus?"

Domanda

Salve prof,avrei una curiosità che non centra nulla con il corso di Reti: per quale ragione si dice che Mac sia insensibile ai virus e ai malware? Si tratta solo di una diceria o è veramente così?

Risposta


Motivo della Risposta

Vedi i link con data 16 Maggio 2014 (oggi) che ho appena messo qui.

(segue piccolissimo update del Marzo 2015; 2 minuti per trovarli e 10 minuti per formattarli sul blog; se cercate tra le mie security news ne trovate certamente molte altre): 

Never trust SMS: iOS text spoofing
FREAK out: Apple and Android SSL is WIDE OPEN to snoopers
Apple Safari 7.0.4 closes 22 holes, including 21 listed under "arbitrary code execution"
Instagram iOS session hijack

giovedì 15 maggio 2014

TCP e la mia sfera di cristallo

Alcuni ricercatori israeliani hanno pubblicato da poco un articolo scientifico su una rivista molto prestigiosa in cui dimostrano la fattibilità di una cosa molto interessante. Ne parlo qui come ulteriore esempio del fatto che la mia sfera di cristallo personale funziona davvero. E' necessaria una introduzione.

Un client ha aperto una connessione TCP con un server. E' possibile che un attaccante riesca ad iniettare dati in quella connessione ?

Il server riceverebbe dalla connessione dati generati dall'attaccante, invece che dal client; allo stesso modo, il client riceverebbe dati generati dall'attaccante invece che dal server.

La gravità potenziale di attacchi del genere è evidente.

In Reti di Calcolatori II analizziamo (anche) questa tipologia di problemi. L'analisi è molto istruttiva, non solo per il risultato (un attaccante che si trova in mezzo tra il client ed il server può fare di tutto, compresi questi attacchi) ma soprattutto come "esempio storico":
  • 1985: La gente inizia a rendersi conto che anche un attaccante che non si trova in mezzo tra il client ed il server può iniettare dati in una connessione esistente---faccenda evidentemente terribile.
  • Gli attacchi cominciano a verificarsi davvero.
  • 1995: Tutte le implementazioni di TCP vengono modificate in modo da rendere impossibili tali attacchi. Tralasciando i dettagli, il valore iniziale di un certo contatore viene scelto in modo pseudo-random. Il numero di tentativi che deve fare un attaccante per iniettare dati diventa talmente elevato da rendere l'attacco impraticabile. Tutti contenti. Tutti.
  • 2001: Dopo ben 6 anni, qualcuno si rende conto che l'analisi statistica effettuata era sbagliata: il numero di tentativi da fare è mooooolto minore di quello che si pensava ed è sufficientemente piccolo da essere praticabile. Viene introdotta una nuova modifica. Tutti contenti. Tutti.
  • 2004: Dopo altri 3 anni si scopre che la nuova modifica soffre essenzialmente dello stesso problema di quella precedente. Ancora una nuova modifica. Tutti nuovamente contenti.
Per ben due volte, un problema estremamente pressante per mezzo mondo è stato studiato dalle aziende ed organizzazioni più all'avanguardia; tutti convinti di averlo risolto; tutti si erano sbagliati; sono stati necessari anni per rendersene conto (inutile dire che durante questi anni nessuno sa cosa gli attaccanti siano riusciti a fare in segreto, ma questa è un'altra faccenda).

Esempio istruttivo di uno degli aspetti fondamentali della sicurezza informatica: oggi tutto il mondo ritiene che una certa azione non è fattibile; domani qualcuno dimostra che tutti (tutti) si erano sbagliati. E' già successo molte volte, per molti protocolli.

Dal 2004 si ritiene che se un attaccante non si trova in mezzo al client al server, "data injection may be possible. However, this has not been demonstrated and it appears to be problematic". Nelle mie slide scrivo dopo questa frase:



Bene, cosa è stato dimostrato proprio pochissimi giorni fa ? "We present attacks that allow an off-path adversary to learn the client port and sequence numbers, and thereby to inject traffic into the TCP connection". Pertanto, ancora una volta si erano sbagliati tutti.

Loro sono andati addirittura oltre. Come discutiamo a Reti II, iniettare dati è solo parte del problema. E' necessario anche che i dati corrispondano a ciò che il livello applicativo si aspetta di ricevere (se un server POP si aspetta di ricevere un comando USER e riceve invece un comando PASS iniettato in modo fraudolento dall'attaccante, allora il server non accetta il comando fraudolento; per un attaccante che non si trova in mezzo e non riesce a vedere il traffico, risolvere questo problema di sincronizzazione è enormemente difficile). Bene, loro sono riusciti anche a falsificare le risposte del server e, quindi, a fornire al browser dati scelti da loro: "we show how to...inject spoofed objects such as scripts and web pages to a connection with a victim web site".

Traduzione: il browser si collega con un server; il browser riceve la pagina fornita dal server, alla quale l'attaccante ha aggiunto script ed elementi scelti da lui. Inutile sottolineare le implicazioni.

La mia sfera di cristallo funziona molto bene.

venerdì 2 maggio 2014

Provetta Reti di Calcolatori

Stato della correzione aggiornato in tempo reale

Commenti sulla provetta: nota Evernote (i nuovi commenti sono aggiunti in coda ad una lista numerata)