Fantasmas virtuales

Ya está disponible para todos los clientes de Censys un nuevo tipo de activo: las entidades web. Una "entidad web" en Censys permite a los usuarios tratar sus activos basados en web como un único bien de alto nivel, agrupando hosts y servicios como parte del ecosistema de servicios web de una organización.

Además de introducir esta nueva clasificación de datos, hemos desarrollado métodos novedosos para rastrear los posibles activos informáticos en la sombra dentro de una organización. Las TI en la sombra hacen referencia a la tecnología, los sistemas y las aplicaciones que los empleados utilizan sin el conocimiento o la aprobación de los departamentos de TI pertinentes. Estos sistemas se despliegan sin la debida autorización, ya sea por error o en nombre de la productividad. La TI en la sombra puede adoptar varias formas, entre ellas

• El uso de servicios personales de almacenamiento en la nube como Dropbox
• Equipos que utilizan herramientas de gestión de proyectos sin supervisión informática
• Dispositivos móviles personales u ordenadores portátiles no autorizados
• Utilizar direcciones de correo electrónico personales para interacciones relacionadas con el trabajo
• Uso no autorizado de servicios en la nube y de alojamiento web

Si se despliega un servidor sin la supervisión de una organización de TI, es probable que el servidor carezca de acceso a las ventajas de la automatización estándar de TI, como las capacidades de supervisión y telemetría, las actualizaciones periódicas del sistema y una higiene de configuración adecuada. Esta falta de apoyo puede dejar el sistema vulnerable a riesgos de seguridad e ineficiencias.

En este post, explicaremos un sencillo método técnico que utilizamos para localizar servidores web que, por definición, no deberían existir. La ausencia de contexto histórico tanto a nivel de host como de DNS hace que estos activos sean totalmente imperceptibles para la mayoría de las herramientas. Sin embargo, podemos obtener más información sobre posibles exposiciones de datos añadiendo contexto histórico a la superficie de ataque de una organización.

Pero antes de llegar a lo bueno, debemos tener una comprensión básica de los diferentes puntos de vista que Censys tiene de Internet.

Las opiniones de Censys

Censys tiene dos visiones únicas pero similares de Internet: la que no tiene nombre y la que tiene nombre.

(Un anfitrión anónimo en Censys)

La vista "Internet sin nombre" engloba los hosts y servicios que responden directamente desde una dirección IP y reaccionan igual tanto si se solicita a través de un nombre de host como de una dirección IP. Muchos servicios de Internet no disponen de medios para que un cliente especifique el nombre de host en la solicitud. Por ejemplo, nada en el protocolo SSH puede informar al servidor remoto de que estás interesado en un nombre de host concreto, por lo que la respuesta será la misma tanto si te conectas a él directamente a través de IP como de un nombre.

(Un host con nombre en Censys)

Por otro lado, la vista de "Internet con nombre" son los hosts y servicios que Censys puede ver independientemente de la IP física y a los que, en cambio, se hace referencia mediante un nombre. Para que los servicios respondan de forma diferente a un nombre de host específico, un intercambio entre el cliente y el servidor debe especificar el nombre después de establecer la conexión. Este proceso significa que debe haber algún método en el protocolo subyacente que inicie dicho intercambio.

"...la vista 'named internet' son los hosts y servicios que Censys puede ver independientemente de la IP física...."

Afortunadamente, dos de los protocolos más comunes en Internet admiten este mecanismo, aunque por razones ligeramente diferentes:

• El protocolo HTTP (a partir de la versión 1.1) especifica que debe incluirse una cabecera "Host" con cada solicitud del cliente, informando al servidor del nombre de host específico y del recurso que se solicita. Sin esta cabecera, cada nombre de dominio necesitaría su propia dirección IP dedicada.
• TLS SNI (Server Name Indication) es una extensión del protocolo Transport Layer Security (TLS) que permite a un cliente "indicar" el nombre de host del servidor al que intenta conectarse antes de establecer una conexión segura. Sin SNI, el servidor no podría determinar el nombre de host correcto y el certificado subyacente asociado y devolvería cualquier certificado por defecto que el servidor hubiera configurado - esto significaría que cada certificado SSL necesitaría su propia dirección IP dedicada para funcionar de forma segura.

En resumen, el servidor web utiliza SNI para responder con un certificado específico para el nombre de host, y la cabecera HTTP Host asigna la solicitud a una entidad backend distinta, como un directorio del sistema de archivos. La gente suele referirse a todo este proceso como "Hosting Virtual".

Muchos servidores web modernos como Nginx tienen opciones de configuración avanzadas en las que no sólo se pueden servir diferentes directorios basados en las cabeceras entrantes del cliente, sino que estas peticiones pueden dirigirse de forma transparente a escuchas y aplicaciones separadas, lo que puede cambiar enormemente la visión de un único host.

Dado que la mayoría de los servidores web responderán de forma diferente en función de la solicitud del cliente, si Censys sólo escaneara el mundo utilizando la dirección IP de los hosts, tendríamos una imagen mínima de cómo es Internet en realidad, y nuestros datos estarían totalmente incompletos; por este motivo, hace unos años introdujimos el escaneado basado en nombres, que hace exactamente lo descrito anteriormente tanto para los protocolos basados en HTTP como en TLS.

Estos escaneos basados en nombres pueden responder a algunas preguntas únicas que alguien pueda tener. Por ejemplo, con nuestros datos, podemos obtener fácilmente un informe sobre el número de IPs por nombre: "el martes pasado, había 325.484.066 nombres de host con una sola dirección IP, y en el otro lado de la balanza, había UN nombre de host que correspondía a 10.733 direcciones IP".

Y cuando se mezclan estos datos de exploración con nombre propio con el contexto histórico, las cosas se ponen aún más interesantes.

Anfitriones muertos y fantasmas virtuales

Al analizar una superficie de ataque, a menudo es un error centrarse únicamente en los aspectos observables del momento presente, como el estado actual del DNS. Pasar por alto los artefactos del pasado puede llevar a una subestimación significativa del estado oculto actual de una superficie de ataque.

"...a menudo es un error centrarnos únicamente en los aspectos observables del momento presente...."

En HTTP, tanto la cabecera Host como el valor SNI de TLS son cadenas arbitrarias. Nada en las especificaciones del protocolo establece que estos valores deban tener una función o incluso ser legítimos. Un cliente puede solicitar google.com desde una IP de twitter.com, y nada se lo impediría. Claro, podría obtener un error del servidor indicando que el host no pudo encontrar datos para el nombre de host solicitado, pero nada detuvo ese intercambio.

En la misma línea, si un administrador elimina un registro DNS que apunta a una dirección IP pero mantiene la configuración del servidor web que asignaba ese nombre a un recurso local, entonces alguien con conocimiento previo de que ese nombre de host pertenece a esa IP podría seguir accediendo a los datos como si el registro DNS siguiera existiendo.

Por otra parte, si un administrador comprara un nuevo servidor para su plataforma de venta de entradas y modificara la entrada DNS para que apunte a la dirección IP del nuevo servidor, sin eliminar nunca la configuración del servidor web antiguo, y luego parcheara una vulnerabilidad crítica en el software del nuevo servidor, pero no en el antiguo, un atacante podría utilizar la información histórica para explotar el software del host antiguo.

En resumen, cuando se altera el registro DNS de un nombre de host para que apunte a una nueva dirección IP o se elimina por completo del DNS, pero la dirección IP anterior sigue operativa con una configuración de host virtual válida para el mismo nombre de host, un atacante con conocimiento histórico del host puede seguir accediendo a los datos antiguos en el servidor antiguo.

A falta de un término establecido para describir este método de análisis de hosts, hemos bautizado informalmente a estos hosts como "fantasmas virtuales","un juego de palabras con el término "host virtual".

Cazafantasmas virtuales

A primera vista, este concepto de "fantasma virtual" puede parecer similar a los DNS colgantes o a la apropiación de subdominios, pero es muy diferente en su ejecución. En primer lugar, los atacantes no toman un papel activo en esto, aparte de apuntar al host de conocimiento previo. En segundo lugar, no se trata de un problema de DNS, sino de un problema más relacionado con el DNS: el problema se debe únicamente a la falta de higiene en la configuración del servidor.

Censys quería medir el alcance de este efecto de "fantasma virtual" en Internet tomando muestras de dos instantáneas de escaneado de Censys basadas en nombres, cada una con una semana de diferencia, y analizando todos los hosts basados en IP que siguen sirviendo contenido para un registro DNS que ya no existe (es decir, el registro DNS ahora devuelve un NXDOMAIN).

Hemos realizado estas pruebas utilizando dos conjuntos de datos, una muestra aleatoria y otra con un enfoque más específico.

Nuestra primera entrada de prueba fueron 50.000 hosts aleatorios que tenían una entrada en nuestra base de datos de escaneado con nombre el 2 de febrero de 2022, pero el 14 de febrero ya habían desaparecido. Esta eliminación podría significar dos cosas:

1. El host se cayó, o un administrador detuvo los servicios de red.
2. Censys no pudo resolver el nombre DNS a una dirección IP.

Los hosts que más nos interesan son aquellos en los que los nombres DNS ya no se resuelven a una dirección IP, por lo que primero comprobamos todos los nombres de host de nuestra muestra y validamos que el servidor de nombres autorizado para ese nombre de host devuelva un NXDOMAIN. Este proceso redujo el número de objetivos potenciales a 8.227 hosts, lo que significa que 41.773 hosts de nuestros datos de muestra aún tenían registros DNS válidos (pero no tenían servicios asociados a ellos).

Para cada registro DNS verificado que ahora devuelve un NXDOMAIN que se encontró en nuestra muestra, obtenemos una copia histórica de los detalles del host asociado y tomamos nota de la siguiente información:

• La dirección IP que el registro DNS utiliza para resolver a 
• El antiguo Sha256Suma del cuerpo de la respuesta HTTP
• El antiguo título HTML de la respuesta HTTP
• La antigua suma Sha256 del certificado TLS del servidor

A continuación, nos conectamos a la IP del host que solía servir contenido para ese registro DNS caducado y emitimos tres consultas HTTP funcionalmente independientes:

1. Una petición GET a la antigua IP con la cabecera HTTP Host y el campo TLS SNI configurado con el nombre DNS que ya no existe.
2. GET a la antigua IP con un valor aleatorio añadido al principio del nombre de host. Por ejemplo, si el nombre de host al que apuntamos es "search.censys.io," emitiremos una solicitud GET para "Host: $random_string.search.censys.io," - la salida de la cual se utiliza para probar posibles sitios de estacionamiento de nombres de dominio o manejadores HTTP predeterminados.
3. Petición GET sin la cabecera Host o el campo SNI en el conjunto de handshake TLS. Queremos asegurarnos de que nuestra respuesta a la solicitud de la cabecera Host difiere de simplemente golpear la IP desnuda.

Nuestro objetivo con este estudio específico era analizar sólo sitios "reales" que no devolvieran simplemente los manejadores HTTP predeterminados o páginas web de aparcamiento de dominios comodín, por lo que utilizamos las dos consultas sin Host+SNI en los pasos 2 y 3 para compararlas con la consulta que hicimos en el paso 1. Por ejemplo, si la respuesta de las consultas 2 y 3 es similar a la de la consulta 1, no lo consideramos un sitio web "real".

Si el nombre de host y la IP pasan la comprobación de validación anterior (lo que significa que lo consideramos un sitio web "real"), comprobamos la respuesta de la primera consulta, buscando los siguientes criterios:

• ¿El cuerpo de la respuesta tiene el mismo SHA256SUM que el de nuestros datos históricos?
• ¿Coincide el título HTML de la respuesta con el de nuestros datos históricos?
• ¿Coincide el certificado del servidor con nuestros datos históricos?

Si se cumplen los tres criterios, es muy probable que el host siga sirviendo contenido para un registro DNS que ya no existe. Si solo se cumplen dos de los tres criterios, la probabilidad es de media a alta, mientras que si solo se cumple uno, la probabilidad es de baja a media.

De los 50.000 hosts aleatorios que muestreamos, había un total de 694 servidores que cumplían al menos uno de estos tres criterios y servían a lo que consideramos un sitio web "real"; 112 de esos hosts (16,1%) cumplían los tres criterios, mientras que sólo 52 (7,5%) hosts cumplían sólo uno.

A continuación se muestra una tabla con el desglose de las combinaciones de los tres criterios desglosadas por el número de hosts.

Con nuestra segunda prueba, también queríamos ejecutar este mismo análisis contra un conjunto de datos no muestreado pero dirigido. Así que obtuvimos una lista de todos los nombres de host y direcciones IP del 2 de febrero de 2023 que no aparecieron el 14 de febrero y que contenían la palabra "admin" en algún lugar del subdominio del nombre DNS.

Nuestro objetivo con esta prueba era encontrar interfaces de administración web que alguien pudiera haber puesto en línea por error y haberles dado un nombre DNS válido, pero que desde entonces sólo se han eliminado de DNS, pero no de la configuración del host virtual del servidor web. Y aunque no son directamente accesibles, estos "fantasmas virtuales" podrían plantear un problema cuando un atacante tiene conocimiento previo de ese antiguo nombre de host y dirección IP.

Entre el 2 y el 14 de febrero, vimos 21.502 combinaciones de IP y nombre de host que eran posibles "fantasmas virtuales" (nombres de host vistos el día 2, no vistos el día 14). Después de ejecutar la validación NXDOMAIN, ese número se redujo a sólo 5.101 posibilidades. Por último, al aplicar a esos 5.101 hosts el mismo proceso que aplicamos a los datos de la muestra, se encontraron 223 hosts que cumplían uno o más criterios de "fantasma virtual". A continuación se muestra el mapeo completo:

Posteriormente, establecimos un servidor DNS local e integramos todos los nombres DNS inexistentes en sus zonas correspondientes, asignando los nombres DNS olvidados a sus direcciones IP originales. El servidor DNS nos permitió navegar por estos "fantasmas virtuales" utilizando cualquier interfaz con capacidad HTTP, como Chromium, y examinar si el proceso había descubierto algún hallazgo digno de mención. A continuación se muestran algunos ejemplos interesantes de sitios web que no deberían ser accesibles, o como nos referimos a ellos, "Fantasmas Virtuales."

Ampliación de la superficie de ataque

Los datos presentados indican que los "fantasmas virtuales" no son infrecuentes. Descubrirlos es una tarea sencilla si se tiene acceso a información sobre cada host, servicio y sitio web que haya existido. Esto refuerza la noción de que no todas las superficies de ataque son visibles, y el contexto histórico es crucial para proporcionar una visión precisa de la huella digital de una organización.

A la luz de estos descubrimientos, nos enorgullece presentar nuestra nueva función de Entidades Web en la Plataforma Censys , que rastrea y alerta automáticamente sobre activos que se califican como "Fantasmas Virtuales". - Se trata de hosts que han sido disociados de sus nombres DNS pero que siguen alojando contenidos en el servidor web. Recomendamos encarecidamente a las organizaciones que incorporen esta función a sus protocolos de seguridad para protegerse frente a posibles amenazas.

Dé el primer paso para proteger sus activos digitales incorporando hoy mismo nuestra función Entidades Web a su estrategia de seguridad. Póngase en contacto con nosotros para programar una demostración.