Como uma simples tag se torna um alto risco para uma empresa?

A segurança com exemplos reais é sempre interessante.

Hoje falaremos sobre o ataque SSRF, quando você pode forçar o servidor a fazer solicitações arbitrárias à Internet por meio da tag img.



Então, estive recentemente envolvido em testes de penetração em dois projetos simultaneamente, em dois deles essa vulnerabilidade foi revelada. As capturas de tela são tiradas diretamente dos relatórios, portanto, todas as informações desnecessárias são manchadas.

Descrição do ataque

Nome do ataque: o servidor faz solicitações arbitrárias à Internet durante a geração de um documento PDF.

Descrição: o PDF é gerado no lado do servidor a partir de uma página html totalmente renderizada com todos os recursos externos. Os documentos continham dados inseridos pelo usuário. Sem filtragem adequada, você pode substituir seus recursos externos na renderização do servidor. Nesse caso, seja o arquivo it-band.by/10gb.blob (tamanho supostamente de 10 Gb).

Pior cenário:

1. Os Ddos atacam por dentro, quando o sistema precisa baixar 100 gigabytes de dados para renderização, a fim de renderizar vários documentos PDF ao mesmo tempo. Como resultado, isso leva à falta de recursos de rede ou memória, o que, por sua vez, pode levar à inatividade do sistema.
2. Um usuário mal-intencionado pode usar o servidor como plataforma para atacar outros recursos.
3. Um usuário mal-intencionado obtém os endereços IP externos dos servidores internos para ataques diretos, ignorando os firewalls de aplicativos da Web (WAF) e os balanceadores.

Avaliação de risco (Probabilidade * Impacto): Médio (5) * Alto (7) = Alto (35) (em ambos os sistemas, o risco foi classificado como alto, embora com proporções diferentes)

O que é interessante:

1. Um sistema usou o wkhtmltopdf para renderizar o html2pdf, o segundo rodou o Firefox, carregou a página e tirou uma captura de tela. De qualquer forma, ambos os sistemas renderizam as duas páginas imediatamente, executam todo o código existente e somente então fazem PDF a partir disso.
2. A proteção do servidor XSS foi instalada nos dois sistemas, mas, em vez de usar o escape de dados de entrada, os dois sistemas usaram a purificação de html, que limpava todos os iframes, scripts, css, formulários e assim por diante. Mas a purificação de html em ambos os sistemas é considerada código html seguro img src="https://it-band.by/10Gb.blob?t=12345.1"/ safe.

Agora siga as etapas e capturas de tela

1) Crie esse arquivo localmente, na tentativa de preenchê-lo posteriormente, no todo ou em parte.



2) No começo, você precisa encontrar campos de usuário vulneráveis.

Sistema 1. Falha ao inserir apenas uma tag img





Sistema 2. Consegui inserir cerca de 20 tags imediatamente



3) Em seguida, geramos o documento PDF.

Sistema 1. PDF Gerado



Sistema 2. PDF Gerado



4) E agora subimos no servidor para ver se havia solicitações para o nosso grande arquivo 10Gb.blob.

Sistema 1. Obtemos o endereço IP e o software do servidor, com a ajuda da qual o documento PDF foi gerado, o nmap mostrou outra porta aberta, que ninguém havia visto antes, pelo endereço IP encontrado.



Sistema 2. Pode ser visto que o servidor tentou baixar 20 arquivos de 10 gigabytes. Também obtemos o endereço de um dos servidores e a versão do Firefox usada.



O resultado. Nos dois sistemas, os erros já foram corrigidos. No primeiro sistema, em vez de purificar html, a fuga é feita durante o processamento de dados do usuário e durante a geração de um documento PDF; no segundo sistema, quaisquer links absolutos para recursos externos são cortados durante o processamento de dados do usuário.

Atualizado.

Enquanto cheguei à publicação do artigo, foram adicionados casos de mais 2 sistemas.

Outro sistema (vamos chamar de Sistema 3) não passou na verificação desse tipo de vulnerabilidade em dois locais ao mesmo tempo: através da injeção de HTML e injeção de CSS.

Sistema 3. Injeção de HTML com download 20 vezes de uma imagem ao vivo 13 Mb (no total 260Mb)



Sistema 3. Injeção de CSS



Sistema 3. O que vemos no servidor atacante ao renderizar um PDF (todos os 20 downloads de uma imagem de 13 Mb são bem-sucedidos)



Qual foi a saída do Sistema 3:

1) Obteve os endereços dos servidores que renderizam e o que eles usam para renderizar. Nesse caso, HeadlessChrome.

2) A geração de um documento PDF levou cerca de 5 minutos, depois o cromo simplesmente caiu. Imagine, se você executar 10 mil dessas solicitações, por um tempo os servidores de geração, em princípio, deixarão de responder às solicitações de outros usuários.

Sistema 4. O ataque SSRF aqui foi realizado não através da tag img, mas através do XSS, quando minha carga útil favorita foi executada no servidor durante a renderização e o servidor lançou o código Javascript arbitrário ao gerar o documento PDF. Comparado aos casos anteriores, é possível realizar ataques mais complexos em outros sistemas.



Sistema 4. PDF renderizado com código JS arbitrário executado no lado do servidor



Premissa 1. Os sistemas exigem o desenvolvimento não apenas das regras do firewall recebido, mas também do de saída, ou do desenvolvimento de infraestrutura com segmentos ou servidores de rede separados, dos quais não há acesso externo.

Premissa 2. Ao encontrar até a menor vulnerabilidade, você deve sempre procurar os piores cenários de uso e impacto nos negócios. Os negócios só podem trabalhar com riscos, o lado técnico, infelizmente, é de pouco interesse para eles.

As informações acima são fornecidas apenas para fins educacionais e educacionais, não é necessário executar seus sistemas.

Denis Koloshko, CISSP, Testador de penetração