Sicurezza, ICT e altro

Symantec ha trovato un ulteriore problema nell’UAC di Vista, per cui un’applicazione protenzialmente truffaldina può essere presentata all’utente come un componente fidato quando chiede il permesso di accrescere i propri privilegi, ed essere quindi presentata in una finestra color verde (suggerimento: tutto OK). Il problema naturalmente non è la vulnerabilità in sè.

Avete presenti le discussioni di una settimana fa sull’UAC, sui suoi limiti e sul fatto che Microsoft non lo considerasse un “security boundary” e quindi i suoi bug non venissero considerati bug di sicurezza? Bene, in questo caso sembra confermato: Microsoft non vuole considerare i problemi di UAC come dei veri problemi di sicurezza; almeno, questo è quello che io posso dedurre dalla risposta data ai ricercatori di Symantec. Naturalmente siamo abituati a non interessarci di cosa Microsoft consideri o meno problema di sicurezza, dato che dipende un po’ dal periodo. Tuttavia, se quello segnalato non è un problema di sicurezza le patch corrispondenti di conseguenza non verranno, probabilmente, marcate come “critical”, e ci si può aspettare che in molti contesti non verranno installate (spero che almeno vengano prodotte, e in tempi brevi).

Ma torniamo all’UAC. Ho detto più volte, e ne sono ancora convinto, come questa sia esattamente la funzionalità che serve per i sistemi in mano agli utenti, specialmente domestici. Ma forse, avrei dovuto fare una precisazione: serve, se funziona. O se è un ragionevole compromesso, nel senso che in qualche caso strano non funziona, qualche caso che sia comunque difficile da sfruttare, soprattutto da remoto. Con “funziona”, naturalmente, intendo dire che se un programma chiede inopinatamente di aumentare i propri privilegi, allora l’utente viene messo sufficientemente in allarme. Se il meccanismo addirittura fornisce indicazioni false, invece, è un danno. Perché in fondo, fra lavorare come amministratore e lavorare come utente con l’AUC, per del codice malevolo si tratta solo di un prompt in più: se il prompt non è efficace, il meccanismo serve a poco.

Ora, dopo tanta pubblicità sulla sicurezza di Vista, che ha incluso l’UAC, devo dire che mi lascia molto perplesso la velocità con cui Microsoft ha cambiato “prospettiva”; mi sarei aspettato una strenua difesa dell’importanza dell’AUC anche con eventuali limiti che venissero man mano scoperti. Almeno, questa è l’idea che mi sono fatto nel tempo del modo di operare del marketing di Microsoft. Invece, l’AUC viene “scaricato” senza troppi complimenti, o almeno ne viene minimizzata l’importanza, a meno di un mese dall’uscita di Vista versione “consumer”. Il dubbio che mi viene è che l’UAC, a forza di compromenssi per essere compatibile all’indietro, per non dare troppo fastidio, per non limitare troppo le funzionalità e potenzialità di Vista, possa aver alla fine subito qualche grosso limite architetturale. Se è così, ci possiamo aspettare che nei prossimi mesi vengano fuori sempre più problemi. Spero che le cose stiano diversamente, o che quantomeno Microsoft prenda più seriamente questa funzionalità e cerchi di correggerne i difetti con la dovuta priorità. Anche perché da un punto di vista di sicurezza, se l’UAC non funziona mi viene veramente difficile giustificare il perché un utente dovrebbe spendere quello che costa il passaggio a Vista, in termini di licenza, requisiti di sistema e problemi di compatibilità.

Riguardo all’UAC segnalo anche questo post interessante di Feliciano Intini.

OpenCRS pubblica un altro documento di overview. Vale la pena di leggerlo… proprio perché non dice niente di nuovo.

Prendo spunto da un piacevole articolo di Securiteam. Dico piacevole, perché sinceramente non riesco a capire qual’è l’aspetto ironico e quale quello serio. Comunque sia, è vero che l’attenzione si è spostata verso le vulnerabilità di tipo applicativo, già da parecchio tempo. Il motivo è semplice: anche il progettista/sistemista più lento, dopo tanti anni che se lo sente dire, assimila l’idea che lasciare attivi e accessibili dei servizi inutili e inutilizzati vuole dire cercarsi problemi. Ormai fermare qualche servizio e chiudere qualche porta sul firewall è una cosa che sanno fare tutti, e trovare vulnerabilità di questo tipo è difficile, anche se non impossibile. Di conseguenza, gli attacchi si sono spostati verso la parte applicativa. La risposta della “security” è stata duplice: da una parte gli strumenti si sono spostati verso la parte alta dello stack: deep packet inspection e, tutto sommato, ips. Questo primo passaggio è quello che secondo me rende discutibile la maggior parte delle statistiche o degli studi che considerano l’andamento delle vulnerabilità dei sistemi informativi su un lungo arco di tempo: il fatto che dieci anni fa non si rilevassero vulnerabilità e attacchi sofisticati sulla parte applicativa vuole solo dire che non valeva la pena di cercarle.

Il punto interessante è la “seconda” risposta della security, che è poi il tema dell’articolo di Securiteam: anche chi pratica penetration testing, vulnerability assessment e simili, si è spostato verso la parte applicativa. Il dubbio è che il motivo sia analogo, e non conseguente, a quello dei malintenzionati. Anche chi si occupa di vulnerability assessment “vive meglio” se trova vulnerabilità critiche piuttosto che se non le trova, per una serie di ovvie ragioni che non credo sia necessario approfondire. D’altra parte, la maggior parte delle aziende, a fronte di un insieme di vulnerabilità presenti sui propri sistemi, l’indicazione di quali siano più critiche se la fanno dare dai professionisti incaricati delle verifiche.

Sto dicendo che chi fa vulnerability assessment grida “al lupo” inutilmente per guadagnarsi la pagnotta? In generale no. C’è chi lo fa, e magari sopravvaluta volutamente il rischio di qualche vulnerabilità: l’esempio dello “scalare la gravità del filtraggio dei pacchetti ICMP” nel post di Securiteam è esemplare. Non credo però che sia la situazione più comune. Il mio problema è un altro. Esattamente come una volta erano presenti le vulnerabilità applicative, ma non interessavano, dieci anni fa erano già presenti i cattivi comportamenti che permettono oggi il phishing, e non interessavano. E adesso sono presenti altri problemi, in particolare sul controllo delle attività degli utenti legittimi, sui quali le vicende di Telecom ci dovrebbero aver fatto suonare tutti i campanelli necessari. Ma anche queste “non interessano”, perché stiamo anocra correndo dietro al Cross Site Scripting. Il mio problema è che si dà troppo peso alla vulnerabilità: la sua individuazione, chiusura, le architetture che contrastano le vulnerabilità del momento. Specialmente se quelle vulnerabilità sono solo quelle facilmente verificabili in un penetration test. Per fare un esempio, è molto più facile presentare al committente una vulnerabilità di cross site scripting che spiegargli perché l’uso di password su SSL non è una gran protezione per un servizio al pubblico, o fargli capire che la soluzione alla mancata installazione di una patch non è installare la patch, ma capire perché non era installata; o ancora, che la preoccupazione non deve essere che i dati personali trattati da una PA siano accessibili all’hacker cinese, ma ai dipendenti che non ne hanno necessità. Certo, non si può chiedere a chi si occupa di sicurezza di combattere con i mulini a vento, ma non si deve neppure adagiare nel “tanto è inutile” e “tanto non si può fare”. Da questo punto di vista, l’attività di vulnerability assessment non è di nessuna utilità. Al contrario: la ricerca di vulnerabilità porta l’attenzione sul sintomo, anzi, sui sintomi di moda al momento, ma non fa molto per curare la malattia. Certo, alla fine le vulnerabilità del sistema devono essere trovate ed eliminate. Ma, appunto, alla fine. Detto questo, dall’occhiata che ho dato alla nuova Testing Guide di OWASP, devo dire che stanno migliorando continuamente. Sarebbe interessante l’utilizzo di questo genere di strumenti come benchmark per categorie di aziende.