¡Diferentes archivos ejecutables firmados por Microsoft tienen aparentemente la misma firma!

0

En los sistemas Windows 10, encontré dos versiones de bootsect.exe (una utilidad suministrada por Microsoft que escribe el sector de arranque del disco) con hashes diferentes (SHA-1 9b7463c79460a55a36b53bee0889f894b2379ec3 para uno 67ea7b4a6d73831600a141f053139b33fe90f1d8 para el otro), pero en la superficie de la misma es la firma válida de Microsoft con fecha del 30-10-2015.

Un análisis más detallado de la pestaña de propiedad / firma digital revela

  • se muestra la misma fecha de la firma (2015-10-30 03:32:09 UTC después de la traducción de mi ubicación)
  • se muestra la misma firma (número de serie, hash, fechas ...)
  • contrasignaturas diferentes:
    • período de validez 2015-10-07 18:17:29 a 2017-01-07 18:17:29 UTC y OU = nCipher DSE ESN:98FD-C61E-E641 para uno
    • período de validez 2015-10-07 18:17:40 a 2017-01-07 18:17:40 UTC y OU = nCipher DSE ESN:7D2E-3782-B0F7 para el otro (probablemente relacionado con el sello de tiempo HSM utilizado).

Al utilizar un editor hexadecimal, veo en particular estas diferencias

  1. en el desplazamiento 0x148..0x14A (única diferencia hasta después del 92% del archivo, donde la firma y la firma de firma parecen existir)
    • 06 33 02 para uno
    • 33 DF 01 para el otro
  2. una cadena de fecha con byte de longitud inicial, que coincide principalmente con la fecha de la firma como se muestra en la interfaz de usuario
    • 20151030033209.248Z para uno
    • 20151030033209.24Z para el otro
  3. cadenas de fecha con el byte de longitud inicial que coinciden con el período de validez de la contrasignación como se muestra
    • 151007181729Z y 170107181729Z para uno
    • 151007181740Z y 170107181740Z para el otro

Preguntas:

  • ¿Por qué son dos versiones de esta utilidad?
  • ¿Cuáles son las diferencias operativas entre estos?
  • ¿Cuál es la razón probable de la diferencia (1.)?
  • ¿No sería trivial que el programa firmado actúe de manera diferente en función de eso (o las diferentes firmas de contra-firma), derrotando uno de los propósitos de la firma digital?
  • ¿Cuál puede ser el rol exacto de las cadenas de fecha en (2.) y por qué difieren en tamaño? ¿Se supone que están relacionados con la compilación de software, la fecha de firma o la fecha de firma?
  • ¿Por qué los períodos de validez en (3) difieren en 11 segundos, cuando las cadenas de fecha en (2) difieren solo en 8/1000 segundos?
  • ¿Por qué no hay un siglo en la definición interna del período de validez? ¿Está permitido por X.509 o cualquier estándar que defina las firmas (de contador)? ¿No es eso un riesgo de que una (contra) firma vuelva a ser válida en el año 2116?
pregunta fgrieu 31.01.2016 - 18:13
fuente

1 respuesta

2

Algunas preguntas pueden ser respondidas, otras son especulativas.

  • X.509 se basa en ASN.1 . ASN.1 define dos tipos de datos para fechas, UTCTime y GeneralizedTime . UTCTime tiene solo dos dígitos para el año, por lo que no es Y2K-clean; Se definió a fines de la década de los ochenta de lo que solo puede describirse como una falta consumada de previsión. Se solucionó temporalmente al definir que UTCTime realmente cubre los años 1950 a 2049, lo que hace que la interpretación sea inequívoca. Las fechas posteriores al 2049 utilizarán GeneralizedTime , que tiene dígitos de cuatro años y por lo tanto está bien hasta el 31 de diciembre de 9999.

    Por lo tanto, los años de dos dígitos son un símbolo de incompetencia, pero no un problema de seguridad stricto sensu .

  • El formato GeneralizedTime (con cuatro dígitos para el año) puede contener segundos fraccionarios, indicados por un punto seguido de dígitos adicionales. El número de dígitos adicionales es teóricamente ilimitado; sin embargo, al codificar, se supone que se eliminan los ceros finales. Si ve "20151030033209.248Z" y "20151030033209.24Z", entonces estas fechas se midieron con (al menos) milisegundos de precisión, pero en este último, el número de milisegundos fue "240" y se eliminó el cero final.

  • Por lo general, la firma y la marca de tiempo se realizan en distintas máquinas; el sellado de tiempo lo realiza una autoridad de sellado de tiempo dedicada cuyo trabajo es mantener un reloj preciso. El sellado de tiempo se retrasa a menudo. En su caso, verá que el sellado de tiempo ocurrió cuatro días después de la firma.

  • Encuentro algunos informes de que las dos versiones de bootsect.exe corresponden a dos versiones diferentes de Windows, llamadas "10.0.10586.0 (th2_release.151029-1700)" y "10.0.10135.0 (winmain_prs.150531-1700 ) ", respectivamente. Según este sitio , este último es una compilación interna de Microsoft que se filtró el 6 de junio de 2015, pero no fue lanzada y por lo tanto es relativamente rara en la naturaleza.

A partir de esta información, deduzco lo siguiente: dentro del proceso de compilación de Microsoft (que probablemente es bastante complejo), se compilaron dos versiones de bootsect.exe al mismo tiempo, y probablemente solo se diferenciaron en el "número de compilación" (supongo que sus bytes en el desplazamiento 0x148 son parte del número de compilación) y firmados en breve sucesión (8 milisegundos entre las dos firmas). Las dos compilaciones pueden corresponder a versiones "estables" y "desarrollo" con diferentes opciones de construcción, pero integradas dentro del mismo proceso de compilación. Estas dos versiones se programaron para la marca de tiempo, que se produce en otro lugar, en otra máquina, con su propia cola. Los dos sellos de tiempo se realizaron unos días más tarde, con un retraso de 11 segundos entre los dos archivos. Uno tiene que imaginar que la cola no está completamente "en orden" y los archivos que se colocaron en cola en una sucesión corta pueden manejarse a diferentes niveles. veces.

Es improbable que los dos archivos se comporten de manera diferente. La firma utiliza Authenticode , que cubre el archivo completo, excepto los pocos campos que no pueden ser parte lógicamente de él, es decir, aquellos para la firma y los certificados, y la suma de comprobación del encabezado. Es posible que un ejecutable firmado inspeccione su propio binario y aproveche una diferencia de un byte en el encabezado para cambiar su comportamiento, pero esto es bastante artificial: el código tiene que hacerlo a propósito. Se supone que las firmas protegen contra las alteraciones malintencionadas de los archivos honestos, no contra los ejecutables falsos que intentan realizar trucos maliciosos.

Por lo tanto, mi conclusión es que sus dos bootsect.exe corresponden a dos compilaciones distintas que se realizaron al mismo tiempo dentro del proceso de compilación de Microsoft, y para dos versiones del código fuente que son, de hecho, idénticas, lo que lleva a la mismo comportamiento Los dos archivos se firmaron en breve sucesión, el sello de tiempo se realizó unos días más tarde de forma independiente, y uno fue parte de un lanzamiento oficial, mientras que el otro fue una compilación interna que se filtró.

    
respondido por el Tom Leek 01.02.2016 - 15:37
fuente

Lea otras preguntas en las etiquetas