30 de JULHO
Já falamos em outras oportunidades aqui no Blog da Integrasul sobre o que é superfície de ataque. Naquela ocasião, citamos como exemplo um sistema de emissão de boletos, que possuía uma superfície de ataque pequena, contendo apenas três campos possíveis de exploração. Mas e se algum destes campos não for corretamente tratado? Aqui, irei demonstrar uma vulnerabilidade que ocorre com uma certa frequência (é a décima colocada na lista OWASP Top 10) e pode aumentar significativamente a superfície de ataque, mesmo que a aplicação contenha apenas um campo de interação. Esta é a vulnerabilidade de Server-Side Request Forgery, ou, para simplificar: SSRF.
Para esta demonstração, foi escrita uma aplicação bastante simples. Esta aplicação é um portal onde é possível consultar o valor de algumas criptomoedas (Bitcoin, Ethereum e Dogecoin). Ao clicar na criptomoeda desejada, a aplicação faz uma requisição para uma API pública e retorna o valor atual da criptomoeda. E, para demonstrar como esta vulnerabilidade pode aumentar a superfície de ataque, foi colocada (escondida atrás do firewall) uma outra aplicação.
À primeira vista, é uma aplicação bastante simples. Informamos a criptomoeda que gostaríamos de consultar e ela retorna o valor. Porém, uma análise um pouco mais apurada pode revelar uma vulnerabilidade bastante crítica. Ao simplesmente abrir as ferramentas de desenvolvedor, é possível ver que, ao realizar uma consulta, é feita uma requisição para a aplicação com um parâmetro chamado "cripto", e seu valor é a URL da API pública para consulta de valores. Também é possível concluir que a requisição à API não está sendo feita pelo nosso navegador; em ve disso, está sendo feita pelo back-end da aplicação (pois esta requisição não está aparecendo na aba Rede).
Isso abre espaço para alguns questionamentos. Será que o back-end da aplicação está fazendo alguma modificação nesse valor antes de apresentá-lo na tela? Será que está sendo feita alguma validação do parâmetro que está sendo informado? Será que é possível fazer requisições para outras APIs ou até mesmo outras aplicações? Bem, um teste que é possível fazer é informar como valor do parâmetro, a própria URL da aplicação. Se não for feita nenhuma sanitização pelo lado do servidor, a página deve ser refletida "em si mesma". Neste nosso exemplo, isso pode ser possível informando como parâmetro para a aplicação ?cripto=http://localhost:5000. E, para nossa surpresa, a aplicação não está fazendo nenhuma verificação no parâmetro que é passado, como é possível ver na imagem abaixo.
E agora é que a exploração começa a ficar interessante. Foi possível fazer (e refletir) uma requisição para a porta 5000, que é onde nossa aplicação está sendo executada. Será que é possível interagir com outras portas desse mesmo servidor? Bem, para isso, criei uma lista (utilizando a linha de comando do Linux, com o comando seq 10000) com algumas possíveis portas para verificação e utilizei a técnica de fuzzing para procurar portas em que a aplicação consegue retornar alguma informação. Como é possível ver, nosso fuzzing resultou em dois resultados positivos, sendo eles as portas 5000 (que é onde nossa aplicação vulnerável está rodando) e 8075.
Com esta informação, podemos verificar o que é retornado ao acessar esta porta:
A página secreta está informando que existe a possibilidade de utilizarmos uma aplicação PHP para execução de comandos. Para verificar essa possibilidade, um teste simples é o comando cat /etc/passwd, que irá fazer a leitura de um arquivo no sistema de arquivos da aplicação.
Com isso, confirmamos a possibilidade de injeção de comandos, abrindo uma nova superfície de ataque. A partir deste ponto, o limite da exploração é a criatividade do atacante.
Neste exemplo, a aplicação principal está permitindo que sejam feitas requisições irrestritas para outras aplicações. Vale ressaltar que mesmo a aplicação secreta estando em uma porta que não está acessível além do firewall, a vulnerabilidade de SSRF permite que essa interação possa ser feita. Isso ocorre porque as requisições estão sendo feitas pelo próprio servidor de aplicação, e não do nosso navegador.
A presença dessa vulnerabilidade não implica apenas a interação com aplicações do mesmo servidor. Da mesma forma que foi possível ler o arquivo /etc/passwd, é possível ler o arquivo /etc/hosts, que contém o endereço IP do servidor. Com essa informação, um atacante obtém informações da rede e pode repetir a técnica de fuzzing para descoberta de novos servidores (e, consequentemente, aplicações que estes disponibilizam) na rede.
E, é claro: a aplicação secreta é um tanto quanto exagerada no sentido de permitir uma execução de código de maneira irrestrita. Foi utilizada neste exemplo como forma de demonstrar que aplicações sensíveis costumam não ser públicas. Porém, na existência de uma vulnerabilidade de SSRF (e não só desta), é possível aumentar a superfície de ataque com novas aplicações e informações que estas contêm.
