Um endpoint de envio de OTP é um exemplo típico de um serviço web que não é comumente listado em uma “lista dos 10 principais vulnerabilidades web”, mas que sem dúvida custou muito mais às empresas do que elas admitiram publicamente, alguém descobre seu endpoint de envio de OTP, escreve um script simples e bombardeia seu endpoint de OTP para ligar para números de tarifa premium ou aleatórios durante a noite. O tipo de fraude mostrada neste exemplo é Fraudulento de Bombeamento de SMS (ou Fraude de Tarifas). A perda neste exemplo não é uma perda técnica, é uma perda financeira direta na sua fatura.
Este artigo descreve os detalhes por trás dessa fraude e como ela é realmente mitigada além da sugestão usual de “limitação de taxa”, que todo documento descreve, mas não explica em detalhes.
Como funciona
Endpoints utilizados para “enviar códigos de verificação” geralmente requerem uma requisição HTTP pública e, por isso, tornam-se um alvo natural para atacantes, já que construir a requisição não exige autenticação ou desafio complexo.
Com esse endpoint, um atacante faria chamadas inúmeras vezes, com o campo de número definido para vários valores. O campo de número poderia ser um número completamente aleatório ou um número de tarifa premium que o atacante selecionou, e o atacante receberia uma fração do custo gerado por essa chamada. Os custos se tornariam significativos para o gateway do serviço, e não seriam notados até que a fatura chegasse e os custos já tivessem sido incorridos.
Por que a "limitação de IP" sozinha não resolve
A resposta mais simples — limitar requisições por IP — resolve apenas parte do problema devido às seguintes razões:
Ataques distribuídos usam proxies ou pools de IPs rotativos. Assim, limites por IPs não ajudarão nos vetores de ataque.
Um IP legítimo (como uma rede corporativa ou NAT móvel) pode gerar requisições de muitos usuários legítimos. Portanto, uma política agressiva de limitação de taxa pode afetar negativamente muitos usuários legítimos.
Múltiplas camadas devem ser empregadas em combinação ao abordar esses tipos de problemas, ao invés de uma única camada.
1. Limitação de taxa por número de destino além do IP de origem.
Enviar múltiplas requisições de verificação para um único número de telefone dentro de um período curto deve ser considerado suspeito, independentemente do número de IPs de onde as requisições vierem.
2. Verificação de requisições
Bloquear ou marcar requisições para números de tarifa premium conhecidos ajuda a reduzir o impacto financeiro das requisições de verificação.
3. Verificação de requisições
Embora bots sofisticados possam contornar tais defesas, elas são eficazes contra muitos dos bots mais simples que compõem a maior parte dos ataques.
4. Monitoramento de orçamento e alertas por gateway.
Um alerta deve ser acionado quando um número incomumente grande de requisições for enviado.
Como isso muda o design do ambiente de testes
Uma consequência indesejada do ataque é que as equipes frequentemente reagem bloqueando endpoints de tantas formas que o QA não consegue testar fluxos de verificação a menos que removam manualmente as proteções. Isso é contraproducente, pois cria um “modo de depuração” não intencional dentro do ambiente de produção, o que é igualmente perigoso.
Semelhante ao exemplo anterior, a separação é benéfica aqui. Utilizar linhas de teste dedicadas evita esse problema. Usamos NumeroVirtual para esse propósito. Ele ajuda a validar todo o fluxo em uma linha separada, enquanto impede a proteção anti-abuso na linha de produção.
Conclusão
Fraude de bombeamento de SMS não se encaixa no molde de um bug clássico de segurança. É realmente uma questão de design e só pode ser detectada na intersecção de uma autenticação cara e um dispêndio financeiro. Os mecanismos de desafio e resposta, combinados com alertas de orçamento, realmente ajudam a conter a fraude, mesmo que na consequência de eliminar todas as tentativas.
Alguém mais já passou por algo assim? Que tipo de proteção vocês acabaram implementando? Geralmente é o primeiro incidente importante que impulsiona a priorização das proteções no roadmap.
Top comments (0)