Por Canuto  

Ocho certificados intermedios de eMudhra tenían claves privadas de apenas 3 a 8 bits, una debilidad que podría permitir la creación de credenciales falsas para sitios de Internet. Aunque fabricantes de navegadores y algunos proveedores de aplicaciones y lenguajes ya los bloquearon, la actualización de sistemas Linux, VPN y dispositivos olvidados podría prolongar la respuesta.
***

  • Las claves privadas comprometidas tenían tamaños de apenas 3 a 8 bits, frente a los 384 bits de una clave NIST P-384.
  • Fabricantes de navegadores y algunos proveedores de aplicaciones y lenguajes bloquearon los certificados, pero las actualizaciones para Linux y dispositivos integrados siguen siendo un desafío.
  • Los registros de transparencia no mostraban uso malicioso; aun así, explotar las claves requeriría un ataque activo de intermediario.

 

Ocho certificados bajo sospecha

Ocho certificados TLS intermedios vinculados con la autoridad de certificación india eMudhra Limited encendieron alertas entre equipos de seguridad, fabricantes de navegadores y desarrolladores. Sus claves privadas eran tan débiles que podrían permitir a quien las controle crear certificados no autorizados que parezcan confiables para navegadores y aplicaciones, incluso para sitios web de terceros. El hallazgo no equivale a que todos esos sitios hayan sido atacados, pero sí expone una falla capaz de socavar la confianza que sostiene las conexiones cifradas.

La señal pública del problema apareció durante el fin de semana en emudhra.we-have-a-problem.com, donde se publicó el mensaje «Tenemos un problema aquí, Wayne». El aviso estaba firmado digitalmente con la clave privada de uno de los certificados de eMudhra, una prueba de que quien lo publicó controlaba esa clave. Para los defensores, el riesgo era inmediato: esa misma capacidad podía servir para firmar certificados falsos que otros sistemas aceptarían como legítimos.

La debilidad de las claves fue extraordinaria incluso para los especialistas que analizaron el incidente. Una clave privada NIST P-384 normal ofrece unos 384 bits de entropía y, por tanto, una cantidad de combinaciones cercana a 2 elevado a 384, un número de 116 dígitos; las claves afectadas, en cambio, tenían tamaños de apenas 3 a 8 bits. Los valores identificados fueron 4, 56, 66, 115, 155, 156, 230 y 237, detalla ArsTechnica.

Filippo Valsorda, ingeniero de criptografía y mantenedor de la criptografía del lenguaje de programación Go, describió el caso como algo que no debería ser posible. Planteó como hipótesis que una interfaz de generación de claves peligrosamente diseñada tuviera un parámetro de tamaño configurado por error, aunque la información disponible no establece cómo ocurrió la falla. Ben Cartwright-Cox, director de BGP.tools, especuló que pudo filtrarse a producción código de ejemplo, pero también señaló que resulta difícil saberlo.

Bloqueos rápidos y una actualización desigual

Para avanzada la mañana del martes 20 de octubre, fabricantes de navegadores y algunas aplicaciones y lenguajes de programación importantes ya habían bloqueado los ocho certificados intermedios, según Ars Technica. Esa respuesta reduce la posibilidad de que los sistemas actualizados acepten certificados fraudulentos emitidos con las claves comprometidas. Sin embargo, el bloqueo no llega automáticamente a todos los programas y equipos que dependen de sus propias copias de certificados confiables.

La respuesta técnica no había llegado de manera uniforme a todas las plataformas y el despliegue de medidas correctivas seguía en curso. El bloqueo de los certificados en algunos productos no permite concluir que todos los sistemas y hosts vulnerables ya estén protegidos: la cobertura depende de las medidas aplicadas por cada proveedor y de las actualizaciones que instalen los usuarios y administradores.

La parte más difícil puede estar en los sistemas menos visibles, como distribuciones de Linux, dispositivos integrados y equipos del Internet de las Cosas. Algunos todavía esperaban actualizaciones, mientras que administradores de sistemas debían instalarlas en numerosas máquinas. También hay herramientas de línea de comandos sin mantenimiento y programas que incluyen su propia copia de certificados raíz; Valsorda señaló que esto ocurre en algunos ecosistemas, como Python, y complica una solución centralizada.

Por esa diversidad, Valsorda comparó la tarea con una limpieza masiva, incluso mayor que la respuesta a Heartbleed. Explicó que intervienen más contextos, personas y tipos de sistemas, y que coordinar a tantos responsables suele tomar tiempo. La actualización no depende únicamente de corregir un navegador: cada proveedor, administrador o fabricante de dispositivos debe identificar qué componentes utiliza y aplicar los cambios correspondientes.

El antecedente de Heartbleed y los límites de los registros

Heartbleed fue una vulnerabilidad crítica de la biblioteca criptográfica OpenSSL que sufrió explotación masiva en 2014. Los ataques permitieron a numerosos hackers descifrar intercambios protegidos por TLS y recuperar, en algunos casos, claves privadas de certificados, cookies de sesión y contraseñas. Miles de servidores quedaron comprometidos, incluidos algunos de grandes empresas y agencias gubernamentales de distintos países.

La recuperación de Heartbleed exigió una cadena extensa de medidas: corregir OpenSSL en los dispositivos afectados, volver a emitir millones de claves TLS, revocar certificados antiguos y cambiar contraseñas y tokens de sesión. También hubo que actualizar dispositivos integrados y otros sistemas que podían quedar fuera de los procesos habituales de mantenimiento. Según Valsorda, esa respuesta tomó años y consumió muchos recursos, una advertencia sobre la escala potencial de la limpieza actual, no una afirmación de que ambos incidentes sean técnicamente idénticos.

Los registros de transparencia de certificados, que permiten rastrear la emisión de certificados confiables para navegadores, no mostraban hasta el reporte señales de uso malicioso de las claves comprometidas. Ese dato es relevante porque no se habían detectado certificados fraudulentos en esos registros, pero no elimina el riesgo ni demuestra por sí solo que nadie haya intentado un ataque. La protección también depende de que las partes interesadas supervisen activamente grandes volúmenes de información y respondan cuando aparece una emisión sospechosa.

Además, la transparencia sirve principalmente después de que se emite un certificado no autorizado, por lo que no sustituye el bloqueo de las claves ni la actualización de los sistemas. El incidente vuelve a mostrar que TLS puede fallar si uno de sus eslabones de confianza es débil, en este caso una autoridad de certificación cuyos certificados podían ser aceptados por numerosos equipos. Ars Technica informó que los representantes de eMudhra no estaban disponibles de inmediato para responder preguntas.

Qué significa para usuarios y redes

La amenaza más inmediata descrita en el reporte afecta especialmente a quienes usan VPN, sobre todo en países donde gobiernos podrían interceptar tráfico de forma maliciosa. El riesgo no implica que cualquier conexión cifrada quede expuesta de manera automática: para explotar certificados comprometidos, el atacante debe ejecutar un ataque activo de intermediario. En ese escenario, se ubica entre las dos partes que se comunican, recibe el tráfico, lo descifra, lo cifra de nuevo y lo envía al destino.

Ese tipo de operación suele requerir capacidades que están al alcance de atacantes con recursos considerables, aunque la dificultad disminuye para quien controla la red local por la que circula la conexión. Una persona que gestione la red de una cafetería, una universidad u otra organización enfrenta menos obstáculos para situarse en una posición de intermediario. La posibilidad de ese escenario explica por qué los certificados comprometidos preocupan incluso sin registros públicos que indiquen un uso malicioso.

Las aplicaciones Signal y WhatsApp, así como WireGuard, no resultan afectadas en los términos descritos porque no dependen de TLS para proteger la confidencialidad de sus comunicaciones. Para otros usos de TLS que no pasan por el navegador, los usuarios pueden tener que esperar a que los proveedores apliquen y distribuyan actualizaciones. El reporte también remite a una página que enumera aplicaciones conocidas ya corregidas, aunque la situación puede cambiar conforme se publiquen nuevos parches.

La recomendación práctica que se desprende del incidente es distinguir entre el bloqueo ya aplicado en algunos productos y la cobertura completa de todos los equipos. Un navegador actualizado puede rechazar los certificados mientras una herramienta independiente o un dispositivo conectado conserva una lista antigua de autoridades confiables. La ausencia de indicios de abuso en los registros es una señal favorable, pero el cierre de la brecha depende de que cada componente afectado reciba e instale su actualización.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados