Forbidden Bypass Cloudflare Zero Trust

Tela de bloqueio Cloudflare Zero Trust

O objetivo deste post é compartilhar uma dica sobre como proceder ao encontrar uma tela de “Forbidden” do Cloudflare Zero Trust durante seus testes. É importante destacar que isso não representa uma vulnerabilidade no serviço da Cloudflare, mas sim uma configuração inadequada por parte das empresas que utilizam o Zero Trust. Portanto, os resultados podem variar e talvez não funcione para você da mesma forma que funcionou para mim. No início, pode parecer algo inofensivo, pois apenas contornar uma página 403 e se deparar com uma tela de autenticação pode não parecer muito significativo. No entanto, se você conseguir conectar os pontos e explorar uma cadeia de vulnerabilidades, pode obter resultados bastante promissores, como aconteceu comigo.

Durante uma atividade de Red Team, encontrei vários subdomínios exibindo a mensagem de “Forbidden” do Cloudflare Zero Trust, o que foi bastante frustrante, já que impedia o acesso e a análise das aplicações. Após dedicar algum tempo pesquisando possíveis métodos de bypass para o Zero Trust, não encontrei nada que realmente funcionasse. Porém, ao revisar a própria documentação do Zero Trust da Cloudflare, encontrei uma pista valiosa relacionada ao uso do aplicativo WARP.

WARP Cloudflare

Para quem não sabe, o WARP é um serviço fornecido pela Cloudflare, inicialmente introduzido como uma VPN para dispositivos móveis, que melhora a segurança e o desempenho da Internet. Ele encripta o tráfego do usuário e o encaminha pela rede global da Cloudflare, oferecendo melhorias de desempenho e benefícios de segurança, como proteção contra ameaças e acesso mais rápido ao conteúdo da Web. Ao se conectar ao WARP, você recebe um IP externo da Cloudflare, e aqui começa a ficar interessante.

IP externo sem estar conectado ao WARPIP externo conectado ao WARP

De acordo com a documentação da Cloudflare, existe uma configuração no Zero Trust que permite o acesso aos seus aplicativos apenas a partir de dispositivos que executam o Cloudflare WARP. O problema é que essa política de acesso valida qualquer versão do WARP, inclusive a versão para consumidores.

Documentação sobre WARP Cloudflare

Sabendo dessa possibilidade, conectei-me ao WARP e tentei acessar as aplicações que estavam bloqueadas. E adivinhe? Recebi um status code 200. Isso facilitou muito meu teste, permitindo que eu acessasse 100% das aplicações que antes estavam bloqueadas com status code 403.

Bom, mas e agora? Se reparar, consegui realizar o bypass do 403, mas agora recebo uma página de login, como ilustra a imagem abaixo.

Página de login Cloudflare Zero Trust

Ao analisar a página, percebi que, ao inserir um e-mail, a aplicação enviava um código de acesso para a caixa de entrada, permitindo, assim, o acesso à aplicação. Isso significava que eu precisava obter acesso a um e-mail corporativo autorizado. No entanto, é importante destacar que, no meu caso, não era qualquer colaborador que tinha acesso às aplicações protegidas pelo Cloudflare Zero Trust. Somente usuários específicos, previamente autorizados no painel administrativo do Zero Trust, podiam acessar essas aplicações, tornando necessário identificar as pessoas certas para prosseguir.

Após várias tentativas e técnicas para obter acesso a uma caixa de e-mail corporativa, consegui finalmente acessar uma conta que possuía as permissões necessárias para acessar as aplicações protegidas pelo serviço da Cloudflare. O próximo passo foi simples: inserir o e-mail, receber o código de verificação e, com isso, obter acesso completo às aplicações que anteriormente estavam restritas.

Exemplo de e-mail recebido com o código para autenticar-se no Cloudflare Zero Trust

Certo, agora consegui acesso às aplicações e posso então iniciar a análise de todas elas, mas podemos explorar ainda mais possibilidades. Sabendo que o Cloudflare Zero Trust funciona de maneira semelhante a uma VPN, é provável que os colaboradores usem esse serviço para se autenticar externamente com a rede interna da empresa. Então, como podemos fazer isso?

Ao analisar a documentação da Cloudflare, compreendi as etapas necessárias para configurar o acesso via Zero Trust. Além de claro, você ter a conta com as devidas permissões já configuradas pela equipe de TI da empresa, que no meu caso já possuía (descoberta na etapa de acessar uma caixa de e-mail), o próximo passo era entender como configurar o WARP na minha máquina. O processo é simples e envolve três etapas:

Baixar e instalar o cliente WARP.Baixar e instalar o certificado da Cloudflare.Realizar o login no Zero Trust usando o e-mail corporativo.

Você pode conferir esses passos detalhados na própria documentação da Cloudflare:

Depois de instalar o WARP, o que deve ser feito é ir em Preferências > Conta > Fazer login com o Cloudflare Zero Trust.

Configurações do WARPLocal para realizar o login com o e-mail corporativo no Cloudflare Zero TrustNome da equipe/empresa conforme é informado ao receber o token no e-mail

Após a configuração, uma janela de autenticação será exibida, solicitando o envio de um código para o e-mail corporativo. Basta repetir o processo de inserção do código, e você terá acesso à rede VPN da empresa. A partir desse ponto, o nível de acesso dependerá de vários fatores, como a configuração do ambiente e da rede, entre outros. No entanto, ficou claro que é possível comprometer o ambiente de uma empresa devido a uma simples falha de configuração em seus serviços.

Resolvi então validar se outras empresas também poderiam ter esse problema de configuração. Para isso, mapeei mais aplicações que estavam com status code 403 no Zero Trust da Cloudflare, utilizando o serviço Asset Inventory da Trickest, uma base de dados de aplicações web relacionadas a programas de bug bounty, extremamente útil para bug hunters. Como podem ver na imagem, selecionei apenas aplicações com o título relacionado ao bloqueio do Zero Trust.

OBS: Também fiz utilizando serviços como Shodan e FOFA onde obtive muito mais resultados, porém, acredito que ficou mais didático utilizando a Trickest.

Base de dados Trickest filtrando apenas resultados relacionados ao Cloudflare Zero Trust

Primeiro, extrai e salvei todas as URLs em um arquivo e, conectado à minha rede normal, executei a ferramenta HTTPX filtrando informações como título da página e status code 200 e 403. Como esperado, não obtive nenhum status code 200.

Execução da ferramenta HTTPX nas URLs sem estar conectado ao WARPResultado: Nenhum status code 200 sem estar conectado ao WARP

Em seguida, conectei-me ao WARP e executei novamente o HTTPX filtrando por status code 200 e 403. Para minha surpresa, recebi retorno de 5 aplicações com status code 200, provando que é possível usar o WARP para “bypassar” o bloqueio do Zero Trust.

Execução do HTTPX agora conectado ao WARPResultado: 5 aplicações com status code 200 e sendo acessível a partir da conexão do WARP

Não tive acesso direto ao painel do Zero Trust da Cloudflare para confirmar as configurações exatas que permitem essa brecha, nem para sugerir correções específicas. No entanto, de acordo com a documentação da Cloudflare, recomenda-se que, ao liberar o acesso aos aplicativos via WARP, seja utilizada a opção “Require Gateway”. Essa configuração garante que apenas dispositivos registrados na instância do Gateway da organização possam acessar as aplicações.

Espero que essa informação possa ser útil nos seus testes, assim como foi para mim. Como mencionei anteriormente, isso não se trata de uma vulnerabilidade, mas de uma falha de configuração. Portanto, é possível que algumas empresas estejam devidamente configuradas e que você não consiga explorar essa brecha.

Obrigado!

by: j0hnZ3RA