Resumen ejecutivo
- Nuestro análisis ha concluido que actualmente hay alrededor de 28.910 hosts que muestran signos de compromiso a fecha de 25 de octubre de 2023.
- Los atacantes se han adaptado, y nuestros anteriores métodos de identificación ya no son eficaces
- Los investigadores han determinado una nueva forma (aunque no tan precisa) de determinar si las puertas traseras de estos dispositivos siguen activas
La semana pasada, compartimos información sobre un evento en curso con dispositivos Cisco y un backdoor instalado en decenas de miles de hosts Cisco. Y en nuestra última actualización, observamos un descenso significativo en el número de infecciones. ¿Y puedes creer que ese número ha caído a cero? Bueno, más o menos...
Desde entonces, el grupo (o individuo) detrás de este compromiso masivo ha visto el error y ha intentado cubrir su visibilidad pública eliminando la configuración que permitía a los investigadores determinar si el dispositivo estaba comprometido. Al hacerlo, los métodos para encontrar estos compromisos quedaron instantáneamente obsoletos.
En esencia, estos dispositivos Cisco ejecutan el servidor web Nginx, y (una de) las configuraciones modificadas por los atacantes es el archivo de configuración Nginx de los hosts. Un astuto lector de Fox-IT se dio cuenta de que en la captura de pantalla que Talos proporcionó, el atacante había añadido otra directiva de configuración de ubicación, que todavía puede darnos una idea de si las puertas traseras están instaladas en el dispositivo.
Una directiva de ubicación en Nginx permite a un administrador actuar de manera diferente a nivel de ruta de URL HTTP, y esta añadida era una coincidencia de expresión regular insensible a mayúsculas y minúsculas para cualquier ruta que incluyera el signo de porcentaje (%), y si ese signo de porcentaje se encuentra en la ruta, simplemente establece algunas cabeceras y devuelve un 404.
Desafortunadamente, debido a cómo Nginx maneja los retornos de error 404, las cabeceras añadidas en esta directiva nunca se envían al cliente, pero como estos dispositivos Cisco parecen tener un manejador 404 personalizado, y esta nueva directiva de configuración anula ese manejador, obtenemos un mensaje de estado 404 diferente (la versión Openresty/Nginx por defecto) cuando esta configuración está en su lugar.
Estamos entrando en territorio inestable cuando se trata de determinar el estado de esta puerta trasera, y no estamos 100% seguros de si esta es la mejor manera de llevar a cabo este tipo de pruebas, pero es la única manera que tenemos en este momento.
Entonces, ¿cuál es el significado de este signo de porcentaje? Sólo podemos suponer nuestras respuestas porque, en la mayoría de los casos, un signo de porcentaje en una URL puede traducir caracteres no imprimibles en algo que un servidor pueda ver (por ejemplo, %41 == 'A'). Por lo tanto, los atacantes están intentando ocultar algo, pero no tenemos forma de saberlo con certeza. Por desgracia, la mayoría de las organizaciones de seguridad como Talos no divulgan nada más de lo que publican, así que esto es todo lo que sabemos.
El 25 de octubre, realizamos otro escaneo secundario contra cada IP vista con características similares a Cisco durante los últimos siete días (esto puede incluir la comprobación de dispositivos que no son específicamente Cisco XE, ya que estamos echando un vistazo más general a todos los dispositivos similares a Cisco, por si acaso), buscando cualquier dispositivo que responda con el mensaje predeterminado Nginx/Openresty 404 cuando se solicita la URI '/%25'. Nuestra lista de entrada contenía más de 135.000 dispositivos potenciales, y sólo 28.910 hosts respondieron con lo que parecía un manejador Openresty/Nginx 404 por defecto al solicitar '/%25', lo que indica que la puerta trasera está instalada.
Una vez más, no podemos decir con un 100% de seguridad si esto es un indicador real de compromiso, pero estos dispositivos Cisco responden de manera diferente cuando se solicita un recurso que no debería existir en estos hosts. Por ejemplo:
Solicitando /%25 en un host previamente comprometido.
Solicitar algún archivo aleatorio que no debería existir en un host previamente comprometido.
Lo intrigante de este incidente es lo específico y dirigido que fue todo. Cisco utiliza Openresty, que es un servidor web basado en Nginx con la capacidad de desarrollar e incrustar Lua en los archivos de configuración - esto es básicamente como mover el desarrollo de aplicaciones en el propio servidor web; esto no es nada fuera de lo común, ya que actualmente hay alrededor de 800.000 servidores Openresty en línea, que no es mucho, pero puede ser considerado moderadamente popular en comparación con otras tecnologías de servidor.
Aunque a primera vista parece que estos atacantes hayan quemado su día cero, es evidente que se trata de un ataque coordinado, bien planificado y bien ejecutado. No sólo encontraron la vulnerabilidad en estos dispositivos (si es que la vulnerabilidad no estaba comprada), sino que también utilizaron las tecnologías subyacentes que se ejecutan en estos dispositivos para implementar una puerta trasera. Esto significa que se invirtió una cantidad razonable de esfuerzo en aprender la tecnología e implementar las puertas traseras específicas del sistema.
Y aunque no fue una ejecución perfecta, aprendieron de sus errores y los corrigieron rápidamente. Hemos visto este patrón unas cuantas veces antes(Deadbolt, ESXiArgs):
- Se produce un incidente, se publica la información
- Noticias e investigación
- Los atacantes vigilan y adaptan sus técnicas para subvertir la identificación y el análisis
- Repita
En este caso, se nos dio suficiente información para encontrar los compromisos iniciales, pero se bloquearon rápidamente cuando los atacantes cambiaron sus métodos y técnicas. Si este nuevo método para encontrar compromisos es preciso, entonces el número de dispositivos ha disminuido drásticamente.
