Falsificação de solicitação do lado do servidor (SSRF)
É uma vulnerabilidade de segurança da Web com falsificação de solicitação do lado do servidor. Está lindamente esquematizado na imagem acima.
Graças a essa vulnerabilidade, o invasor usa o servidor vulnerável para enviar solicitações a outros servidores por meio dele.
Como as solicitações passam pelo servidor, as páginas que os usuários não podem acessar podem ser acessadas. As funções não autorizadas podem ser controladas e manipuladas com as configurações do sistema.
Na rede onde há um servidor vulnerável a SSRF, pode haver muitos servidores que não saem para a Internet. Ao explorar a vulnerabilidade, outros servidores podem ser descobertos por meio do servidor vulnerável. Ele ainda nos permite testar em outros servidores.
Quando você imagina, muitos cenários de ataque vêm à mente. Não é possível enumerar os cenários um a um, mas alguns exemplos podem ser dados.
Vamos considerar um site. Existe uma API onde os privilégios do usuário podem ser definidos. ( http://target/privilege/user.admin ) Dessa forma, os usuários podem receber autoridade de administrador. Normalmente não estamos autorizados a enviar solicitações aqui.
Com uma vulnerabilidade SSRF no site, podemos acessar essa API e nos dar autoridade de administrador. etc. etc Esses cenários continuam e continuam.
Nesse sentido, veremos a vulnerabilidade do SSRF praticamente no ambiente de laboratório do PortSwigger.
Exemplo-1
Tarefa: visualizar a página de administração e excluir o usuário carlos.
Vamos clicar no botão "Verificar Estoque" e interceptar com a ferramenta BurpSuite
Uma solicitação é enviada para um endereço pelo servidor e o resultado é retornado para nós.
Podemos mudar o endereço. Acessando a página de administração solicitada por nós.
Normalmente não tínhamos acesso para isso. Isso é exatamente o que é a vulnerabilidade do SSRF.
De qualquer forma, vemos um URL para excluir Carlos. Vamos enviar a ele uma solicitação e concluir o laboratório.
Excluímos o usuário Carlos
Foi assim que resolvemos o laboratório.
Exemplo-2
Tarefa: encontre o servidor back-end, acesse-o e exclua o usuário carlos.
No exemplo anterior, fizemos uma requisição a ele novamente através do servidor dizendo localhost. Desta vez, tentaremos acessar outro servidor atrás do servidor vulnerável.
O ID da rede nos foi fornecido pelo laboratório. Encontraremos o ID do host por tentativa.
Para isso, vamos enviar a requisição ao Intruder. Vamos especificar a parte para tentar e definir a carga útil.
Ele tentará um por um, começando de 1 a 255.
Vemos que a resposta na solicitação 133 é de 200 flechas. Então encontramos o servidor de destino.
ip de destino: 192.168.0.133
Tudo o que resta é deletar o usuário carlos.
Nós resolvemos este laboratório também.
Exemplo-3
Tarefa: contornar a medida cautelar com lista negra.
Como precaução, uma lista negra foi criada, então coisas simples como 127.0.0.1 ou localhost podem ser banidas.
palavra banida localhost.
Existe uma maneira de contornar isso. Existem endereços que resolvem para localhost. Dessa forma, podemos expressar a palavra proibida sem digitá-la.
Superamos isso com 127,1.
Vamos acessar a página de administração e deletar carlos
Vamos tentar fazer url-encode, onde a palavra admin também é proibida.
Após url-encode 2 vezes, acessamos a página.
Tudo o que resta é deletar Carlos.
Foi assim que lidamos com Carlos.
Exemplo-4
Tarefa: explorar vulnerabilidade ssrf via redirecionamento aberto.
Vemos a solicitação de saída. Mas precisamos encontrar uma parte de redirecionamento.
Depois de vasculhar a página, encontramos algo diferente
solicite desta forma.
se clicarmos no siga o botão de redirecionamento.
Desta forma podemos ver.
O que precisamos fazer é acessar a página de administração.
Vemos a página de administração. Podemos concluir este laboratório excluindo Carlos.
Exemplo-5
Tarefa: detectar vulnerabilidade ssrf cega.
Até este exemplo, podíamos ver a saída dos dados.
Mas não podemos ver nenhuma resposta na vulnerabilidade cega.
Existem métodos para detectar isso também.
Neste exemplo, vamos detectá-lo com o método fora de banda
.
Desta vez, não há botão de checkstock na página, então mexi um pouco para encontrar o ponto fraco.
Vemos o parâmetro Referer.
Insira um endereço onde você possa ver as solicitações de DNS recebidas. Você pode usar ngrok.
Se pudermos fazer uma solicitação para outro endereço no servidor, podemos falar sobre a existência de ssrf lá. É assim que a vulnerabilidade é detectada.
Exemplo-6
Tarefa: Ignorar lista branca As listas brancas
são um pouco mais difíceis de contornar do que as listas negras porque são mais rígidas.
Podemos contornar a lista branca explorando as inconsistências no analisador de URL.
Primeiro, vamos clicar no botão verificar estoque e capturar a solicitação de saída.
Vamos começar a testar o parâmetro stockApi.
Podemos usar expressões "# @ /" para usar o analisador contra nós.
Eu codifiquei # como um url duplo.
Não poderíamos ignorá-lo completamente. Vou adicionar a declaração @.
Sim, nós o contornamos. A resposta não encontrada é do diretório.
Vamos especificar o diretório admin.
O resto é deletar o usuário Corlos.
Exemplo-7
Tarefa: Exploração de shellshock
Sabemos que há uma máquina vulnerável a shellshock na rede local do servidor onde a vulnerabilidade SSRF está localizada.
Vamos explorar a vulnerabilidade do SSRF e, em seguida, a exploração do shellshock.
Determinamos que o parâmetro do referenciador é vulnerável à vulnerabilidade ssrf.
Quando examinamos a solicitação http recebida, vemos que ela contém nossas informações de agente do usuário. Este é o nosso ponto de entrada para exploração.
Adicionamos nosso código à seção user-agent. Com este comando, uma solicitação de DNS será enviada do servidor vulnerável para o endereço que especificamos. E nesta solicitação, veremos as informações do whoami na parte do subdomínio.
Na seção Referer, para Shellshock () { :;}; Usaremos <comando> e ao mesmo tempo, como não sabemos o endereço IP da máquina na rede interna, faremos a varredura do último octeto entre 1-225.
Tanto.