takito1812/web-hacking-playgroundAplicação web com vulnerabilidades encontradas em casos reais, tanto em pentests quanto em programas Bug Bounty.
Web Hacking Playground é um ambiente controlado de hacking web. Ele consiste em vulnerabilidades encontradas em casos reais, tanto em testes de penetração quanto em programas de Bug Bounty. O objetivo é que os usuários possam praticar com elas e aprender a detectá-las e explorá-las.
Outros tópicos de interesse também serão abordados, como: bypass de filtros criando payloads personalizados, execução de ataques encadeados explorando várias vulnerabilidades, desenvolvimento de scripts de prova de conceito, entre outros.
O código-fonte da aplicação está visível. No entanto, a abordagem do laboratório é de caixa-preta. Portanto, o código não deve ser revisado para resolver os desafios.
Além disso, deve-se notar que fuzzing (tanto de parâmetros quanto de diretórios) e ataques de força bruta não fornecem nenhuma vantagem neste laboratório.
Recomenda-se o uso do Kali Linux para realizar este laboratório. No caso de usar uma máquina virtual, é aconselhável usar o hipervisor VMware Workstation Player.
O ambiente é baseado em Docker e Docker Compose, portanto é necessário ter ambos instalados.
Para instalar o Docker no Kali Linux, execute os seguintes comandos:
sudo apt update -y
sudo apt install -y docker.io
sudo systemctl enable docker --now
Para instalar o Docker em outras distribuições baseadas em Debian, execute os seguintes comandos:
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo systemctl enable docker --now
Para instalar o Docker Compose, execute o seguinte comando:
sudo apt install -y docker-compose
Nota: No caso de usar M1, recomenda-se executar o seguinte comando antes de construir as imagens:
export DOCKER_DEFAULT_PLATFORM=linux/amd64
O próximo passo é clonar o repositório e construir as imagens Docker:
git clone https://github.com/takito1812/web-hacking-playground.git
cd web-hacking-playground
sudo docker-compose build
Além disso, recomenda-se instalar a extensão do navegador Foxy Proxy, que permite alterar facilmente as configurações de proxy, e o Burp Suite, que usaremos para interceptar requisições HTTP.
Criaremos um novo perfil no Foxy Proxy para usar o Burp Suite como proxy. Para isso, vá até as opções do Foxy Proxy e adicione um proxy com a seguinte configuração:
Após instalar tudo o que é necessário, você pode implantar o ambiente com o seguinte comando:
git clone https://github.com/takito1812/web-hacking-playground.git
cd web-hacking-playground
sudo docker-compose up -d
Isso criará dois contêineres de aplicações desenvolvidas em Flask na porta 80:
É necessário adicionar o IP dos contêineres ao arquivo /etc/hosts, para que possam ser acessados pelo nome e que o servidor de exploração possa se comunicar com a aplicação web vulnerável. Para isso, execute os seguintes comandos:
sudo sed -i '/whp-/d' /etc/hosts
echo "$(sudo docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' whp-socially) whp-socially" | sudo tee -a /etc/hosts
echo "$(sudo docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' whp-exploitserver) whp-exploitserver" | sudo tee -a /etc/hosts
Feito isso, a aplicação vulnerável pode ser acessada em http://whp-socially e o servidor de exploração em http://whp-exploitserver.
Ao usar o servidor de exploração, as URLs acima devem ser usadas, utilizando o nome de domínio e não os IPs. Isso garante a comunicação correta entre os contêineres.
Quando se trata de hackear, para representar o servidor do atacante, o IP local do Docker deve ser usado, pois o laboratório não foi projetado para fazer requisições a servidores externos como Burp Collaborator, Interactsh, etc. Um Python http.server pode ser usado para simular um servidor web e receber interações HTTP. Para isso, execute o seguinte comando:
sudo python3 -m http.server 80
O ambiente é dividido em três estágios, cada um com vulnerabilidades diferentes. É importante que sejam feitos em ordem, pois as vulnerabilidades dos estágios seguintes se baseiam nas dos estágios anteriores. Os estágios são:
Abaixo estão spoilers das vulnerabilidades de cada estágio. Se você não precisar de ajuda, pode pular esta seção. Por outro lado, se você não souber por onde começar, ou quiser verificar se está no caminho certo, pode expandir a seção que lhe interessa.
Neste estágio, a sessão de um usuário específico pode ser roubada através de Cross-Site Scripting (XSS), que permite a execução de código JavaScript. Para isso, a vítima deve conseguir acessar uma URL no contexto do usuário; esse comportamento pode ser simulado com o servidor de exploração.
As dicas para resolver este estágio são:
Neste estágio, um token pode ser gerado que permite o acesso como admin. Este é um ataque típico de JSON Web Token (JWT), no qual o payload do token pode ser modificado para escalar privilégios.
A dica para resolver este estágio é que existe um endpoint que, dado um JWT, retorna um cookie de sessão válido.
Neste estágio, o arquivo /flag pode ser lido através de uma vulnerabilidade de Server Site Template Injection (SSTI). Para isso, você deve fazer com que a aplicação execute código Python no servidor. É possível executar comandos do sistema no servidor.
As dicas para resolver este estágio são:
A funcionalidade vulnerável é protegida por autenticação de dois fatores. Portanto, antes de explorar a SSTI, deve-se encontrar uma maneira de contornar a solicitação do código OTP. Há momentos em que a aplicação confia nas requisições feitas a partir do próprio servidor e os cabeçalhos HTTP desempenham um papel importante nessa situação.
A SSTI é cega, isso significa que a saída do código executado no servidor não é obtida diretamente. O módulo Python smtpd permite criar um servidor SMTP que imprime as mensagens que recebe na saída padrão:
sudo python3 -m smtpd -n -c DebuggingServer 0.0.0.0:25
A aplicação usa Flask, então pode-se inferir que o mecanismo de template é Jinja2, pois é recomendado pela documentação oficial do Flask e é amplamente utilizado. Você deve obter um payload compatível com Jinja2 para conseguir a flag final.
A mensagem de email tem uma limitação de caracteres. Informações sobre como contornar essa limitação podem ser encontradas na Internet.
Soluções detalhadas para cada estágio podem ser encontradas na pasta Soluções.
Os seguintes recursos podem ser úteis para resolver os estágios:
Pull requests são bem-vindos. Se você encontrar algum bug, por favor, abra uma issue.