La semana pasada, DigiCert reveló un problema de conformidad que afectaba a 83.267 certificados debido a un error en la verificación del control de dominios (DCV), lo que obligaba a revocarlos. Esto tiene implicaciones significativas para las organizaciones, que deben volver a emitir rápidamente estos certificados o enfrentarse a posibles interrupciones del servicio y a la pérdida de confianza de los usuarios.
En el momento de redactar este informe, Censys observó 26.373 certificados afectados aún en uso en hosts públicos, casi el 99% de los cuales han sido revocados. Este incidente sirve como otro recordatorio de las dificultades actuales para equilibrar el cumplimiento y el tiempo de respuesta para las organizaciones, siguiendo de cerca la reciente retirada de Entrust.
En este blog, examinamos los detalles del incidente, así como la perspectiva de Censyssobre su alcance, e identificamos las principales empresas e industrias afectadas.
Resumen ejecutivo
- En 28 de julio de 2024, DigiCert informó de un problema de cumplimiento debido a un error en su proceso de proceso de Verificación de Control de Dominio (DCV). El Foro de Navegadores de Autoridades de Certificación (CA/B) exige a DigiCert que revoque certificados afectados en un plazo de 24 horas para mantener la conformidad como autoridad de certificación de confianza.
- El incidente ha causado importantes trastornos, y las organizaciones se han apresurado a sustituir los certificados dentro del estricto plazo establecido. En particular, Alegeus, una empresa de tecnología financiera del sector sanitario, solicitó una orden judicial para retrasar el proceso de revocación, alegando el grave impacto operativo y la posible interrupción del acceso de los clientes.
- DigiCert ocupa actualmente el cuarto Autoridad de Certificación (CA) de confianza más activa en nuestro conjunto de datos, e informó de que 83.267 certificados únicos se vieron afectados por este problema. Utilizando los datos de Censys , determinamos que 33,201 de ellos estaban en uso en la web pública el 30 de julio. En el plazo de una semana, el número de certificados en uso afectados disminuyó en casi 7,000y ahora es de 26,373 a 6 de agosto.
- Nuestro análisis de los dominios registrados muestra que el Tecnología y Telecomunicaciones fueron los más afectados en cuanto al número de certificados afectados.
- A 6 de agosto de 2024, 98.82% de los certificados de hoja únicos afectados por este incidente que observamos en uso en hosts de cara al público han sido revocado. DigiCert declaró que todos los clientes afectados están obligados a reemitir los certificados afectados antes de este viernes 9 de agosto a las 20:30 UTC.
- Este incidente se produce poco después de que Entrust fuera retirada como Autoridad de Certificación de confianza el mes pasado, lo que pone de manifiesto los obstáculos a los que se enfrentan las organizaciones para gestionar eficazmente los certificados. Encontrar un equilibrio entre los requisitos de cumplimiento de las autoridades de certificación y dar a los usuarios tiempo y recursos suficientes para responder adecuadamente a este tipo de incidentes sigue siendo un reto difícil.
- Detección con Censys:
- Censys Los clientes de ASM pueden identificar los servicios que están utilizando activamente un certificado afectado dentro de sus espacios de trabajo mediante la consulta de un nuevo riesgo de baja gravedad denominado "Certificado afectado por el incidente de revocación de DigiCert de julio de 2024"
- Los usuarios de nuestra función de búsqueda pueden encontrar hosts con certificados afectados consultando labels=digicert-revoked-dcv. Para refinar los resultados para sus dominios específicos, ajuste esta consulta para filtrar por services.tls.certificates.leaf_data.names. Tenga en cuenta que esta detección de etiquetas acaba de desplegarse, por lo que puede tardar hasta 48 horas en propagarse por completo.
La cuestión
El 28 de julio de 2024, DigiCert emitió un informe inicial de incidentes que revelaba que un subconjunto de sus certificados no cumplía la normativa debido a un error en su proceso de Verificación de Control de Dominio (DCV). En consecuencia, DigiCert disponía de 24 horas para revocar y volver a emitir todos los certificados afectados para mantener la conformidad con las autoridades de certificación raíz como Google y Mozilla.
DigiCert opera dos sistemas principales para la emisión de certificados: un sistema de gran volumen para gestionar las solicitudes de CDN y proveedores en la nube y un sistema de bajo volumen para los usuarios que requieren una mayor gestión de la configuración. Este problema sólo afectaba a los certificados emitidos desde el sistema de bajo volumen, mientras que el sistema de alto volumen no se veía afectado. Dado que el sistema de bajo volumen atiende a clientes que necesitan configuraciones precisas, es probable que estos certificados se utilicen en entornos de alta seguridad.
La causa raíz del problema procedía del proceso de DigiCert para verificar la propiedad de los nombres de dominio, conocido como Validación de Control de Dominio (DCV). La DCV puede realizarse a través de varios métodos como el correo electrónico, HTTP o whois, pero el fallo en este caso estaba relacionado con la DCV basada en DNS.
En la DCV basada en DNS, los clientes deben crear un registro DNS específico (y temporal) con un valor que coincida con el contenido solicitado por la CA (DigiCert). Por ejemplo, la documentación DCV de DigiCert de DigiCert describe dos métodos para este proceso:
- Opción 1
- Vaya al sitio de su proveedor de DNS y cree un nuevo registro CNAME
- En el campo hostname (o equivalente), introduzca dnsauth.
- En el campo de tipo de registro (o equivalente), seleccione CNAME.
- En el campo de host de destino (o equivalente), introduzca [valor_aleatorio].dcv.digicert.com para que el registro CNAME apunte a dcv.digicert.com.
- Opción 2
- Vaya al sitio de su proveedor de DNS y cree un nuevo registro CNAME.
- En el campo de nombre de host (o equivalente), introduzca el valor aleatorio que copió de su cuenta de CertCentral.
- En el campo de tipo de registro (o equivalente), seleccione CNAME.
- En el campo de host de destino (o equivalente), introduzca dcv.digicert.com para que el registro CNAME apunte a dcv.digicert.com
Digamos que nuestro reto aleatorio DigiCert es _FOOBAR. Para la "Opción 1", el registro DNS resultante sería el siguiente:
_dnsauth IN CNAME _FOOBAR.dcv.digicert.com. ; _dnsauth.example.com.
Mientras que la "Opción 2" tendría un aspecto ligeramente distinto:
_FOOBAR IN CNAME dcv.digicert.com. ; FOOBAR.example.com.
DigiCert puede entonces hacer una petición DNS para el nombre de dominio dado, verificar el valor correcto en la respuesta, y así confirmar que el usuario que solicita el certificado posee ese nombre de dominio.
Este proceso funciona bien, pero es importante tener en cuenta el guión bajo que precede al valor aleatorio (challenge) que nos dieron. La razón de esto se describe en una recomendación de un borrador del IETF que describe las mejores prácticas para la DCV utilizando DNS:
“The RECOMMENDED format is application-specific underscore prefix labels. Domain Control Validation records are constructed by the provider by prepending the label “_<PROVIDER_RELEVANT_NAME>-challenge” to the domain name being validated (e.g. “_foo-challenge.example.com”). The prefixed “_” is used to avoid collisions with existing hostnames.” – draft-ietf-dnsop-domain-verification-techniques-02 Section 5.1.1
Esencialmente, esto significa que el uso de un guión bajo precedente ayuda a evitar conflictos en los que la cadena aleatoria generada para DCV podría coincidir inadvertidamente con un registro DNS existente. Aunque técnicamente los guiones bajos violan las normas RFC de DNS, la mayoría de los resolvedores DNS los aceptan. Los guiones bajos no suelen utilizarse para la resolución general, sino que se reservan para que los procesen los sistemas de automatización.
DigiCert también describió esta función en un entrada de blog el 29 de julio de 2024de forma similar. Aunque el guión bajo es simplemente una recomendación en el borrador del IETF, es un requisito para las autoridades de certificación. No obstante, el sistema de emisión de certificados de bajo volumen de DigiCert no aplicaba este requisito.
La idea de que esta función sólo existe para evitar registros DNS ya existentes puede subestimar otros riesgos de seguridad, potencialmente mayores, cuando no se utiliza el guión bajo. Un usuario de Bugzilla destacó en una respuesta a DigiCert que esta comprobación del guión bajo no es sólo para evitar posibles colisiones de nombres. En determinadas circunstancias, un usuario malintencionado podría aprovechar este descuido para crear un certificado para un dominio que no posee.
"La razón real del guión bajo es para que los servicios que permiten a los usuarios crear registros DNS en subdominios (por ejemplo, servicios DNS dinámicos) puedan bloquear a los usuarios que registren subdominios que empiecen por un guión bajo y estar a salvo de la emisión de certificados no deseados." - Comentario nº 10
Este usuario señaló un escenario en el que un producto o servicio permite a los usuarios controlar un registro DNS de un nombre de dominio principal que no poseen. Por ejemplo, considere un producto que permite a los usuarios registrar cuentas, con cada cuenta o nombre de usuario asignado a un registro DNS controlable. Un ejemplo es el de los servicios DNS dinámicos, en los que los usuarios pueden actualizar automáticamente determinados registros públicos en función de la dirección DHCP que tengan asignada, utilizando el nombre de usuario como subdominio. Por ejemplo, si un usuario recibe una dirección DHCP de 192.168.1.2puede actualizar $nombredeusuario.algún-servicio-dyndns.com para que apunte a esa IP.
Si ese fuera el caso, técnicamente podría registrar una nueva cuenta en ese servicio con el nombre de usuario siendo la cadena de desafío aleatoria proporcionada por DigiCert. A continuación, podría actualizar el registro DNS nombre_usuario.algún-servicio-dyndns.com con un valor CNAME de dcv.digicert.com. Esto le permitiría pasar la comprobación DCV de DigiCert, lo que llevaría a la emisión de un certificado válido.
Una persona señaló que noip[.]com puede ser un buen ejemplo de un objetivo de este problema, que potencialmente podría permitir a un atacante obtener un certificado válido para ddns[.]net.
“No-IP (https://www[.]noip.com) allows the creation of arbitrary labels under their domains like ddns[.]net, enabling users to easily create subdomains such as <some_arbitrary_string>.ddns.net and map them as CNAMEs to any target.” – Comment #15
Y este parece ser definitivamente el caso; en las siguientes dos capturas de pantalla, mostramos que podemos crear un subdominio arbitrario de nuestra elección con el valor CNAME de dcv.digicert.com sin error si excluimos el guión bajo precedente, pero falla si incluimos un guión bajo.
 |
 |
| Sin el guión bajo precedente. |
Con el guión bajo precedente. |
 |
Técnicamente, un atacante podría haber creado certificados válidos para cualquiera de los nombres de dominio preconfigurados que aparecen a la izquierda (ddns[.]net, gotdns[.]ch) |
Un servicio que implemente una función de este tipo debería denegar automáticamente cualquier cuenta o registro nuevo con un guión bajo en el prefijo, tratándolos como palabras clave reservadas (como hace noip más arriba). Sin embargo, como DigiCert no aplicaba el prefijo de guión bajo, cualquier acceso de modificación de DNS en esos sistemas podía aprovecharse para obtener un certificado válido para el nombre de dominio principal.
En resumen, el guión bajo es crucial no sólo para evitar colisiones de nombres, sino también para proporcionar una capa adicional de seguridad a los servicios que permiten a los usuarios modificar dominios protegidos. Habilita mecanismos de filtrado para impedir que usuarios (no) autorizados aprovechen los registros DNS para obtener certificados válidos.
Implicaciones en el mundo real.
Este incidente ha creado un gran revuelo entre particulares y empresas, provocando el caos en los equipos de ingenieros de todo el mundo, que se apresuran a actualizar sus hosts con los nuevos certificados. Tanto es así que una empresa de tecnología financiera especializada en la sanidad sanitaria, Alegeuspresentó una orden judicial para obtener una orden de restricción temporal sobre DigiCert en un intento de retrasar la revocación.
"La recertificación de los sitios web de Alegeus requiere que Alegeus se coordine con cada uno de sus clientes y no puede completarse para todos los sitios web de Alegeus en el plazo prescrito por DigiCert. En consecuencia, Alegeus solicitó tres días para completar la recertificación de los sitios web de Alegeus. DigiCert se ha negado". - Página 3.8
Esto es, básicamente, afirmar que el corto plazo no era suficiente para Alegeus y pensó que una de las mejores formas de ampliar el plazo era convertirlo en un asunto legal. Su razonamiento parece legítimo:
"Si DigiCert revoca los certificados de seguridad de los sitios web de Alegeus, causará a Alegeus daños graves e irreparables por un importe que se determinará en el juicio." - Página 9
Y si leemos el alegato de la cadena de correos electrónicos original enviada por Alegeus a DigiCert el 29 de julio de 2024, podemos solidificar aún más su razón al leer lo grave de la situación:
"La revocación de los certificados, tal como se propone, provocará importantes problemas de acceso a nuestros clientes y a sus partícipes, lo que significa que millones de partícipes y consumidores no podrán acceder a los fondos reservados y destinados a pagar prestaciones sanitarias hasta que se resuelvan los problemas de acceso". - Página 3
Básicamente se afirma que, sin una ampliación adecuada del plazo, vidas humanas reales pueden verse afectadas. Creo que un buen punto a tener en cuenta aquí es que mientras las propias autoridades de certificación pueden no tener ningún problema con estos plazos tan ajustados, sus clientes no siempre tienen el mismo lujo - incidentes como este pueden ser bastante preocupantes para el consumidor a tratar. Obviamente, la mejor manera de que esto hubiera sucedido es que no hubiera ocurrido en absoluto, pero aquí estamos.
Referencias
CensysPerspectiva
Cuota de mercado de DigiCert
Según la notificación original del incidente de DigiCert, esto afectó a "aproximadamente el 0,4% de las validaciones de dominio aplicables"; pongamos esa cifra en un contexto del mundo real.
DigiCert es una importante autoridad de certificación (CA). Ocupa el cuarto lugar entre las CA de confianza más activas de nuestro conjunto de datos, habiendo emitido aproximadamente 54,1 millones de certificados, lo que representa casi el 7% de todos los certificados de confianza emitidos en la actualidad.
En foro Bugzilla de Mozillaun representante de DigiCert adjuntó archivos CSV con enlaces a 83.267 certificados de hoja supuestamente afectados por este problema de DCV.
El 30 de julio, unos días después de que se revelara el incidente, identificamos más de 455.999 direcciones IPv4 distintas (repartidas entre hosts físicos y virtuales) que utilizaban 33.201 de estos 83.267 certificados afectados.
Una semana después, el 6 de agosto, 26.373 certificados afectados seguían en línea, lo que supone un descenso de 6.828 certificados en una semana.
El cuadro siguiente resume estas estadísticas semanales desde nuestra perspectiva.
| Fecha |
Hosts IPv4 físicos |
Hosts físicos y virtuales |
Certificados de hoja activa |
Dominios únicos |
| 7/30/2024 |
456002 |
4085959 |
33201 |
30528 |
| 8/6/2024 |
241343 |
3599368 |
26373 |
24693 |
Impacto en la industria y la empresa:
Analizamos los nombres de dominio asociados a estos certificados activos observados el 30 de julio, clasificándolos por el número de hosts únicos y clasificando las empresas e industrias correspondientes para los certificados con diez o más hosts (en total, 2.262 nombres de dominio únicos). Obsérvese que sólo se tuvieron en cuenta los dominios registrados, no los subdominios (ej: www.censys.com y community.censys.com se evalúan ambos como "censys.com").
| Empresa |
Recuento de dominios |
Recuento de anfitriones |
Certificados de hoja única |
% del total de certificados de hoja afectados |
| Vodafone |
19 |
6165 |
2178 |
16.10% |
| Bloomberg |
6 |
3685 |
630 |
4.66% |
| ABB |
5 |
601 |
250 |
1.85% |
| Yahoo |
6 |
6283 |
223 |
1.65% |
| Hitachi |
1 |
260 |
215 |
1.59% |
| Poste Italiane |
1 |
332 |
200 |
1.48% |
| Grupo Atlas World |
1 |
315 |
196 |
1.45% |
| Bouygues Telecom |
5 |
425 |
148 |
1.09% |
| Grupo Qt |
1 |
191 |
146 |
1.08% |
| Engie |
3 |
463 |
142 |
1.05% |
Vodafone destaca con más de 2.100 certificados de hoja única afectados, lo que indica que probablemente dependen en gran medida de DigiCert para sus necesidades de certificados. Bloomberg, ABB, Yahoo e Hitachi son las cinco empresas más afectadas de las que pudimos atribuir correctamente a un propietario.
| Industria |
Recuento de dominios |
Recuento de anfitriones |
Certificados de hoja única |
% del total de certificados de hoja afectados |
| Tecnología |
916 |
184276 |
3001 |
22.23% |
| Telecomunicaciones |
65 |
81456 |
2652 |
19.64% |
| Servicios financieros |
192 |
21259 |
1017 |
7.53% |
| Medios de comunicación |
102 |
15308 |
1007 |
7.46% |
| Sanidad y farmacia |
156 |
7679 |
708 |
5.24% |
| Gobierno |
80 |
3987 |
687 |
5.09% |
| Servicios |
22 |
1694 |
568 |
4.21% |
| Seguros |
54 |
5817 |
565 |
4.18% |
| Educación |
133 |
12997 |
510 |
3.78% |
| Fabricación |
61 |
7218 |
495 |
3.67% |
| Venta al por menor |
80 |
12495 |
421 |
3.12% |
| Transporte y logística |
50 |
1712 |
314 |
2.33% |
| Entretenimiento |
95 |
13127 |
286 |
2.12% |
| Bienes de consumo |
51 |
4689 |
139 |
1.03% |
| Publicidad y marketing |
35 |
1922 |
107 |
0.79% |
| Ingeniería y construcción |
16 |
741 |
106 |
0.79% |
| Contratación y empleo |
14 |
1202 |
99 |
0.73% |
| Aeroespacial |
3 |
178 |
96 |
0.71% |
| Legal |
6 |
172 |
88 |
0.65% |
| Automoción |
30 |
783 |
82 |
0.61% |
Los datos también revelan que los sectores de Tecnología y Telecomunicaciones son los más afectados por este incidente de revocación. Tecnología tiene el mayor número de certificados de hoja única, con 3.001, y Telecomunicaciones le sigue de cerca, con 2.652. Los certificados digitales se utilizan habitualmente en estos sectores para proteger grandes redes e infraestructuras de comunicación.
Los servicios financieros, los medios de comunicación y los sectores sanitario y farmacéutico se encuentran entre los más afectados. Nuestra investigación sobre el incidente de Entrust en juliocuando se retiró a Entrust como autoridad de certificación de confianza, identificó a los servicios financieros como el sector más afectado.
¿Cuántos de estos certificados se revocan?
Según página de incidencias actualizada de DigiCerttodos los certificados afectados deben ser reemplazados antes del 9 de agosto de 2024, a las 20:30 UTC. A partir de ahora, el 98,82% de los certificados de hoja afectados han sido revocados, lo que supone un aumento significativo desde el 30 de julio de 2024, cuando sólo alrededor del 5% habían sido revocados.
| Fecha |
Total de certificados Leaf activos |
# Revoked |
% Revocado |
| 30 de julio |
33201 |
1652 |
4.98% |
| 6 de agosto |
26373 |
26061 |
98.82% |
¿Qué se puede hacer?
- Los clientes afectados deberían haber recibido una notificación de DigiCert, y se les recomienda tomar medidas inmediatas para volver a emitir e instalar nuevos certificados a través de su cuenta DigiCert CertCentral.
- Censys Los clientes de ASM verán un nuevo riesgo de baja gravedad denominado "Certificado afectado por el incidente de revocación de DigiCert de julio de 2024" relacionado con este problema que puede utilizarse para detectar certificados afectados en sus espacios de trabajo.
- Los clientes de la búsqueda pueden utilizar la consulta labels=digitalizador-revocado-dcv para encontrar hosts que utilicen uno de los certificados afectados. Para limitar los resultados y filtrarlos por sus dominios, modifique esta consulta y sustituya "sudominio.com". Tenga en cuenta que acabamos de publicar esta detección de etiquetas, por lo que puede tardar más de 48 horas en propagarse.
Referencias:
