Ignorando proteções SSRF

Olá,

Já faz um tempo desde a última vez que postei. Eu queria compartilhar um desvio SSRF legal que encontrei enquanto caçava em um programa privado.

SSRF significa falsificação de solicitação do lado do servidor. A falsificação de solicitação do lado do servidor permite que um invasor abuse de solicitações HTTP para solicitar informações sobre o servidor internamente ou rede interna.

Coisas para olhar para fora? Parâmetros como url= next= host= image= img= etc. Qualquer coisa que pareça estar fazendo uma solicitação da web para um servidor. Isso pode ser abusado para apontar a solicitação internamente.

Como encontrei o endpoint vulnerável?

Enquanto caçava em um programa privado, eu estava fazendo um amplo reconhecimento. Eu reuni uma lista enorme de subdomínios, principalmente puxando de censys. Depois disso, fiz força bruta e procurei na máquina de retorno por URLs em todos os hosts. Na época, ssrf era meu foco, então reuni meu diretório e a saída do endpoint e procurei por “proxy.php”. Felizmente eu tive um sucesso.

Ao estudar a solicitação, isso estava fazendo uma solicitação HTTP de saída para um URL especificado. Se eu inseri meu link de colaborador burp, não recebi uma pesquisa. Eu tentei o básico usual, inserindo 127.0.0.1 e notações de IP de hosts internos, cada solicitação foi bloqueada, a menos que a solicitação tivesse o nome do host do site.

É aqui que as coisas ficam técnicas. ao enviar uma solicitação com meu colaborador arroto, juntamente com a formatação das credenciais do navegador, por exemplo, url=https:// hostnameofwebsite.com@myburpcollablink , recebi uma resposta.

Eu tentei explorar isso mudando-o porque atualmente o acima estava usando o navegador para enviar hostnameofwebsite como credenciais para myburpcollablink, o que não era bom.

Recentemente, acabei de ver um vídeo ssrf no google quando foi explicado se você usasse um \ isso pararia a análise no back-end após o primeiro host. O front-end interpretaria a solicitação como hostnameofwebsite como credenciais para myburpcollablink, mas o back-end processaria apenas a solicitação de front-end, portanto, hostnameofwebsite. Aqui eu mudei e usei url=http://169.254.1698.254\@hostnameofwebsite.

Vamos explicar. 169.254 é o endereço IP interno dos metadados da AWS. A solicitação de front-end está vendo isso como 169.254 como credenciais para hostnameofwebsite, que passa na verificação de front-end, pois hostnameofwebsite deve estar na solicitação. O back-end ignora esse formato e processa comohttp://169.254.169.254\que então corta e passa apenas a solicitação.

Fechado como resolvido