Detectan indicios de interceptación de tráfico cifrado de Jabber.ru en Hetzner y Linode

 (notes.valdikss.org.ru)
1 puntos por GN⁺ 2023-10-21 | 1 comentarios | Compartir por WhatsApp
  • Se confirmaron indicios de que las conexiones XMPP STARTTLS en el puerto 5222 eran interceptadas mediante un proxy MiTM transparente en un servidor dedicado de Hetzner y VPS de Linode del servicio XMPP ruso jabber.ru/xmpp.ru
  • El atacante emitió varios certificados TLS con Let’s Encrypt para terminar la conexión cifrada en el medio; el problema salió a la luz cuando el puerto 5222 de jabber.ru en Hetzner empezó a entregar un certificado vencido
  • No hubo señales de compromiso del servidor ni de ARP spoofing en el mismo segmento de red, y las instancias de Linode mostraban una ruta y una MAC de gateway distintas a las de una VM normal, lo que aumenta la posibilidad de una reconfiguración de la red de hosting
  • El MiTM fue confirmado al menos desde el 21 de julio hasta el 19 de octubre de 2023, y queda la posibilidad de que existiera desde el 18 de abril de 2023; el 100% de las conexiones al puerto 5222 se vieron afectadas, mientras que el puerto 5223 quedó excluido
  • Las comunicaciones de jabber.ru/xmpp.ru durante ese periodo deben considerarse comprometidas, y el cifrado de extremo a extremo como OMEMO, OTR y PGP solo protegía si ambas partes habían verificado las claves

La interceptación revelada por un certificado vencido

  • jabber.ru es un servicio XMPP ruso iniciado en 2000, también conocido como xmpp.ru
  • El 16 de octubre de 2023, al conectarse al servicio apareció el mensaje “Certificate has expired”, aunque todos los certificados instalados en el servidor estaban actualizados
  • La anomalía apareció solo en el puerto 5222 para XMPP STARTTLS, y no se observó en otros puertos como el 5223 para XMPP TLS
  • Los servidores afectados fueron un servidor dedicado de Hetzner en Alemania y dos servidores virtuales de Linode
  • En el tráfico del puerto 5222 se observó que el servidor recibía un ClientHello reemplazado, no el ClientHello original del cliente

Resultados de la investigación de compromiso interno del servidor

  • La investigación se centró en la posibilidad de hackeo del servidor y de spoofing en la red local
  • En el lado del servidor se revisaron los siguientes elementos, sin encontrar anomalías:
    • Registros en general
    • Horas de modificación de ejecutables y bibliotecas
    • Procesos en ejecución, mapas de memoria y dangling file descriptors
    • Existencia de bibliotecas de secuestro LD_PRELOAD en espacio de usuario usando busybox compilado estáticamente
    • Existencia de módulos de secuestro a nivel de kernel, volcando memoria del kernel con LiME y analizándola con volatility
  • En los logs del kernel del servidor dedicado de Hetzner, la única excepción encontrada fue un registro de que el enlace físico de red estuvo desconectado durante 19 segundos el 18 de julio de 2023
  • Los servidores de Linode se usaban solo como túneles para rutas alternativas hacia el servidor de Hetzner, y solo ejecutaban servicios básicos como SSH y NTP
  • Dentro del túnel Hetzner↔Linode se veía el ServerHello normal del servidor Hetzner, pero este cambiaba al enviarse al cliente por la interfaz de red de Linode
    • En otras palabras, el mismo tipo de interceptación de conexión cifrada ocurrió tanto en Hetzner como en Linode

Señales anómalas observadas en la red de Linode

  • Desde la perspectiva de red se revisaron los siguientes puntos, pero no se encontraron señales de secuestro alrededor de la red del servidor:
    • Si había ARP spoofing de la dirección MAC del gateway
    • Si una misma IP respondía varias veces a solicitudes ARP en el segmento L2
    • Reglas de ruteo anómalas inyectadas mediante ICMP redirect u otros mecanismos
    • Reglas de Netfilter
    • Existencia de túneles difíciles de detectar, como IPsec
  • Las máquinas Linode afectadas no podían descubrir por ARP ni hacer ping a IPs vecinas del mismo segmento de red, pero desde redes externas esas IPs vecinas funcionaban con normalidad
  • Una VM Linode de un tercero no afectada sí podía hacer ping a hosts vecinos y estaba conectada a un router Cisco Systems
  • En cambio, los VPS afectados estaban conectados a un gateway con una dirección MAC cuyo fabricante no se podía identificar
  • Por esta diferencia, aumenta la posibilidad de que las VM de Linode afectadas tuvieran una configuración de red distinta a la de las instancias normales de Linode, o que hubieran sido aisladas en una VLAN separada

Certificados falsificados y rastros en Certificate Transparency

  • En la base de datos de transparencia de certificados crt.sh se encontraron certificados fraudulentos que no habían sido emitidos por los servidores de jabber.ru
  • El servicio XMPP normal usaba dos tipos de certificados:
    • xmpp.ru, *.xmpp.ru
    • jabber.ru, *.jabber.ru
  • Los certificados emitidos maliciosamente tenían una configuración ligeramente distinta a la de los certificados legítimos:
    • O bien faltaba el Subject Alternative Name con comodín
    • O bien se emitían agrupando jabber.ru, xmpp.ru en un solo certificado
  • Parte de la configuración MiTM en Linode para el dominio xmpp.ru estaba mal configurada:
    • El servidor original estaba configurado para ofrecer tanto certificados de jabber.ru como de xmpp.ru según el dominio XMPP solicitado
    • El lado MiTM solo ofrecía el certificado de xmpp.ru
  • La hora de emisión del certificado del 18 de julio de 2023 coincide casi con la hora en que el enlace de red del servidor Hetzner se cortó por unos segundos
  • Un escáner externo de red confirmó que el servidor Linode ofrecía el certificado 04:b7:85… en el puerto 5222 al menos desde el 21 de julio de 2023
  • Ese escáner no procesaba el rango de Hetzner

Equipo frente al puerto 5222 y diferencias de ruta

  • Se realizaron pruebas de red adicionales desde el exterior contra el VPS de Linode
  • Los hosts vecinos del mismo segmento de Linode eran alcanzables desde la conexión de Internet de una laptop en el hop 13
  • El puerto 5222 interceptado del servidor Linode dawn.jabber.ru también era alcanzable en el hop 13
  • Sin embargo, los puertos no interceptados del mismo servidor, como el puerto SSH 22, solo eran alcanzables en el hop 14 tras pasar por un hop privado adicional
  • Este resultado significa que la dirección IP de la VM de Linode estaba detrás de un equipo adicional, y que ese equipo procesaba directamente el puerto TCP 5222 mientras ruteaba los demás puertos al destino real
  • Desde dentro del VPS no era posible crear una nueva conexión con source port 5222
    • El router no respondía a paquetes provenientes de ese source port
    • Tampoco enviaba ICMP error ni Time-to-Live Exceeded para paquetes salientes con TTL=0 o TTL=1

Modo de terminación de STARTTLS y huella de detección

  • Según pruebas con testssl.sh, el proxy interceptor permitía anonymous ciphers tanto en xmpp.ru de Linode como en jabber.ru de Hetzner
  • Esta es una mala configuración poco común y puede usarse como huella para detectar MiTM en XMPP
  • Las bibliotecas SSL/TLS comunes suelen compilarse sin soporte para anonymous ciphers, y a menudo es difícil configurar un servicio para usarlos incluso si se habilitan explícitamente en el archivo de configuración
  • El servidor original no tenía configurados anonymous ciphers
  • Con el mismo comando de testssl.sh se revisaron unos 20 servicios XMPP populares, pero no se encontraron señales anómalas como soporte para Anonymous NULL Ciphers

Conclusiones confirmadas e impacto en usuarios

  • El atacante emitió varios certificados SSL/TLS con Let’s Encrypt para los dominios jabber.ru y xmpp.ru desde el 18 de abril de 2023
  • El ataque Man-in-the-Middle para descifrar el tráfico XMPP de clientes de jabber.ru/xmpp.ru fue confirmado al menos desde el 21 de julio hasta el 19 de octubre de 2023
  • Existe la posibilidad de que hubiera comenzado el 18 de abril de 2023, pero no está confirmado
  • El alcance fue el 100% de las conexiones al puerto 5222 de XMPP STARTTLS; el puerto 5223 no estuvo incluido
  • El atacante falló al renovar el certificado TLS, y en el puerto 5222 de jabber.ru en Hetzner el proxy MiTM empezó a ofrecer un certificado vencido
  • El ataque MiTM se detuvo inmediatamente después de la investigación, las pruebas de red y la presentación de tickets de soporte a Hetzner y Linode el 18 de octubre de 2023
  • Sin embargo, al menos en un servidor de Linode seguía existiendo escucha pasiva en forma de un hop de ruteo adicional
  • No hubo indicios de que el servidor hubiera sido hackeado, y parece que las redes de Hetzner y Linode fueron reconfiguradas específicamente para este ataque contra las direcciones IP del servicio XMPP
  • Las comunicaciones de jabber.ru/xmpp.ru durante ese periodo deben considerarse comprometidas
    • El atacante podía actuar como si las acciones se hubieran ejecutado desde una cuenta autenticada, sin conocer la contraseña de la cuenta
    • Podía descargar el roster de la cuenta, acceder a todo el historial de mensajes del lado del servidor que no estuviera cifrado, enviar nuevos mensajes y modificar mensajes en tiempo real
  • Las comunicaciones con cifrado de extremo a extremo como OMEMO, OTR y PGP solo están protegidas contra la interceptación si ambas partes verificaron las claves de cifrado
  • Los usuarios deben revisar si hay nuevas claves OMEMO o PGP no aprobadas en el almacenamiento PEP y cambiar sus contraseñas

Prevención y monitoreo que pueden hacer los operadores

  • Como la emisión de nuevos certificados queda registrada en Certificate Transparency, se puede configurar monitoreo de Certificate Transparency
  • Con las extensiones CAA Record Extensions for Account URI and ACME Method Binding de RFC 8657 se puede limitar el método de emisión de certificados y los identificadores de cuenta autorizados para emitirlos
  • Se pueden monitorear los cambios de certificados SSL/TLS de todos los servicios mediante servicios externos
  • Se pueden vigilar cambios en la dirección MAC del gateway predeterminado
  • El channel binding de XMPP puede detectar un MiTM aunque el interceptor presente un certificado válido
    • Tanto el cliente como el servidor deben soportar el mecanismo de autenticación SCRAM PLUS
    • En el momento del ataque no estaba activado en jabber.ru
  • Las recomendaciones adicionales del desarrollador de ACME Hugo Landau están recopiladas en More recommendations from ACME developer Hugo Landau

Respuestas de Hetzner y Linode

  • Al 20 de octubre de 2023 no se había recibido una respuesta suficiente de Hetzner ni de Linode
  • En la actualización del 3 de noviembre de 2023, ambas empresas seguían sin dar una respuesta adecuada sobre este incidente
  • Hetzner respondió que, para servidores root dedicados y servidores Cloud, solo proporciona hardware, acceso a la red y la infraestructura necesaria, y que no podía ofrecer una solución adicional
  • Linode cerró el ticket diciendo que había recibido los logs, pero no observó actividad ilegal que afectara al servicio
  • El equipo operativo se inclina por la hipótesis de que Hetzner y Linode fueron obligadas a configurar esto como una interceptación legal a pedido de la policía alemana
  • Otra posibilidad es que haya ocurrido una intrusión en las redes internas de Hetzner y Linode dirigida específicamente contra jabber.ru, pero sigue siendo un escenario mucho menos creíble, aunque no completamente imposible

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-10-21
Opiniones en Hacker News

  • Parece muy probable que esté relacionado con una investigación sobre ciberdelincuencia rusa. Si leíste a Krebs o alguna vez viste foros rusos más oscuros, xmpp.ru te va a sonar; de hecho, existe ese contexto.
    No intento endilgarle nada a los operadores; quiero decir que, cuando se opera un servicio anónimo, termina adquiriendo este tipo de características.
    https://ddanchev.blogspot.com/2021/03/exposing-currently-act...
    https://ddanchev.blogspot.com/2019/07/profiling-currently-ac...
    https://blog.talosintelligence.com/picking-apart-remcos/
    https://flashpoint.io/wp-content/uploads/Plea-Agreement-USA-...
    El artículo en sí es realmente interesante y parece un ejemplo práctico de por qué todos deberían usar servicios de monitoreo de transparencia de certificados.

    • Las organizaciones de narcotráfico usan ampliamente XMPP junto con Tor como canal de comunicación seguro. El mercado darknet Hydra intentó expandir sus “servicios” a la UE y fue cerrado por la policía alemana en 2022; pudo haber pasado algo similar aquí, o quizá no.
    • Yo también lo veo más o menos así. Parece posible que esté relacionado con los cierres de Genesis Market o Qakbot.

  • Estoy de acuerdo con la mayoría de las medidas de mitigación propuestas. Si se trata de un objetivo de alto riesgo, vale la pena considerar superponer una capa adicional de autenticación que no dependa de autoridades certificadoras confiables: cosas como servicios onion de Tor, SSH o WireGuard.
    Coincido en que todos los certificados SSL/TLS emitidos están sujetos a transparencia de certificados, y crt.sh también tiene un feed RSS.
    Usar CAA suele ser una buena idea, pero me pregunto si ayuda en este caso. Al atacante le basta con solicitar exactamente la configuración de certificado permitida por CAA; aunque podría ayudar si se pudiera restringir con más fuerza un método de validación específico.
    También coincido en que hay que monitorear con un servicio externo los cambios de certificados SSL/TLS de todos los servicios. Los objetivos de alto riesgo siempre deben saber qué certificados son válidos y verificarlo.
    En cuanto a monitorear cambios en la dirección MAC del gateway predeterminado, un ataque más sofisticado podría mantener la misma dirección MAC.
    No sabía que el “channel binding” de XMPP también podía detectar un ataque de intermediario que presenta un certificado válido.

    • Soy autor de ACME-CAA (RFC 8657). Se puede poner el identificador único de una cuenta ACME en el registro CAA, de modo que esto puede mitigar ataques como este salvo que el atacante obtenga la clave privada de la cuenta ACME o fuerce el servicio ACME.
      Claro, bajo el supuesto de que el servidor de nombres esté protegido con DNSSEC. Si no, también podrían interceptar las consultas DNS cuando la autoridad certificadora las haga.
      Para ver todas las consideraciones de seguridad, basta con leer el RFC 8657. Este RFC fue diseñado para ser más fácil de leer que un RFC típico.
      Mi publicación de blog con contexto: https://www.devever.net/~hl/acme-caa-live
    • ¿Qué pasa si un Estado ordena a una autoridad certificadora dentro de su país emitir un certificado sin logs CT y además le impone una orden de silencio? Si la alternativa es ir a la cárcel por no obedecer, no creo que un administrador de sistemas común quiera ir preso para proteger un servidor Jabber ruso.
    • Si tienen acceso físico al servidor, simplemente apuntarían a eso. Con un poco de esfuerzo se pueden espejar el disco, la red y la RAM de hardware común.

  • Si lograron hacer perfectamente un ataque de intermediario real y se olvidaron de renovar el certificado, eso es bastante alemán :-)

    • Me pregunto si alguien lo “olvidó” a propósito. Tal vez quería que la gente se enterara de esto.
      O quizá alguien siguió las órdenes con muchísima diligencia. Había una orden de configurar el certificado, pero no un requisito de renovarlo automáticamente :)
    • Let’s Encrypt manda correos de aviso continuamente; ¿cómo podría pasar eso?

  • Archivo: https://archive.ph/C0jYJ
    Las teorías son interesantes y, si son ciertas, explican cómo obtuvieron el certificado. La lección podría ser tener varias sondas en distintos proveedores, verificar todas las huellas TLS y recibir alertas cuando aparezca una huella desconocida, comprobando además si existe en los logs de transparencia de certificados.
    openssl s_client -servername news.ycombinator.com -connect news.ycombinator.com:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin
    SHA1 Fingerprint=7E:49:BA:40:86:87:B3:39:66:93:94:9E:9C:45:71:85:3C:8D:95:16

    • Agregué la sección “¿Se puede prevenir o monitorear este tipo de ataque?”. Hay varias señales que pueden usarse para detectar el ataque desde el primer día.
      Como todos los certificados SSL/TLS emitidos están sujetos a transparencia de certificados, conviene configurar monitoreo de transparencia de certificados como Cert Spotter para recibir alertas por correo cuando se emita un nuevo certificado para el dominio.
      Si se restringen los métodos de validación usando las extensiones de registros CAA de RFC 8657 —es decir, Account URI y ACME Method Binding— y se especifica el identificador exacto de la cuenta que puede emitir nuevos certificados, se puede impedir la emisión de certificados para el dominio mediante otras autoridades certificadoras, cuentas ACME o métodos de validación.
      También hay que monitorear con un servicio externo los cambios de certificados SSL/TLS de todos los servicios, y monitorear los cambios en la dirección MAC del gateway predeterminado.

  • Me dio algo de curiosidad que la dirección MAC no fuera una dirección administrada localmente. Parecía posible que alguien hubiera elegido intencionalmente ese rango de direcciones
    https://www.google.com/search?q=%2290%253Ade%253A01%22+linod...
    Si buscas "90:de:01" linode y "90:de:00" linode, parece que recientemente se asignaron direcciones de este bloque a otras VM de Linode. No tengo ahora una VM de Linode para comparar directamente, pero parece que el tráfico se enrutó hacia otra VM dentro de la infraestructura de Linode

  • Es una especulación sin fundamento, pero creo que Jabber fue objetivo porque es conocido por usarse en mercados de la darknet para tráfico de drogas u otras actividades ilegales
    Esto demuestra que no se debe confiar solo en “está cifrado, así que está bien”. Como mínimo, los mensajes deberían cifrarse con PGP
    Me pregunto si PGP puede romperse con computadoras cuánticas y si en el futuro habrá refuerzos contra ese tipo de ataques. Si se recopilaron mensajes cifrados en masa, al final descifrarlos podría ser solo cuestión de tiempo
    Y parece que esto ocurre con casi todo el tráfico web al que se puede acceder. Ver https://en.wikipedia.org/wiki/Utah_Data_Center

    • Jabber/XMPP tiene cifrado de extremo a extremo desde hace al menos 10 a 15 años. En la época en que Facebook/Google Talk soportaban XMPP, se podía usar así incluso con amigos comunes mediante pidgin, kopete, etc.
      Claro que intercambiar claves de forma segura con un vendedor anónimo de drogas en internet es propenso a errores
    • Este ataque de intermediario podría haber sido parte del cierre de Genesis Market, aunque no deja de ser una especulación bastante sacada de la nada
      https://therecord.media/genesis-market-takedown-cybercrime
    • Una segunda capa de cifrado ayudaría, pero no recomendaría PGP en particular
      PGP tiene muchos problemas y mucha gente recomienda evitarlo. Por ejemplo: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ / https://news.ycombinator.com/item?id=20455780

  • Las comunicaciones con cifrado de extremo a extremo como OMEMO, OTR y PGP solo están protegidas contra interceptaciones cuando ambas partes verificaron las claves de cifrado. El atacante tendría que armar un ataque de intermediario separado para cada método de cifrado de extremo a extremo usado
    Algunos clientes XMPP que he visto no dejaban usarlo si no se indicaba explícitamente que se había verificado una identidad de cifrado específica
    Aun así, es un buen recordatorio. Si nunca viste ni gestionaste un número absurdamente largo o algún valor equivalente, es difícil decir que realmente se estableció cifrado de extremo a extremo

  • Hay una parte de esta historia que no entiendo. Si se trataba de una interceptación legal, ¿por qué Hetzner y Linode habrían configurado una interceptación de intermediario con un certificado y una clave LE separados?
    Podrían haber extraído directamente la clave privada TLS desde la RAM o el almacenamiento del VPS. Incluso en un servidor físico dedicado, se podría hacer un volcado de RAM tras un reinicio sin aviso y sacar la clave privada
    La extracción de la clave privada no aparece en los logs de CT, así que es mucho más sigilosa y prácticamente imposible de detectar

    • Probablemente porque era más fácil
      Otra posibilidad es que una cosa fuera un “registro” y la otra una “interceptación”, y que los niveles de autorización fueran distintos. Aunque no conozco bien la situación legal actual en Alemania
    • Probablemente porque eso sería “más ilegal”. Si el servidor no está directamente involucrado en actividades de ciberdelincuencia, no creo que esté permitido hackearlo
    • Si es un servidor físico, ¿no se podría conectar en caliente una tarjeta PCIe y extraer los datos deseados vía DMA? Algo como una tarjeta de red con firmware hecho a la medida podría hacerlo
      Suena como un método demasiado estándar para las fuerzas del orden, así que imagino que ese tipo de equipo podría existir como producto listo para usar

  • Un usuario ya lo había publicado en Reddit hace 3 días: https://www.reddit.com/r/hetzner/comments/17ankoh/does_hetzn...

  • Me pregunto si hay alguna forma legal de exigir a Hetzner/Linode un comentario sobre esta situación. Parece muy probable que detrás de la interceptación haya alguna agencia gubernamental o la policía

    • Dado que Hetzner es una empresa alemana, si se trata de una interceptación legal no se les puede exigir una respuesta. Sería difícil sin pasar primero por un abogado
      En cambio, si no fuera una interceptación legal, no creo que Hetzner la hubiera permitido. Eso también sería una violación de la ley
    • Tampoco hay garantía de que la interceptación se haya hecho a través de Hetzner o Linode. Por ejemplo, podría haber sido del lado del operador de telecomunicaciones, y en casi cualquier país, desde hace décadas, los operadores han sido obligados a colaborar con la interceptación legal