I corsi di "Reti di Calcolatori" e "Reti di Calcolatori II e Principi di Sicurezza Informatica" sono, credo, interessanti anche perché hanno molti agganci con l'esperienza quotidiana di utilizzo di Internet e dei dispositivi informatici in genere.
In questo semestre sto tenendo il corso di "Reti II". La quantità di eventi legati agli argomenti del corso che ho visto nelle ultime settimane è stata davvero molto grande. Riporto alcuni di questi eventi qui sotto.
Abbiamo detto che il codice deve essere in grado di confrontare correttamente tra di loro valori che superano il massimo valore rappresentabile su 32 bit. Ad esempio, se viene trasmesso il byte 1000 e poi il byte 1002, è facile per il ricevente capire che il secondo deve seguire il primo: 1002 è più grande di 1000. Ma se viene trasmesso il byte numero 2^32-1 e poi il byte numero 1, capire che il secondo deve seguire il primo non è per niente facile, in quanto 1 è (molto) più piccolo di 2^32-1. Il codice di TCP deve cioè essere in grado di gestire correttamente gli overflow dei numeri di sequenza, in quanto se si trasmette una quantità elevata di dati in una connessione allora l'overflow si verifica di sicuro.
Poche settimane fa la Boeing ha informato che i loro aerei 787 devono essere spenti completamente (!) ogni 51 giorni: non hanno tenuto conto del problema dell'overflow nelle letture dei sensori quindi potrebbero verificarsi dei problemi "potenzialmente catastrofici"...
Abbiamo detto che esistono moltissimi algoritmi per il "congestion control" e che questo è un settore in cui la ricerca è ancora molto attiva. Non è stato infatti ancora individuato un algoritmo in grado di fornire prestazioni ottimali in scenari molto diversi tra loro: ogni algoritmo ha prestazioni ottime con alcune tecnologie di rete e non tanto ottime con altre tecnologie (ovviamente questa è una semplificazione "da bar").
All'ultimo NSDI (17th USENIX Symposium on Networked Systems Design and Implementation) sono stati presentati vari algoritmi per il controllo della congestione in TCP, tra i quali uno proposto da un gruppo dell'MIT e specializzato per le reti della telefonia cellulare. Una descrizione informale può essere trovata qui.
Abbiamo detto che un attaccante può forzare un client ad eseguire il protocollo NTLM in modo da osservare il traffico generato dal client ed usare tale traffico per tentare di indovinare la password del client.
Un software per videoconferenze utilizzato moltissimo in questo periodo di quarantena, specialmente negli USA, rende molto semplice fare attacchi di questo genere.
E' stato trafugato il database username-password proprio di uno di questi forum. Chi la fa l'aspetti.
Altrimenti in caso di furto del database succede quello che è successo al provider di posta elettronica email.it che ha fatto una figura davvero barbina: 600.000 (seicentomila) password in chiaro. No comment. Con tutti i messaggi email. No comment. Ovviamente in vendita nei forum.
Abbiamo detto che, in pratica, le VPN hanno limitazioni durante la fase di creazione della VPN e in presenza di eventuali vulnerabilità (errori) sui server VPN.
Da alcuni mesi sono in corso numerose campagne di attacco che si basano, appunto, su vulnerabilità dei server VPN. Una è questa, che ha preso di mira agenzie governative cinesi.
Parleremo di vulnerabilità delle applicazioni web, tra le quali il cross-site scripting (XSS). Una molto interessante è stata resa pubblica di recente, in un "customer portal that provides real-time information to terminal operators on the status of shipments into and out of a marine container terminal". Recentemente ne sono state rese pubbliche un bel pò anche nei plugin di WordPress ma questa non è una notizia.
Parleremo anche delle vulnerabilità in generale, ma queste sono davvero troppe per potere essere citate...
In questo semestre sto tenendo il corso di "Reti II". La quantità di eventi legati agli argomenti del corso che ho visto nelle ultime settimane è stata davvero molto grande. Riporto alcuni di questi eventi qui sotto.
Numeri di sequenza su 32 bit in TCP
L'implementazione di TCP deve associare un numero di sequenza ad ogni byte trasmesso. I numeri di sequenza sono rappresentati su 32 bit.Abbiamo detto che il codice deve essere in grado di confrontare correttamente tra di loro valori che superano il massimo valore rappresentabile su 32 bit. Ad esempio, se viene trasmesso il byte 1000 e poi il byte 1002, è facile per il ricevente capire che il secondo deve seguire il primo: 1002 è più grande di 1000. Ma se viene trasmesso il byte numero 2^32-1 e poi il byte numero 1, capire che il secondo deve seguire il primo non è per niente facile, in quanto 1 è (molto) più piccolo di 2^32-1. Il codice di TCP deve cioè essere in grado di gestire correttamente gli overflow dei numeri di sequenza, in quanto se si trasmette una quantità elevata di dati in una connessione allora l'overflow si verifica di sicuro.
Poche settimane fa la Boeing ha informato che i loro aerei 787 devono essere spenti completamente (!) ogni 51 giorni: non hanno tenuto conto del problema dell'overflow nelle letture dei sensori quindi potrebbero verificarsi dei problemi "potenzialmente catastrofici"...
Controllo della congestione in TCP
L'implementazione di TCP regola dinamicamente la velocità di trasmissione in modo da tentare di prevenire situazioni di "congestione", situazioni cioè in cui il traffico che TCP inietta in Internet in un certo momento è eccessivo per la capacità che ha Internet in quel momento.Abbiamo detto che esistono moltissimi algoritmi per il "congestion control" e che questo è un settore in cui la ricerca è ancora molto attiva. Non è stato infatti ancora individuato un algoritmo in grado di fornire prestazioni ottimali in scenari molto diversi tra loro: ogni algoritmo ha prestazioni ottime con alcune tecnologie di rete e non tanto ottime con altre tecnologie (ovviamente questa è una semplificazione "da bar").
All'ultimo NSDI (17th USENIX Symposium on Networked Systems Design and Implementation) sono stati presentati vari algoritmi per il controllo della congestione in TCP, tra i quali uno proposto da un gruppo dell'MIT e specializzato per le reti della telefonia cellulare. Una descrizione informale può essere trovata qui.
Raccolta di NTLM hash per offline guessing di password
Tutti i sistemi Windows usano il protocollo di autenticazione NTLM.Abbiamo detto che un attaccante può forzare un client ad eseguire il protocollo NTLM in modo da osservare il traffico generato dal client ed usare tale traffico per tentare di indovinare la password del client.
Un software per videoconferenze utilizzato moltissimo in questo periodo di quarantena, specialmente negli USA, rende molto semplice fare attacchi di questo genere.
Password in vendita nei forum
Abbiamo detto che i database username-password sono spesso in vendita sui forum, per così dire, "specializzati".E' stato trafugato il database username-password proprio di uno di questi forum. Chi la fa l'aspetti.
Password memorizzate in chiaro
Abbiamo detto che nei database username-password queste ultime non, ripeto, non devono essere memorizzate in chiaro per nessun motivo. Devono essere memorizzate in un formato non invertibile (e computazionalmente complesso da calcolare).Altrimenti in caso di furto del database succede quello che è successo al provider di posta elettronica email.it che ha fatto una figura davvero barbina: 600.000 (seicentomila) password in chiaro. No comment. Con tutti i messaggi email. No comment. Ovviamente in vendita nei forum.
Rischi pratici delle VPN
Le VPN sono un ottimo strumento difensivo.Abbiamo detto che, in pratica, le VPN hanno limitazioni durante la fase di creazione della VPN e in presenza di eventuali vulnerabilità (errori) sui server VPN.
Da alcuni mesi sono in corso numerose campagne di attacco che si basano, appunto, su vulnerabilità dei server VPN. Una è questa, che ha preso di mira agenzie governative cinesi.
Le prossime settimane
Parleremo degli attacchi ai siti HTTPS ed in particolare dei problemi che ci sono quando HTTPS coesiste con HTTP. Un esempio interessante di questi problemi è stato enfatizzato di recente per la app TikTok usata da moltissimi utenti: i server video sono su HTTP quindi i contenuti possono essere manipolati da un network attacker senza problemi. Un altro che mi è parso incredibile è relativo a Netflix: i cookie di autenticazione sono su HTTPS ma è molto facile indurre un browser o una app a trasmetterli su HTTP e quindi, se si riesce ad osservare il traffico, a trafugarli.Parleremo di vulnerabilità delle applicazioni web, tra le quali il cross-site scripting (XSS). Una molto interessante è stata resa pubblica di recente, in un "customer portal that provides real-time information to terminal operators on the status of shipments into and out of a marine container terminal". Recentemente ne sono state rese pubbliche un bel pò anche nei plugin di WordPress ma questa non è una notizia.
Parleremo anche delle vulnerabilità in generale, ma queste sono davvero troppe per potere essere citate...
Commenti