¿Cómo obtener cualquier certificado en Internet? Simplemente pregúntele a SSL.com

El centro de certificación SSL[.]com se vio envuelto en un escándalo después de que un investigador de seguridad informática, que opera bajo el seudónimo de Sec Reporter, demostrara una vulnerabilidad que permitía emitir un certificado TLS falso para el dominio del importante servicio en la nube chino Alibaba Cloud.

El error radicaba en la implementación del método de verificación del control del dominio mediante un registro DNS. Según lo previsto, el usuario que desea obtener un certificado debe añadir un registro de texto en el DNS con una dirección de correo electrónico para recibir un código único de verificación. Sin embargo, el sistema interpretaba erróneamente el dominio del correo electrónico como verificado. Así, si alguien podía recibir correos en, por ejemplo, vulture@example[.]com, de repente tenía la posibilidad de solicitar un certificado también para example.com.

Sec Reporter aprovechó esta falla indicando una dirección de correo electrónico en el dominio aliyun.com y obtuvo certificados para aliyun[.]com y www[.]aliyun[.]com, que pertenecen a Alibaba. Aunque el investigador no era propietario ni administrador del recurso, el sistema de SSL[.]com igualmente confirmó el derecho a emitir certificados.

SSL[.]com ya ha reconocido el error y ha comenzado a corregirlo. Se revocaron 11 certificados emitidos utilizando este método. Además de aliyun.com, la lista incluye dominios de la empresa canadiense Medinet, del proveedor de soluciones logísticas de Singapur Gurusoft, del servicio publicitario BetVictor y de otros recursos menos conocidos.

Por ahora se desconoce si estos certificados fueron utilizados por atacantes en incidentes reales, pero la mera posibilidad de tal escenario representa una amenaza grave. Certificados de este tipo podrían utilizarse para crear sitios web falsos, robar datos y capturar tráfico cifrado, lo cual es especialmente peligroso en contextos de phishing y ataques del tipo "hombre en el medio".

La empresa ya ha desactivado temporalmente el método de verificación en cuestión y ha prometido presentar un informe completo del incidente a más tardar el 2 de mayo. Según los datos preliminares, el problema surgió debido a una implementación incorrecta del punto 3.2.2.4.14 en la política de certificación de SSL[.]com, que describe el proceso de validación mediante correo electrónico especificado en DNS.

El incidente resalta la importancia de una implementación confiable de todos los niveles de seguridad en la infraestructura de certificados digitales, especialmente en aquellos mecanismos donde la automatización se combina con la confianza en el DNS.