Come non pensare alla penosa prestazione calcistica di ieri sera

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.

Quanto sopra è proprio ciò che è accaduto con il patch in esame.

La vulnerabilità era in un certo segmento di codice che dato un nome di file prelevava automaticamente quel file; specificando un nome di file che risiede su un server remoto, usando una particolare sintassi Windows molto simile a quella degli URL, quel codice provocava l'accesso automatico al server specificato, con gli effetti sopra descritti.

Il patch consiste in una funzione che, dato un nome di file, determina se il file è locale o remoto. Ad esempio questo è locale '\file.wav' mentre questo è remoto '\\Akamai.com\file.wav'  (file di nome file.wav che risiede sul server di nome Akamai e deve essere prelevato con il protocollo di condivisione file di Windows, il quale forza il client ad autenticarsi). Se il file viene classificato come locale allora viene invocata la funzione che preleva il file, altrimenti no.

Questo è un modo più complicato ma corretto per specificare un file remoto: '\\.\UNC\Akamai.com\file.wav'. Questo nome viene correttamente classificato come remoto. Il ricercatore ha pensato bene di mettere un ulteriore slash dopo 'UNC' ed ha verificato che '\\.\UNC\\Akamai.com\file.wav' viene erroneamente classificato come nome locale. Ergo viene invocata la funzione che preleva il file. Ergo, ci risiamo. Vulnerabilità ancora sfruttabile.

Nota bene: un errore apparentemente banale nella classificazione di stringhe può portare al game over in poche ore.

Fortunatamente il ricercatore ha effettuato il cosiddetto "responsible disclosure", cioè ha informato Microsoft del problema e questo problema è stato reso noto pubblicamente solo contestualmente al rilascio di un ulteriore aggiornamento di Outlook, patch del patch...