Análise de Risco de UX de OAuth em Phishing por Código de Dispositivo

O truque de phishing mais cruel nem sempre é a página falsa de login com um domínio de máscara de Halloween em promoção. Às vezes, é a página real de autorização, sorrindo educadamente enquanto pede que um usuário aprove a coisa errada. O phishing por código de dispositivo é o tipo de problema de identidade que faz defensores olharem para um recurso perfeitamente legítimo e sussurrarem: é claro que isso virou uma técnica básica. A lição não é que o OAuth está quebrado. A lição é que a experiência de login, o acesso condicional e os prompts de consentimento agora fazem parte da superfície de ataque, e merecem a mesma suspeita que normalmente reservamos para bancos de dados expostos e comunicados à imprensa sobre levar a segurança a sério.

O que aconteceu, segundo a Proofpoint e a Rubrik A Proofpoint descreve

o phishing por código de dispositivo como uma evolução na tomada de controle de identidade, não como um feitiço novo e misterioso encontrado em um grimório de porão. Sua pesquisa de ameaças diz que o phishing de credenciais ainda permite tomada de controle de contas, fraudes, ransomware e espionagem, enquanto agentes de ameaça se expandiram para phishing por código de dispositivo e OAuth à medida que as organizações melhoram as defesas contra phishing comum de MFA. Esse é o desenvolvimento da trama: quando os defensores tornam o golpe antigo menos lucrativo, o adversário não se aposenta; ele procura um fluxo de trabalho em que os usuários já confiam.

A discussão da Rubrik com a pesquisadora da Proofpoint Selena Larson enquadra o problema como abuso do fluxo de autenticação, com adversários explorando estruturas legítimas de comunicação para capturar acesso administrativo e corporativo. Essa escolha de palavras importa porque a camuflagem não é apenas uma marca falsificada ou um domínio parecido. A camuflagem é a própria cerimônia normal de login, o que significa que as equipes de segurança precisam revisar a cerimônia, não apenas as credenciais inseridas durante ela.

Como o fluxo real vira

a isca, segundo a Proofpoint A Proofpoint diz que, de 2020 até por volta de 2022, equipes de red team e, ocasionalmente, criminosos e agentes de ameaça de espionagem usaram phishing por código de dispositivo para enganar alguém a autorizar uma solicitação maliciosa. Essa é a parte importante para quem constrói sistemas: a vítima não está necessariamente digitando uma senha em uma página falsificada. Ela pode estar concluindo um fluxo real de autorização e concedendo acesso em um contexto que não entende.

Isso muda a pergunta de defesa de “o usuário percebeu a página falsa?” para “o sistema tornou a escolha arriscada compreensível antes do consentimento?”. Um prompt que diz “aprove este código” pode ser tecnicamente correto e ainda assim inútil para uma pessoa tentando concluir um convite de reunião, um chat de suporte ou algum outro ritual de trabalho com pânico moderado. Precisão não é a mesma coisa que compreensão, e atacantes prosperam nessa brecha como mofo em uma geladeira esquecida do escritório.

O que foi exposto, segundo Krebs e BleepingComputer

O Krebs on Security documentou a versão mais antiga dessa história de identidade em 2022, quando phishing por SMS mirou funcionários de empresas comerciais de recrutamento e os levou a páginas que imitavam telas de autenticação da Okta. Krebs relatou que aqueles que enviaram credenciais eram então solicitados a fornecer códigos de acesso de uso único para MFA. A técnica é diferente, mas a moral é tristemente familiar: se a etapa de autenticação pode ser retransmitida ou manipulada por engenharia social, a presença de MFA não significa automaticamente que a decisão foi segura.

A cobertura da BleepingComputer sobre phishing OAuth por código de dispositivo no Azure e no Google aponta para outra complicação prática: as defesas de identidade vivem dentro de implementações específicas de cada plataforma. Isso não significa que toda equipe precise virar entusiasta de comitê de padrões OAuth, embora parabéns às três pessoas que já são. Significa que os defensores devem inventariar onde a autorização por dispositivo está habilitada, quais apps podem solicitá-la e como cada plataforma explica a solicitação para a pessoa que está diante do teclado.

Como conter isso, segundo a Rubrik e Krebs A conversa da

Rubrik orienta defensores para controles arquiteturais, incluindo políticas de acesso condicional e estruturas rígidas de conformidade de dispositivos. É exatamente aí que isso pertence. Treinar usuários para reconhecer prompts suspeitos é útil, mas fazer cada funcionário depurar OAuth pessoalmente sob pressão de prazo não é uma estratégia; é um teste de estresse no trabalho com tokens de nuvem.

Krebs também relatou em 2022 que Apple, Google e Microsoft anunciaram suporte a abordagens de login sem senha que dependem do desbloqueio de um smartphone, com especialistas dizendo que as mudanças devem ajudar a derrotar muitos tipos de phishing, ao mesmo tempo em que alertam que um futuro realmente sem senhas ainda pode estar a anos de distância para a maioria dos sites. O login sem senha pode reduzir o roubo de senhas, mas o phishing por código de dispositivo é um lembrete de que a próxima luta é a clareza da autorização. Se um usuário está aprovando acesso, o produto precisa mostrar o que está sendo aprovado, para qual app, a partir de qual contexto e por que a solicitação é incomum.

O que isso realmente significa para você, segundo a Proofpoint e Krebs

Para equipes de identidade, a conclusão é simples o suficiente para caber em um post-it e deprimente o suficiente para estragar o almoço: revisem fluxos de login como superfícies de produto, não apenas como encanamento de segurança. O enquadramento da Proofpoint sobre tomada de controle de contas e o histórico de Krebs sobre phishing de códigos de acesso apontam para o mesmo modo de falha, em que uma etapa de autenticação tecnicamente válida vira um palco de engenharia social.

Audite a disponibilidade de códigos de dispositivo, restrinja o acesso condicional, exija dispositivos em conformidade quando apropriado e reescreva os prompts para que os usuários consigam entender o risco antes de consentir. Para todos os demais, não trate uma página real de login como prova de que a solicitação é legítima. Vá com calma quando um prompt pedir que você insira um código, aprove um dispositivo ou autorize um app que você não começou a usar intencionalmente. A próxima defesa de identidade útil pode não ser outra caixa de seleção no painel de configurações de MFA. Pode ser uma frase mais clara exatamente no momento em que alguém está prestes a entregar as chaves ao personagem errado.