Credential stuffing

O que é credential stuffing

Credential stuffing é o teste automatizado de combinações de usuário e senha que já vazaram em um serviço, contra os acessos de um serviço diferente, até encontrar as que funcionam.

A premissa que o sustenta é de comportamento, não técnica: muita gente reutiliza a mesma senha em vários sites. O atacante não precisa quebrar nada. Precisa de uma lista e de paciência.

O detalhe que muda toda a análise é este: as credenciais testadas são válidas em algum lugar. Isso separa esse ataque de qualquer tentativa de adivinhação e define como ele é detectado.

Não é força bruta, e a diferença decide a detecção

Os dois ataques parecem iguais em um painel e se comportam ao contrário. Confundi-los é a razão mais frequente pela qual uma equipe acredita estar coberta e não está.

• Força bruta — o atacante não sabe a senha e a procura. Muitas tentativas contra a mesma conta, taxa de acerto muito baixa. Deixa um rastro evidente: uma conta com dezenas de falhas seguidas.
• Credential stuffing — o atacante já tem a senha e procura onde ela funciona. Uma ou duas tentativas por conta, distribuídas por centenas de milhares de contas diferentes, com uma taxa de acerto comparativamente alta.

Daí sai a consequência prática. Um bloqueio após cinco tentativas falhas por conta é um controle desenhado contra a força bruta. Diante de um ataque que faz uma tentativa por conta, esse limite nunca é atingido, em nenhuma conta, e o painel de segurança não mostra nada estranho.

O sinal existe, mas não está onde se procura. Não aparece em uma conta: aparece no agregado. Um volume de tentativas de acesso muito acima do normal, com uma proporção de falhas também anômala, distribuído por contas sem relação entre si. Olhando conta por conta, é invisível. Olhando o total da hora, salta aos olhos.

Como o ataque acontece, passo a passo

A sequência está industrializada e quase nenhum dos seus passos exige habilidade técnica particular.

1. Conseguir a lista. Combinações de e-mail e senha provenientes de vazamentos acumulados de outros serviços. Circulam agregadas, consolidadas e ordenadas, e as maiores são compilações de muitos vazamentos anteriores.
2. Escolher o alvo e estudar seu acesso. Como o formulário responde, se distingue entre usuário inexistente e senha incorreta, que mensagens devolve. Essa diferença de respostas é informação que o atacante usa.
3. Distribuir a origem. Proxies residenciais, rotação de endereços, variação da impressão digital do navegador e do cliente. O objetivo é que nenhuma origem concentre tentativas suficientes para chamar a atenção.
4. Testar uma ou duas combinações por conta. Nunca mais que isso. O limite é deliberado: mantém cada conta abaixo de qualquer limiar de bloqueio.
5. Separar as que funcionam. O resultado é uma lista curta de credenciais confirmadas nesse serviço, muito mais valiosa que a lista original.
6. Usá-las ou vendê-las. O uso direto é um account takeover. A venda transfere a exploração para outro ator, às vezes meses depois, o que separa o ataque da sua consequência e complica a investigação.

O passo 4 é o que torna inútil o controle padrão. Todo o resto é escala.

Onde aparece em uma jornada de identidade

O credential stuffing atinge o acesso, não o cadastro. Aparece onde há uma senha para validar.

• Login de usuários existentes — o alvo direto, e o caminho para um account takeover.
• Recuperação de acesso — os mesmos dados vazados alimentam as respostas de segurança e os dados de contato que um fluxo de recuperação pede.
• Interfaces de acesso menos vigiadas — aplicações antigas e pontos de entrada que ficaram fora das regras do canal principal.

Nenhum desses momentos envolve verificação de identidade. O credential stuffing não ataca a comprovação de quem é uma pessoa: ataca o que a organização aceitou como substituto dessa comprovação.

O serviço atacado nunca foi invadido

Vale dizer explicitamente porque muda a conversa interna depois de um incidente: quando o credential stuffing dá certo, o sistema atacado não teve nenhuma falha de segurança. Não houve intrusão, não houve vulnerabilidade explorada e não houve vazamento de dados próprio.

O que aconteceu é que uma pessoa usou sua senha em dois lugares e um dos dois foi comprometido. O serviço que recebe o ataque herda o risco de um serviço com o qual não tem relação.

Isso tem duas consequências. A primeira é que endurecer a política de senhas própria, exigindo mais caracteres ou rotação periódica, não cobre esse ataque: a senha vazada já cumpre essa política. A segunda é que o único controle que ataca a causa é deixar de depender de um segredo que a pessoa pode reutilizar.

Quem é afetado e quanto custa

O ataque mira qualquer serviço com acesso por usuário e senha, e o valor do alvo define se o atacante o testa.

• Varejo e comércio eletrônico — contas com meios de pagamento salvos e com programas de pontos, que são os alvos mais frequentes porque o saldo quase nunca é olhado.
• Apostas e gaming — contas com fundos e com verificação de identidade já realizada, o que as torna reutilizáveis para outras fraudes.
• Serviços financeiros — menos expostos ao acesso direto por terem duplo fator, mas igualmente afetados pelo custo da avalanche de tentativas.
• Serviços de assinatura e conteúdo — revenda de acessos, que é uma fraude de baixo valor unitário e volume alto.

Há um custo que aparece antes de qualquer fraude e costuma ser o primeiro a ser notado: a infraestrutura. Um ataque com esse formato gera um pico de tentativas de acesso que degrada o desempenho, dispara alertas, satura registros e às vezes afeta usuários legítimos por medidas de contenção aplicadas às pressas.

Quais controles o detêm

A defesa se divide entre a camada de rede, a camada de acesso e o desenho da credencial. Os três trechos são comprados em lugares diferentes.

• Limitação de taxa por origem e por grupo de origem — não por conta, que é onde o ataque se esconde. É implementada na borda, na rede de distribuição de conteúdo ou no firewall de aplicação. Um provedor de identidade não a fornece.
• Gestão de bots — análise da impressão digital do cliente, detecção de automação e desafios progressivos. É uma categoria de produto própria, com fabricantes especializados.
• Detecção de anomalias no agregado — vigiar a proporção de acessos bem-sucedidos sobre o total e a curva de tentativas por hora, em vez de olhar conta por conta. É o controle que torna visível o que o limite não vê, e muitas vezes é trabalho de analytics interno, não de um produto comprado.
• Comparação com bases de credenciais vazadas — rejeitar no cadastro e na troca de senha qualquer chave que conste em vazamentos conhecidos. Existem serviços públicos e comerciais que expõem essa comparação sem receber a senha em claro. É a medida com a melhor relação entre custo e efeito, e um provedor de biometria não a vende.
• Respostas uniformes no formulário de acesso — que o sistema não distinga entre usuário inexistente e senha incorreta, nem na mensagem nem no tempo de resposta. Tira do atacante a informação do passo 2.
• Segundo fator que não se pode ditar — transforma uma credencial válida em insuficiente. Um fator que a pessoa pode ler e ditar continua vulnerável ao phishing, mas contra credential stuffing qualquer segundo fator já é uma barreira real, porque o ataque é automatizado e não tem a quem pedir o código.
• Sinais de dispositivo e de sessão — dispositivo nunca visto, geolocalização incoerente, sequência de navegação impossível para uma pessoa.
• Escalonamento na operação sensível — voltar a pedir presença no momento da transferência ou do resgate, não só no acesso.
• Eliminar a senha — um acesso sem senha não tem nada a preencher. É o único controle que ataca a causa em vez da consequência.

Os dois controles de maior efeito imediato, a limitação de taxa na borda e a gestão de bots, são comprados de fabricantes de infraestrutura e de segurança web. Uma equipe que espere resolver credential stuffing com seu provedor de identidade vai cobrir o trecho posterior ao acesso, não o pico de tráfego que o precede.

Como a VU aborda isso

A VU trabalha sobre a credencial e sobre o que acontece depois do acesso. A camada de rede é coberta por outro tipo de fabricante.

O Autentica suporta autenticação sem senha com sete fatores disponíveis: rosto, TOTP, OTP por SMS, OTP por e-mail, link mágico, senha e documento de identidade. Um acesso que não usa senha deixa sem objeto uma lista de senhas vazadas, que é a definição do ataque.

Onde a senha se mantém, o segundo fator é o que impede que uma credencial válida seja suficiente. Contra um ataque automatizado, até os fatores mais fracos diante do phishing funcionam, porque não há uma pessoa do outro lado a quem pedir o código.

O Protege contra a fraude avalia sinais de risco sobre o dispositivo e a sessão, que é o que separa um acesso com credenciais corretas feito pelo titular de um feito por quem as comprou.