Introducción
En Censys, nuestra misión es elaborar el plano definitivo de la web, cartografiar todas las anomalías extrañas y desenterrar por dónde deambulan las cosas salvajes. Exploramos Internet indiscriminadamente y hacemos un trabajo excelente. Y cuando miras estos datos todo el día, como nosotros, tiendes a acostumbrarte a las pequeñas rarezas (como los honeypots comerciales) que encuentras a menudo y te vuelves insensible a las cosas extremadamente extrañas.
Una realidad que surge rápidamente de estos datos es darse cuenta de la abundancia de engaños en Internet. No me refiero al ámbito de las redes sociales y las discusiones sobre la redondez de la Tierra o la existencia de pájaros inexistentes, sino a la repentina comprensión de que las cosas que manejan Internet no siempre son lo que dicen ser. No hay leyes ni mecanismos reguladores que obliguen a los hosts conectados a Internet a revelar su verdadera identidad o propósito:
Puedes generar un certificado SSL para google.com, y prácticamente nadie se interpondrá en tu camino para impedir que lo despliegues. Puedes crear una entrada DNS inversa para tu dirección IP que resuelva a facebook.com, y nadie pestañeará. Incluso modificar tu servidor web Apache para que diga que está ejecutando Nginx no provocará una redada de la policía de Internet.
Cuando uno pretende hacerse una idea de cómo es Internet, debe desprenderse de verdades preconcebidas y abordar todo lo que encuentra con una buena dosis de escepticismo. Sin embargo, es poco probable que la mayoría de los anfitriones nos engañen sobre su verdadera naturaleza, ya que elaborar y mantener estas falsedades requiere cierto esfuerzo.
Honeypots
Pero hay clases particulares de hosts donde el objetivo real es engañar, ya sea para la seguridad a través de la oscuridad o para el análisis del tráfico de red potencialmente malicioso. Estos hosts se denominan Honeypots: hosts y redes desplegados para obtener información sobre los tipos de ataques que se producen en las redes, normalmente utilizados junto con IDS y cortafuegos para perfeccionar la postura de seguridad de una organización.
Estos sistemas mienten a propósito sobre el tipo de servicio y software que se está ejecutando para engañar a los posibles hackers e intentar explotar el servidor. Incluso Amazon ha entrado recientemente en el juego de los honeypots con su proyecto MadPot, y empresas como Greynoise llevan años operando en el sector de los honeypots comerciales. Una búsqueda rápida en GitHub sobre honeypots arroja más de 500 proyectos, algunos con miles de estrellas, y ha sido un popular mecanismo de seguridad y un pasatiempo durante décadas.
Algunos honeypots son mejores que otros, pero normalmente cada uno tiene un escenario específico en el que destaca. Pero la realidad es que los honeypots mal diseñados pueden ser muy ruidosos y fáciles de detectar, mientras que los honeypots decentemente diseñados a menudo se pueden encontrar con un poco de escrutinio. Por el contrario, los honeypots mejor diseñados nunca serán detectados.
Por ejemplo, el software especializado de honeypot GasPot intenta emular un servicio legítimo de medición automática de tanques (ATG) (utilizado para controlar los niveles de combustible), pero se desenmascara fácilmente con poco escrutinio.
(Un servicio ATG real)
(Un servicio GasPot (Fake) ATG)
Tres indicadores diferencian el GasPot y un dispositivo ATG real:
- El GasPot tiene un número limitado de códigos de diagnóstico que aceptará, y para cualquier código que no entienda, devolverá el código de error "9999FF1B".
- GasPot formatea las marcas de tiempo en las cargas útiles de forma diferente a los dispositivos ATG reales. Por ejemplo, GasPot las formatea como "MM/DD/AAAA HH:MM", mientras que un dispositivo ATG real formatea sus marcas de tiempo de la siguiente manera: "Nov 8, 2022 15:45"
- Los dispositivos ATG reales utilizan CRLF ("\r\n"), mientras que GasPot utiliza principalmente nuevas líneas ("\n\n") debido al código de la siguiente captura de pantalla
El código GasPot que genera nuevas líneas en lugar de CRLF
Una vez conocido esto, es razonablemente fácil utilizar Censys para encontrar hosts que ejecuten este servidor honeypot GasPot simplemente buscando servicios ATG que no utilicen nuevas líneas en lugar de CRLF: services: (service_name=ATG and banner="*\n\n\n\n*")
Y cuando busque estos servicios GasPot, observará que la mayoría de los resultados tienen hosts con todo tipo de características y clasificaciones de servicios "interesantes" y poco comunes que no suelen encontrarse juntos en el mundo real.
En la captura de pantalla de resultados de GasPot anterior, muchos hosts tienen cuatro o cinco tecnologías de bases de datos diferentes que son funcionalmente idénticas (MSSQL, MySQL, Postgres, etc.). También vemos servicios comúnmente asociados con aplicaciones web cotidianas que se ejecutan junto con servicios IoT y SCADA. Para colmo, muchos de estos servidores ATG viven en AWS, que, que yo sepa, no tiene acceso directo a tanques físicos de gasolina. No es la mejor representación de la realidad.
Señuelos
Los escáneres de red como Censys registrarán la información de un servicio exactamente como la presenta el host y, además de los datos sin procesar, aumentaremos los detalles del host con información sobre los servicios y el software en ejecución mediante etiquetas y CPE. La lógica que subyace a la búsqueda y aplicación de estas etiquetas de software y servicios es, en su mayor parte, un proceso sencillo que implica expresiones regulares y concordancia de patrones utilizando datos internos y de código abierto. Y para la mayoría de los hosts en Internet, esto funciona perfectamente bien.
Así que cuando nos enteramos de un nuevo conjunto de hosts de los que se hablaba en las redes sociales que intentaban no sólo mentir sobre quiénes eran, sino aparentemente sobrecargar los escáneres de red con falsos positivos, no me sorprendió, ya que hemos sido testigos de cosas similares antes.
El 20 de septiembre de 2023, Censys empezó a observar alrededor de 50 hosts con una característica única y caótica: en la respuesta HTTP, estos hosts incluían una cabecera Server de 37.213 bytes (utilizada habitualmente para identificar el servidor en ejecución) con cientos de nombres de software diferentes.
Durante las siguientes semanas, vimos cómo el número de hosts con estos datos aumentaba drásticamente, pasando de tres a seis mil hosts diarios. Para el 30 de septiembre, vimos más de 27.252 hosts únicos que presentaban este enorme y odioso encabezado de servidor.
Lo más interesante es dónde estaban ubicados estos hosts (geográficamente y por sistema autónomo). En el momento de escribir esto, todos los hosts existen en el sistema autónomo AMAZON-02, una de las mayores redes de AWS. Pero, al inicio de este evento, se vieron otros dos AS con estos hosts: AMAZON-AES(AS14618) y BJ-GUANGHUAN-AP(AS55960), los cuales detuvieron estos servicios específicos nueve días después, el 29 de septiembre. A continuación se muestra un gráfico (a escala logarítmica) de cada AS encontrado con este servicio perturbador y el número de hosts.
Beijing Guanghuan Xinwang Digital es el proveedor de servicios de Internet con el que Amazon se asocia para operar legalmente AWS en China, lo que significa que los bloques IP que anuncia este AS son propiedad y están operados por Amazon, pero los centros de datos y el tránsito están controlados por Xinwang Digital.
Dado que para abrir una cuenta en AWS China es necesario disponer de una licencia comercial china válida, la mera existencia de estos hosts apunta a una operación basada en China. Curiosamente, intentaron enmascararlo trasladando todo a AMAZON-02, ubicado principalmente en Estados Unidos, a finales del mes pasado. Con la magnitud de este incidente, apunta a un experimento muy bien planificado con respaldo extranjero, corporativo(posiblemente estatal o incluso educativo). Dado que el despliegue de servicios en AWS proporciona anonimato, y cada uno de estos servidores parece ser estructuralmente similar sin ninguna otra indicación de quién es su propietario, es difícil decir con precisión quién está detrás de esto.
Objetivos
Nos preguntábamos si Censys era un objetivo explícito o si había otras razones para que existieran estos hosts. Al final, estos hosts "engañaron" a nuestro escáner para que aplicara muchas etiquetas de software (técnicamente correctas, porque eso es lo que nos dijo el servidor). Aún así, desde el punto de vista del usuario, resultaban molestos y potencialmente engañosos.
We started by looking at the data that triggered these red herrings. At a cursory glance, all of the data seems to be just random server names that may have been aggregated from random hosts on the internet, along with defining multiple HTML <title> tags in the response body:
La realidad es que estos puntos de datos no son aleatorios, ni se han extraído de los datos del host. Cada valor de la cabecera del servidor visto en la cabecera de respuesta y cada título HTML encontrado en el cuerpo corresponde directamente a una regla del escáner de vulnerabilidades de código abierto Project Discovery's Nuclei.
NUCLEI
Las plantillas de núcleo son reglas codificadas en YAML que describen cómo buscar, validar y ejecutar exploits en hosts conectados a Internet. Muchas de estas reglas definirán dónde buscar algo y expresiones regulares para determinar si se debe intentar un exploit y si el exploit tuvo éxito.
En este caso, el creador de estos ruidosos servicios analizó secciones específicas de cada plantilla Nuclei centrada en la web para crear un único servicio que activara todas las vulnerabilidades web conocidas por Nuclei.
For example, one of the HTML titles found in the data is “<title>Flowchart Maker & Online Diagram Software</title>”, which directly corresponds to the “matchers” configuration section of the Nuclei template “http/cves/2022/CVE-2022-1713.yaml“:
La sección matcher de Nuclei contiene la palabra clave "part", que define en qué parte de una respuesta HTTP se pueden encontrar estos datos y luego define un conjunto de reglas para hacer coincidir dentro de esa parte de la respuesta HTTP. Así, si la regla de Nuclei define "part: body", el texto coincidente se colocará en el cuerpo HTML del servidor. La misma regla general se aplica a "part:title" y "part: header".
 |
| Lo curioso de estos datos es que todo el ruido generado (incluso si se trata de una definición "matcher" del encabezado Cookie) se rellena como una línea gigante en el encabezado Servidor de la respuesta HTTP. |
Even more amusing is that Nuclei uses Mustache templating, which can substitute strings encased between “{{“ and “}}” with dynamic data. For example, in the Nuclei definition for CVE-2012-0394, we see that it attempts to match data based on a Mustache-defined variable:
matchers-condition: and
matchers:
- type: word
words:
- '{{result}}'
Como el creador de este ruidoso servicio no tuvo esto en cuenta, podemos ver estas variables en bruto en los hosts. Esto confirma la fuente de todos estos datos.
RECOG
Mientras se cerraban los servicios que ejecutaban la cabecera de servidor de 37k bytes derivada de Nuclei, los hosts seguían funcionando con un conjunto de datos diferente a través de miles de puertos. A continuación se muestra un gráfico que representa el recuento total de servicios en los 10 principales hosts de AS55960 que inicialmente tenían la cabecera de servidor de 37k. Aquí, podemos ver que dos hosts, 54.223.45.228 y 52.80.98.93, se desviaron significativamente en el número de servicios creados entre el 20 de septiembre y el 2 de octubre de 2023, el primero duplicando sus servicios de la noche a la mañana de 4.000 a 8.000 servicios.
Estos nuevos servicios tenían una huella digital completamente distinta de los originales;
Estos servicios sobrantes (captura de pantalla de arriba, a la derecha) no coinciden con los indicadores descritos anteriormente en este post. En su lugar, están ejecutando una técnica similar, pero esta vez, aparentemente utilizando una fuente de datos diferente a la anterior para generar estas enormes cargas útiles. En lugar de utilizar Nuclei para crear estos datos falsos, estos otros datos parecen derivarse del marco de huellas dactilares Recog de Rapid7, que Metasploit utiliza para obtener información de software de los servicios:
Así que parece que el desarrollador de estos servicios simplemente analizó las secciones de ejemplo de las definiciones de huellas dactilares Recog basadas en la web y las metió todas en un encabezado de servidor en el host. Lo mismo puede decirse de la multitud de títulos HTML encontrados en el cuerpo de las respuestas, todos aparentemente derivados de ejemplos en las definiciones de huellas dactilares.
Sin embargo, estos servidores derivados de Recog han existido dentro de nuestros datos durante años, por lo que la teoría de trabajo es que una organización en China que ha estado haciendo este tipo de configuraciones durante un tiempo modificó su generador de servicios para incluir datos derivados de Nuclei. Y dado que esos servicios aparecieron y desaparecieron en pocas semanas, cabe suponer que los resultados no eran los esperados, por lo que los servicios generados por Nuclei fueron descartados, pero el método Recog siguió funcionando.
Este repositorio, con un nombre que no podemos decir en voz alta, incluye varios directorios en idioma chino que incluyen datos muy parecidos a estos hosts. Se desconoce si esta es la verdadera fuente de estos datos, pero parece hacer referencia a otro producto llamado "NSFocus Advanced Threat Hunting System"
"NSFOCUS Advanced Threat Hunting System ("ATH" para abreviar) utiliza tecnología de defensa contra el engaño (tecnología honeypot de nueva generación) para atrapar con precisión los comportamientos de ataque y proporcionar pistas sobre las actividades de intrusión de los atacantes."
Incluso contiene un directorio más sospechoso y, traducido del chino, dice lo siguiente:
"La muestra contiene un gran número de palabras clave de búsqueda que contaminan los motores de búsqueda de activos del ciberespacio".
Y cuando se compara el contenido de ywkXErYz. html con el de 175.178.174.46 del 5 de octubre, coinciden.
ywkXErYz.html
Cuerpo de la respuesta HTTP
Por lo tanto, podemos decir con seguridad que en este caso específico, estamos ante un conjunto de datos elaborados específicamente para meterse con bases de datos de escaneo en línea como Censys. Sin embargo, en el momento de escribir estas líneas, sólo hay unos siete de estos hosts en línea, y no parecen tener nada que ver con este último suceso, ya que todos parecen vivir en sistemas autónomos completamente diferentes.
Conclusión
¿Fue este incidente un "ataque" intencionado contra Censys? Parece ser más complejo que eso; podría atribuirse a varias posibilidades diferentes. En primer lugar, estos servicios podrían considerarse honeypots algo ingenuos y sencillos. Otra posibilidad es que sean servicios diseñados deliberadamente para provocar que los escáneres de vulnerabilidades conocidos perciban todo como vulnerable.
Teniendo en cuenta que Metasploit, la herramienta de pruebas de penetración y explotación de código abierto ampliamente utilizada, se basa en Recog para las huellas digitales de software, y dada la reciente tendencia de los investigadores a emplear Nuclei para las pruebas de vulnerabilidad, este último escenario parece cada vez más plausible. Sugiere que alguien, o algo, puede estar intentando engañar a los escáneres de vulnerabilidades para que generen alertas para una amplia gama de objetivos.
Otra teoría plausible es que una entidad esté evaluando sistemáticamente las capacidades de los escáneres de red en línea como Censys. Esto podría incluir la identificación de limitaciones, temporización y mecanismos de tiempo de espera e incluso la exploración de posibles métodos para sobrecargar los servidores backend o socavar la fiabilidad de los escáneres de datos que, como Censys , obtienen y almacenan.
Pero apostamos a que muchos de estos hosts son simples honeypots de bricolaje que atrapan a los denominadores comunes más bajos. Sea cual sea el motivo, vigilaremos de cerca este tipo de servidores y los etiquetaremos cuando sea necesario.
