Una autoridad de certificación envió el remate de un chiste de XKCD
Una revelación impactante del investigador de seguridad "Wayne" el 17 de octubre reveló un fallo profundo en la infraestructura de clave pública: ocho certificados intermedios de eMudhra, incluyendo autoridades de TLS y de firma de código, fueron comprometidos. Las claves privadas subyacentes para estos certificados, en las que confiaron los principales navegadores y sistemas operativos durante 17 meses, eran enteros trivialmente pequeños; uno era literalmente el número 4.
Estas claves dependían de la curva elíptica P-384, que normalmente requiere que un private scalar (d) sea un número grande e impredecible de 384 bits, ofreciendo aproximadamente $10^{115}$ posibilidades. En cambio, las claves comprometidas de eMudhra presentaban 47 bytes iniciales de cero, con el byte final conteniendo un valor lo suficientemente pequeño como para ser atacado por fuerza bruta con un máximo de 255 candidatos.
Esta debilidad catastrófica permitió la recuperación inmediata de las claves privadas. Los valores identificados fueron:
- 4
- 56
- 66
- 115
- 155
- 156
- 230
- 237
A pesar de su tamaño minúsculo, estos enteros todavía producen puntos de clave pública matemáticamente válidos en la curva. Esto significa que los certificados pasaron las comprobaciones estructurales estándar, ocultando la fragilidad criptográfica subyacente. Google Chrome y Firefox bloquearon rápidamente estos certificados, seguidos por Apple y Microsoft.
El error dejó un rastro documental y una alarma ignorada
La causa reportada se remonta a una April 2025 key ceremony donde eMudhra modificó un script para probar exportaciones de claves. Este script generó inadvertidamente pares de claves adicionales débiles en el Hardware Security Module (HSM). Los operadores, engañados por etiquetas similares, utilizaron estas claves comprometidas para las solicitudes de certificados, en lugar de las claves criptográficamente fuertes previstas.
Crucialmente, surgió una advertencia en junio de 2025. Sectigo, el firmante cruzado, informó de firmas no válidas en las Listas de Revocación de Certificados (CRL) de eMudhra. Esta discrepancia ocurrió porque eMudhra intentó firmar las CRL con sus claves originales y fuertes, que no correspondían a las claves débiles integradas en los certificados emitidos.
En lugar de investigar la discrepancia subyacente, eMudhra volvió a firmar las listas de revocación utilizando las claves débiles. Esta solución temporal ocultó efectivamente el síntoma, permitiendo que el fallo de seguridad fundamental persistiera durante 16 meses más.
Operativamente, este incidente subraya dos lecciones críticas. Las ceremonias de claves exigen independent identity and strength checks en todo el material criptográfico generado. Además, cualquier discrepancia en la firma, particularmente en el contexto de una infraestructura de clave pública, debe activar una respuesta inmediata ante incidentes en lugar de una solución superficial.
Los navegadores tenían barreras de seguridad. Los sistemas de compilación a menudo no las tienen
Sectigo firmó de forma cruzada los intermedios de eMudhra, dándoles un amplio alcance en los almacenes de confianza de las plataformas. El investigador Wayne demostró el control al firmar un mensaje de prueba, "We have a problem here", con cada una de las ocho claves comprometidas. Esto confirmó el compromiso de las claves y destacó el potencial generalizado de uso indebido.
Navegadores como Google Chrome y Mozilla Firefox revocaron rápidamente los certificados, a menudo en cuestión de horas. Estos aplican registros de Certificate Transparency (CT), que registran públicamente todos los certificados TLS de confianza. Los navegadores suelen rechazar los certificados que no están presentes en estos registros, una salvaguarda crítica que evitó la explotación directa en los navegadores.
Sin embargo, los clientes que no son navegadores a menudo carecen de estas defensas robustas. Herramientas como curl, Python, Node, Go y Git dependen frecuentemente de paquetes de CA locales, omitiendo por completo las comprobaciones de CT o revocación. Esto los deja vulnerables a ataques de machine-in-the-middle (MITM).
Las consecuencias prácticas son considerables. Un atacante que posea una de estas claves falsificadas podría atacar:
- Llamadas a API
- Scripts de instalación
- Ejecutores de CI
- Credenciales en la nube
Las dos claves de firma de código comprometidas también generaron preocupaciones sobre software falsificado, lo que podría distribuir actualizaciones o aplicaciones maliciosas. Para obtener más detalles técnicos, consulte Mozilla Bugzilla: eMudhra Private Key Compromise of Intermediate Certificates.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Actualice el almacén de confianza y luego pruebe todo el pipeline
Los proveedores de navegadores y los operadores de plataformas actuaron rápidamente para desconfiar de los certificados afectados. Apple, Google Chrome, Microsoft y Mozilla bloquearon los intermediarios comprometidos en cuestión de días, mientras que Sectigo terminó su acuerdo de firma cruzada con eMudhra. Go emitió una versión de emergencia específica, la 1.27.3, bloqueando directamente estos ocho intermediarios dentro de su biblioteca estándar.
La cobertura de actualizaciones de dispositivos y software aún puede variar, especialmente para sistemas integrados. Para mitigar el riesgo, actualice su sistema operativo y los paquetes de CA de inmediato. Actualice los entornos de ejecución de lenguajes como Go a la versión 1.27.3 y el paquete certifi de Python a la 2026.10.19. Reconstruya las imágenes de contenedor y los ejecutores de CI/CD para asegurarse de que todas las dependencias estén actualizadas.
Pruebe sus clientes contra el endpoint de prueba del incidente publicado, DV G3B eMudhra.we-have-a-problem.com. Si su cliente rechaza la cadena de certificados con un error, es seguro. Este paso de validación es crucial para todos los sistemas que dependen de la confianza en los certificados.
El incidente subraya una lección crítica de PKI: las comprobaciones de formato no pueden probar la aleatoriedad o la intención. Automatice las comprobaciones de fortaleza de las claves como parte de las ceremonias de claves. Valide que las claves públicas de los certificados coincidan precisamente con las claves HSM previstas, no solo que sean estructuralmente válidas. Supervise los registros de Certificate Transparency (CT) y trate las firmas de revocación no válidas, como la advertencia de Sectigo de junio de 2025, como emergencias de seguridad graves.
Preguntas frecuentes
¿Qué estaba mal con las claves privadas de eMudhra?
Ocho certificados de CA intermedios utilizaron valores de clave privada minúsculos, incluido el 4, en lugar de valores impredecibles de 384 bits. Las claves correspondientes podían recuperarse probando solo unas pocas posibilidades.
¿Estaban en riesgo los usuarios comunes de navegadores?
Los requisitos de Certificate Transparency de los navegadores modernos ayudaron a bloquear certificados falsificados no registrados, aunque las protecciones y actualizaciones variaron. El software que no es un navegador a menudo carece de comprobaciones equivalentes.
¿Por qué los pipelines de CI eran motivo de preocupación?
Las herramientas y servicios en los pipelines de compilación pueden confiar en paquetes de CA locales sin verificar la Certificate Transparency o la revocación de certificados, aceptando potencialmente un certificado de servidor falsificado.
¿Qué deberían hacer los desarrolladores?
Actualizar los almacenes de confianza del sistema operativo y del entorno de ejecución del lenguaje, reconstruir los contenedores afectados y probar el comportamiento de validación de certificados de los clientes que no son navegadores y de los ejecutores de CI.