Quanto segue è un patetico quanto inutile tentativo di distrarmi e non pensare alla pessima prestazione calcistica di ieri sera, decisamente non all'altezza dell'evento e dei nostri gloriosi colori.
Nella lezione di "Computer Networks and Principles of Cybersecurity" di ieri, mi è stata posta la domanda "E' possibile che un patch introduca nuove vulnerabilità?". La mia risposta è stata affermativa, ho evidenziato che un patch è un software, quindi può introdurre errori, vulnerabilità, può fare riemergere errori o vulnerabilità presenti e risolti in versioni precedenti, può correggere la specifica vulnerabilità presumibilmente risolta da quel patch solo in parte. Non è frequente, ma può accadere ed è quindi una possibilità da tenere presente. Uno dei numerosi motivi che rendono così complessa la gestione delle vulnerabilità è anche questo.
Stamattina ho letto un esempio molto interessante di quanto abbiamo detto.
Pochissime settimane fa Microsoft ha rilasciato un patch per risolvere una vulnerabilità molto grave, sfruttata da attaccanti russi. Abbiamo parlato di questa vulnerabilità a lezione, permette di forzare una "coerced authentication" nei confronti di Microsoft Outlook. Qualunque utente autenticato di una organizzazione può sfruttare questa vulnerabilità. E' sufficiente inviare un email "costruito opportunamente" ad un account ad alto privilegio dell'organizzazione stessa. La ricezione ed elaborazione di tale email da parte di Outlook provoca il lato client di Outlook ad autenticarsi con NTLM nei confronti di un server predisposto dall'attaccante ed indicato nell'email. Tale server può sfruttare questa autenticazione per eseguire un "relay attack" ed eseguire una operazione autenticata (con l'identità dell'utente che ha ricevuto l'email, quindi ad alto privilegio) su un server scelto dall'attaccante stesso. Esistono vari software gratuiti per eseguire il relay attack. Sono stati riportati vari casi nei quali c'è stato il "game over" (full compromise) dopo poche ore dall'ottenimento delle credenziali di un utente a basso privilegio, necessarie per eseguire l'attacco. Qui c'è un video che mostra l'esecuzione dell'attacco, spiegato chiaramente ma con vari dettagli non banali e non trattati nemmeno nel corso della magistrale.
Bene, il patch per questa vulnerabilità non la risolve completamente. Un ricercatore dell'azienda Akamai ha infatti rilevato che esiste ancora un modo per costruire email tale da forzare il comportamento sopra descritto. La sua analisi è scritta in maniera molto chiara e focalizzata, qualità abbastanza rare in documenti di questa natura. Ne consiglio la lettura a chiunque sia interessato in questi argomenti.
Il dettaglio dell'errore contenuto nel patch è un esempio interessante di un punto che tratteremo nella prossima lezione. Escludere la presenza di vulnerabilità in un software è "praticamente impossibile" per la combinazione di questi motivi (discussione iper-semplificata; i motivi sono molti di più ma questa è la sostanza):
- "Software is not continuous": l'output per un dato input X1 ci fornisce "poca informazione" sull'output che sarà ottenuto con un input X2 "poco diverso" da X1.
- Per garantire l'assenza di vulnerabilità in un software dovremmo quindi testarne il comportamento per tutti i possibili input, cosa ovviamente non fattibile.
- Le vulnerabilità si trovano tipicamente negli input "strani, non corrispondenti a quelli normali o prevedibili", proprio perché questi input non sono stati considerati in fase di coding e di testing.
Commenti