Introdução
Em um ataque Server-side request forgery (SSRF), o atacante pode abusar dessa funcionalidade para ler ou atualizar recursos internos. O atacante pode fornecer ou modificar a URL em que o código está utilizando no servidor para enviar ou receber informação, e selecionando certas URL, o atacante pode ser capaz de ler configurações do servidor, tais como as metadados de servidores da AWS, conectar em serviços internos como banco de dados em conexões HTTP ou realizar POST requests à serviços internos que não são pretendidos que sejam expostos.
Descrição
A aplicação web alvo pode ter funcionalidades que são importadas através de uma URL ou ler informações que a URL pode conter. O atacante pode modificar essa URL e chamar essa funcionalidade com uma URL completamente diferente ou manipular como essas URLs são feitas
Quando a requisição manipulada chega ao servidor, o código do lado do servidor pega a URL modificada e tenta ler as informações da URL manipulada. Ao selecionar essa URL, o atacante pode estar apto a ler informações e serviços que não estão diretamente expostos a internet
Qual é o impacto de ataques SSRF?
Um ataque SSRF bem sucedido pode resultar em ações não autorizadas ou acesso a informação de dentro da organização, tanto dentro da aplicação vulnerável quanto em outras aplicações que backend se comunica.
É possível que com um Server-Side Request Forgery (SSRF) exista um (CWE-35) Path Transversal
É possível que com um Server-Side Request Forgery (SSRF) exista um Remote Code Execution]
Um ataque SSRF pode conectar com serviços terceirizados e resultar em ataques maliciosos que podem aparentar estarem vindo da aplicação vulnerável.
Casos práticos
Ataque SSRF contra o próprio servidor
Em uma aplicação Web onde existe uma requisição dentro de outra requisição, é possível mudar o link da segunda requisição para testar se existe algum SSRF mudando os parâmetros da primeira requisição, exemplo:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118
stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1
O parâmetro stockApi pode ser alterado para IPs locais, tais como:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118
stockApi=http://localhost/admin
Nesse ataque, o atacante pode conseguir o conteúdo da página /admin
Ataques SSRF contra outros serviços do backend
Existem sistemas que são privados e estão conectados a uma rede privada. Nessa rede, todos os sistemas estão conectados e podem interagir entre si sem precisar de autenticação (a segurança está primordialmente no fato de que a rede é privada). Ao alterar os parâmetros de requisição, como mostrado no exemplo passado, é possível atacar esses outros sistemas, por exemplo:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118
stockApi=http://192.168.0.68/admin
Burlando sistemas de defesa contra SSRF
É possível que as aplicações tenham sistemas de segurança e defesa contra SSRF, portanto, é possível burlá-los.
Ataques SSRF em requests com blacklist de inputs
Algumas aplicações podem ter uma blacklist de inputs, tais como 127.0.0.1 e localhost, entretanto, ou conteúdos sensíveis tais como /admin. Nessa situação, você pode facilmente circular o filtro em:
- Usar uma representação do IP
127.0.0.1, tal como2130706433,017700000001ou127.1. - Registrar o seu próprio domínio que aponta para
127.0.0.1 - Ofuscar strings bloqueadas através da utilização de códigos hexadecimais
- Mudar o protocolo de
httpparahttpspode também burlar o sistema de defesa de alguns sistemas contra SSRF.
Ataques SSRF em requests com whitelist de inputs
Algumas aplicações permitem somente os inputs que são cadastrados, que começam com, ou que contem em uma whitelist de parâmetros permitidos. Nessa situação, você pode burlar esse sistema ao ultrapassar por esses filtros na URL.
A URL pode ser manipulada para ficar como:
- Você pode embutir credenciais na URL antes do hostname, usando o
@. Por exemplo:
https://expected-host:fakepassword@evil-host
- Você pode utilizar o caractere
#para indicar um fragmento da URL. Por exemplo:
https://evil-host#expected-host
- Você pode definir a hierarquização do DNS para um domínio que você tem controle. Por exemplo
https://expected-host.evil-host
- Você pode colocar caracteres codificados em URL para confundir o código de URL. Isso pode particularmente ser útil quando você está lidando com caracteres diferentes do que o realiza requisições no backend. Note que você também pode tentar double-encoding caracteres.
Ataques SSRF através de uma exploração de um (CWE-601) Open Redirect
Em alguns casos, um openredirect pode levar a uma exploração de um SSRF. Por exemplo, a URL
/product/nextProduct?currentProductId=6&path=http://evil-user.net
retorna para
http://evil-user.net
Logo isso pode ser explorado como
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin