Passa ai contenuti principali

Il patch che non era un patch

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...

Commenti

Popular Posts

"Ingegneria deve essere difficile"

Il ritaglio di giornale qui sotto ricorda uno degli eventi più non-trovo-un-aggettivo-appropriato del mio periodo di studente di Ingegneria a Pisa. Ricordo che una mattina iniziò a spargersi la voce "hanno murato la porta del dipartimento!".  Andammo subito a vedere ed arrivammo un pò prima dei giornalisti che scattarono questa foto. La porta era murata, intonacata, pitturata di bianco e sovrastata da una scritta "INGEGNERIA DEVE ESSERE DIFFICILE". Le "E" di "INGEGNERIA" erano scritte al contrario perché era una sorta di "marchio di fabbrica" della facoltà di Ingegneria di Pisa. L'aula più grande, quella in cui pressoché tutti gli studenti seguivano i corsi dei primi anni, aveva infatti alcuni bellissimi "affreschi scherzosi" che furono fatti nel corso delle proteste studentesche di qualche anno prima ed in cui la parola "Ingegneria" era appuntoi scritta in quel modo. Si era anche già sparsa la voce di cosa era

Perché studiare Analisi Matematica???

Un mio caro amico mi ha scritto: ...sono con mia figlia che studia Analisi 1...A cosa serve, al giorno d'oggi, studiare Analisi (a parte sfoltire i ranghi degli aspiranti ingegneri)? Riporto la mia risposta di seguito, forse può "motivare" qualche altro studente. ... Per un ingegnere la matematica è fondamentale perché è un linguaggio ; ed è il linguaggio essenziale per trattare gli argomenti che dovrà affrontare come ingegnere; non sono importanti i contenuti specifici; è importante, anzi fondamentale, che riesca a capirli, ricostruirli etc. ad esempio, chi deve usare l'inglese, lo usa perché in un modo o nell'altro lo conosce; nessuno di noi ha usato esattamente le frasi o i dialoghi o le regole che ha incontrato negli esercizi di inglese o di tedesco; nella matematica è lo stesso; non sono importanti i limiti, le serie, i teoremi di cauchy o che so io; ma se uno non è in grado di capire quel linguaggio allora non sarà in grado di capire davvero quas

40 anni di Internet: Cosa non ha funzionato e perché

Leggo molti documenti tecnico-scientifici per lavoro e, in parte, per "piacere". Molti sono interessanti, alcuni molto interessanti. E' raro che trovi un documento che mi appare illuminante. Questo indicato sotto è uno dei pochi documenti in questa categoria. Sembra banale, in quanto è molto discorsivo e parla di molte cose note: IP, DNS, NAT.... In realtà è profondissimo. Una miniera di riflessioni profonde, sintetiche, focalizzate ed, appunto, illuminanti. A mio parere imperdibile per chiunque abbia un qualche interesse negli aspetti tecnici di Internet. Chi non ha la pazienza di leggerlo per intero, legga almeno gli ultimi due paragrafi. Failed Expectations (l'autore, Geoff Houston , fa parte della Internet Hall of Fame )

ChatGPT: supererebbe il mio esame di Reti di Calcolatori?

Molto probabilmente chi ha a che fare con i corsi di laurea scientifici e tecnologici, come me, ha preso atto della notizia che ChatGPT ha superato esami universitari in giurisprudenza ed economia con un pò, diciamo così, di sufficienza. Pensando "da noi non potrebbe mai succedere; figuriamoci". E' quello che ho pensato io. Poi però ho fatto a ChatGPT qualche domanda di Reti di Calcolatori. Ho quasi cambiato idea. "Quasi" perché nello scritto di Reti di Calcolatori faccio sempre esercizi. Pur non avendoli sottoposti a ChatGPT sono certo che questi esercizi non li sa risolvere. Ma alle "domande tipiche da orale" ha fornito risposte che mi hanno davvero stupefatto. Riporto qui sotto solo un esempio di "dialogo", relativo a validazione di firma digitale e certificati auto-firmati. Risposte sostanzialmente corrette e pertinenti, molto più sintetiche e focalizzate di quelle che ricevo normalmente. E più rapide. Alla fine ha riconosciuto di esser