
Você implementou o OAuth, você está protegido?
OAuth é uma opção conveniente para as organizações à medida que se afastam das senhas. O OAuth padrão é bastante fácil de implementar, e porque remove a senha, OAuth Parece resolver grande parte do dilema da Engenharia Social que está assolando organizações de todos os tamanhos. Se parece que estou criando um problema, eu estou. Então, qual é o problema? Bem, antes de nos aprofundarmos nas preocupações com OAuth, vamos rapidamente olhar para o que OAuth É.
O que é OAuth, uma breve história
Ao mais alto nível, OAuth é um padrão aberto para autorização. Especificamente, OAuth Geralmente é usado para fornecer acesso delegado seguro e substituir o mecanismo de autenticação de nome de usuário / senha por tokens de acesso. OAuth é ótimo para seu uso pretendido, pois resolve uma série de problemas inerentes ao fornecimento de Single Sign On (SSO) capacidades entre aplicativos, como remover o nome de usuário e senha da equação. Semelhante a como as permissões de arquivo funcionam em pastas; OAuth Também permite controles granulados multados para acesso compartimentalizado aos dados que um usuário deseja compartilhar. OAuth Pode parecer muito bom agora, e na verdade é um ótimo padrão. Não é infalível.

Como o OAuth é vulnerável?
Uma das grandes vulnerabilidades inerentes ao OAuth é que ele permite aos usuários a capacidade de conceder permissões a elementos de seus dados para aplicativos de terceiros. Em um mundo perfeito, essa é uma ótima característica que permite aos usuários ter a flexibilidade de conceder acesso granular aos seus dados. Infelizmente, no caso de phishing de consentimento, eles geralmente fornecem acesso a entidades maliciosas e, nos piores casos, fornecem faixas de dados organizacionais a essas entidades também.
Microsoft detalha os passos abaixo:

Um invasor registra um aplicativo com um provedor OAuth 2.0, como o Azure Active Directory
O aplicativo é configurado de uma maneira que faz parecer confiável, como usar o nome de um produto popular usado no mesmo ecossistema
O atacante obtém um link na frente dos usuários, o que pode ser feito através de phishing convencional baseado em e-mail, comprometendo um site não malicioso ou outras técnicas
O usuário clica no link e é mostrado um aviso de consentimento autêntico pedindo-lhes para conceder as permissões de aplicativo malicioso aos dados
Se um usuário clicar em aceitar, ele concederá permissões ao aplicativo para acessar dados confidenciais
O aplicativo recebe um código de autorização que resgata por um token de acesso e, potencialmente, um token de atualização
O token de acesso é usado para fazer chamadas API em nome do usuário.
Se o usuário aceitar, o atacante pode obter acesso ao seu e-mail, regras de encaminhamento, arquivos, contatos, notas, perfil e outros dados e recursos sensíveis.
Um exemplo específico de phishing de consentimento OAuth pode ser visto em TA2552. Este ator nomeado foi supostamente perpetrando ataques O365 desde agosto 2019. Os clientes foram alvo de links que os levaram a páginas legítimas de consentimento de aplicativos de terceiros Microsoft. Uma vez assinados, os usuários continuaram com o processo de consentimento O365 real, concedendo ao aplicativo malicioso permissões somente leitura de seus dados, especificamente os contatos e e-mail do usuário. Como visto abaixo, as vítimas podem ser alvo novamente.

Fluxo de Proofpoint e mais detalhes.
Passos para proteger sua organização
Não deixe para o usuário
O treinamento de segurança deve fazer parte da estratégia geral de mitigação de risco de todas as organizações. No entanto, as poucas horas por ano dedicadas à tarefa ficam aquém da experiência ao longo da vida da maioria dos atacantes. Dito isso, até mesmo os profissionais de segurança mais experientes foram vítimas de phishing e imitações de sites. Tire o máximo possível das mãos dos usuários. Implemente a autenticação protegida por Full Duplex Authentication® (FDA) ) o que torna inviável para o usuário conceder inadvertidamente acesso aos aplicativos maliciosos. Para mais informações sobre FDALeia o nosso white paper aqui.
Use a autenticação “Secure by design”
Os pontos fortes do OAuth também podem ser grandes fraquezas. O OAuth foi concebido para ser flexível e, embora possa ser adequadamente seguro com o cuidado e a nutrição de uma equipe de desenvolvimento excepcional que se concentra na segurança, pode ser mal implementado e deixado com vulnerabilidades gritantes. Em vez disso, implemente a autenticação, como o NoPass™, que foi construído do zero para ser seguro.
