Windows Update - Intercepción

Question

Windows Update - Intercepción

Navega tus respuestas

#1 de MiW CryptAnalytics (2 votos)
#2 de Thomas Pornin (1 votos)

3

Estoy tratando de monitorear las solicitudes / respuestas HTTP realizadas al realizar una actualización de Windows.

Tengo una máquina con Windows 8 configurada con un proxy en IE. También he importado a través de netsh para winhttp:

netsh winhttp import proxy source = ie

El proxy se está ejecutando en otra máquina en el puerto 8080 y está configurado para interceptar SSL.

He intentado con el proxy Burp o con un proxy Squid normal (usando ssl_bump). Los certificados de CA raíz se instalan en la máquina con Windows 8, en el almacén de la Máquina local, bajo CA de raíz de confianza. Si navego desde IE o Chrome, puedo acceder a los sitios https sin una advertencia (ya que el certificado de servidor presentado está firmado por la autoridad de certificación).

Sin embargo, si intento usar Windows Update, obtengo un error:

"Hubo un problema al buscar actualizaciones"

Este es un problema conocido, Bluecoat recomienda agregar una excepción para la intercepción SSL para Windows Update:

enlace

Microsoft hace la misma recomendación para TMG:

enlace

Parece que el servicio de Windows Update no solo comprueba el certificado de la forma habitual, sino que verifica la lista de CA diferentes o requiere específicamente un certificado de servidor determinado del sitio de Windows Update.

La pregunta es, ¿cómo puedo solucionar esto para poder ver las solicitudes HTTP realizadas por Windows Update?

tls updates windows proxy

pregunta user61451 03.03.2013 - 12:33

fuente

2 respuestas

Lea otras preguntas en las etiquetas tls updates windows proxy

CA interna para solución de firma digital - Basada en PKI ¿Cuáles son las mejores prácticas para la seguridad basada en RSA?

score 2 · Answer 1

Este problema me ha desafiado por un tiempo, pero encontró una manera de resolverlo. Normalmente se manifiesta como el error de actualización de Windows 80245006 o 803D000A

Escribí una herramienta llamada SuperPhishers DetermineSubCAIdentity.py en marzo de 2015 que le permitirá omitir la verificación interna de Windows de que los certificados son realmente de Microsoft. El nombre es un juego en la controversia de Lenovo SuperFish en el momento.

La parte fácil es que su proxy SSL genere algo moderno: como RSA > = 2048 y SHA256RSA, etc. Usé sslsplit y lo modifiqué para generar compendios SHA256. Windows requiere SHA256 en su actualización y almacena los certificados o falla con 0x803D000

La parte difícil es eludir las comprobaciones de Windows de que el certificado de CA es Microsoft:

Básicamente, hay dos funciones que implementan una verificación de que el certificado de CA es legítimo. Ambos se llaman DetermineSubCAIdentity en wuaueng.dll y storewuauth.dll Usando Nektra Deviare2, la función DetermineSubCAIdentity se enganchó para que siempre se completara dejando EAX = 3. Esto permite que el cheque de Microsoft pase y la función de actualización o almacenamiento continúa normalmente.

Si parcheas esta función en ambos archivos DLL, permite la intercepción del tráfico de la Tienda Windows. Revisa tu tráfico interceptado o corre a través de ICAP para reescribir la diversión.

Hice un video aquí: enlace

El código y el informe técnico están aquí: enlace

Thomas Pornin tiene razón en que necesita modificar los archivos DLL. Cuando modifiqué los archivos DLL en el disco, SFC los reemplazó con los buenos. Sin embargo, al hacerlo en memoria con Deviare2 inyectado en un proceso del SISTEMA, a Windows 8.1 no parece importarle.

Espero que esto ayude y que sea agradable ver que el tráfico de la Actualización de Windows está claro por primera vez.

score 1 · Answer 2

Entre las posibles actualizaciones se encuentran las actualizaciones de los contenidos predeterminados del propio almacén de confianza. Si Windows estaba usando el almacén de confianza predeterminado, cualquier CA en esa tienda podría editar una actualización falsificada que desalojaría a sus competidores. También podría alterar cualquier parte del sistema operativo. Para un sistema operativo, la ruta de las actualizaciones es muy sensible . Sería bastante arriesgado dar el poder de las actualizaciones a un centenar de CA. No se puede confiar realmente en que todos ellos hagan su trabajo correctamente (han ocurrido contratiempos, no muy a menudo, pero aún así ...).

Lo que podría intentar es agregar su certificado falso para el servidor SSL de Windows Update en el " editores de confianza " (el de la" computadora local "). Incluya el certificado de servidor falso en sí mismo, no la CA controlada por Burp que emite certificados falsos sobre la marcha (no sé si Burp puede usar un certificado falso no dinámico específico para un servidor determinado). Normalmente, esta tienda es para validar firmas en controladores, no para servidores SSL, pero dada la forma en que Microsoft maneja los certificados, esto puede funcionar y hacer lo que quiera (no tengo una máquina con Windows para probar eso ahora).

Si el código de Windows no usa un almacén de confianza de fácil acceso, sino que codifica la lista de certificados aceptables para el servidor de Windows Update, entonces tendrá que recurrir a modificaciones de DLL, como las escrituras de malware hacen para ganarse la vida. . El SO intentará defenderse activamente contra eso.