SMS para autenticação em duas etapas: um método de segurança pior do que parece

 (ccc.de)
2 pontos por GN⁺ 2024-07-12 | 1 comentários | Compartilhar no WhatsApp
  • O CCC conseguiu visualizar senhas de uso único por SMS em tempo real por meio da exposição da IdentifyMobile, num caso em que mais de 198 milhões de SMS de mais de 200 empresas foram vazados
  • O 2FA por SMS é um mecanismo auxiliar para impedir abusos quando apenas a senha foi roubada, mas a segurança real também depende fortemente do nível de gestão dos prestadores de envio de SMS
  • A IdentifyMobile expôs códigos de autenticação, números de telefone dos destinatários, nomes dos remetentes e algumas informações de conta na internet, e o acesso era possível apenas adivinhando o subdomínio idmdatastore
  • Google, Amazon, Facebook, Microsoft, Telegram, Airbnb, FedEx e DHL estavam entre os afetados, e só com o feed em tempo real já era possível tentar sequestrar números do WhatsApp ou realizar transações financeiras e logins em serviços
  • A autenticação em duas etapas por SMS é melhor do que usar apenas senha, mas métodos menos dependentes da rede móvel e de operadoras de SMS, como senhas de uso único geradas por aplicativo ou tokens de hardware, são mais seguros

As fragilidades do 2FA por SMS reveladas pela exposição da IdentifyMobile

  • O 2FA por SMS exige tanto a senha que o usuário conhece quanto um código por SMS que comprova acesso ao número de telefone
    • É usado como uma camada extra para impedir o sequestro de contas quando apenas a senha foi comprometida
    • O SMS pode incluir códigos válidos por pouco tempo, como códigos de verificação do WhatsApp ou TANs para transferências bancárias
  • A autenticação baseada em SMS já está exposta a vários vetores de ataque
  • Neste caso, mesmo sem atacar diretamente a rede móvel ou o usuário, um prestador de envio de SMS pode se tornar o elo fraco da cadeia de autenticação
    • A IdentifyMobile é uma fornecedora que envia SMS em grande volume para várias empresas e serviços
    • Essa fornecedora tinha acesso ao conteúdo das mensagens SMS, e esse conteúdo incluía códigos de autenticação
    • O CCC conseguiu acessar dados em tempo real apenas adivinhando o subdomínio idmdatastore

Alcance da exposição e riscos reais

  • Os dados expostos incluíam não só o conteúdo das mensagens SMS, mas também números de telefone dos destinatários, nomes dos remetentes e, em alguns casos, outras informações de conta
  • Mais de 200 empresas foram afetadas, incluindo casos em que a segurança de autenticação foi confiada à IdentifyMobile de forma direta ou por meio de outros prestadores de serviço
    • Google, Amazon, Facebook, Microsoft
    • Telegram, Airbnb, FedEx, DHL
    • No total, mais de 198 milhões de SMS foram vazados
  • Só com o feed em tempo real, já eram possíveis vários cenários de abuso
    • Sequestro de números do WhatsApp
    • Se a senha fosse conhecida, realização de transações financeiras sem acesso ao telefone
    • Se a senha fosse conhecida, login em vários serviços
  • Para abuso real, em geral ainda era preciso conhecer a senha, mas os dados também incluíam links de 1-click login
    • Em algumas grandes empresas afetadas, o escopo protegido pela IdentifyMobile estava limitado a serviços específicos
    • A negligência da IdentifyMobile expôs empresas e clientes a riscos consideráveis
    • O CCC não armazenou os dados, mas não é possível descartar que outras pessoas tenham acessado

Métodos de autenticação que podem substituir o SMS

  • Quando disponível, é mais seguro usar senhas de uso único geradas por aplicativo ou tokens de hardware em vez de SMS
    • Esses métodos não dependem da rede móvel
    • Também não dependem de provedores de envio de SMS como a IdentifyMobile
    • Ainda assim, a autenticação em duas etapas é melhor do que usar apenas uma senha

Leituras relacionadas

1 comentários

 
GN⁺ 2024-07-12
Opiniões no Hacker News

  • Recentemente, um conhecido caiu em um phishing via Google Ads: o atacante comprou anúncios para termos de busca como “BANKNAME login”, clonou com bastante precisão a página de login do banco e, por trás, estava fazendo um ataque de retransmissão.
    Quando ele digitou no site o código de autenticação em duas etapas do app do celular, a tela rejeitou e pediu um novo código, mas, na verdade, o segundo código era um código de aprovação para adicionar um novo beneficiário do tipo “pay anyone”, e foi assim que o dinheiro saiu da conta.
    Eu achava que a autenticação em duas etapas por SMS era fraca em termos de protocolo, mas, nesse caso, o método por SMS do banco, que envia uma mensagem diferente ao adicionar um novo beneficiário em vez de usar a mesma do login, talvez tivesse sido melhor.
    Idealmente, em vez de um app simples que gera tokens, deveria haver tokens por tipo de transação, como um token para login e outro para adicionar beneficiários, sem que um possa substituir o outro. Fico curioso se alguém já viu um banco oferecendo autenticação em duas etapas nesse nível.
    Talvez passkeys tornem esse problema irrelevante, já que estabelecem uma conexão física com o hardware local. A propósito, a vítima acabou recebendo o dinheiro de volta.

    • Anúncios não são apenas um incômodo terrorismo psicológico que consome largura de banda e recursos de processamento; eles também são o principal vetor para espalhar golpes e malware na web.
      Para melhorar sua postura de segurança, instalar um bloqueador de anúncios é uma das melhores medidas. Recomendo muito configurar o uBlock Origin para amigos ou familiares que não têm familiaridade com tecnologia.
    • O HSBC de fato tem esse recurso. Nos apps de cada país, é possível gerar códigos de segurança diferentes para login no site, confirmação de transações (por exemplo, enviar dinheiro a um beneficiário) e reautenticação (por exemplo, alterar informações pessoais como número de telefone).
      A tela do app australiano pode ser vista aqui, e os apps dos EUA e do Reino Unido são parecidos: https://www.hsbc.com.au/content/dam/hsbc/au/images/ways-to-b...
      O HSBC oferece isso há anos, e não entendo bem por que ainda não virou padrão ou por que outros bancos dos EUA não adotaram.
    • Por curiosidade, comprei um anúncio no Google uma vez; só tentei porque me deram créditos grátis, mas, mesmo assim, antes da aprovação do anúncio tive de contornar uma quantidade absurda de condições e diretrizes.
      Então não entendo por que eles são tão rígidos com anúncios comuns, mas vendem anúncios para páginas de phishing que se passam por bancos e miram pessoas que estão pesquisando por esses bancos.
    • Vale a pena avisar familiares e conhecidos que até o FBI recomenda usar extensões de bloqueio de anúncios em mecanismos de busca justamente para evitar esse tipo de golpe [0].
      “Ao fazer pesquisas na internet, use uma extensão de bloqueio de anúncios. A maioria dos navegadores permite adicionar extensões, incluindo extensões de bloqueio de anúncios. Esses bloqueadores podem ser ativados e desativados dentro do navegador, permitindo anúncios em determinados sites e bloqueando anúncios em outros.”
      [0] https://www.ic3.gov/Media/Y2022/PSA221221
    • Outra lição daqui é favoritar ou memorizar a URL do banco e não confiar que um mecanismo de busca vai levar você até o banco.

  • Há muito tempo suspeito que empresas que obrigam autenticação em duas etapas por SMS não estão realmente preocupadas com segurança; elas simplesmente querem o número de telefone e usam a autenticação em duas etapas como teatro de segurança para obtê-lo.

    • Isso certamente também existe. O número de telefone virou uma espécie de novo número de identificação nacional: um identificador único que quase nunca muda e conecta usuários entre vários serviços.
      Além disso, é um identificador que você entrega pessoalmente a quase todo mundo que conhece, então dá para dizer que parece um sistema ruim.
    • Se o serviço tem contas gratuitas, exigir número de telefone ajuda na prevenção de fraudes e no combate ao abuso por múltiplas contas.
      Dificulta criar novas contas para contornar bloqueios e torna mais fácil correlacionar comportamentos ruins que aparecem em várias contas.
    • A maioria das empresas, na prática, quer números de telefone por causa da prevenção de spam.
      Acho que a contribuição dos spammers para a degradação da internet é subestimada.
    • O motivo para obrigar autenticação em duas etapas por SMS é que presumir que o usuário tem um número de telefone gera muito menos atrito do que presumir que ele instalou um app de autenticação em duas etapas e sabe gerenciar essa ferramenta.
      Também é mais fácil de dar suporte.
    • Ou talvez originalmente usassem e-mail para autenticação em duas etapas, até que um auditor disse “isso não é autenticação em duas etapas”, e então perceberam que o middleware de notificações aceitava SMS além de e-mail.

  • O NIST já deixa explícito há bastante tempo que não se deve usar autenticação em duas etapas por SMS.
    NIST SP 800-63B §5.1.3.3
    https://pages.nist.gov/800-63-3/sp800-63b.html#pstnOOB

    • A perspectiva e os interesses do NIST não necessariamente coincidem com aquilo que um provedor de serviços precisa considerar na experiência de clientes e usuários.
      Cliente: “Como assim app de autenticação em duas etapas? O código não chegava no meu celular?”
      Suporte: “Sim, mas agora não oferecemos mais suporte a autenticação em duas etapas por SMS.”
      Cliente: “Mas nunca tive problema quando o código chegava no meu celular.”
      Suporte: “Sim, mas o NIST recomenda não usar autenticação em duas etapas por SMS.”
      Cliente: “O que é NIST? Isso é muito frustrante. Preciso entrar na minha conta.”

  • Infelizmente, quase todos os bancos obrigam o uso de SMS, porque os apps bancários se recusam a rodar em celulares com root. Que belo resultado de segurança.

    • Ainda assim, existe uma alternativa.
      No meu país, quase todos os bancos obrigam autenticação em duas etapas baseada em app, sem alternativa por SMS.
      Se você não quer comprar e carregar um celular separado, só resta usar um dos poucos bancos que não exigem isso.
    • Isso é, sim, um ganho de segurança.
      Em celulares com root, existe a possibilidade de outros apps espiarem e roubarem informações bancárias.
      Parece bastante razoável que um app bancário não rode em um celular cuja segurança foi comprometida.
    • É controverso, mas celulares com root são inerentemente menos seguros.
      O GrapheneOS, porém, não entra nessa categoria, porque as builds oficiais do GrapheneOS não têm acesso root.

  • O texto mistura dois problemas com implicações de segurança diferentes
    Links de login com 1 clique são preocupantes, e serviços como o WhatsApp podem ser tomados apenas com acesso a SMS
    Mas códigos de autenticação em duas etapas são relativamente menos preocupantes. Como são um segundo fator, o invasor também precisaria da senha
    Nesse caso, eu ficaria bem menos alarmado com o uso de SMS e o risco de interceptação

    • Para cada banco de dados de mensagens SMS que vaza, vazam algo como 1000 bancos de dados de credenciais de contas

  • No Reino Unido, parece que quase todas as transações de banco online agora são verificadas por SMS. Pelo que parece, isso é exigido por lei e substituiu o sistema anterior de verificação com cartão bancário + leitor de cartão + PIN
    O método antigo não só era mais seguro, como também não dependia de um celular funcionando normalmente e com sinal
    Espero que um dia reconheçam que isso foi um erro terrível e corrijam, mas não tenho grandes expectativas

    • Fiquei curioso para saber qual banco. Uso Lloyds e as transações são verificadas pelo app, não por SMS
    • A primeira frase não é verdadeira de forma alguma. SMS é uma das opções, mas muitos bancos oferecem autenticação em duas etapas baseada em app
      Concordo que o leitor de cartão era útil offline. Mas eu quase nunca lembrava de levar o aparelho, então frequentemente ficava bloqueado durante viagens

  • A Suécia resolveu esse problema há muito tempo com o BankID
    https://en.wikipedia.org/wiki/BankID
    É impressionante o que dá para alcançar quando instituições públicas e privadas cooperam um pouco. É a única forma de fazer login e autenticação em duas etapas em serviços do governo e na maioria dos bancos, e funciona bem
    É difícil acreditar que nem todos os países tenham um sistema assim, e mais ainda que a UE inteira não tenha algo desse tipo

    • A UE está introduzindo a Digital Wallet para isso. Espero que seja melhor de usar do que a versão finlandesa do BankID, e melhor ainda se depender menos de bancos ou de outras entidades privadas rentistas
      Mesmo assim, não crio expectativas muito altas
      https://ec.europa.eu/digital-building-blocks/sites/display/E...
    • Pela descrição da wiki, fico me perguntando se ele realmente não oferece suporte a Linux. Talvez dê para usar a versão em cartão como alternativa

  • As mensagens no bucket S3 pareciam ser atualizadas a cada 5 minutos: https://www.zeit.de/digital/datenschutz/2024-07/it-sicherhei...
    Dito isso, o CCC errou ao definir isso como um problema exclusivo de 2FA por SMS. O afetado não foi apenas o Twilio Verify (API de autenticação em duas etapas), mas todos os SMS enviados por meio desse fornecedor

    • Fiquei curioso para saber de onde veio a evidência sobre o Twilio Verify. Não é mencionado em lugar nenhum

  • Isso parece mais um problema de segurança de fornecedor, que não protegeu corretamente um repositório de dados sensíveis, do que um problema do SMS em si

    • OTP e tokens de hardware não precisam gravar segredos rotativos em um repositório de dados potencialmente legível publicamente, então isso também é um problema do SMS
      Esse vetor de ataque específico simplesmente não existe nessas tecnologias

  • Várias instituições financeiras em que trabalho exigem autenticação em duas etapas por SMS e não oferecem opções HOTP/TOTP. É enlouquecedor