Mitigaciones para el incidente de interceptación MitM de Hetzner/Linode contra XMPP.ru
(devever.net)- jabber.ru y xmpp.ru sufrieron un ataque MitM que combinó la interceptación de tráfico en la ruta del proveedor de hosting con la emisión no autorizada de certificados de Domain Validation, dejando en evidencia brechas defensivas en servicios TLS que no son web
- El monitoreo de logs de Certificate Transparency y el sondeo de claves públicas TLS ayudan a detectar anomalías, pero la detección completa es difícil ante certificados no registrados en CT y MitM selectivo
- Implementar ACME-CAA (RFC 8657) junto con DNSSEC permite autorizar solo a una cuenta específica de una CA específica para emitir certificados, por lo que al atacante no le basta simplemente con usar la misma CA
- A diferencia de los navegadores web, muchos clientes no web no exigen pruebas de CT (SCT), y los CA/Browser Forum Baseline Requirements tampoco obligan a registrar todos los certificados en CT
- Los operadores deberían evaluar ACME-CAA, DNSSEC, monitoreo de CT, servicios onion de Tor y distribución jurisdiccional; los usuarios deberían tomar el cifrado de extremo a extremo y la verificación de huellas digitales como línea básica de defensa
Estructura central del incidente
- Los operadores de jabber.ru y xmpp.ru informaron que el servicio sufrió un ataque man-in-the-middle
- El ataque tuvo la forma de dos elementos combinados
- Hetzner y Linode interceptaron el tráfico dirigido a las máquinas del servicio
- El atacante obtuvo sin autorización certificados de Domain Validation para ese servicio
- Se evalúa como muy probable que el Estado alemán lo haya coordinado, o que Alemania lo haya coordinado junto con uno o más Estados
- También quedan otras posibilidades
- Que Hetzner y Linode hayan respondido voluntariamente a una solicitud de vigilancia de una potencia extranjera sin obligación legal
- Sin embargo, en ese caso implicaría una evaluación muy negativa para ambas empresas y podría ser ilegal, por lo que se considera poco probable
Métodos de detección y límites
- El primer método es monitorear los logs de Certificate Transparency (CT) para encontrar certificados emitidos que el operador no solicitó
- Existen algunos servicios que hacen esto en su lugar
- Las herramientas que filtran bien y avisan solo sobre certificados no solicitados todavía tienen margen de mejora
- El segundo método es conectarse periódicamente al servicio y verificar que la clave pública del servidor TLS coincida con el valor esperado
-
Áreas que el monitoreo de CT puede pasar por alto
- Incluso un certificado emitido por una CA legítima no necesariamente queda registrado en logs de CT
- Los CA/Browser Forum Baseline Requirements todavía no establecen el registro en CT como requisito obligatorio para las CA
- Los navegadores web rechazan certificados que no tengan prueba criptográfica de registro en logs de CT, por lo que el registro en CT se vuelve obligatorio en la práctica
- La mayoría de las aplicaciones cliente no web no verifican ni exigen que el certificado tenga prueba de registro en CT
- En teoría, un atacante puede conseguir certificados no registrados en CT
-
Posible evasión mediante MitM selectivo
- Aunque se intente detectar MitM mediante sondeo del servicio, el atacante podría identificar las conexiones de detección y no aplicar MitM a esas conexiones
- Como mínimo, los sondeos deberían realizarse a través de Tor para evitar situaciones en las que sean fáciles de identificar
- La pila TLS puede ser identificada por señales como el orden de enumeración TLV, por lo que podría distinguirse entre un cliente XMPP real y un agente de sondeo
- En lugar de excluir de una blacklist los sondeos conocidos, el atacante también podría aplicar MitM mediante una whitelist solo al tráfico de personas específicas de interés
- Ninguno de los dos métodos de detección ofrece confiabilidad completa
Riesgos que pueden reducirse con ACME-CAA
- Los certificados TLS son un mecanismo para evitar ataques MitM, pero el propio modelo de Domain Validation, con el que las CA verifican el control del dominio, es vulnerable a MitM
- Si el atacante puede interceptar todo el tráfico dirigido al sitio víctima, y no solo una parte, el riesgo aumenta
- ACME-CAA (RFC 8657) puede mitigar este problema en determinadas circunstancias
- La idea central es especificar mediante registros DNS que solo una cuenta específica de una CA específica pueda emitir certificados para el dominio
- No basta simplemente con usar la misma CA
- Se necesita acceso a la misma cuenta en esa CA
- En Let's Encrypt, se necesita acceso a la clave privada ACME usada para la solicitud de certificado
- Según los métodos de ataque conocidos, se evalúa que implementar esta extensión habría podido bloquear el ataque
-
Precauciones de implementación
- Para que ACME-CAA funcione correctamente, se requiere implementar DNSSEC
- Sin DNSSEC, las solicitudes DNS de la CA también pueden ser interceptadas
- Quien controle la clave de firma DNSSEC puede eludir esta barrera
- Una zona DNS protegida con DNSSEC puede operarse sin entregar la clave de firma a un tercero
- En ese caso, el proveedor de hosting DNS no tiene autoridad para comprometer la zona
- Este enfoque se evalúa como la mejor estrategia de implementación
- El atacante podría intentar presionar al registrador del dominio o al registro del TLD para cambiar la clave de firma DNSSEC registrada para el dominio
- Es probable que esa acción sea visible
- Debido a las características del caché DNS, podría ser difícil impedir que sondeos repetidos detecten el cambio de clave
- También existe la posibilidad de que el atacante presione a la propia CA para que emita indebidamente un certificado
- Si una CA de terceros viola las reglas o comete un error, el sistema sigue siendo vulnerable
- Los CA/Browser Forum Baseline Requirements exigen que las CA verifiquen DNSSEC
- Sin embargo, una CA de terceros puede emitir un certificado aunque no esté autorizada en los registros CAA
- Como el registro en CT no es obligatorio, ese certificado podría no detectarse
Flujo que podría elegir un atacante más hábil
- El atacante de este incidente no fue perfecto, ya que dejó que el certificado ilegal expirara
- A medida que se expande el cifrado barato y fácil de usar, se espera que los ataques a nivel estatal se vuelvan más sofisticados y más frecuentes
- Un atacante estatal más hábil podría elegir el siguiente flujo
- Aprovechar que las CA no están obligadas a registrar en logs de CT y solicitar un certificado no registrado
- Presionar al proveedor de hosting para aplicar MitM a todo el tráfico dirigido a la máquina víctima
- Distinguir de forma heurística el tráfico de interés y el tráfico de detección mediante huellas de la pila TLS e IP de origen
- Usar el MitM para hacer que la CA crea que el atacante es el controlador legítimo del dominio víctima
- Si el dominio usa ACME-CAA y DNSSEC, podría intentar presionar al proveedor de hosting DNS, al registrador, al registro del TLD o a la CA
Huecos en la infraestructura TLS actual
-
Falta de exigencia de CT en clientes TLS no web
- Los navegadores web exigen que los certificados de CA incluyan una prueba criptográfica de registro en logs de CT
- La mayoría de los otros clientes TLS no exigen pruebas de CT, por lo que pueden aceptar certificados no registrados
- Es probable que muchos clientes XMPP también entren en esta categoría
- La verificación de CT no se activa automáticamente por enlazar con OpenSSL; requiere una implementación aparte
- El software usado para comunicaciones sensibles debería considerar soporte para exigir CT
-
Ausencia de obligación de registrar certificados en CT
- Los CA/Browser Forum Baseline Requirements, las reglas de la industria que deben seguir las CA, no exigen registrar los certificados en logs de CT
- Se considera necesario avanzar hacia exigir que todos los certificados se registren en logs de CT
- Si la exigencia de CT se implementa de forma generalizada, este problema podría volverse técnicamente irrelevante
-
Falta de servicios de monitoreo de CT
- Se necesitan más servicios de monitoreo de CT
- Actualmente, uno de los principales servicios de alertas de CT es SSLMate's Cert Spotter
- El precio puede ser una carga para servicios basados en voluntariado, entre otros
- El monitoreo de CT debería diseñarse para reducir falsos positivos y avisar solo sobre emisiones de certificados anómalas o aparentemente no autorizadas
-
Falta de transparencia en DNSSEC
- Actualmente no existe una infraestructura criptográfica desplegada que detecte cambios en las claves DNSSEC configuradas para un dominio
- Si los registradores de dominio y registros de TLD son presionados o comprometidos y cambian las claves DNSSEC de un dominio, la protección de ACME-CAA puede debilitarse
- Sería deseable una solución de transparencia que haga visibles públicamente los cambios de clave de zonas DNSSEC
- Esta solución podría registrar solo cambios de clave de zona, como registros DS, y no todos los registros de la zona
Recomendaciones para operadores de servicios
- Para servicios que podrían ser objetivo de ataques estatales, se recomienda aplicar defensas en orden de mayor costo-beneficio
-
ACME-CAA y DNSSEC
- Implementar ACME-CAA puede dificultar que un atacante engañe a una CA para obtener un certificado del dominio
- La guía de implementación puede consultarse en el artículo de implementación de ACME-CAA
- Las Security Considerations del RFC también contienen advertencias importantes
- Si se implementa ACME-CAA, también debe implementarse DNSSEC
- Si es posible, conviene elegir un proveedor de DNSSEC que no requiera entregar las claves de firma al proveedor
-
Servicios proxy y monitoreo de CT
- Se evalúa que usar servicios como Cloudflare deja al operador en un estado similar a hacer MitM contra sí mismo
- Hay que suscribirse a un servicio de monitoreo de logs de CT o revisar los logs periódicamente por cuenta propia
- SSLMate's Cert Spotter ofrece monitoreo automático de pago
- Cert Spotter es open source, por lo que también puede autoalojarse
- crt.sh ofrece búsqueda manual en logs de CT
-
Distribución jurisdiccional y servicio onion de Tor
- Puede evaluarse la distribución jurisdiccional, ubicando en distintos países al registrador del dominio, el registro del TLD, el hosting DNS, la CA y el proveedor de hosting
- Se pueden elegir países o bloques geopolíticos con baja probabilidad de cooperar entre sí
- Ofrecer un servicio onion de Tor permite evitar infraestructura centralizada como TLS y las CA
- En un servicio onion de Tor, la clave pública del servicio es la propia dirección
- Los usuarios deben recibir la dirección onion correcta a través de un canal confiable
- Un tercero puede inducirlos a usar una dirección onion incorrecta
-
Sondeo automático basado en Tor
- El sondeo automático mediante Tor no es una solución completa, pero puede detectar errores torpes que ocurren en la realidad
- Usar Tor reduce la facilidad con la que el sondeo puede identificarse como tal
- Para reducir la posibilidad de huellas TLS, conviene que el software cliente use una biblioteca TLS comúnmente utilizada
- Si es posible, es mejor usar el cliente real
- Para un servicio XMPP, podría usarse un cliente XMPP real
- Incluso si tiene éxito, solo permite detectar después del compromiso; para entonces, los usuarios ya podrían haber sido afectados
-
Otros vectores de ataque y peores supuestos
- Si se dificulta el MitM, aumenta la probabilidad de que el atacante use otras vías, como comprometer la propia máquina, robar claves privadas o sustraer información sensible
- Un atacante estatal puede presionar al proveedor de VM para que realice un volcado de memoria a nivel de hipervisor
- Un servidor dedicado también puede ser comprometido mediante acceso físico del atacante
- Los operadores deberían recomendar a los usuarios el cifrado de extremo a extremo y asumir que, pese a sus mejores esfuerzos, el servicio puede verse comprometido
- Se evalúa que el cifrado “de extremo a extremo” entregado como aplicación web no ofrece una protección significativa
Acciones necesarias para CA, desarrolladores de clientes y usuarios
-
CA/Browser Forum
- Debe exigir que todos los certificados se registren en logs de CT, o elevar una propuesta en ese sentido
-
Desarrolladores de aplicaciones cliente
- Deben agregar una función que exija la presencia de Signed Certificate Timestamps (SCTs) en los certificados TLS y activarla por defecto
- Deben permitir que los usuarios sepan que cuentan con esta protección
- Como la exigencia de pruebas de CT presenta cierta variabilidad, también deben considerar las discusiones relacionadas
- El software debería ofrecerse como open source para permitir auditoría pública
- También deben considerar riesgos de cadena de suministro y la posibilidad de que la propia empresa desarrolladora sea obligada legalmente a comprometer el software
- Los canales de distribución que el desarrollador no controla directamente, como los repositorios de paquetes de distribuciones Linux, pueden ayudar a reducir el daño
-
Usuarios finales
- Aunque el operador del servicio actúe de buena fe, deben asumir que el servicio puede ser comprometido pese a sus mejores esfuerzos
- Si su vida depende de que el servicio no sea comprometido, no deben confiar en ese servicio
- En XMPP, deben usar tecnologías de cifrado de extremo a extremo como OMEMO u OTR
- Deben verificar siempre las huellas digitales de sus contactos
- No deben realizar cifrado de extremo a extremo con software basado en web, o al menos deben asumir que está comprometido
- Si el proveedor del servicio ofrece un servicio onion de Tor, deberían considerar usarlo, pero deben obtener la dirección onion de una fuente confiable
-
CA y autores de estándares
- Si una CA no soporta ACME-CAA (RFC 8657), debería considerar implementarlo
- Incluso una CA que no esté basada en ACME puede implementar ACME-CAA
- Aunque las reglas del CA/Browser Forum permitan no registrar en CT, una CA puede adoptar una política de registrar todos los certificados en CT
- Los autores de estándares pueden volver a evaluar la posibilidad de transparencia DNSSEC, al menos para registros DS
Evaluación de confidential computing
- Si preocupa incluso el compromiso de la máquina por parte del proveedor de hosting, las tecnologías actuales de confidential computing no se consideran una solución suficiente
- Desplegarlas puede ser mejor que no hacer nada, pero no debe creerse que son seguras
- Se evalúa que las tecnologías actuales, incluidas las de AMD e Intel, dependen de claves maestras del proveedor capaces de abrir puertas traseras en el sistema
- Un atacante estatal puede presionar al proveedor para que entregue esas claves, y entonces el enfoque colapsa
- Podrían existir métodos de confidential computing que no dependan de claves maestras, pero los enfoques actuales no alcanzan ese estándar
Material relacionado
- Mitigating the Hetzner/Linode XMPP.ru MitM interception incident, part 2: XMPP-specific mitigations: consejos de mitigación específicos para XMPP
- Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service: informe del incidente original
- ACME-CAA (RFC 8657)
- Let's Encrypt now supports ACME-CAA: closing the DV loophole
- Web-based cryptography is always snake oil
- Cloudflare considered harmful
1 comentarios
Opiniones de Hacker News
Es interesante el resumen del ataque en https://notes.valdikss.org.ru/jabber.ru-mitm/
El atacante emitió varios certificados SSL/TLS de jabber.ru y xmpp.ru con Let’s Encrypt desde el 18 de abril de 2023, y se confirmó que, del 21 de julio al 19 de octubre, se aplicó un ataque de intermediario al 100% del tráfico de clientes al menos en el puerto 5222 de XMPP STARTTLS
Después, al fallar la reemisión de certificados, el puerto 5222 de jabber.ru empezó a servir certificados vencidos; el ataque se detuvo poco después de que comenzaran la investigación y las consultas a Hetzner/Linode, pero en algunos servidores de Linode seguía habiendo escucha pasiva mediante saltos de ruteo adicionales
Parece que el servidor en sí no fue hackeado, sino que las redes de Hetzner y Linode fueron reconfiguradas apuntando a las IP del servicio XMPP
Ni esa página ni las enlazadas desde aquí mencionan la fijación de certificados; no sé si será porque XMPP no la soporta, pero si la soportara, creo que podría haber evitado este ataque
Lamentablemente, jabber.ru usa software de servidor de 2016, y esa versión tan antigua no lo soporta
Hoy la fijación de certificados tiene muchos problemas porque los certificados tienen vidas útiles cortas y se renuevan con frecuencia. Si al usuario se le pregunta cada mes si quiere aceptar un certificado nuevo, terminará presionando “Accept” sin pensarlo también ante un certificado del atacante
El channel binding funciona independientemente del certificado y garantiza que el flujo TLS termine en la entidad esperada
Me resulta extraño que se enfoquen en la ausencia de soporte CT/SCT en los clientes XMPP. Este ataque usó certificados válidos emitidos por Let’s Encrypt y también publicados en los logs de CT, así que CT/SCT no lo habría detectado
Si hubiera habido registros CAA estrictos, la verificación SCT podría detectar un escenario teórico en el que otra autoridad certificadora emitiera certificados, pero en la práctica tampoco había CAA, y el channel binding es más favorable a la privacidad y depende menos de terceros
Es decir, pudo responder al protocolo ACME desde el HTTP alojado, o pudo escribir registros DNS TXT, lo que parece implicar que la víctima ya había perdido el control del servidor de procesos o de los servidores de nombres
Entiendo que la fijación de certificados solo es posible cuando se puede controlar el cliente, y consiste en insertar directamente en el cliente los certificados permitidos para esquivar toda la infraestructura de clave pública web
En una situación en la que se conectan clientes genéricos, no hay forma de saber qué certificado debe permitirse, y justamente para eso se usa la infraestructura de clave pública web
Claro que, incluso si se ofrece un cliente propio, el problema solo sube un nivel: el lugar desde donde los clientes descargan el cliente personalizado puede verse comprometido y distribuirse un cliente malicioso
A esta lista le falta la defensa más obvia. Hay que habilitar, y si es posible exigir, SCRAM-xxxxx-PLUS como método de autenticación
La idea de la variante PLUS es simple pero efectiva. En vez de verificar solo con el salt, se vincula a una conexión TLS específica, de modo que la autenticación solo sea válida en una única conexión TLS
Esto también se conoce como channel binding
Me da curiosidad quiénes son los usuarios finales de xmpp.ru y jabber.ru. ¿Será para capturar tráfico entre soldados o espías rusos? No me gusta la vigilancia masiva, pero no entiendo por qué apuntaron justo a dominios rusos.
Lo más plausible es un escenario para atrapar a carders u operadores de botnets. Jabber/XMPP sigue siendo bastante popular en ese ambiente ruso, y en artículos como los de Krebs on Security se ven con frecuencia capturas de pantalla o logs donde aparecen varios servidores como @exploit.in, @jabber.ru, etc.
Aun así, sea cual sea la intención, la vigilancia masiva en general es repugnante.
No sé exactamente cuál es la proporción de uso delictivo y no delictivo en esos dos servidores, pero igual que en Tor se mezclan contenidos claramente ilegales con usos legítimos, aquí seguramente también hay bastantes conversaciones completamente normales.
Por eso, en principio no estoy muy a favor de invadir la privacidad para vigilar a ciberdelincuentes arbitrarios en países fuera de jurisdicción donde además sería difícil extraditarlos.
Entiendo que Hetzner quizá no tuvo más opción que cooperar si no quería terminar como Lavabit, pero, como alguien que solía recomendarla seguido, sería bastante decepcionante si Hetzner supo del ataque de intermediario y lo permitió o ayudó. Por lo demás, la considero una de las mejores empresas de hosting.
Tiene buena transparencia, mejor uptime, confiabilidad y soporte que la mayoría de los proveedores cloud, y sus costos no son excesivos. También es elogiable su esfuerzo por convertir el diseño ecológico en una decisión económicamente inteligente.
En “reducir > reutilizar > reciclar”, la reducción se ve en su diseño KISS. Por ejemplo, techos altos e inclinados que ayudan a la disipación natural del calor[2], chasis de servidores que son más bien un soporte estructural mínimo y una cubierta para el flujo de aire que chasis reales, y diseños de motherboards estándar con el socket rotado 90 grados para enfriar VRM, CPU y memoria con un solo ventilador[3].
La “reutilización” se ve en sus subastas de servidores. En vez de desechar hardware viejo, lo alquilan mediante un sistema de subasta holandesa, evitando tanto el costo de hardware nuevo como el costo ambiental de fabricar todo de nuevo en cada generación.
Si tuvieran servidores dedicados fuera de Europa, los usaría mucho más.
[1]: “Legal” en sí también es difícil de definir. Un periodista de un país es un “agente extranjero” para otro, y un “luchador por la libertad” de un país es un “terrorista” para otro.
[2]: Der8auer: Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein - https://youtu.be/5eo8nz_niiM?t=259
[3]: Der8auer: Hetzner shows Special AM5 Board with 90° Rotated Socket - https://youtu.be/V2P8mjWRqpk
El artículo dice que “CT es opcional”, pero al final, ¿no es algo que debería decidir el cliente XMPP? Ahora que los navegadores prácticamente lo exigen, me pregunto qué impide que los clientes XMPP exijan CT.
Tampoco entiendo si eso significa que dependen de algún almacén de confianza que emite certificados que no funcionan en navegadores.
El problema es que el comportamiento de exigir CT no viene activado por defecto en casi ninguna biblioteca TLS. Por eso los desarrolladores de clientes XMPP tendrían que activarlo deliberadamente, y por ahora creo que la mayoría, o todos, no lo hacen. Claro que eso podría cambiar.
Este artículo sugiere usar OTR en XMPP, pero lamentablemente OTRv3 usa criptografía antigua y OTRv4 todavía no está finalizado.
https://dustri.org/b/time-to-sunset-otr.html
Ante la pregunta “¿qué haría un atacante perfecto?”, si se tiene acceso físico a la computadora, supongo que habría una forma de extraer datos del dispositivo mediante algún tipo de intercepción del bus.
En la época del dial-up y de la banda ancha lenta y de alta latencia tenía sentido, pero hoy hay muchos lugares con fibra de alta velocidad y baja latencia hasta los puntos de peering.
Mientras más nos alejemos de los centros de datos y la nube, más debería funcionar la infraestructura de Internet como fue diseñada originalmente, y menos tendría que pasar por puntos de agregación centralizados que hoy son graves puntos de falla y grandes riesgos de seguridad.
Investigué CAA y mi proveedor de DNS actual no admite ese registro. ¿Hay alguna razón por la que tuvo que ser un tipo nuevo y no un registro TXT, que es más común?
Si eso no funciona, hay que pedir soporte. Los registros CAA son un tipo cada vez más usado, así que hoy en día un servicio que no los admite no es muy bueno.
No conozco la discusión de diseño de CAA, pero es muy probable que se haya debatido en la lista de correo correspondiente del IETF.
Los proveedores de DNS deberían soportar diversos tipos de RR, y los propietarios de dominios deberían votar con sus registros NS.
Hay una lista de proveedores de DNS que soportan CAA en https://github.com/StackExchange/dnscontrol/blob/master/docu....
Vale la pena probar si puedes montar un servidor primario oculto y dejar al proveedor solo como servidor secundario. En Linode pude esquivar esa limitación así.
Falta la opción de operar tu propia autoridad certificadora y elegir cuidadosamente los certificados raíz.
El proveedor tiene acceso al host, así que puede inspeccionar el trabajo desde afuera y el usuario no se daría cuenta.
Por ejemplo, habría que implantar un módulo de kernel que sobreviva incluso después de una actualización del kernel y que se oculte a sí mismo de forma muy avanzada. El artículo también trata el análisis de volcados de memoria sin procesar.
¿Cuál sería una solución técnica fundamental contra este tipo de ataques por parte de un Estado, o de un actor poderoso equivalente? ¿Habrá alguna forma de cumplir ese sueño geek de un software que pueda distribuirse libremente y que nadie, salvo su autor, pueda censurar, intervenir o modificar?
¿Bastaría con un sistema P2P bien diseñado sobre la infraestructura actual de Internet, o habría que desplegar además una red mesh global de bajo ancho de banda que funcione de forma inalámbrica?
Espero que Freenet 2023 evolucione hacia una experiencia de desarrollo sin fricción para aplicaciones P2P.