Incidente Digicert, o cuando una revocación de certificados termina en pleito

21 de agosto de 2024

Introducción

Estamos ya más que acostumbrados a que los navegadores nos avisen de una forma cada vez más agresiva de cuando nuestra navegación no es segura. Esta protección se realiza mediante el uso de certificados TLS/SSL. La comunicación entre nuestro navegador y el servidor que nos proporciona la información a que estamos accediendo se cifra y protege mediante claves públicas incluidas en esos certificados TLS.

El proceso de obtención y gestión de esos certificados es un juego con unas reglas muy claras que se definen de forma conjunta entre los principales navegadores de internet, Chrome, Firefox, Safari, Edge, y las autoridades certificadoras en un foro conocido como CABF por sus siglas en inglés (Certificate Authority Browser Forum)

Recientemente un incidente técnico detectado por DigiCert, una de esas Autoridades de Certificación (CA o Certificate Authority, en inglés), ha requerido la invalidación urgente y reemisión de un volumen apreciable de certificados. Pero a algunos clientes, en particular a alguna infraestructura crítica, digamos que no le ha sentado bien esta urgencia y ha demandado a Digicert por daños y perjuicios.

En este artículo repasaremos lo que ha sucedido, el impacto que ha tenido y sacaremos algunas conclusiones sobre que pasos se van a dar para mejorar este proceso a futuro.

¿Qué ha sucedido?

A finales de julio DigiCert advirtió que revocaría masivamente certificados SSL/TLS debido a un error en cómo la compañía verificó si un cliente poseía o operaba un dominio y requiere que los clientes afectados vuelvan a emitir certificados dentro de las 24 horas (el plazo finalizaba el 31 de julio)

DigiCert es una de las autoridades de certificación (CAs) prominentes que proporciona certificados SSL/TLS, incluyendo certificados Validados por Dominio (DV), Validados por Organización (OV) y de Validación Extendida (EV).

✅ Estos certificados se utilizan para cifrar la comunicación entre un usuario y un sitio web o aplicación, aumentando la seguridad contra la monitorización maliciosa de la red y los ataques de MiTM (man in the middle).

Al emitir un certificado para un dominio, la autoridad de certificación debe primero realizar la Verificación de Control de Dominio (DCV en inglés) para confirmar que el cliente es efectivamente el dueño del dominio.

Uno de los métodos utilizados para validar la propiedad del dominio es agregar una cadena con un valor aleatorio en el registro CNAME DNS del certificado y luego realizar una búsqueda DNS para el dominio para asegurarse de que los valores aleatorios coincidan.

Pongamos un ejemplo sacado del propio informe técnico del incidente de DigiCert: Si se solicita un certificado para foo.example.com, se puede agregar un registro DNS CNAME válido de tres maneras, siendo una de ellas:

1. _valorAleatorio.foo.example.com CNAME dcv.digicert.com

En esta forma de validación, se requiere un prefijo de guión bajo ('_') con el valorAleatorio. El requisito del prefijo de guión bajo en este caso se basa en el RFC1034, que requiere que los nombres de dominio comiencen con un carácter alfanumérico. Incluir un guión bajo significa que el subdominio utilizado para la validación nunca puede coincidir con un dominio real. No incluir el guión bajo se considera un riesgo de seguridad porque existe la posibilidad de una colisión entre un dominio real y el subdominio utilizado para la verificación.

DigiCert tras una investigación interna descubrió que el problema era que durante un período de aproximadamente 5 años (desde agosto de 2019), su plataforma no incluyó la validación de ese prefijo en el mecanismo de identificación del propietario de un dominio ni lo indicaba en su documentación.

Incluso cuando los clientes demostraron con éxito su identidad, y es muy poco probable que esto se haya abusado de alguna manera, esto rompió las reglas del CA/B Forum, iniciando el proceso de revocación urgente marcado en las “reglas del juego”.

4.9.1.1 Reasons for Revoking a Subscriber Certificate […] With the exception of Short‐lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs:

5. The CA obtains evidence that the validation of domain authorization or control for any Fully‐Qualified Domain Name or IP address in the Certificate should not be relied upon.

Impacto del incidente

En este caso, la compañía descubrió que casi 85.000 certificados TLS (aproximadamente el 0.4% de todos los certificados de DigiCert) se emitieron sin la presencia del mencionado guión bajo mientras había un error presente en su plataforma que no verificaba este punto.

¿Nunca había sucedido esto antes?

En el pasado, varias CA han ignorado incidentes de seguridad triviales como este. Defectos en los procedimientos de verificación que ocurrieron y fueron obviados, especialmente cuando las posibilidades de que algo así sea activamente explotado por un actor malicioso son minúsculas.

Sin embargo, el error de Digicert ocurrió en un momento “caliente”, justo cuando Google había retirado la confianza a dos CAs en las últimas semanas: GlobalTrust y entrust. Parece que Digicert no quiso enfurecer al equipo de seguridad de Google por el riesgo que supondría para todos sus clientes la eliminación de la confianza de sus certificados.

Así que DigiCert decidió seguir el procedimiento establecido a rajatabla y revocar todos esos certificados que emitió y estaban afectados mientras el error estuvo activo en su plataforma.

Cuando entran en escena los departamentos legales

DigiCert asegura que el proceso iba muy bien en su mayor parte hasta que comenzó a escuchar a los operadores de servicios críticos, donde los certificados no podían ser reemplazados con esa ventana de urgencia debido a estrictos requisitos de mantenimiento y tiempo de actividad.

Las cosas se pusieron más feas cuando uno de los clientes de DigiCert, el procesador de pagos de atención médica de EE. UU. Alegeus Technologies, demandó a la compañía y obtuvo una orden de judicial temporal favorable que impedía a DigiCert revocar su certificado.

Tras esto Digicert contactó con CABF forum para resolver esta delicada situación y acordó una ampliación del plazo de reemisión hasta el 3 de agosto para ciertos operadores de infraestructuras críticas afectados y un plazo mayor, todavía por establecer por los juzgados, para el caso que cuenta con una demanda judificial activa.

Conclusiones

Como conclusiones resaltamos principalmente dos:

Digicert en su informe del incidente se ha comprometido a liberar el código utilizado para el control de la validación de dominio (previsto para noviembre del 2024). Esto permitirá una revisión del mismo por parte de la comunidad y tratar de que este tipo de errores sean detectados de forma más temprana para minimizar el impacto.
De cara a las “reglas del juego” del CABF parece evidente que se deben incluir ciertas excepciones sobre las revocaciones de certificados de emergencia de 24 horas para operadores de infraestructuras críticas que no podrán honrar esa ventana por razones evidentes de continuidad.

Una cosa es revocar con urgencia un certificado TLS de un negocio común, y otra cosa bien distinta es revocar con urgencia el certificado del servicio de un centro de emergencias como el 112 o un servicio de informes de emergencia utilizado por el sector petroquímico, por ejemplo.

⚠️ Para recibir alertas de nuestros expertos en Ciberseguridad, suscríbete a nuestro canal en Telegram: https://t.me/cybersecuritypulse

____