Em março de 2020, a pandemia começou, então eu tive muito tempo livre. Eles precisavam ser gerenciados com sabedoria e decidi obter a certificação OSWE. Depois de passar no exame em 8 de agosto, tirei algumas semanas de folga e, em meados de setembro, disse a mim mesmo: “Sabe de uma coisa? Meu nome não apareceu no Hall da Fama do Facebook em 2020, embora isso aconteça lá anualmente. É hora de resolver esse problema! ”.
Nunca encontrei uma vulnerabilidade em um dos subdomínios do Facebook, então estudei os artigos e encontrei uma postagem sobre o subdomínio do Facebook que me chamou a atenção. Este é um ótimo post, recomendo lê-lo: [bug de conversão de HTML para PDF leva a RCE no servidor do Facebook] .
Depois de ler este post, percebi que muitas vulnerabilidades podem ser encontradas em um aplicativo da web tão grande.
Meu objetivo principal era
https://legal.tapprd.thefacebook.com
implementar RCE (Remote Code Execution) ou algo semelhante.
Executei ferramentas de difusão para descobrir todos os endpoints deste aplicativo da web, tirei uma soneca de duas horas e assisti a um filme. Então voltei para o meu computador e encontrei bons resultados.
403:
/tapprd/
/tapprd/content/
/tapprd/services/
/tapprd/Content/
/tapprd/api/
/tapprd/Services/
/tapprd/temp/
/tapprd/logs/
/tapprd/logs/portal/
/tapprd/logs/api/
/tapprd/certificates/
/tapprd/logs/auth/
/tapprd/logs/Portal/
/tapprd/API/
/tapprd/webroot/
/tapprd/logs/API/
/tapprd/certificates/sso/
/tapprd/callback/
/tapprd/logs/callback/
/tapprd/Webroot/
/tapprd/certificates/dkim/
/tapprd/SERVICES/
Acho que este resultado é o suficiente para confirmar minha teoria sobre a enormidade desta aplicação. Então comecei a ler os arquivos Javascript, para entender como funciona o site, quais métodos ele usa, etc ...
Vi uma forma de contornar o redirecionamento para o Login SSO no
https://legal.tapprd.thefacebook.com/tapprd/portal/authentication/login
e após analisar a página de login encontrei este endpoint:
/tapprd/auth/identity/user/forgotpassword
Depois fuzzing por endpoint do usuário, identifiquei outro endpoint
/savepassword
aguardando uma solicitação POST. Após examinar os arquivos Javascript, descobri como a página funciona, se o token gerado e o token xsrf são necessários, etc. A princípio pensei que valia a pena tentar para verificar, você pode alterá-los manualmente com a ajuda
burp suite
, mas ocorreu um erro falha da operação .
Achei que fosse o endereço de e-mail errado ou algo semelhante. Vamos tentar pegar o e-mail do administrador. Comecei a anotar endereços de e-mail arbitrários, fazendo uma lista de palavras e usando o arroto para testar o que acontecia.
Quando voltei algumas horas depois, vi os mesmos erros, além de outro resultado. Foi um redirecionamento 302 para a página de login. Uau, porra funcionou!
Deixe-me explicar o que aconteceu aqui: enviei solicitações aleatórias com um token CSRF usando um cracker e endereços de e-mail aleatórios com uma nova senha de endpoint
/savepassword
e um dos resultados foi um redirecionamento 302.
Redirecionar
Agora pude ir para a página de login, digitar meu email e uma nova senha - BOOM, o login no aplicativo foi realizado com sucesso e tive acesso ao painel de administração!
Eu li o relatório de um hacker que encontrou um RCE anterior implementado com PDF, a empresa deu a ele uma recompensa de apenas $ 1000. Então eu decidi: ok, você precisa causar uma boa impressão e escrever o exploit perfeito para obter um alto impacto.
Rapidamente escrevi um script Python simples para explorar esta vulnerabilidade: você insere um endereço de e-mail e uma nova senha, e o script altera a senha.
O impacto foi tão grande aqui porque os funcionários do Facebook fizeram login com suas contas de trabalho. Ou seja, eles usaram seus próprios tokens de acesso à conta do Facebook e é provável que se outro invasor quisesse usar essa exploração, isso lhe daria acesso às contas de alguns funcionários do Facebook. Então
, relatei a vulnerabilidade e meu relatório foi revisado .
Recebi um prêmio de US $ 7.500 em 2 de outubro
Eu gostei muito do exploit para esta vulnerabilidade, e decidi que não era suficiente, o script é muito fraco! Vale a pena continuar a cavar mais fundo.
Portanto, encontrei mais duas vulnerabilidades, que discutirei na segunda parte do artigo.
Parte dois
Na primeira parte, descobri a capacidade de sequestrar uma conta com uma API insegura, o que me permitiu alterar a senha de qualquer conta de administrador sem intervenção do usuário, pela qual o departamento de segurança do Facebook me pagou $ 7.500 . Na segunda parte, descobri uma maneira de sequestrar uma conta usando a manipulação de cookies. Combinado com o SSRF interno , recebi uma recompensa de $ xxxxx . Sim, uma soma de cinco dígitos ... Bem, vamos começar.
Antes da publicação, o artigo foi verificado por várias partes, e eu tive que obter permissão por escrito para ele, para que alguns dos nomes e informações pudessem ser alterados a pedido do Facebook e seus parceiros.
Quando descobri a vulnerabilidade na primeira parte do artigo, o Facebook a corrigiu no dia seguinte ao recebimento do relatório. Então comecei a estudar história
burp suite
para entender como tudo funciona.
Como você pode ver na imagem (número 1 em um fundo azul), ASPXAUTH é usado como um cookie . Idealmente!
Você vê aonde estou chegando? ASPXAUTH tem 80% de chance de ser vulnerável, mas isso requer as seguintes informações:
validationKey
(): , .decryptionMethod
(): ( «AES»).decryptionIV
(): ( — , ).decryptionKey
(): , .
Você pode ler mais sobre isso aqui: Classe MachineKey .
Não tenho informações sobre nenhum dos pontos, então por que presumi que há uma vulnerabilidade aqui?
Na verdade, eu não sei disso, mas a maioria dos aplicativos ASPXAUTH em cookies criptografados com chaves de criptografia geralmente usam apenas e-mail ou usuário e tempo de expiração de cookie. Eu usei esse método muitas vezes em programas de recompensa de outros sites e funcionou.
Eu precisava encontrar uma maneira de contornar esse sistema, pelo menos não uma tentativa de tortura. Fui ao Google e procurei outros sites que usam o mesmo aplicativo. Eu deveria ter sorte e encontrar um site usando o mesmo aplicativo e as mesmas chaves de criptografia e apenas escolher o nome de usuário de administrador correto.
Encontrei outro site usando o mesmo aplicativo, o registro estava ativo, então fiz login com o nome de usuário de administrador do Facebook, interceptei a solicitação, peguei ASPXAUTH e substituí-o por um Facebook ASPXAUTH expirado. Adivinha o que aconteceu?
Já senti falta deste painel, mas finalmente voltei a ele. Agora, vamos falar um pouco sobre a supervisão do ASP.net que a maioria dos desenvolvedores deve levar em consideração ao criar aplicativos para mantê-los seguros:
- ASPXAUTH deve ser armazenado no banco de dados e o aplicativo deve validá-lo para correção.
- Como uma verificação adicional, ASPXAUTH às vezes deve conter mais do que apenas o nome de usuário.
- Cada site deve ter chaves exclusivas de criptografia e descriptografia (as chaves padrão devem ser alteradas).
Conclusão 1 : Eu poderia entrar em qualquer conta de administrador, sabendo apenas o seu nome de usuário; Considero a complexidade desta vulnerabilidade muito baixa e seu impacto alto . Se eu apenas relatar essa vulnerabilidade, receberei apenas US $ 7.500 , como na primeira parte, mas queria mais.
No painel, notei algo curioso, nomeadamente a opção de criar formulários e outra opção - trigger API. Suspeitei de algo, provavelmente há uma possibilidade de SSRF (Server-Side Request Forgery) ilimitado. Portanto, escrevi uma carta para o departamento de segurança do Facebook, dizendo que há quase cem por cento da vulnerabilidade SSRF crítica no aplicativo, pedindo permissão para testá-lo. A resposta veio para mim:
Naquela época, eu ainda estava discutindo o relatório da primeira parte (invasão de conta) com eles, porque relatei essas vulnerabilidades uma semana depois da primeira. Como você pode ver, o departamento de segurança do Facebook continuou a acreditar que eu estava reivindicando outro desvio de autenticação e SSRF, mesmo depois de explicar as vulnerabilidades com evidências. A julgar por isso, recebi permissão para testar o SSRF.
Depois de um tempo, escrevi um pequeno roteiro e enviei para o editor deles. O script me permitiu enviar qualquer solicitação com qualquer dado (GET, POST, PUT, PATCH, HEAD, OPTIONS) para qualquer URL, interna e externa.
No back-end do script, eu poderia alterar o método de solicitação e os dados enviados, etc.
Nesse estágio, eu poderia expandir essa vulnerabilidade para RCE, talvez para LFI (Inclusão de arquivo local, adicionando arquivos locais), se eu for um pouco mais longe ( não estou completamente certo disso, mais tarde pedi permissão ao Facebook para fazer engenharia reversa o pedido, mas eles recusaram e disseram que não achavam que eu poderia expandir o ataque ).
Então, tentei atacar o Facebook com um script canário. Adivinha o que aconteceu de novo?
Recebi meu token canário. Qual é o próximo? Preciso escrever um novo relatório com todos os detalhes, incluindo scripts e PoC (prova de conceito), como me foi dito acima.
Conclusão 2: ao escrever um script para enviar solicitações arbitrárias, consegui obter o SSRF interno e fornecer acesso à rede interna do Facebook. Considero a dificuldade deste ataque baixa e o impacto crítico .
Impact SSRF:
SSRF- Facebook, , -, . SSRF .
SSRF-, , , , , .
Saiba mais sobre as vulnerabilidades de SSRF no artigo portswigger .
Conclusão final: encadei as duas vulnerabilidades até o ponto em que tive acesso à intranet do Facebook ( SSRF ), usando o controle de conta para acessar meu script carregado dentro do aplicativo, enviando as solicitações arbitrárias que eu queria.
Vamos falar sobre o que posso alcançar com a cadeia de vulnerabilidade que descobri:
- Posso acessar a conta de qualquer funcionário do Facebook no painel do Departamento Jurídico.
- Não há necessidade de explicar a importância das informações que um invasor pode obter após o login.
- Eu poderia usar o SSRF para acessar a intranet do Facebook (intern.our.facebook.com).
- Acho que com um pouco mais de esforço, posso expandir essa vulnerabilidade e usá-la para fazer a varredura da rede / servidores internos.
Todos nós sabemos como o SSRF é crítico , especialmente se não for limitado por frequência. Posso alterar facilmente o tipo de conteúdo e os métodos de solicitação. De acordo com os guias de pagamento do Facebook , essa vulnerabilidade deve ser recompensada com $ 40.000 em um bônus de $ 5.000 se eu puder alterar o tipo de conteúdo da solicitação e o método de solicitação.
Depois de uma longa espera, recebi esta mensagem do Facebook:
Recebeu um prêmio de $ 40.000 do Facebook mais um bônus de $ 2.000 (acima dos $ 7.000 esperados ).
Eu fiz a eles uma pergunta sobre por que não recebi o Bônus de Controle Total ( $ 5.000 ) e recebi esta resposta:
No total, com a primeira vulnerabilidade, isso somou US $ 54.800 .
Relatei essa vulnerabilidade alguns dias após a primeira parte do relatório de vulnerabilidade.
Cronologia dos relatórios:
- Quarta-feira, 9 de setembro de 2020 - Relatório de vulnerabilidade enviado.
- Segunda-feira, 26 de outubro de 2020 - o Facebook me pediu para abrir um novo relatório. ~ Medidas corretivas tomadas.
- Segunda-feira, 26 de outubro de 2020 - relatório revisado.
- Quinta-feira, 25 de fevereiro de 2021 - Problema resolvido e recompensa paga. Cerca de seis meses, sim .
- Sexta-feira, 5 de março de 2021 - bônus de $ 5.300 pago.
Quero dar alguns conselhos valiosos aos caçadores de insetos. Ao ver ASPXAUTH, tente obter cookies de outro site usando o mesmo aplicativo e teste o mesmo método que o meu:
- Crie novos cookies ASPXAUTH de outro site.
- Verifique se os cookies funcionarão no site sob investigação.
Gostei do processo, mas esperar seis meses e fechar relatórios por motivos irracionais era chato. Agradeço, mas tive que trabalhar muito e este não é o único SSRF que encontrei. Na verdade, achei mais curiosos, mas o Facebook fechou os relatórios como "informativos" porque a empresa assinou um acordo com o fornecedor que fechou algumas semanas depois de analisar os relatórios. No final das contas, esse não é o meu problema, então essa experiência não é agradável.
No final, quero me desculpar se algo não ficou claro. Demorou algum tempo para publicar a segunda parte - como mencionei acima, estava aguardando a permissão por escrito e a revisão do relatório. Portanto, muitos aspectos foram removidos ou censurados para preservar a confidencialidade de terceiros.