Cuando los nombres de host internos se filtran a la nube

 (rachelbythebay.com)
1 puntos por GN⁺ 2026-02-06 | 1 comentarios | Compartir por WhatsApp
  • Se descubrió un caso en el que la interfaz web de un equipo NAS doméstico envía un nombre de host solo interno a un servicio externo
  • Un script de reporte de errores de sentry.io incluido en la UI web del NAS envía el nombre de host interno al exterior junto con el stack trace
  • Se observó un comportamiento extraño en el que sentry.io intenta iniciar de vuelta una conexión TLS usando ese nombre de host, pero sin enviar una solicitud real
  • Gracias a que ya se había configurado DNS wildcard con anticipación, fue posible detectar la filtración, y si se usan nombres de host sensibles existe un riesgo grave de exposición de información
  • Existe un posible problema de seguridad por el que, si se abusara de este mecanismo, se podría inducir un escaneo DNS sobre hosts arbitrarios

Instalación del NAS y configuración del nombre de host interno

  • Se compró un equipo NAS, se instalaron los discos y se conectó a la red doméstica, operándolo en modo HTTPS
  • Se instaló un certificado TLS wildcard para una subzona de un dominio sin significado en Internet pública (por ejemplo, *.nothing-special.whatever.example.com)
  • Se agregó una entrada solo local como 172.16.12.34 nas.nothing-special.whatever.example.com al archivo /etc/hosts para acceder desde el navegador

Descubrimiento de accesos inesperados desde el exterior

  • Unos días después de instalar el NAS, empezaron a llegar solicitudes desde el exterior ("outside world") usando ese mismo nombre de host
  • Ese nombre de host era un nombre completamente interno que solo existía en el archivo /etc/hosts de la laptop
  • Fue posible detectar la filtración porque ya se había configurado de antemano una entrada DNS wildcard para *.nothing-special.whatever.example.com apuntando a una máquina administrada por la persona afectada
  • Cada vez que se cargaba el NAS, un host de GCP intentaba conectarse presentando ese nombre de host interno como SNI

Causa de la filtración: reporte de errores a sentry.io

  • La interfaz web del NAS incluía una función de phone home y, como parte de ella, enviaba stack traces a sentry.io
  • El navegador hacía el callback a sentry.io y al mismo tiempo enviaba el nombre de host usado para el equipo de almacenamiento interno
  • Se confirmó que del lado de sentry.io se creaba una conexión TLS de vuelta hacia ese nombre de host, pero sin enviar ninguna solicitud HTTP real

Implicaciones de seguridad y respuesta

  • Si el nombre de host incluye información sensible (por ejemplo, algo como mycorp-and-othercorp-planned-merger-storage), existe riesgo de una filtración grave de información
  • Usando este mecanismo de reporte de sentry, sería posible inducir un escaneo DNS sobre hosts externos arbitrarios (el método concreto se deja al lector)
  • Como medida de respuesta, se ejecutó Little Snitch para bloquear ese dominio completo para todas las apps

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-02-06
Comentarios en Hacker News

  • Parece que la gente lo está entendiendo mal. Esto no es un problema de logs de CT, sino de certificados wildcard
    Sentry, al recopilar trazas del lado del cliente, extrajo el nombre de host al que se enviaba la solicitud e intentó volver a consultarlo, pero fue rechazado

    • Probablemente también pudo haber sido un intento de obtener el favicon para mostrarlo en la UI de trazas
    • Pero con una arquitectura así, Sentry podría terminar enviando solicitudes a IP arbitrarias, lo que crea una vulnerabilidad de seguridad. En particular, incluso podría acceder repetidamente a IP que reportan tráfico malicioso de forma automática
    • La razón por la que la gente se confunde es que la entrada del blog está escrita de forma muy confusa y poco clara

  • Los nombres de host, en esencia, no son información privada
    Se exponen al exterior por varias vías, como consultas DNS o certificados TLS
    Si quieres ocultar un servicio privado, es mejor poner el secreto en la ruta de la URL en vez de en el nombre de host
    Por ejemplo, algo como fileservice.example.com/my-hidden-service-007-abc123/ se transmite solo por HTTPS, así que queda mucho menos expuesto

    • Claro que, incluso en ese caso, la ruta puede enviarse a servicios externos como Sentry, así que conviene usar URL opacas y no acostumbrarse a poner secretos en la URL
    • También hubo quien preguntó: “¿Si se usara solo HTTP, se reduciría este tipo de exposición?”

  • Alguien preguntó si “clown GCP Host” era un término técnico. Resultó que el autor estaba usando una forma satírica de referirse a la cloud
    El punto central del problema es que la interfaz web del NAS enviaba logs a Sentry incluyendo nombres de host internos
    En un caso así, yo probablemente lo reemplazaría por un SO open source confiable, o bloquearía las llamadas a Sentry con filtrado DNS como PiHole

    • “clown” es una forma de burlarse de la cloud de Big Tech; según dicen, en IRC antes también se usaba la expresión “clown computing”
      Alguien explicó que usa DNS local y un proxy TLS para bloquear por completo el tráfico saliente hacia el exterior
    • Otra persona añadió que “clown” es un término viejo para satirizar a los grandes proveedores cloud y sus usuarios
    • Uno bromeó con que a veces usa la palabra “weenie” en lugar de “clown”
    • También hubo humor del estilo: “El circo se fue, pero los payasos se quedaron”

  • Por casos como este, considero que uBlock Origin es el mínimo indispensable para la seguridad web
    Es demasiado grave que la mayoría de las páginas web carguen montones de scripts de terceros y filtren datos
    No es una solución de fondo, pero sí lo mejor que podemos hacer ahora mismo

    • Yo también instalé AdGuard Home en el router y bloquea entre 15% y 20% del tráfico. Eso te hace notar cuán severos son el rastreo y la publicidad

  • Para evitar este tipo de problemas, conviene poner un proxy inverso Nginx al frente e inyectar encabezados CSP
    Eso no impide que el NAS haga solicitudes hacia afuera por sí mismo, pero sí puede bloquear las que hace el navegador en su lugar
    Por ejemplo, una solicitud de avatar de Steam (https://avatars.steamstatic.com/HASH_medium.jpg) también puede bloquearse con una política CSP
    Si hace falta, se puede dejar abierto solo una parte. Además, se puede añadir Referrer-Policy: no-referrer para que el nombre de host no quede registrado en logs externos

    • Alguien señaló la redundancia de decir “ATM machine”
    • Y otra persona respondió en tono de broma: “NPM es bastante simple”

  • Compré un Synology NAS y me he arrepentido varias veces
    Fuera del software de la comunidad, casi no hay nada que puedas hacer
    Aplicar SSL con Let's Encrypt también es complicado, y como las rutas no son estándar, cuesta encontrar dónde va cada configuración
    Hay muchas quejas: versión vieja de rsync, falta de utilidades básicas, etc. Mejor habría usado un NAS basado en Linux o BSD

    • También hubo quien dijo que, usándolo solo como servidor de archivos, Synology es muy estable y queda satisfecho. Aun así, por sus políticas cerradas, planea mudarse a UniFi NAS
    • Otra respuesta fue que “querer un servidor y quejarse de que un NAS no es un servidor” es contradictorio
    • Alguien compartió que en el foro de Doozan hay una guía para instalar Debian reciente en un Synology NAS
    • También aconsejaron: “Déjalo solo como servidor de archivos/iSCSI, que es muy estable, y no lo toques”
    • En cambio, otra persona dijo que compró un modelo RS217 por $100 y fue de sus mejores compras. Usa Synology Office en lugar de Google Docs y quedó impresionado con el nivel de acabado de la UI

  • Hace poco configuré Sentry y este sistema tiene una función que intenta configurar monitoreo de uptime automáticamente
    Si reconoce un host, le envía pings periódicos y, si responde de forma estable durante unos días, muestra una alerta del tipo: “¿Quieres configurar monitoreo de uptime para este host?”

    • Alguien comentó brevemente: “Oportunidad de expansión”

  • Yo personalmente bloqueo todo el dominio relacionado con Sentry
    No es una solución general, pero en mi entorno es lo mejor

  • En los servidores de búsqueda inversa de direcciones se ven a menudo intentos de resolver hasta direcciones de red interna (ULA, RFC1918)
    Si combinas esos datos con otra información, puedes inferir el estado interno de una red
    Incluso comentaron que “durante la recolección en la darknet llegaron a capturar audio por UDP”

    • A eso alguien respondió preguntando: “¿Ese audio UDP correspondía a tráfico SIP de qué año?”

  • Hace tiempo investigué algo parecido en Heroku
    Cuando creas una app nueva, se le asigna un subdominio aleatorio, pero incluso antes de hacer cualquier consulta DNS ya empiezan a llegar solicitudes de escáneres de vulnerabilidades
    Cuando pregunté a Heroku, me dijeron que era porque la URL de la nueva app quedaba expuesta en los logs de transparencia de certificados (CT)

    • Alguien comentó que eso equivale a poner un letrero de “por favor atáquenme” en cada servicio nuevo, y señaló que en los logs de CT deberían haberse registrado solo hashes en vez de certificados reales
      También compartieron el enlace How Certificate Transparency Works
    • Otra persona dijo: “Yo uso un dominio wildcard para evitar ese problema”, y subió una captura (enlace a imagen)