Existe uma coisa chamada SSRF. Muito foi escrito sobre ela, mas ainda assim, vou lhe dizer brevemente.
Digamos que você vá ao site, preencha o perfil e acesse o item "upload avatar". E você tem a opção - fazer upload de um arquivo ou especificar um link.
Nesse caso, estamos interessados no segundo ponto. Se fornecermos um link para um recurso que contém uma imagem, o aplicativo Web:
- Transfere-o
- Verifique se a imagem é a imagem
- Verifique os tamanhos, pois eles podem não se encaixar
- Exiba para o usuário (para cortar)
Então aqui. Se o site não verificar de onde está tentando baixar a imagem, isso é uma vulnerabilidade (como regra). Além disso, os vetores de ataques a um recurso tão pequeno como o download de imagens são tão extensos que não há reunião suficiente na barra para passar por todas as opções.
Uma vez me perguntaram: “O que posso fazer se posso colocar apenas um link http (s)? Não dá nada! "
Eu te digo.
A opção mais fácil é tentar identificar os serviços internos. Se estamos falando de uma imagem, você pode tentar olhar para os caminhos padrão como favicon.ico, logos ou o diretório de ícones, sugerindo que o Apache seja usado. Ao enviar solicitações, podemos iterar sobre endereços locais populares, bem como subdomínios do site que funcionam na infraestrutura interna. São todos os tipos de bambu, jira, gitlab e outras coisas amadas por todas as empresas.
Para que é necessário? Mas porque conhecimento é poder. Afinal, mesmo cegamente, você pode usar várias vulnerabilidades e explorações. Conhecendo o fornecedor ou a versão do servidor ou serviço da Web usado, você reduz o alcance dos ataques que pode aplicar. Talvez nem agora, mas no futuro, o conhecimento de informações técnicas sobre a infraestrutura interna o ajudará a explorar outras vulnerabilidades.
Bem, fomos proibidos de nos permitir inserir endereços IP. Suponha que tenhamos algum recurso importante dentro da infraestrutura e seu endereço IP seja 192.168.1.1
Antes de tudo, iniciamos mentalmente um domínio ao qual atribuiremos esse IP. Que seja my-test-site.com. Na vida real, você deve criar subdomínios cujo endereço será direcionado para o IP de que precisamos, mas mais sobre isso posteriormente.
Força bruta da senha
Vamos sonhar que temos um roteador dentro. O diretório / admin / está em Autenticação básica. Alterando o link, podemos selecionar logins e senhas para o roteador. Mas aqui é bem simples, nós apenas formamos um link do formulário
http://login:password@my-test-site.com/admin/Assim, o valor antes dos dois pontos será o login, depois dele - a senha. E através do sinal @, haverá um domínio para o qual esses dados serão enviados. Observe que ele não funciona com todos os tipos de pessoas de contato nas quais você precisa preencher um formulário. Portanto, a autenticação básica é necessária - uma janela pop-up com uma resposta 401 do servidor.
Se tivéssemos sorte e o site retornasse pelo menos o código de resposta (200, 401, 503), seria muito mais fácil. Então podemos observar claramente o processo e ver nossa vitória:
http://admin:password@my-test-site.com/admin/ - 401
http://admin:admin@my-test-site.com/admin/ - 401
http://admin:123456@my-test-site.com/admin/ - 200Ao enviar uma dúzia ou duas dessas solicitações, você pode tentar encontrar a senha desse roteador. E depois vá para o script para salvar seu próprio DNS ou até /reboot.cgi
E se não houver resposta e é sempre a mesma?
Aqui os horários nos ajudarão.
Horários
Tudo leva tempo. Como levo seu tempo para ler um artigo, os serviços demoram para responder.
A peculiaridade é que podemos tentar acessar recursos internos e medir o tempo para responder à pergunta - existe algum serviço ou não?
Depois de enviar muitas solicitações, você pode classificar cegamente serviços internos, portas e até diretórios e arquivos, contando com uma anomalia de respostas.
1302 ms - http://test.company.com
1307 ms - http://db.company.com
5483 ms - http://jira.company.com
1410 ms - http://docs.company.com
1366 ms - http://kafka.company.comO subdomínio jira respondeu por mais tempo, provavelmente por dentro, e a diferença é perceptível porque o servidor da Web tentou carregar a página e percebeu que não era uma imagem. E o que importa para nós não é o fato de "Quem respondeu por mais tempo?", Mas "Quem respondeu não como todos os outros?" Como o tempo pode ser um atraso - por exemplo, se você encontrar um arquivo ou script grande que demora muito para ser executado. Ou vice-versa, uma resposta rápida.
1302 ms - http://test.company.com
1307 ms - http://db.company.com
423 ms - http://jira.company.com
1410 ms - http://docs.company.com
1366 ms - http://kafka.company.comNesse caso, a resposta diz que é 401 ou um redirecionamento que não processa o analisador de imagens. Ou talvez o site esteja acessível, mas depois de verificar os primeiros bytes ou tipo de conteúdo, nosso aplicativo da Web o rejeitou antes de fazer o download completo da página. Outros sites neste exemplo não esperaram por uma conexão (ou o nome do host não ficou sóbrio)
Mecanismos de verificação de IP
Muitos sites confirmaram que o endereço IP não é interno. Mas a lógica pode estar errada e, às vezes, você ainda pode conectar o aplicativo ao endereço IP interno. Por exemplo, um site faz check-in em dois blocos lógicos. Primeiro, ele verifica se o host que aponta para o IP externo me foi fornecido com precisão. Se, após passar com êxito na primeira verificação, o site estabelecer uma conexão, sem armazenar em cache o endereço IP do parágrafo anterior, você poderá fazer um truque engraçado.
Na primeira solicitação do domínio my-test-site.com, forneça um IP externo, por exemplo 123.123.123.123
E assim que passar na validação, comece a enviar IP interno para o mesmo domínio.
Nesse caso,
Emil Lerner fez um ótimo serviço - 1u.ms!
O domínio 1u.ms responde com os endereços IP especificados.
O formato do domínio deve ser o seguinte:
make-%IP%-rebind-%IP-rr.1u.msPor exemplo
make-123.123.123.123-rebind-127.0.0.1-rr.1u.msA primeira solicitação será respondida com o endereço 123.123.123.123 e a segunda solicitação já será respondida em 127.0.0.1 (se forem uma após a outra, dentro de 5 segundos).
A propósito, o endereço IP pode ser escrito sem pontos, caso você precise de um subdomínio:
make-123-123-123-123-rebind-127-0-0-1-rr.1u.msA propósito, antes de fazer e depois de rr, você pode escrever palavras arbitrárias para impedir o uso de dados em cache:
bo0om-make-123-123-123-123-rebind-127-0-0.1-rr-test.1u.msE para ver o log - o análogo da cauda -f:
curl http://1u.ms:8080/log(ou o mesmo link no navegador)
Digitalização de porta usando DNS
De fato, ao gerenciar registros DNS, você pode tentar verificar as portas. Um pequeno truque nos ajudará com isso.
Suponha que tenhamos um domínio my-test-site.com.
Geralmente, ele contém pelo menos um registro A para o recurso abrir.
Digamos que o IP do nosso site seja 172.217.20.46 (retirado do google.com.br). Mas podemos especificar várias dessas entradas! Imagine que nós os criamos e nossos registros DNS são assim:
my-test-site.com 172.217.20.46
my-test-site.com 192.168.1.1Nosso recurso será aberto? Sim vai. E tudo porque o primeiro registro vai primeiro.
Agora mude os registros DNS da seguinte maneira:
my-test-site.com 192.168.1.1
my-test-site.com 172.217.20.46Nosso recurso será aberto? Será novamente :)
E tudo porque o recurso primeiro tentará inicializar a partir do primeiro IP especificado e, se houver algum problema, ele passará para o segundo.
curl "my-test-site.com" -v
* Trying 192.168.1.1...
* TCP_NODELAY set
* Immediate connect fail for 192.168.1.1: Host is down
* Trying 172.217.20.46...
* TCP_NODELAY set
* Connected to my-test-site.com (172.217.20.46) port 80 (#0)
> GET / HTTP/1.1
> Host: my-test-site.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=UTF-8
< Referrer-Policy: no-referrer
< Content-Length: 1561
< Date: Tue, 21 Jan 2020 16:35:08 GMTUsando esse recurso, você pode descobrir quais portas estão abertas e quais não. De fato, muitas (mas não todas) as bibliotecas tentarão chegar primeiro ao primeiro recurso, listado primeiro nos registros DNS e depois no segundo.
Aqui indicamos o link para o nosso recurso no carregamento do avatar.
Especificando nosso domínio, alterando a porta, tentamos usar o método de exceção para determinar qual porta está disponível.
http://my-test-site.com:22 - 172.217.20.46:22
http://my-test-site.com:80 - 172.217.20.46:80
http://my-test-site.com:8080 -
http://my-test-site.com:9200 - 172.217.20.46:9200
http://my-test-site.com:3306 -Como especificamos 192.168.1.1 como o primeiro registro, concluímos que esse endereço respondeu à biblioteca em 192.168.1.1 (portas 8080 e 3306), mesmo que estivesse incorreto, mas respondeu. Portanto, essas portas estão abertas e existem serviços nelas. Nesse caso, ele não mudará para o segundo endereço.
O serviço 1u.ms aqui também pode ajudar, neste caso, teremos a seguinte configuração:
make-%IP%-and-%IP%rr.1u.msdo tipo
make-192.168.1.1-and-172.217.20.46rr.1u.msEle retornará duas entradas, todos os outros recursos, como no parágrafo anterior.
A propósito, essa abordagem pode ser usada para uma Rebinding DNS mais rápida, forçando o navegador a mudar de um servidor "travado" para um servidor em funcionamento. Eu acho que será mais rápido do que esperar um minuto para atualizar o cache do DNS. No entanto, com o Chrome, por exemplo, esse truque não funcionará, pois é necessário um IP aleatório.
Outro problema é que o servidor DNS com o qual o aplicativo da web determina os endereços de domínio pode ter round robin interno - altere a ordem dos registros, distribuindo uniformemente a carga em todos os servidores. Por exemplo, 8.8.8.8 recusou esse recurso, mas no 1.1.1.1 ele está presente.
Redirecionamentos
Tente redirecionamentos! Bem, primeiro, os redirecionamentos podem reduzir o número de solicitações para um aplicativo Web, por exemplo, ao verificar portas usando DNS. Se a resposta chegar, redirecione para outra porta ou domínio. Caso contrário, talvez ele tenha tropeçado em um porto aberto.
Mas a melhor coisa, é claro, é tentar alterar o protocolo usando o redirecionamento. Na minha prática, houve casos em que um redirecionamento para o arquivo: /// etc / passwd funcionou e mostrou o conteúdo do arquivo. Na versão com ssrf cego, você pode tentar alterar o protocolo para gopher (enquanto ele ainda existe) e já pode enviar cartas usando comandos para SMTP e outras magias.
Negação de serviço
O carregador de inicialização será interrompido se eu fornecer um arquivo de entrada com 10 GB de tamanho? Ou uma imagem de 225.000 por 225.000 pixels, ocupando 141,4 GB de RAM. Isso pode afetar o desempenho do site. É verdade que um servidor com falha não nos trará nenhuma diversão, portanto, lembre-se disso.
E um monte de tudo
Provavelmente é tudo o que posso citar agora. Isso não leva em consideração as vulnerabilidades associadas ao download (onde ele é carregado, como é salvo, que é verificado ao mesmo tempo) e partes de terceiros (lembre-se do
imagetragick e
gifoeb ). Se você tiver outras idéias, deixe um comentário.
Não posso deixar de dar
uma Bíblia ao
SSRF que descreva a maioria dos casos nesse ataque. E também uma página com SSRF no repositório
PayloadsAllTheThings favorito de
todos , com o suporte ativo da comunidade.
A propósito, muitos ataques são aplicáveis ao servidor (no servidor) e ao cliente (no navegador). Atacante - ataque, seja criativo. Defendendo - defenda-se, seja mais esperto do que atacar.
https://bo0om.ru/blind-ssrfZen