El caso de cómo, buscando RCE por US$20, terminaron siendo administradores de .mobi

 (labs.watchtowr.com)
2 puntos por GN⁺ 2024-09-12 | 1 comentarios | Compartir por WhatsApp
  • watchTowr Labs registró por unos US$20 el dominio vencido dotmobiregistry.net, con lo que tomó control del antiguo hostname del servidor WHOIS de .mobi, y comprobó que clientes WHOIS antiguos y flujos de validación de certificados TLS/SSL todavía confiaban en esa dirección
  • Aunque el servidor WHOIS oficial de .mobi se había trasladado a whois.nic.mobi, muchas herramientas seguían consultando la dirección antigua, whois.dotmobiregistry.net, con el valor hardcodeado
  • Tras desplegar un servidor WHOIS temporal el 30 de agosto de 2024, hasta el 4 de septiembre recibieron consultas de más de 135,000 sistemas únicos y 2.5 millones de consultas, lo que dejó en evidencia que un dominio legacy abandonado seguía ampliamente conectado con infraestructura real de Internet
  • Algunas autoridades certificadoras TLS/SSL usaban validación por correo basada en WHOIS para verificar la propiedad de dominios .mobi, y en una prueba con GlobalSign apareció whois@watchtowr.com como candidato de correo de verificación para microsoft.mobi
  • Los investigadores no emitieron realmente un certificado malicioso; posteriormente, el NCSC del Reino Unido y ShadowServer conectaron el dominio a un sinkhole para que proxyara respuestas WHOIS legítimas de .mobi

Un dominio vencido de US$20 resucita como infraestructura WHOIS

  • El objetivo original de watchTowr Labs era encontrar una RCE explotable en la práctica en el proceso con el que los clientes WHOIS parsean las respuestas del servidor
  • En los experimentos iniciales, se hicieron pasar por un servidor WHOIS y devolvieron cadenas largas, confirmando que algunos clientes crasheaban con facilidad
  • Sin embargo, para que un atacante controle una respuesta WHOIS, normalmente necesitaba una de estas condiciones
    • Un MITM que intercepte el tráfico WHOIS en la capa de red
    • Acceso al servidor WHOIS real
    • Un referral WHOIS que apunte a un servidor controlado por el atacante
  • Estos prerrequisitos son una barrera alta para ataques reales, pero la situación cambió cuando venció el dominio del antiguo servidor WHOIS de .mobi
  • El servidor WHOIS de .mobi se había movido de whois.dotmobiregistry.net a whois.nic.mobi, y el dominio anterior, dotmobiregistry.net, estaba vencido desde alrededor de diciembre de 2023
  • Tras registrar ese dominio, watchTowr colocó un servidor WHOIS detrás de whois.dotmobiregistry.net para comprobar si los clientes WHOIS que tenían hardcodeada la dirección antigua seguían consultándolo

La superficie de ataque creada por hardcodear direcciones de servidores WHOIS

  • WHOIS usa servidores separados por cada TLD, pero no cuenta con un mecanismo estandarizado sólido para que los clientes descubran ese servidor en tiempo real
  • En la práctica, es común que las herramientas WHOIS tomen como referencia una lista de texto publicada por IANA y hardcodeen en tiempo de desarrollo las direcciones de los servidores
  • Cuando las direcciones de servidores no cambian con frecuencia, el problema se nota menos, pero si una dirección cambia y el dominio antiguo vence, los clientes obsoletos pueden seguir consultando la dirección abandonada
  • watchTowr respondió a las solicitudes WHOIS entrantes con el servidor lglass y devolvió información WHOIS falsa que hacía parecer que watchTowr era el propietario de todos los objetivos consultados
  • La respuesta también incluía ASCII art y una solicitud para que dejaran de consultar

Volumen y origen de las consultas observadas

  • Tras desplegar el servidor WHOIS el 30 de agosto de 2024, en cuestión de horas consultaron más de 76,000 IP de origen únicas
  • En unos dos días, la base SQLite acumuló 1.3 millones de consultas, y para el 4 de septiembre de 2024 se confirmaron 2.5 millones de consultas y más de 135,000 sistemas únicos
  • Entre los orígenes de las consultas había grandes registradores de dominios y sitios que ofrecen funciones WHOIS
    • domain.com
    • godaddy.com
    • who.is
    • whois.ru
    • smallseo.tools
    • seocheki.net
    • centralops.net
    • name.com
    • webchart.org
  • Servicios de análisis de seguridad también usaban el antiguo servidor WHOIS de .mobi
    • urlscan.io usaba esos resultados WHOIS en páginas de dominios .mobi
    • VirusTotal consultaba el servidor WHOIS temporal de watchTowr y mostraba los resultados
  • También se identificaron numerosos servidores de correo y filtros antispam
    • Los filtros antispam pueden realizar búsquedas WHOIS sobre el dominio del remitente
    • Los casos iban desde cheapsender.email hasta hosts que parecían infraestructura gubernamental de Bangladesh, como mail.bdcustoms.gov.bd
  • Se observaron direcciones relacionadas con .gov en varios países
    • Argentina, Pakistán, India, Bangladesh, Indonesia, Bután, Filipinas, Israel, Etiopía, Ucrania, EE. UU.
    • Como ejemplos relacionados con Brasil se incluyeron antispam.ap.gov.br y master.aneel.gov.br
  • Entre los orígenes .mil apareció como ejemplo Swedish Armed Forces
  • También se identificaron orígenes .edu y de empresas de seguridad, con menciones a Group-IB, Detectify y Censys
  • Si direcciones .gov y servidores de correo consultan el servidor WHOIS cada vez que reciben emails desde dominios .mobi, surge la posibilidad de observar pasivamente quién se comunica con quién

Vulnerabilidades en clientes WHOIS antiguos y posibilidad de RCE

  • watchTowr buscó precedentes de vulnerabilidades en el parseo de respuestas WHOIS y resumió que, de 26 resultados de CVE relacionados, solo quedaban 3 bugs activables mediante una respuesta WHOIS malformada
  • Una posible razón de que haya tan pocos casos es la percepción de que la explotación real requiere prerrequisitos difíciles, como controlar el servidor WHOIS de un TLD
  • phpWHOIS CVE-2015-5243 es una vulnerabilidad que permite RCE porque ejecuta con eval de PHP los datos recibidos desde el servidor WHOIS
    • El código vulnerable escapaba de forma incompleta solo " en la cadena de respuesta WHOIS antes de pasarla a eval
    • El análisis de Netitude presentaba un payload de ejemplo como ”;phpinfo();//
    • Las versiones vulnerables de phpWHOIS tenían hardcodeado whois.dotmobiregistry.net
  • Fail2Ban CVE-2021-32749 es una vulnerabilidad de inyección de comandos porque la salida WHOIS se pasaba sin sanitización adecuada a la herramienta mail
    • Fail2Ban puede consultar por WHOIS la información del propietario de una IP bloqueada e incluirla en un correo al administrador
    • Sin embargo, esta vulnerabilidad ocurre en consultas WHOIS sobre direcciones IP, por lo que no se alcanza directamente solo con el control del servidor WHOIS de dominios .mobi que obtuvo watchTowr
  • Para lograr ejecución real de código, sigue siendo necesario que coincidan un cliente que todavía consulte el antiguo servidor WHOIS de .mobi y una implementación vulnerable del cliente

Impacto incluso en flujos de validación de certificados TLS/SSL

  • Algunas autoridades certificadoras TLS/SSL soportan un método en el que parsean el correo de contacto administrativo desde los datos WHOIS para confirmar la propiedad del dominio y envían un enlace de verificación a ese correo
  • Los ejemplos listados por watchTowr de autoridades certificadoras o revendedores que soportan validación de propiedad basada en WHOIS son
    • Trustico
    • Comodo
    • SSLS
    • GoGetSSL
    • GlobalSign
    • DigiSign
    • Sectigo
  • En una prueba con GoGetSSL, al subir un CSR ficticio de watchTowr.mobi, no apareció el whois@watchtowr.com configurado por watchTowr, sino solo un correo placeholder que indicaba que WHOIS no había tenido éxito
  • En una prueba con Entrust, se parseó el registro WHOIS legítimo de microsoft.mobi y solo aparecieron como candidatos de verificación correos del dominio microsoft.com; watchTowr.mobi no fue parseado
  • En una prueba con GlobalSign, al principio parecía que no podía parsear el registro WHOIS de microsoft.mobi, pero el resultado cambió cuando watchTowr copió el formato de salida de microsoft.mobi del servidor WHOIS legítimo y lo adaptó para servirlo desde su propio servidor WHOIS
  • GlobalSign consultó el servidor WHOIS de watchTowr y parseó whois@watchtowr.com desde la respuesta, proponiéndolo como correo de verificación para microsoft.mobi
  • watchTowr se detuvo en ese punto y no emitió realmente un certificado TLS/SSL malicioso
  • En teoría, el flujo de ataque sería el siguiente
    • Colocar un servidor WHOIS malicioso en el antiguo hostname autoritativo
    • Intentar comprar un certificado TLS/SSL para un dominio .mobi objetivo
    • La autoridad certificadora consulta WHOIS y envía el correo de verificación a una dirección del atacante, no al propietario real
    • Si el atacante hace clic en el enlace, puede obtener un certificado TLS/SSL para el dominio objetivo
  • Con esa capacidad, ataques como interceptar tráfico o suplantar el servidor objetivo serían teóricamente posibles

Medidas posteriores y problemas pendientes

  • Antes de la publicación, el NCSC del Reino Unido y la ShadowServer Foundation respondieron en conjunto
  • El dominio dotmobiregistry.net y el hostname whois.dotmobiregistry.net fueron conectados a un sistema de sinkhole proporcionado por ShadowServer
  • Ese sinkhole proxya respuestas WHOIS legítimas para dominios .mobi
  • También se estableció un proceso para notificar a las partes afectadas
  • Este caso muestra una falla estructural que aparece cuando interactúan infraestructura legacy, dominios abandonados, procesamiento basado en WHOIS y procedimientos de validación de autoridades certificadoras TLS/SSL
  • Un actor con capacidad de MITM también podría falsificar datos WHOIS e intentar el mismo tipo de ataque; e incluso con mecanismos como la transparencia de certificados, siguen existiendo barreras operativas para ataques a gran escala

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-09-12
Opiniones de Hacker News

  • Para que se llegara a esta situación seguramente se combinaron errores de varias personas, pero hay algo claro que habría podido evitar este ataque en particular: nunca dejar que un dominio expire
    El servidor WHOIS del dominio de nivel superior .MOBI se trasladó hace unos años de whois.dotmobiregistry.net a whois.nic.mobi, y parece que el dominio dotmobiregistry.net quedó abandonado tras expirar alrededor de diciembre de 2023
    Cuando una empresa empieza a usar un dominio nuevo porque cuesta 10 dólares al año, ese dominio se convierte, en la práctica, en un activo por el que deberá pagar 10 dólares al año para siempre. Una vez que un dominio queda asociado a un negocio, esa asociación no se puede cortar por completo

    • Esta es la razón más clara de por qué Verisign es un operador monopólico y debería regularse como un bien público, igual que la electricidad o el agua. La idea de que hay opciones y de que uno no queda atado es casi una ilusión; cuando compras un dominio y empiezas a usarlo, en la práctica quedas ligado a él para siempre. Verisign también lo sabe, por eso pelea desesperadamente por conservar su monopolio
    • Incluso Google metió la pata con esto por un momento
      https://money.cnn.com/2016/01/29/technology/google-domain-pu...
    • Siempre hay que usar subdominios. Para una empresa, un solo dominio de 10 dólares al año basta durante toda su existencia
    • Me gusta este punto. Me recuerda las publicaciones del blog de Backblaze donde calculaban la probabilidad de que fallaran tantos discos como para perder datos de usuarios
      Al final, creo que el valor calculado en sí no era tan importante, porque es más probable olvidar el pago por perder un aviso de renovación debido a una tarjeta de crédito vencida o a filtros de spam
      ¿Cómo hacen las grandes empresas para no olvidar pagar los costos de sus dominios? ¿Le encargan a un registrador caro renovaciones por un período cercano al “infinito”? Parece un problema de operaciones de negocio bastante difícil

  • Tengo la sensación de que un día voy a despertarme y ver la noticia de que, desde una habitación de hotel en un lugar remoto, alguien hizo algo con una Raspberry Pi conectada al hotspot Wi-Fi de un café cercano y desapareció todo Internet

    • Me recuerda a cuando en las residencias universitarias alguien conectaba cualquier router que había traído de casa y rompía Internet al repartir direcciones DHCP incorrectas. Es como eso, pero a escala mundial
    • En realidad, bastantes cosas se sostienen con esperanza y rezos [0], pero Internet fue diseñada para ser robusta [1]. En este caso, el alcance estuvo limitado a .mobi
      [0] https://xkcd.com/2347/
      [1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
    • Que esto se relacione con el reciente “White House asks agencies to step up internet routing security efforts” [1] es pura coincidencia
      [1] https://news.ycombinator.com/item?id=41482087

  • ¿Por qué las herramientas usan listas de servidores WHOIS hardcodeadas?
    Parece que hay una forma estándar de registrarlos en DNS, pero una prueba rápida muestra que a muchos dominios de nivel superior les faltan esos registros. Un ejemplo que sí funciona es dig _nicname._tcp.fr SRV +noall +answer, que devuelve _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.
    Además, existe un borrador de Internet vencido sobre esto: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...

    • Con solo tener mobi.whois.arpa. CNAME whois.nic.mobi ya se habría podido resolver el problema. El problema es lograr que todos se pongan de acuerdo y adopten esa forma
      Como dijo fanf2 más abajo, parece que también se podría consultar primero al servidor WHOIS de IANA. Si consultas mobi en https://www.iana.org/whois, parte de la respuesta incluye whois: whois.nic.mobi
    • En la realidad existen muchísimas más cadenas hardcodeadas de las que uno imagina, y muchas más de las que debería haber
    • WHOIS probablemente sea mucho más antiguo incluso que el concepto de registros SRV
    • Estas herramientas normalmente se crean por una necesidad puntual y se publican para que otra persona las use o para que su propio autor las consulte después. Otros “ingenieros” las copian y pegan sin dudar, y cuando eso entra en producción se convierte en un CVE como este
      La falta de capacidad de los desarrolladores ya es un problema, pero las alucinaciones de IA van a empeorar aún más esta situación

  • He visto demasiados equipos que no se dan cuenta de que, cuando empiezas a usar un dominio de forma significativa, en la práctica tienes que renovarlo hasta la muerte térmica del universo o, al menos, hasta la muerte térmica del equipo
    Ya sea un caso como este, una URL vieja pero importante que quedó en algún lado, o que un integrante del equipo se haya registrado en un servicio con un correo del dominio antiguo, es muy difícil saber cuándo realmente puedes soltar un dominio viejo

  • La superficie de ataque que aparece con solo comprar un dominio expirado de un servidor WHOIS antiguo es realmente enorme

  • La verdadera solución para WHOIS es RDAP
    Lamentablemente, no es obligatorio para los dominios de nivel superior de código de país, y entre los dominios de nivel superior que no son de código de país también hay muchos donde no funciona correctamente
    https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
    https://resolve.rs/domains/rdap-missing.html

    • ¿Cómo mitiga eso los problemas descritos en el artículo?

  • Un trabajo excelente.
    El dominio dotmobiregistry.net y el hostname whois.dotmobiregisry.net ahora apuntan a un sistema sinkhole proporcionado por ShadowServer, y se indica que este sistema hace de proxy para las respuestas WHOIS legítimas de los dominios .mobi.
    Si esos dominios iban a quedar en desuso, habría sido mejor devolver una respuesta tipo 404. Si se les permite seguir funcionando como si fueran normales, disminuye el incentivo para migrar al dominio oficial.

    • Whois no admite códigos de estado HTTP, pero el sinkhole de ShadowServer responde así:
      Domain not found.
      >>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<
    • Por lo que se ve en el artículo, llevaba años roto y muchos clientes no se habían dado cuenta.

  • Creo que el enfoque general de la computación está condenado al fracaso. Depende de una seguridad perfecta, y se asume que esa seguridad se logra con revisiones de SBOM y actualizaciones frecuentes.
    Pero eso nunca ocurre. Incluso con log4j, el 40% de todas las descargas corresponde a versiones vulnerables. Ni hablar de cuando un proveedor dentro de la cadena de suministro cierra o deja de mantener un componente.
    Igual que nuestro cuerpo es siempre un campo de batalla contra microorganismos, todo inevitablemente estará siempre lleno de bugs y agujeros.

    • No; de forma lenta pero segura se puede escribir código bueno y confiable, usarlo para crear mejores herramientas y luego usar esas herramientas para construir lo siguiente.
      Probablemente tome décadas, pero el camino parece bastante claro. Hay que dedicarle esfuerzo, aplicar el conocimiento obtenido de cada “lección” y no detenerse.

  • En general, me gustó el tono de “no queríamos hacer esto, pero la situación siguió creciendo y en cada paso obtuvimos algo más grande de lo esperado”.
    Si quienes se oponían hubieran escuchado y corregido el parsing, quizá los autores se habrían ahorrado todo ese trabajo.

  • Si le damos la vuelta a esto, ¿se supone que debemos confiar en que todos los servidores WHOIS del mundo son siempre auténticos y seguros?
    Especialmente desde el punto de vista de una autoridad certificadora que realiza validación TLS, no querría enterarme de que al ejecutar whois somethingarbitrary.ru quedo expuesto a ejecución remota de código por culpa de un servidor ruso.