Recentemente, comecei a receber uma proposta para verificar a operação de vários serviços em busca de erros e vulnerabilidades. E nessas propostas, tento trabalhar no resultado e obter o máximo prazer do processo. Mas o resultado do último "projeto" me chocou para dizer o mínimo.
Me pediram para testar o provedor de hospedagem.
Não divulgarei o nome. E na minha história vou usar o nome Hoster. Com o próprio site, o serviço de hospedagem era padrão. Ofertas para comprar certificados VDS, domínios e SSL.
Primeiro, fiquei surpreso com a forma como a conta pessoal do usuário foi implementada. Não era necessário comprovar a propriedade do endereço de e-mail durante o registro. Ou seja, você pode se registrar com o endereço de e-mail steve.jobs@apple.com. Ou melhor ainda, support@hoster.com.
Felizmente, porém, por analogia com
essa história , a divulgação de informações confidenciais da central de suporte de serviços não aconteceu.
No entanto, isso aconteceu quando eu criei uma solicitação de suporte de teste e verifiquei imediatamente a disponibilidade de solicitações de ID vizinhas para outras solicitações de suporte. Surpreendentemente, eles estavam disponíveis. E foi possível observar quem e o que se registra no hoster. E que problemas os usuários enfrentam? Em geral, a vulnerabilidade padrão do IDOR, que agora não surpreenderá ninguém. Claro, ela foi instantaneamente corrigida.
Havia também vários lugares com o XSS armazenado. Havia também o Blind XSS que retornou o cookie do administrador de serviços para mim. Graças a esse XSS, consegui descobrir onde a interface do administrador está localizada e, em geral, revelou muitas informações interessantes.
- Quantos usuários ativos.
- Quantos domínios estão no controle.
- Quantos VDS estão implantados.
E muito mais ...
Houve vários erros nos tokens de CSRF, que permitiram, em nome do usuário, fazer muitas coisas perigosas em sua conta. E se havia lugares onde os tokens de CSRF eram transferidos, eles eram simplesmente transferidos. Ninguém planejou verificá-los no back-end. Como resultado das minhas descobertas, parte da funcionalidade foi completamente desativada. Por exemplo, a autenticação 2FA foi decidida como removida temporariamente, pois não ocorreu na implementação.
No decorrer do meu trabalho, prestei atenção não apenas aos problemas de segurança, mas também aos erros de implementação ou problemas na operação de algumas funcionalidades. Eu gosto de controle de qualidade não poderia passar assim. Como resultado, meu rastreador de problemas alcançou a figura 22. Tantos problemas no conjunto que eu encontrei e consertei (extremamente notáveis).
Os resultados foram mais do que convincentes. E eu já planejava concluir este projeto. Mas, por alguma razão, lembrei-me novamente do problema da falta de confirmação do proprietário do endereço de e-mail durante o registro. E ele começou a apresentar situações em que isso pode criar problemas máximos para a hospedagem e seus proprietários. Em algum momento, comecei a pensar nas relações dos proprietários desse serviço de hospedagem com outros projetos da mesma empresa que conhecia. Depois de alguns minutos, registrei uma conta com o endereço de email de outro projeto da mesma empresa (seja support@example.com). Em seguida, consegui vincular o domínio example.com à minha conta criada suppot@example.com. Mas ainda não consegui controlar o conteúdo do domínio vinculado.
Mas ele poderia pescar perfeitamente com e-mails em nome do serviço example.com.
Não está claro para onde chegaram as cartas de resposta. Porque eu respondi uma dessas cartas de teste para mim mesma. Mas eu não recebi a resposta em si. Provavelmente desapareceu em resposta ao verdadeiro proprietário da conta de e-mail support@example.com.
E então aconteceu algo pelo qual eu decidi escrever este artigo.
Consegui resolver o subdomínio esquecido. Vulnerabilidade de controle de subdomínio clássico. Você pode ler mais sobre isso
aqui .
Não sei por que, mas tentei adicionar uma ligação a um domínio inexistente. E eu fiz isso.
O subdomínio foi adicionado com sucesso e eu pude controlar o conteúdo desse subdomínio. E o conteúdo foi exibido.
Mas isso não pode ser o mesmo! Como assim ?! Afinal, a vulnerabilidade de controle clássico de subdomínios funciona apenas com subdomínios existentes.
Esta situação absolutamente não se encaixava na minha cabeça. Ou seja, foi possível ignorar os níveis de validação da minha atitude em relação a example.com, que nunca é minha (provavelmente graças ao
exemplo .com no nome da minha conta). Mas como é possível adicionar subdomínios e controlá-los sem nenhum componente de verificação nos registros A, TXT, CNAME ...?
Normalmente eu vejo isso - adicionaremos um subdomínio a você, apenas você prova que pode fazê-lo. Vá e adicione ao TXT este hash
ololopyshpyshpyshbdysh123 .
Mas não havia tal coisa. Deseja o subdomínio admin.example.com? Não tem problema!
Como se uma vulnerabilidade de controle de subdomínio V2.
Devido à capacidade de me comunicar rapidamente com os proprietários do serviço de hospedagem testado - a Pandora me abriu esta caixa.
Acabou o seguinte. A hospedagem funcionou através do CloudFlare. E ele trabalhou de uma maneira muito esperta.
Vou tentar explicar em palavras simples.
Grosso modo, digo-lhe, venha a mim, eu vou te hospedar. Delegue seus domínios para mim.
Depois, envio todas as chamadas recebidas indiscriminadamente para o CloudFlare, considerando-as corretas.
E se você confiasse em mim com o domínio vasya.ru e um vizinho viesse zapilitar o site com test.vasya.ru e também me desse hospedagem, então meu servidor, tendo acesso ao CloudFlare e já com direitos a vasya.ru, adicionou o terceiro nível sem problemas domínio para um vizinho e todas as regras, rapidamente e sem questionar. Para todo o DNS, as informações corretas do CloudFlare chegaram. E CloudFlare confia em mim.
Normalmente, é claro, os provedores de hospedagem configuram seus serviços DNS. Mas aqui acontece que eles trapacearam e apenas transferiram tudo para o CloudFlare de um usuário.
Portanto, temos uma aquisição de subdomínio god_mode. É verdade que isso funcionou apenas com os endereços que a hospedagem já controla. Mas em conjunto com o painel de administração do serviço descoberto anteriormente - isso pode ser um truque para os clientes do serviço de host e do host.
No momento, quase todas as vulnerabilidades e erros críticos foram corrigidos. E espero que ninguém decida sobre essas delícias arquitetônicas depois de ler esta história.
PS: Comentários e sugestões sobre o artigo são bem-vindos. Agradecimentos especiais ao
Patriot2k pela consultoria técnica! Também estou aberto a sugestões para testar algo interessante.