Diversi file eseguibili firmati da Microsoft hanno apparentemente la stessa firma!

Question

Diversi file eseguibili firmati da Microsoft hanno apparentemente la stessa firma!

#1 da (2 voti)

0

Sui sistemi Windows 10, ho trovato due versioni di bootsect.exe (un'utilità fornita da Microsoft che scrive il settore di avvio del disco) con diversi hash (SHA-1 9b7463c79460a55a36b53bee0889f894b2379ec3 per una 67ea7b4a6d73831600a141f053139b33fe90f1d8 per l'altro), ma su la superficie di esso ha la stessa firma Microsoft valida datata 2015-10-30.

Analisi approfondita della proprietà / scheda della firma digitale rivela

stessa data di firma visualizzata (2015-10-30 03:32:09 UTC dopo la traduzione dalle mie impostazioni internazionali)
stessa firma visualizzata (numero di serie, hash, date ..)
diverse controfirme:
- periodo di validità 2015-10-07 18:17:29 a 2017-01-07 18:17:29 UTC e OU = nCipher DSE ESN:98FD-C61E-E641 per uno
- periodo di validità 2015-10-07 18:17:40 a 2017-01-07 18:17:40 UTC e OU = nCipher DSE ESN:7D2E-3782-B0F7 per l'altro (probabilmente correlato al timestamping utilizzato da HSM).

Usando un editor esadecimale, vedo in particolare queste differenze

con offset 0x148..0x14A (unica differenza fino a dopo il 92% del file, dove la firma e la controfirma sembrano vivere)
- 06 33 02 per uno
- 33 DF 01 per l'altro
una stringa di data con un byte di lunghezza iniziale, per lo più corrispondente alla data della firma come mostrato nell'interfaccia utente
- 20151030033209.248Z per uno
- 20151030033209.24Z per l'altro
stringhe di data con periodo di validità della controfirma corrispondente al byte di lunghezza iniziale, come mostrato
- 151007181729Z e 170107181729Z per uno
- 151007181740Z e 170107181740Z per l'altro

Domande:

Perché sono due versioni di questa utilità?
Quali sono le differenze operative tra queste?
Qual è la probabile ragione della differenza (1)?
Non sarebbe banale che il programma firmato agisse in modo diverso sulla base di quella (o delle diverse controfirme), vanificando uno degli scopi della firma digitale?
Quale può essere il ruolo esatto delle stringhe di data in (2.) e perché differiscono per dimensioni? Si suppone che siano correlati alla build del software, alla data della firma o alla data della controfirma?
Perché i periodi di validità in (3) differiscono di 11 secondi, quando le stringhe di data in (2) differiscono solo di 8/1000 secondi?
Perché non c'è un secolo nella definizione interna del periodo di validità? E 'permesso da X.509 o qualunque standard definisce le firme (contatore)? Non è un rischio che una (controfigura) firma di nuovo valida nell'anno 2116?

microsoft digital-signature timestamp

posta fgrieu 31.01.2016 - 18:13

fonte

1 risposta

Leggi altre domande sui tag microsoft digital-signature timestamp

L'autenticazione wifi tipica dell'hotel è insicura? [duplicare] Personal Cloud Storage vs. Servizi di condivisione file

score 2 · Answer 1

Alcune domande possono essere risolte, altre sono speculative.

X.509 si basa su ASN.1 . ASN.1 definisce due tipi di dati per le date, UTCTime e GeneralizedTime . UTCTime ha solo due cifre per l'anno, quindi non è Y2K-clean; è stato definito alla fine degli anni '80 da ciò che può essere descritto come una consumata mancanza di lungimiranza. È stato temporaneamente risolto definendo che UTCTime copre davvero gli anni dal 1950 al 2049, rendendo l'interpretazione univoca. Le date oltre il 2049 devono utilizzare GeneralizedTime , che ha cifre di quattro anni e quindi va bene fino al 31 dicembre 9999.

Pertanto, gli anni a due cifre sono un simbolo di incompetenza, ma non un problema di sicurezza stricto sensu .
Il formato GeneralizedTime (con quattro cifre per l'anno) può contenere secondi frazionari, indicati da un punto seguito da cifre aggiuntive. Il numero di cifre extra è teoricamente illimitato; tuttavia, al momento della codifica, gli zeri finali dovrebbero essere rimossi. Se vedi "20151030033209.248Z" e "20151030033209.24Z", allora queste date sono state misurate con precisione (almeno) millisecondo, ma in quest'ultimo il numero di millisecondi era "240" e lo zero finale è stato rimosso.
Di solito, la firma e l'indicazione dell'ora vengono eseguite da macchine distinte; il timestamp viene eseguito da un'Autorità di timestamp dedicata che ha il compito di mantenere un orologio accurato. Il timestamp è spesso ritardato. Nel tuo caso, vedi che l'indicazione dell'ora si è verificata quattro giorni dopo la firma.
Trovo alcuni rapporti che le due versioni di bootsect.exe corrispondono a due diverse build di Windows, chiamate "10.0.10586.0 (th2_release.151029-1700)" e "10.0.10135.0 (winmain_prs.150531-1700 ) ", rispettivamente. Secondo questo sito , quest'ultimo è una build interna Microsoft che è stata trapelata il 6 giugno 2015, ma non era pensata per il rilascio ed è quindi relativamente rara in natura.

Da queste informazioni, I deduce quanto segue: all'interno del processo di compilazione di Microsoft (che è probabilmente abbastanza complesso), due versioni di bootsect.exe sono state compilate contemporaneamente, differendo probabilmente solo nel "build number" (suppongo che i tuoi byte con offset 0x148 siano parte del numero di build) e firmati in breve successione (8 millisecondi tra le due firme). Le due versioni potrebbero corrispondere a versioni "stabile" e "sviluppo" con diverse opzioni di costruzione, ma integrate nello stesso processo di compilazione. Queste due versioni sono state quindi pianificate per l'indicazione dell'ora, che si verifica altrove, su un'altra macchina, con la propria coda. I due timestamp sono stati eseguiti pochi giorni dopo, con un ritardo di 11 secondi tra i due file: si deve immaginare che l'accodamento non sia completamente "in ordine" e che i file in coda in successione possano essere gestiti in modo diverso volte.

È improbabile che i due file si comportino diversamente. La firma utilizza Authenticode , che copre il file completo tranne i pochi campi che non possono essere logicamente parte di esso, cioè quelli per la firma e i certificati e il checksum dell'intestazione. È possibile per un eseguibile firmato ispezionare il proprio binario e sfruttare una differenza di un byte nell'intestazione per cambiare il suo comportamento, ma questo è abbastanza artificiale: il codice deve farlo apposta. Si suppone che le firme proteggano da alterazioni dannose di file onesti, non da eseguibili shifty che tentano di eseguire inganni subdoli.

La mia conclusione è quindi che il tuo due bootsect.exe corrisponde a due build distinti che si sono verificati simultaneamente all'interno del processo di compilazione Microsoft, e per due versioni del codice sorgente che sono, in effetti, identiche, portando così al stesso comportamento. I due file sono stati firmati in breve successione, timbrati alcuni giorni dopo indipendentemente l'uno dall'altro, e uno era parte di una versione ufficiale mentre l'altro era una build interna che è stata fatta trapelare.