hit counter
Atsiv: attacco al kernel code signing di Vista ? Non proprio - NonSoloSecurity Blog di Feliciano Intini - Site Home - TechNet Blogs

NonSoloSecurity Blog di Feliciano Intini

Notizie, best practice, strategie ed innovazioni di Sicurezza (e non solo) su tecnologia Microsoft

Atsiv: attacco al kernel code signing di Vista ? Non proprio

Atsiv: attacco al kernel code signing di Vista ? Non proprio

  • Comments 3
  • Likes

Non so se avete letto questa notizia del tool australiano Atsiv: in ogni caso è importante che ve ne parli, sia per segnalarvi le iniziative che Microsoft ha rapidamente adottato in merito, sia per fare qualche riflessione, per così dire più filosofica, sugli aspetti di sicurezza. Questo tool permetterebbe di bypassare la policy Kernel Mode Code Signing (KMCS) della versione x64 di Windows Vista che intende caricare nel Kernel solo codice che sia stato firmato digitalmente con un valido certificato per il Code Signing. Gli articoli che ne hanno dato notizia l'hanno messa, chi più chi meno, nella solita forma "pro-Microsoft": trovato il modo per aggirare la funzionalità di sicurezza, buco in Vista, e cosi via...
Con parole semplici, come funziona il tool Atsiv ? Primo passo: installa dei driver firmati. Chi può installare driver ? Solo un amministratore. Sapete già dove vado a parare, visto che abbiamo già toccato l'argomento:

l'azione esplicita di un amministratore di installare del software a sua discrezione può essere considerata un buco di sicurezza del sistema operativo, secondo gli attuali modelli informatici ?
Io non credo proprio.

Ho poi sottolineato che i driver sono firmati: in quanto tali vi sembra che la policy di Vista x64 sia stata aggirata ? No. Secondo passo: questi driver caricano il proprio loader che è in grado di caricare quello che vuole, e quindi anche driver non firmati, e di farlo anche in modo che si nascondano alla rilevazione da parte dei tool. Come interpretate questo comportamento così descritto ? Se ci fate caso è la tipica descrizione di un trojan che si installa come rootkit. E' per questo che Microsoft è corsa ai ripari e già ieri, 2 agosto, ha classificato questo tool come potenziale spyware in Windows Defender, a concordare con Verisign la revoca del relativo certificato e a valutare se aggiungere tale chiave revocata anche alla lista di revoca propria del meccanismo KMCS: vi consiglio la lettura del post su Windows Vista Security con valutazioni e dettagli. Quali sono le riflessioni "filosofiche" di cui vi dicevo ? Intanto la considerazione del precedente paragrafo rientrato: un limite oggettivo del modello degli attuali sistemi operativi è che la sicurezza del sistema si appoggia su un set di codice di base che sia considerato sicuro e affidabile (Trusted) al tempo 0, il cosiddetto TCB. Dal momento che l'amministratore ha autorità di estendere il TCB con codice arbitrario, può di fatto invalidare tutta la sicurezza del sistema, fine. In che cosa cerca di migliorare questo modello la policy KMCS ? Estendere la funzionalità Authenticode a tutto il codice da caricare nel kernel significa solo aumentare l'identificazione di chi ha scritto il codice che sta entrando nel Kernel e quindi nel TCB. Ma se non si trova un modo per poter certificare e valutare la qualità e l'affidabilità del codice che estende il TCP, non aiutiamo l'utente amministratore nelle sue valutazioni costringendolo ad essere l'anello debole della sicurezza dei suoi sistemi, come dice con ragione Larry Seltzer che chiude l'articolo di eWeek su Atsiv dicendo "the most important security device is the one sitting at the keyboard". 

Comments
  • Ragionamento ineccepibile.

    Non sono un utente Windows ma bensì OSX. Nulla può sulla negligenza dell'amministratore perché nessun sistema deve interferire sulle attività eseguite da chi si presenta come Amministratore. Lui deve sempre avere completa coscienza delle sue azioni e in maggior modo sulle conseguenze.

    Lui deve poter anche formattare il sistema senza neanche troppi alert. Lui deve sempre sapere cosa sta facendo o cosa sta installando.

    Quindi, se per installare un virus o un trojan si deve essere amministratori, il problema di certo non è dell'OS ma della persona che si spaccia per Admin.

    Su Windows anche il niubbo si autentica come Amministratore sulla propria macchina. Se proprio si vuol coprire questo bacino di utenze, fate in modo che anche venga richiesta nuovamente la password quando l'operazione eseguita tenta di installare cose che solo l'amministratore dovrebbe fare. Almeno per avvisare che si sta cercando di fare un'azione che potrebbe essere doppiamente pericolosa (molti utenti windows la prenderebbero come una scocciatura).

    Cmq, molti non hanno neanche coscienza di utilizzare il proprio PC con il ruolo di ADMIN, non sanno neanche cosa sia un Admin.

    Ci vuole più igiene dell'informatica. Molti utenti windows pensano che sia semplicemente una lista di attività igieniche da operare sul proprio case, tastiera e monitor.

    Questo è il mio parere.

  • Ciao Simone, la funzionalità che richiedi sia presente per richiedere nuovamente la password di fronte ad operazioni amministrative è proprio la feature di User Account Control introdotta in Windows Vista (ne trovi qualche dettaglio in un paio di miei post nella categoria Windows Vista Security). Ma visto che usi OSX condividi come affronta questa problematica: non credo che OSX possa fare a meno dell'amministratore, e quindi perché il "niubbio" non dovrebbe autenticarsi su OSX ?

  • ... ovviamente no ! Io invece ho cercato di farlo a dispetto della combinazione peggiore di data per

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment