Com o Twitter desativando a autenticação de dois fatores para mensagens de texto, achei que seria divertido mergulhar fundo em como a fraude por SMS funciona e como os desenvolvedores de aplicativos podem se proteger contra ela.
É uma história fascinante de incentivos perversos, regulamentação míope e engenhosidade técnica.
Vamos cavar! 👇
Para começar, vamos recapitular o recente anúncio do Twitter:
Em inglês simples, isso significa simplesmente que apenas os usuários da versão paga do Twitter receberão um código enviado para o telefone durante o login.
A chave para entender a fraude de SMS é entender que alguns números são premium . Se você quiser ligar ou enviar um SMS para esse número, isso custará algum dinheiro - geralmente dezenas de centavos - e o proprietário do número recebe uma parte dessas dezenas de centavos para si.
Os proprietários desses números de telefone normalmente oferecem serviços legítimos que custam dinheiro para fornecer e oferecem valor a seus usuários, como televotação, namoro e suporte técnico.
No entanto, esses números podem ser jogados para lucro fácil 🤑
Um mau ator, vamos chamá-lo de Bob , consegue vários números de telefone premium[1]. Bob pode ser um hacker ou um operador de rede de telefonia móvel que deu errado.
Bob encontra um serviço da web que enviará mensagens de texto para seus números de telefone premium. Essas mensagens podem ser códigos de autenticação de dois fatores, senhas únicas ou qualquer outra mensagem de texto enviada ao usuário como parte do serviço (por exemplo, partiful.com envia lembretes de eventos via SMS).
Bob encontra uma maneira de fazer com que o serviço envie milhares de SMSs para seus números de telefone premium. Isso pode ser muito fácil. O serviço de front-end pode ser fácil de manipular e os endpoints de back-end podem estar desprotegidos e fáceis de fazer engenharia reversa.
Pior ainda, muitos serviços usam um endpoint padronizado para enviar SMSs. Isso torna muito mais fácil para Bob encontrar sites para atacar. Por exemplo, se o serviço usa um terceiro para autenticar usuários e enviar códigos 2FA ou OTP, como Auth0, então o endpoint para enviar SMSs é mais conhecido: tudo o que Bob precisa fazer é descobrir uma maneira de descobrir os Auth0s ID para um serviço da web (bastante fácil, já que o front-end do serviço da web faz uma solicitação contendo esse ID) e, em seguida, eles podem atacar todos os sites que usam esse serviço de terceiros.
Por fim, Bob faz com que o serviço envie milhares de SMSs para seus números de telefone premium. O serviço da web perde 💵💵💵 e Bob lucra.
Não há uma bala de prata para evitar fraudes por SMS. Mas aqui estão algumas ideias que podem funcionar:
Se estiver usando um serviço de terceiros para autenticar usuários, como Auth0, você pode ofuscar o endpoint usado para enviar SMSs. Embora isso não impeça um ataque de imediato, torna muito mais difícil descobrir que um ataque é possível.
Semelhante a como um ladrão de bicicletas visa as bicicletas mais fáceis de roubar, um bom hacker passaria para os serviços da web que são mais fáceis de hackear. Meu palpite é que essa abordagem funcionaria bem o suficiente para a longa cauda de aplicativos.
Bloqueie todas as solicitações de IPs originados em provedores de nuvem, ISPs fraudulentos ou que sejam incompletos. Isso deve ser bastante simples de implementar - existem muitos serviços que permitem avaliar a qualidade de um endereço IP - e provavelmente seria muito eficaz.
Adicione limitação de taxa baseada em IP ao endpoint que envia SMS para bloquear o ataque de Bob. Se configurado corretamente, isso não afetará usuários legítimos. No entanto, isso só funciona contra um ataque simples. Se Bob arquitetar seu ataque para enviar solicitações de vários endereços IP — um ataque distribuído —, isso não funcionaria.
Envie um SMS para um número de telefone específico apenas um pequeno número de vezes antes de bloquear esse número de telefone por um período de espera. Poderíamos fazer isso no front-end, mas se Bob estiver determinado, ele pode descobrir o endpoint de back-end para atacar. Bloquear o número de telefone no back-end é mais difícil: requer manter um registro dos números de telefone e suas tentativas de login recentes[2].
Força o usuário a resolver um CAPTCHA antes de enviar um SMS. Embora essa abordagem funcione bem para bloquear invasores — resolver o CAPTCHA é difícil e caro em grande escala —, ela prejudica a experiência do usuário com o serviço.
Identifique e bloqueie números de telefone de tarifa premium , usando libphonenumber . Embora isso pareça promissor, não sei quão confiáveis são os dados e quão eficaz é essa abordagem.
Envie mensagens de texto apenas para contas pagas. Essa é a abordagem que o Twitter adotou. Não é uma opção ruim, mas como você pode ver na lista acima, há muitas outras abordagens que você pode adotar.
Bloqueie operadoras de rede de telefonia móvel com um alto número de usuários fraudulentos. Isso bloquearia operadoras de rede claramente ruins, mas não funcionaria bem se a rede tivesse muitos usuários legítimos.
Use o WhatsApp para enviar mensagens. O WhatsApp é gratuito ao contrário do SMS, mas nem todos os usuários do mundo usam o WhatsApp[3].
Uma boa solução faria uso suficiente das abordagens acima, priorizando o investimento de tempo e a eficácia, até que os invasores se movessem para alvos mais fáceis.
Tenho alguma experiência pessoal na implementação das medidas acima e tenho uma ou duas histórias para compartilhar sobre como minha equipe lidou com as consequências. Mas isso é história para outra hora… 👨💻
Isso me leva ao meu ponto final:
IMO, Twilio - uma API de SMS dominante - tem uma grande oportunidade de oferecer proteção contra fraude por SMS como um complemento (gratuito? 🙏) para suas APIs padrão.
Como o Twilio possui dados sobre números de telefone e operadoras fraudulentos em todas as suas contas, o Twilio está em uma posição única para bloquear rapidamente números e operadoras ruins - antes que se tornem um grande problema para vários serviços da web.
O Twilio pode até mesmo detectar números de telefone inválidos usando o Silent Network Auth - um mecanismo de autenticação de última geração - e parece que esse utilitário deve ser compartilhado entre seus usuários.
Eu adoraria ouvir quaisquer outros pensamentos, ideias e abordagens que as pessoas usaram - por favor, compartilhe escrevendo um comentário abaixo, e todos nós podemos aprender.
Por enquanto é isso — proteja esses endpoints e tenha uma ótima semana!
Há uma excelente discussão no HackerNews.
[1] Observe que esses números de telefone premium nem precisam funcionar: eles não precisam estar conectados a um cartão SIM que esteja funcionando e registrado em um telefone. Desde que possam ser encaminhados, eles podem ser usados neste ataque.
[2] Estou curioso para saber se há uma boa estrutura de dados e algoritmo para tornar isso eficiente e funcionar em escala. Por favor, compartilhe se você souber de um!
[3] Crédito para @csharpminor no HN por sua sugestão .
Sou Apu , CTO da koodos e engenheiro.
Este post apareceu originalmente no meu blog pessoal - inscreva-se para mais como ele!