Cos’è l’Authenticode Microsoft?
L’Authenticode è una misura di sicurezza per i file eseguibili e i file del catalogo di Windows. Può essere utilizzato per garantire che la sorgente è attendibile e che i file non sono stati manomessi. Si basa sulle seguenti tecnologie: Public Key Cryptography Standards (PKCS) #7 (specifica chiavi crittografate), PKCS #10 (formati richieste certificati), X.509 (specifica certificato), Secure Hash Algorithm (SHA) e algoritmi di hashing MD5.
Come funziona?
Come puoi vedere dall’immagine seguente, l’Authenticode sostanzialmente aggiunge un certificato digitale alla fine del file. I valori in grigio (checksum e tabella certificati nell’intestazione delle directory di dati) non sono considerati per la creazione della firma Authenticode. Modificando il valore checksum del file, ad esempio, la firma digitale rimane valida.
Elusione dell’Authenticode
Come indicato nell’ultimo articolo, che spiega perché non si deve utilizzare MD5 per l’hashing, il motivo per cui non conviene utilizzarlo per la firma del codice è chiaro. È possibile, infatti, generare un file nocivo con lo stesso MD5 di un file in chiaro: se il programma in chiaro a cui è stata apposta la firma digitale utilizza l’hashing MD5 per la firma del codice e l’autore del malware si serve del metodo Collision Attack o del metodo Chosen Prefix Collision più dispendioso, può creare un file nocivo con MD5 identico a quello originale. All’autore del malware, quindi, basta copiare e incollare nel malware la firma dal programma autentico in modo tale che il malware includa la firma valida del produttore originale.
Una dimostrazione è fornita sul seguente sito Web:
https://blog.didierstevens.com/2009/01/17/playing-with-authenticode-and-md5-collisions/
Anche se non si utilizza MD5 per firmare il codice dei programmi, esistono altri metodi per aggiungere o modificare dati in un file dotato di firma senza invalidarlo. In alcuni casi, inoltre, il produttore originario apporta lievi modifiche all’eseguibile binario senza modificare il certificato digitale. Tali casi sono così eclatanti da lasciare interdetti. Esempio: un produttore fornisce programmi di installazione personalizzati ai clienti; l’eseguibile binario per il programma di installazione è identico per tutti i clienti, ma il produttore può includervi anche informazioni personalizzate come il nome utente del cliente o altro. Il produttore potrebbe apporre la firma digitale in ogni programma di installazione per ogni singolo cliente; ma se i download del programma sono migliaia ogni giorno, firmare tutti i programmi diventerebbe un lavoro eccessivamente lungo e dispendioso.
Attualmente esistono due tecniche note per aggiungere dati a un file binario dotato di firma digitale, senza invalidare il certificato:
- Riempimento della struttura del certificato
- Attributi invalidati
Il riempimento della struttura del certificato comporta l’aggiunta di dati subito dopo la parte PKCS#7 della tabella del certificato di attributo. Generalmente, le dimensioni dei dati PCKS #7 sono inferiori a quelle specificate (definite in una struttura WIN_CERTIFICATE), per cui lo spazio rimanente viene riempito per lo più con byte zero. Questo piccolo spazio può essere utilizzato per salvare alcuni dati supplementari invece dei byte zero senza invalidare la firma.
Tecnica degli attributi invalidati: i certificati digitali contengono vari ID oggetto (OID) che servono a identificare i dati contenuti nel certificato. Per ottenere l’ora della firma, ad esempio, si individua l’oggetto con ID = “1.2.840.113549.1.9.5” corrispondente all’oggetto szOID_RSA_signingTime, che contiene i dati richiesti. Questo sistema è concepito in modo che in futuro possono esserci nuovi oggetti con nuovi OID, per cui è possibile sfruttare questa circostanza per creare nuovi OID non standard per includervi i dati desiderati. È sufficiente l’inizializzazione con byte zero e l’inserimento di dati personalizzati per ogni cliente per non invalidare la firma.
In realtà questi due metodi sono scarsamente utilizzati per vari motivi e in futuro è possibile che verranno totalmente abbandonati. Se viene utilizzato uno di questi metodi, tuttavia, la memorizzazione dei dati in queste aree richiede molta prudenza. Si è verificato un caso in cui uno sviluppatore ha utilizzato la tecnica del riempimento della struttura del certificato per memorizzare vari URL per il download e l’installazione del proprio software. Il malware sfruttava questa tecnica per modificare gli URL per il download e l’installazione del malware senza invalidare il certificato del produttore originale.
Come riportato nel bollettino MS13-098, con il riempimento del certificato è possibile disabilitare la convalida delle firme: basta modificare una voce del registro… Magari in futuro ciò avverrà per default.
Lo speriamo!
