Antes mesmo de começar a compreender a complexa ciência da segurança da informação, parecia-me que a autenticação 2FA é uma maneira garantida de proteger sua conta e que nenhum desses hackers pode, por exemplo, retirar minha moeda interna para comprar roupas para os personagens da conta do jogo. Porém, com o tempo, ficou provado experimentalmente que um sistema de autenticação de dois fatores pode ter um grande número de vulnerabilidades.
Em palavras simples, a autenticação de dois fatores é uma confirmação da ação, digitando o código gerado para aumentar a segurança e jogando paus nas rodas de hackers condicionais durante o movimento ou antes de iniciar.
O sistema de confirmação de código é muito difundido, é usado em todos os lugares em vários sites e pode ser conectado para logins primário e secundário. Mas o aplicativo não se limita a isso - os desenvolvedores anexam uma confirmação sobre a funcionalidade de recuperação de senha, confirmação de registro / assinatura, confirmação adicional de transações financeiras, alteração de senha e alteração de dados pessoais. Ocasionalmente, o 2FA é usado como uma parede após o logout para cronometrar, e não como uma senha ou outra forma de confirmação.
Neste artigo, coletei maneiras de testar o 2FA quanto a vulnerabilidades, sua exploração e também as opções possíveis para contornar a proteção existente contra certos tipos de ataques. Vejamos a lista de verificações de vulnerabilidade que se aplicam ao 2FA:
1. Falta de limite de taxa
O algoritmo de limite de taxa é usado para testar se uma sessão do usuário (ou endereço IP) pode ser limitada em tentativas ou velocidade e sob quais circunstâncias isso acontece. Se o usuário tiver concluído muitas solicitações dentro de um certo período de tempo, o aplicativo Web poderá responder com um código 429 (muitas solicitações) ou aplicar um limite de Taxa sem mostrar erros. A ausência de um limite de taxa implica que, durante a enumeração normal, não há restrições quanto ao número de tentativas e / ou velocidade - é permitido iterar sobre os códigos várias vezes (a qualquer velocidade) dentro do período de validade da sessão / token.
Muitas vezes, é necessário lidar com um limite de taxa "silencioso"; se você perceber que não há erros e o corpo / código HTTP não mudar nas solicitações subseqüentes, fique feliz cedo demais e primeiro verifique o resultado final do ataque usando código válido.
2. O limite da taxa existe, mas pode ser contornado
Casos que eu tive que conhecer antes:
1) Limitar a velocidade dos fluxos sem obstrução após atingir uma determinada velocidade
Muitas vezes, os pesquisadores de segurança tentam pegar o código usando 5 ou mais threads para acelerar um ataque (no Burp Intruder, o número padrão de threads é 5 sem demora). Às vezes, porém, um sistema de segurança contra interrupção ou um Load Balancer regular só pode responder a esse único fator. Se você estiver tentando fazer força bruta com 5 threads, reduza o número para 1 e depois para 1 com um atraso de um segundo. Antes, tive a sorte de observar esse comportamento e foi com a ajuda de tais manipulações que ocorreu a seleção bem-sucedida do código, que levou à aquisição da conta. Se o código 2FA não tiver uma data de validade específica, teremos muito tempo para resolver. Se o período de validade estiver presente, o sucesso do ataque será reduzido, mas o perigo potencial de vulnerabilidade ainda estará presente, pois ainda há uma chance de entrar no código desejado.
2) O código OTP gerado não muda
Isso não se aplica a códigos que mudam constantemente, como no Google Authenticator, mas apenas aos códigos estáticos que vêm em SMS, email ou pessoalmente via messenger.
A essência desse desvio é que o mesmo código OTP é enviado constantemente ou por algum tempo, por exemplo, 5 minutos, o que é válido durante todo esse tempo. Também vale a pena garantir que nenhum limite de taxa silencioso ocorra.
Exemplo de relatório:
hackerone.com/reports/420163Suponha que o aplicativo gere um código aleatório de 001 a 999 e o envie ao telefone, dentro de 10 minutos quando a funcionalidade "enviar novamente" estiver ativada, obteremos o mesmo código. Mas o limite de taxa está vinculado à solicitação, o que limita o número de tentativas por token de solicitação. Podemos solicitar constantemente um novo código, gerar um novo token de solicitação, aplicá-lo a uma solicitação subsequente (usando grep-match em um conjunto de arrotos ou usando nosso próprio script) e executar força bruta de um intervalo de números de 001 a 999. Portanto, constantemente, use um novo token de solicitação selecionaremos com êxito o código correto, pois ele não muda e é estático por um determinado período de tempo. As limitações deste ataque são um número longo ou misturar letras com números como código de confirmação.
Essa situação não deve ser incentivada; você deve tentar separar pelo menos parte de nossa lista, porque existe a possibilidade de o código gerado estar nesta parte da lista, uma vez que é gerado aleatoriamente. Ao tentar, você precisa confiar no acaso, mas ainda existe a chance de entrar na combinação certa, o que prova uma vulnerabilidade que definitivamente precisa ser corrigida.
3) Redefina a taxa-limite-a ao atualizar o código.
Na solicitação de verificação de código, o limite de taxa está presente, mas após ativar a função de reenviar o código, ele é redefinido e permite continuar o código de força bruta.
Exemplos de relatórios:
https://hackerone.com/reports/149598 , - teoria;
hackerone.com/reports/205000 , uma exploração prática baseada em um relatório anterior.
4) Ignorando o limite de taxa alterando o endereço IP
Muitos bloqueios são baseados na restrição de recebimento de solicitações do IP, que atingiu o limite de um certo número de tentativas ao executar uma solicitação. Se o endereço IP for alterado, haverá a oportunidade de contornar essa restrição. Para verificar esse método, basta alterar seu IP usando o servidor proxy / VPN e verificar se o bloqueio depende do IP.
Maneiras de mudar o IP:
- Os proxies podem ser usados em um ataque usando o complemento IP Rotator do Burp Suite github.com/RhinoSecurityLabs/IPRotate_Burp_Extension . Na minha opinião, essa é a melhor escolha, pois nos oferece ~ tentativas ilimitadas de força bruta e endereços IP que permitem executar um ataque de força bruta sem erros e interrupções de 42x.
- Uma boa opção pode ser um script python com um módulo de solicitações de proxy, mas primeiro você precisa obter um grande número de proxies válidos em algum lugar.
Como a ferramenta de rotação de IP envia solicitações usando os endereços IP da AWS, todas as solicitações serão bloqueadas se o aplicativo Web estiver atrás do firewall CloudFlare.
Nesse caso, você precisa descobrir adicionalmente o IP do servidor da Web original ou encontrar um método que não se refira aos endereços IP da AWS.
5) O site inclui suporte para X-Forwarded-For
O cabeçalho X-Forwarded-For embutido pode ser usado para alterar o IP. Se o aplicativo tiver processamento interno para esse cabeçalho, envie X-Forwarded-For: desejado_IP para substituir o IP para ignorar a restrição sem o uso de proxies adicionais. Toda vez que uma solicitação é enviada pelo X-Forwarded-For, o servidor da Web pensa que nosso endereço IP corresponde ao valor transmitido pelo cabeçalho.
Materiais sobre este tópico:
hackerone.com/reports/225897medium.com/@arbazhussain/bypassing-rate-limit-protection-by-spoofing-originating-ip-ff06adf341573. Ignore 2fa substituindo parte da solicitação de uma sessão de outra conta
Se um parâmetro com um valor específico for enviado para verificar o código na solicitação, tente enviar o valor da solicitação para outra conta.
Por exemplo, ao enviar um código OTP, é verificado o ID do formulário, o ID do usuário ou o cookie associado ao envio do código. Se aplicarmos os dados dos parâmetros da conta na qual você deseja ignorar a verificação de código (Conta 1) a uma sessão de uma conta completamente diferente (Conta 2), obteremos o código e o inseriremos na segunda conta, então podemos ignorar a proteção na primeira conta. Depois de recarregar a página 2FA deve desaparecer.
4. Ignore o 2FA usando a "funcionalidade de memorização"
Muitos sites que oferecem suporte à autorização 2FA têm a funcionalidade "lembre-se de mim". É útil quando o usuário não deseja inserir um código 2FA nos logins subseqüentes. É importante identificar como o 2FA é "lembrado". Pode ser um cookie, um valor na sessão / armazenamento local ou apenas anexar 2FA a um endereço IP.
1) Se o 2FA for anexado usando um cookie, o valor do cookie deverá ser inquestionável
Ou seja, se um cookie consiste em um conjunto de números que aumentam para cada conta, é bem possível aplicar um ataque de força bruta ao valor do cookie e ignorar o 2FA. Os desenvolvedores devem fornecer ao cookie (junto com o cookie da sessão principal e o token CSRF) o atributo HttpOnly, para que não possa ser roubado usando o XSS e usado para ignorar o 2FA.
2) Se 2FA estiver anexado ao endereço IP, você poderá tentar substituí-lo
Para identificar esse método, faça login na sua conta usando a função de armazenamento 2FA, depois mude para outro navegador ou modo de navegação anônima do navegador atual e tente fazer login novamente. Se o 2FA não for solicitado, o 2FA foi anexado ao endereço IP.
Para substituir o endereço IP, você pode usar o cabeçalho X-Forwarded-For no estágio de digitar o login e a senha, se o aplicativo da Web suportar.
Usando esse cabeçalho, você também pode ignorar a função da lista branca de endereços IP, se houver alguma nas configurações da conta. Ele pode ser usado em conjunto com o 2FA como proteção adicional da conta ou o 2FA pode nem ser solicitado se o endereço IP corresponder à lista branca (com o consentimento do usuário). Assim, mesmo sem conectar o 2FA ao endereço IP, em alguns casos, o 2FA pode ser contornado, contornando os métodos de proteção associados.
Em geral, anexar 2FA a um endereço IP não é uma maneira totalmente segura de proteção, porque quando você está presente na mesma rede, quando conectado ao mesmo provedor de serviços de Internet / VPN com um endereço IP estático, o 2FA pode ser ignorado.
A maneira mais segura de se proteger é não se lembrar do 2FA em detrimento da usabilidade.
5. Erro de controle de acesso inadequado na página de entrada 2FA
Às vezes, uma página de diálogo para inserir 2FA é apresentada como uma URL com parâmetros. O acesso a uma página com parâmetros no URL com cookies que não correspondem aos usados para gerar a página ou sem cookies não é seguro. Mas se os desenvolvedores decidiram aceitar os riscos, você precisa passar por vários pontos importantes:
- O link expira para a entrada 2FA?
- se o link está indexado nos mecanismos de pesquisa.
Se o link tiver uma vida útil longa e / ou os mecanismos de pesquisa contiverem links funcionais para entrada 2FA / os links puderem ser indexados (não há regras nas robots.txt / meta tags), é possível usar um mecanismo de desvio 2FA na página de entrada 2FA, na qual ignore completamente o login e a senha e obtenha acesso à conta de outra pessoa.
6. Censura inadequada de dados pessoais na página 2FA
Ao enviar um código OTP em uma página, a censura é usada para proteger dados pessoais, como email, número de telefone, apelido etc. Mas esses dados podem ser totalmente divulgados nos pontos de extremidade da API e em outras solicitações para as quais temos direitos suficientes no estágio 2FA. Se inicialmente esses dados não eram conhecidos, por exemplo, inserimos apenas um logon sem saber o número de telefone, isso é considerado a vulnerabilidade de divulgação de informações. Saber o número de telefone / email pode ser usado para ataques subsequentes de phishing e força bruta.
Um exemplo de exploração de uma vulnerabilidade usando o preenchimento de credenciais. Digamos que exista um banco de dados no domínio público com logins e senhas para o site A. Os invasores podem usar os dados desse banco de dados no site B:
- Primeiro, eles verificam se o usuário existe no banco de dados do site B usando o erro "Enumeração de contas" ao registrar / recuperar a senha. Normalmente, muitos sites não consideram isso uma vulnerabilidade e assumem riscos. "Vulnerabilidade" está na presença de um erro sobre o fato do registro do usuário no site. Idealmente, uma mensagem segura na página de recuperação de senha é a seguinte:
- Depois de obter o banco de dados de usuários existentes, os atacantes aplicam senhas a essas contas.
- Se eles encontrarem 2FA, eles ficarão presos. Porém, no caso de censura insuficiente dos dados do usuário, eles podem complementar seu banco de dados com seus dados pessoais (se não estiverem no banco de dados original).
7. Ignorando 2FA em determinadas circunstâncias
Ao executar algumas ações que levam ao login automático em sua conta, o 2FA pode não ser solicitado.
1) Ignore 2FA ao recuperar uma senha
Muitos serviços efetuam login automaticamente em sua conta após concluir o procedimento de recuperação de senha. Como o acesso à conta é fornecido instantaneamente, quando você faz login na sua conta 2FA, ela pode ser ignorada e completamente ignorada.
Impacto de um relatório semelhante de hacker que enviei recentemente:
Se um invasor obtém acesso ao e-mail da vítima (ele pode invadir a conta usando phishing, ataques de força bruta, preenchimento de credenciais etc.), ele pode ignorar o 2FA, embora nesse caso o 2FA deva proteger a conta. No momento, para o 2FA, há uma verificação do código do Google Authenticator ou do código de backup, mas não do código do e-mail. Portanto, esse desvio faz sentido.
2) Ignorando 2FA ao fazer login através de uma rede social
Você pode conectar uma rede social à sua conta de usuário para fazer login rapidamente na sua conta e, ao mesmo tempo, configurar o 2FA. Quando você faz login na sua conta através das redes sociais, o 2FA pode ser ignorado. Se o email da vítima for invadido, será possível recuperar a senha da conta da rede social (se isso permitir) e entrar no serviço sem inserir 2FA.
Impacto de um dos relatórios:
- Muitas outras vulnerabilidades, como a configuração incorreta do OAuth enviada anteriormente # 577468, para capturar completamente a conta, quebrando o 2FA.
- Se um invasor invadir o email do usuário, ele poderá tentar recuperar o acesso à conta da rede social e fazer login na conta sem verificação adicional.
- Se um invasor invadir uma conta da vítima, ele poderá associar uma rede social à conta e efetuar login no futuro, ignorando completamente o 2FA e inserindo o login / senha.
3) Ignorando 2FA em uma versão mais antiga do aplicativo
Os desenvolvedores geralmente adicionam versões intermediárias de um aplicativo Web a domínios / subdomínios para testar determinadas funções. Curiosamente, se você fizer login usando seu nome de usuário e senha, o 2FA não será solicitado. Talvez os desenvolvedores estejam usando uma versão mais antiga do aplicativo, na qual não há proteção para o 2FA, o próprio 2FA está desabilitado ou foi intencionalmente desabilitado para teste.
Além disso, você pode verificar outras vulnerabilidades ao mesmo tempo, - registrar um novo usuário em um servidor intermediário cujo email existe no banco de dados da versão de produção pode nos fornecer dados pessoais da produção; a ausência de um limite de taxa em funcionalidades importantes, por exemplo, recuperação de senha. Um exemplo da vulnerabilidade mais recente é um bug no Facebook de US $ 15.000, que permitiu invadir uma conta usando o código de recuperação de senha bruteforce em beta.facebook.com
www.freecodecamp.org/news/responsible-disclosure-how-i-could-have-hacked-all- contas-facebook-f47c0252ae4d .
4) Ignorando 2FA em caso de plataforma cruzada
As implementações 2FA na versão móvel ou para computador podem diferir da versão web do aplicativo. 2FA pode ser mais fraco que na versão web ou completamente ausente.
7. Ao desativar o 2FA, o código atual não é solicitado.
Se, ao desativar o 2FA, uma confirmação adicional não for solicitada, como o código atual do aplicativo autenticador do google, o código do email / telefone, nesse caso, haverá certos riscos. Com uma solicitação limpa, há uma chance de um ataque CSRF. Se for encontrado um vetor de desvio da proteção CSRF (se houver), o 2FA poderá ser desativado. Uma vulnerabilidade de clickjacking também pode ser usada - após alguns cliques de um usuário inocente, o 2FA será desconectado. A validação do código anterior adicionará proteção 2FA adicional, dados possíveis ataques de CSRF / XSS / Clickjacking, bem como configurações incorretas do CORS.
Vou dar um exemplo de hackerone.com: quando você desativa o 2FA em um formulário, é necessário inserir duas variáveis ao mesmo tempo, o código atual com o aplicativo e a senha do autenticador do Google. Esta é a melhor e recomendada proteção.
8. As sessões criadas anteriormente permanecem válidas após a ativação do 2FA
Quando o 2FA está ativado, é desejável que as sessões paralelas na mesma conta terminem e o diálogo de entrada 2FA seja exibido, o mesmo com uma alteração de senha. Se a conta foi comprometida e a primeira reação da vítima for a inclusão do 2FA, a sessão do invasor será desativada e o próximo login e senha exigirão o 2FA. Em suma, esta é a melhor prática a ser seguida. Costumo notar como as trocas de criptomoedas adicionam proteção semelhante. Exemplo de relatório do HackerOne, -
https://hackerone.com/reports/534450.
9. A ausência de um limite de taxa na sua conta
O 2FA pode ser implementado em várias funções da conta pessoal do usuário para maior segurança. Pode ser uma alteração de endereço de email, senha, confirmação de uma alteração de código para transações financeiras, etc. A presença do limite de taxa-a na sua conta pode diferir da presença do limite de taxa-a no 2FA ao entrar na sua conta. Muitas vezes me deparei com casos semelhantes quando era possível selecionar livremente um código 2FA na minha conta, enquanto na entrada um limite de taxa "Estrito" era definido.
Se os desenvolvedores inicialmente adicionaram proteção contra alterações de dados não autorizadas, essa proteção deve ser suportada e corrigida por todos os desvios possíveis. Se o desvio for encontrado, isso será considerado uma vulnerabilidade de desvio do recurso de segurança que foi implementada pelos desenvolvedores.
10. versionamento de API
Se você vir algo como / v * / na solicitação do aplicativo Web, em que * é um número, é provável que você possa mudar para uma versão mais antiga da API.
Na versão antiga da API, pode haver uma proteção fraca ou pode não existir. Essa é uma ocorrência bastante rara e ocorre se os desenvolvedores esquecerem de remover a versão antiga da API no ambiente de produção / armazenamento temporário.Por exemplo, / endpoint / api / v4 / login executa uma solicitação de login, verificando o nome de usuário e a senha. Se 2FA estiver presente na conta, essa solicitação deverá ser seguida por / endpoint / api / v4 / 2fa_check, nada mais. Se substituirmos a versão da API antes do 2FA, em alguns casos, podemos evitá-la. / endpoint / api / v3 / login pode levar a / endpoint / v3 / login_successful? code = RANDOM, ignorando 2fa_check porque nesta versão da API, o 2FA simplesmente não foi implementado.Outro exemplo - no request / endpoint / api / v4 / 2fa_check, há um limite de taxa, enquanto / endpoint / api / v3 / 2fa_check permite a iteração de códigos sem nenhuma restrição.11. Controle de acesso inadequado ao solicitar códigos de backup
Os códigos de backup são gerados imediatamente após a ativação do 2FA e estão disponíveis em uma única solicitação. Após cada chamada subsequente à solicitação, os códigos podem ser gerados por uma nova ou permanecer inalterados (códigos estáticos). Se houver vulnerabilidades de configuração incorreta / XSS do CORS e outros bugs que permitem "extrair" os códigos de backup da solicitação de resposta para o terminal de exibição do código de backup, o invasor poderá roubar os códigos e ignorar o 2FA se o nome de usuário e a senha forem conhecidos.Em geral, o 2fa é uma das maneiras mais confiáveis de proteger sua conta, a menos que, é claro, os desenvolvedores armazenem os códigos 2FA atuais de todos os usuários do aplicativo Web no painel de administração - e isso aconteceu na minha prática. Também gostaria de observar que os desenvolvedores de algumas empresas criam aplicativos para gerar seus próprios códigos 2FA (exemplos são Salesforce, Valve) e, devido à segurança insuficiente, essa ênfase na independência do uso de outros aplicativos de autenticação oferece aos atacantes um ponto de entrada adicional para ignorar o 2FA. O alcance da aplicação dessa proteção é bastante amplo e oferece aos que desejam ignorar a proteção 2FA mais oportunidades, espaço para criatividade e aumentam o número de variações dos desvios 2FA.Espero que essas informações sejam úteis para pesquisadores de segurança da informação, caçadores de bugs e para que os desenvolvedores minimizem o número de vulnerabilidades no serviço que está sendo desenvolvido. Fique seguro!