0
0
Ataque explora respostas do HTTP 301 para redirecionar usuários. Técnica abusar das respostas HTTP 301 padrão para envenenar o cache do navegador e alcançar a persistência de endpoints para recursos não TLS.
As organizações tomam muito cuidado para garantir que todos os seus dados da Web sejam entregues por meio de HTTPS, com TLS forte e sólida implementação criptográfica.
Cada vez mais empresas sabem que precisam fornecer conteúdo da Web apenas por meio de HTTPS e que precisam implementar autoridades de certificação confiáveis, proteger suas infraestruturas de chave pública e monitorar cuidadosamente seus certificados TLS. Uma forte criptografia da Web é uma obrigação para garantir que os dados que trafegam entre os servidores da Web e o endpoint não possam ser interceptados por invasores cibernéticos.
Até algum tempo atrás apenas sessões da web com dados confidenciais, como números de cartão de crédito para e-commerce e credenciais de autenticação, eram implantadas por meio de HTTPS. Por exemplo, a maioria das páginas da Web de um site seria entregue por meio de HTTP, mas o HTTPS seria usado quando um cliente digitasse suas informações financeiras para fazer uma compra.
Mas agora precisamos entender que todo o conteúdo da Web deve ser entregue por meio de HTTPS para proteger qualquer transferência de dados, mesmo que seja texto simples, pois existe o risco de ataque do tipo man-in-the-middle .
Implementar criptografia forte é ótimo! Mas, muitas vezes, quando os códigos cifrados são tão complexas que demoram meses para que um hacker consiga quebrar, eles procuram, e encontram, maneiras de contornar a criptografia.
A fechadura da porta mais difícil é inútil se uma janela pode ser facilmente quebrada!
Segundo o site da Venafi, o pesquisador de segurança Piotr Duszyński, encontrou uma janela muito fácil de ser utilizada que poderia tornar sua implementação HTTPS fácil de contornar.
Em seu blog ele descreve uma técnica interessante de usar as respostas para o HTTP 301 (“Redirecionamento permanente”) para envenenar o cache do navegador e alcançar a persistência do endpoint para recursos não TLS. Combinado com o “Client Domain Hooking”, publicado pelo mesmo pesquisador, isso tem um impacto interessante do ponto de vista de segurança.
As organizações estão substituindo o HTTP por HTTPS em um ritmo acelerado, e essa função HTTP específica é aquela que o Google endossa oficialmente para direcionar os navegadores de seus usuários para as páginas da Web HTTPS.
“Redirecione seus usuários e mecanismos de pesquisa para a página ou recurso HTTPS com redirecionamentos HTTP 301 do lado do servidor.”
Isso é ótimo. Mas isso também significa que a transição maciça de HTTP para HTTPS torna a exploração que Duszyński descobriu ser aplicável a milhões de sites em todo o mundo e descreve como o ataque explora respostas do HTTP 301 para redirecionar usuários para sites maliciosos.
O ataque descrito por Duszyński é um ataque de envenenamento de cache da Web que pode direcionar o usuário, ao tentar acessar uma página web HTTPS legítima, para o servidor Web do invasor cibernético.
Como funciona?
Primeiro de tudo, no White Paper: “Client Domain Hooking”, um atacante cibernético pode tentar um ataque man-in-the-middle através de ligação de domínio do cliente.
“O navegador envia uma solicitação HTTP que é interceptada por um invasor e redirecionada para o proxy …
O proxy inspeciona a solicitação recebida (incluindo dados de contexto) e a encaminha para o servidor relevante em nome das vítimas.
O servidor responde com um recurso que contém vários URLs com vários domínios e esquemas de URL diferentes (por exemplo, HTTP e HTTPS).
O proxy inspeciona a resposta recebida e substitui todas as ocorrências de FQDNs (Fully qualified domain names) por um único domínio controlado pelo invasor. ”
Isso é o que poderia ser usado para realizar o primeiro passo neste ataque de envenenamento de cache da Web, descrito por ele no artigo Permanent URL Hijack Through 301 HTTP Redirect Cache Poisoning.
“O navegador envia uma única solicitação não TLS que foi interceptada por um invasor por meio de um ataque MITM ou ‘DNS Cache Poisoning’ baseado em rede.”
Então o “proxy reverso responde com um HTTP 301 que será armazenado em cache indefinidamente pelo navegador, a menos que seja indicado de outra forma pelo cabeçalho ‘Cache-Control’ (30 dias nesta resposta de exemplo)…
O navegador segue a cadeia de redirecionamento para o serviço TLS e, a partir de agora, ele interage com todos os serviços por meio de um domínio controlado pelo invasor, mas isso se aplica apenas à sessão de navegação atual.”
A partir desse ponto, com seus certificados TLS legítimos no navegador do usuário, quando eles tentarem visitar suas páginas da Web HTTPS, eles serão direcionados para as páginas da Web do atacante cibernético!
HTTP 301 Cache Poisoning In Practice from Piotr Duszynski on Vimeo.
Fonte: Piotr Duszynski – HTTP 301 Cache Poisoning In Practice
Todos os tipos de ataques cibernéticos podem ser implantados em páginas maliciosas, incluindo ataques com arquivos de malware que podem ser enviados para os usuários, ou mesmo ataques fileless, descritos aqui no blog em Como os adversários usam ataques Fileless para escapar da segurança, que atuam apenas na memória.
A partir das páginas maliciosas, para onde as vítimas são direcionadas, os atacantes cibernéticos podem controlar completamente os PCs e dispositivos móveis de suas vítimas.
Segundo a Venafi, essa exploração de redirecionamento HTTP 301 pode ser especialmente perigosa, porque o conteúdo da Web pode ser fornecido por meio de aplicativos móveis como WebViews e semelhantes.
Como podemos evitar este ataque?
Segundo Duszyński, existem vários métodos de atenuação que podem ser usados para evitar essa forma de ataque:
- Para aplicativos móveis, lembre-se de proibir todo o tráfego não TLS sem exceções.
- Para navegadores, você deve garantir que o HSTS seja sempre usado para todos os seus nomes de domínio, de preferência com uma entrada de pré-carregamento de HSTS.
- Além disso, você pode usar o Modlishka com a configuração descrita em Client Domain Hooking – Example Attack para verificar se o seu aplicativo não pode ser facilmente conectado ao domínio.
- Os usuários finais devem considerar a desativação do tráfego não TLS por meio dos seguintes plug-ins de exemplo: “Firefox” , “Chrome” (ainda aguardando aprovação para a Chrome Store…)
- Mais soluções possíveis são descritas no documento divulgado no artigo Client Domain Hooking – Example Attack .
- Configure os servidores da Web para impedir o tráfego HTTP por padrão.
- Imponha mecanismos de ATS para iOS
- Proíba todo o tráfego de texto sem formatação para aplicativos Android.
- Defina cabeçalhos HSTS válidos em seus serviços e adicione seus domínios às listas de pré-carregamento de HSTS.
- Desabilite o JavaScript se ele não for usado.
FONTE: https://minutodaseguranca.blog.br/ataque-explora-respostas-do-http-301-para-redirecionar-usuarios/