Vulnerabilidades que afetam o OAuth da Microsoft e GitHub leva a ataques de redirecionamento

Principais vantagens

• Vulnerabilidades em implementações OAuth2.0 populares da Microsoft e de outros levam a ataques de redirecionamento que contornam a maioria das soluções de detecção de phishing e soluções de segurança de e-mail.
• A Proofpoint observou ataques em grande escala visando com sucesso centenas de usuários de locatários de clientes da Proofpoint, e os números aumentam diariamente.
• A maioria dos URLs de phishing estavam abusando dos domínios do Azure da Microsoft para hospedar os ataques de phishing, fazendo com que parecessem mais legítimos.
• As campanhas detectadas incluem, entre outras, phishing do Outlook Web Access, phishing de login do PayPal e coleta de cartão de crédito.

Visão geral

A Proofpoint descobriu vários métodos novos e anteriormente desconhecidos para iniciar um ataque de redirecionamento de URL usando as implementações OAuth2.0 populares da Microsoft e de outros. Aplicativos em nuvem de terceiros usam OAuth 2.0 para obter acesso limitado aos recursos de usuários protegidos nas principais plataformas, como Microsoft 365 e Google Workspace. Os pesquisadores de ameaças da Proofpoint começaram a detectar esses ataques de redirecionamento contra ambientes Microsoft 365 em fevereiro de 2020. 

Vulnerabilidades de redirecionamento aberto surgem quando um aplicativo da web incorpora parâmetros controláveis ​​pelo usuário para especificar um link de redirecionamento. Um invasor pode criar uma URL para um aplicativo da web que causa um redirecionamento para um domínio externo arbitrário. Ataques clássicos de redirecionamento aberto manterão o alvo de redirecionamento na própria URL. No novo tipo que descobrimos, o URL de destino de redirecionamento é configurado na estrutura do provedor OAuth, sem qualquer validação desse URL.

Além disso, o URL de destino de redirecionamento estará ausente do URL legítimo e, portanto, ignorará a maioria das soluções de detecção de phishing e soluções de segurança de e-mail. A vítima que clica no URL confia no provedor OAuth e não espera um redirecionamento imediato, como observamos neste tipo de ataque. Isso torna a sequência de ataque mais encoberta e potente em comparação com os clássicos ataques de redirecionamento aberto.

Ataques reais visando a implementação OAuth da Microsoft

Analisamos os dados do Proofpoint e encontramos ataques direcionados em grande escala usando modi operandi (MOs), que discutiremos em detalhes posteriormente nesta postagem do blog. Os ataques usam dezenas de aplicativos distintos de terceiros do Microsoft 365 com URLs de redirecionamento mal-intencionados definidos para eles. Eles atingiram com sucesso centenas de usuários de inquilinos de clientes da Proofpoint, e os números continuam crescendo diariamente.

Todos os aplicativos de terceiros estavam sendo entregues por meio de um URL da Microsoft com um parâmetro de consulta response_type ausente, com a intenção de redirecionar usuários desavisados ​​para diferentes URLs de phishing. A maioria dos URLs de phishing estavam abusando dos domínios do Azure da Microsoft para hospedar os  ataques de phishing , fazendo com que parecessem mais legítimos. O kit de phishing usado nesses ataques foi abordado em detalhes por SeclarityIO  aqui . 

As campanhas detectadas incluem, entre outras, phishing do Outlook Web Access, phishing de login do PayPal e coleta de cartão de crédito – e essas campanhas ainda estão vivas e em evolução.

Uma campanha de phishing do PayPal está abusando do sistema de login login.live.com “Contas da Microsoft”, que não requer autenticação do usuário antes de redirecionar para a página de phishing. O seguinte GIF demonstra o redirecionamento depois que o usuário clica no link de URL legítimo da Microsoft:

Figura 1. GIF demonstrando um esquema de phishing do PayPal, em que um usuário é redirecionado após clicar em um link de URL legítimo da Microsoft

Como a Microsoft implementa OAuth 2.0

OAuth 2.0 é um protocolo amplamente adotado para autorização. Ao desenvolver um aplicativo OAuth, os desenvolvedores devem registrar seus aplicativos na estrutura do provedor OAuth para obter um ID de aplicativo (cliente) exclusivo e, como parte desse processo, eles fornecem seu URI de redirecionamento. O provedor OAuth redireciona o usuário com a resposta de autorização para o URI de redirecionamento.

Existem muitos fluxos OAuth 2.0 diferentes  . Um ataque de redirecionamento requer um dos seguintes fluxos: fluxo de código de autorização, fluxo implícito e fluxo híbrido, que combina os fluxos de autorização e implícito.

A implementação do OAuth 2.0 da Microsoft depende do ponto de extremidade da plataforma de identidade da Microsoft (v2.0), ou o ponto de extremidade do Azure AD mais antigo, para autenticar usuários antes do processo de autorização.

O diagrama a seguir explica um fluxo de login OAuth básico (também conhecido como OpenID Connect). Mas a ideia geral é verdadeira para o fluxo de código de autorização OAuth, que é o caso de uso principal e mais prevalente.

Figura 2. Fluxo de login típico do OAuth

Posteriormente nesta postagem, discutiremos o login.live.com, que é outro sistema de login para contas pessoais da Microsoft que o OAuth 2.0 usa.

Os fluxos OAuth relevantes começam com um usuário navegando para (ou sendo redirecionado para) a URL de autorização, que está localizada no   endpoint / authorize sob a URL API correta.

No caso da plataforma de identidade da Microsoft, o URL apresenta o seguinte formato:

Figura 3. Formato de URL do fluxo OAuth da plataforma de identidade da Microsoft

E no caso do ponto de extremidade v1.0 Azure AD, a URL apresenta este formato:

Figura 4. Formato de endpoint de URL para o endpoint v1.0 Azure AD

Ambos os URLs requerem os   parâmetros client_id  e  response_type para um URL válido, enquanto a v2.0 também requer o parâmetro de escopo. Outros parâmetros de consulta são opcionais.

Observe que os pontos de extremidade de autorização no URL  https://login.windows.net  redirecionam automaticamente para  https://login.microsoftonline.com  com todos os parâmetros de consulta fornecidos. Isso significa que todos os fluxos válidos e inválidos mencionados nesta postagem também se aplicam a URLs que começam com  https://login.windows.net em  vez de  https://login.microsoftonline.com .

Nesse ponto, os usuários precisarão se autenticar e, em seguida, autorizar as permissões do aplicativo.

As permissões autorizadas permitirão o acesso do aplicativo aos recursos do usuário. Assim que o usuário consentir, o servidor de autorização redireciona o usuário para a URL de redirecionamento do aplicativo.

Figura 5. Tela de login da Microsoft, permissões necessárias

Como quebrar o fluxo válido

A cadeia normal de eventos do protocolo OAuth detalhado acima ocorre quando todos os parâmetros de consulta necessários estão presentes e contêm um valor válido. Para acionar um ataque de redirecionamento, o invasor modifica alguns parâmetros ou elimina outros completamente. Em seguida, o usuário é  redirecionado para um URL de redirecionamento controlado pelo invasor após clicar em um URL de aparência legítima pertencente à Microsoft  e se identificar por meio de um dos pontos de extremidade de autenticação da Microsoft.

A Microsoft, por design, envia respostas de erro ao URL de redirecionamento do aplicativo para que o aplicativo tenha a chance de tratá-los. Junto com o fato de que valores específicos para determinados parâmetros de consulta podem disparar um erro logo após a autenticação, a escolha de design da Microsoft torna possível um ataque de redirecionamento. Um invasor pode, portanto, criar uma URL especial usando um dos mecanismos que descreveremos mais tarde nesta postagem e enviar essa URL para vítimas em potencial por e-mail ou qualquer outro meio de comunicação.

Então, quais são os casos de erro que causam um redirecionamento? Apresentaremos diferentes MOs, cada um começando com um  URL legítimo de propriedade da Microsoft  seguido por um  redirecionamento pela própria Microsoft  para um URL controlado pelo invasor com interação mínima do usuário em todo o fluxo:

1. Quando o  parâmetro de consulta response_type  está ausente ou contém um valor não relevante (qualquer coisa diferente de “token”, “código” ou “id_token” ou uma combinação dos dois últimos valores), o usuário será redirecionado pela Microsoft logo após a autenticação . O diagrama a seguir ilustra um URL clicado por um usuário, com o  parâmetro response_type  ausente no URL:

Figura 6. Fluxo de ataque de response_type ausente

2. Quando o  parâmetro de escopo  existe, mas contém um valor inválido (qualquer valor que irá acionar um  erro “invalid_resource” ), o usuário será redirecionado novamente pela Microsoft após a autenticação. A documentação oficial afirma que isso pode ser causado por qualquer escopo pertencente a um “recurso inválido porque não existe, o Azure AD não pode localizá-lo ou não está configurado corretamente”. 

Um exemplo simples de um valor de escopo inválido é um erro de digitação no valor do escopo. Um invasor pode criar um escopo ruim com a intenção de confundir o usuário com um escopo real (como Openld, onde em vez da letra maiúscula “I” há um “L” minúsculo). O diagrama a seguir ilustra o cenário de um escopo inválido sendo usado no URL:

Figura 7. Fluxo de ataque de escopo inválido

3. Se todos os parâmetros de consulta forem válidos e o usuário acessar a tela de consentimento, clicar no botão “Cancelar” também fará com que o usuário seja redirecionado para a URL controlada pelo invasor.

Figura 8. Tela de consentimento solicitada de permissões da Microsoft

O terceiro caso, embora não seja um redirecionamento imediato, representa uma ameaça perigosa. Nessa situação, clicar no botão “Aceitar” dará ao aplicativo malicioso acesso aos recursos do usuário, enquanto clicar no botão “Cancelar” redirecionará o usuário para a URL de redirecionamento malicioso do aplicativo. O último cenário pode levar a um novo conjunto de ameaças – pense em phishing de credencial, download forçado de um arquivo malicioso ou até mesmo encadear o redirecionamento com outra vulnerabilidade para entregar uma ameaça completamente diferente.

Quebrando um sistema de login diferente da Microsoft

A Microsoft mantém um sistema de login totalmente diferente para contas pessoais, denominado “contas Microsoft”, onde os usuários podem consentir com o mesmo tipo de aplicativos registrados por meio do Portal do Azure, usando URLs do seguinte formato:

Figura 9. URL OAuth de contas pessoais da Microsoft

Todos os MOs de redirecionamento mencionados anteriormente também estão disponíveis neste sistema de login. Uma diferença substancial é que no caso deste formato de URL, os redirecionamentos acontecem  antes mesmo  do processo de autenticação. Isso significa que ao usar os métodos mencionados anteriormente para redirecionar o usuário inocente junto com este formato de URL, o usuário nem mesmo terá a chance de fazer o login e o redirecionamento, pela própria Microsoft, acontecerá assim que o usuário clicar no link criado com códigos maliciosos URL

Figura 10. Fluxo de ataque de contas da Microsoft

Quebrando o fluxo OAuth para diferentes provedores

Outros provedores de OAuth também sofrem de vulnerabilidades de redirecionamento aberto semelhantes. GitHub, um serviço popular de hospedagem de código baseado em git, que também pertence à Microsoft, permite que os usuários criem aplicativos OAuth que automatizam e melhoram os fluxos de trabalho. Usando o GitHub como o provedor de identidade para autenticar os usuários, qualquer pessoa pode registrar um aplicativo OAuth enquanto fornece um URL de redirecionamento que pode ser um URL de phishing malicioso.

Depois de registrar seu aplicativo e obter seu client_id, existem vários cenários de erro em que o GitHub, por design, redirecionará os usuários para o URL de redirecionamento malicioso:

1. Quando o   parâmetro de consulta redirect_uri difere do URL definido pelo aplicativo, os usuários serão redirecionados (após a autenticação) para o URL de redirecionamento definido para o aplicativo. Isso significa que os invasores podem direcionar os usuários para clicar em URLs de consentimento incorporados com qualquer URL legítimo para causar um redirecionamento para um URL malicioso diferente. O seguinte URL não redirecionará para o URL legítimo, mas para o URL original registrado para o aplicativo:

Figura 11. URL do GitHub OAuth

2. Se o usuário entrar na página de consentimento com sucesso, mas rejeitar o acesso ao aplicativo (clicando no botão “Cancelar”), ele também será redirecionado para o URL de redirecionamento. Embora seja uma prática perigosa, o URL de redirecionamento é mencionado na parte inferior da página de consentimento, com o texto “A autorização irá redirecionar para: <URL de redirecionamento>.” Observe que o texto não menciona que o cancelamento também redirecionará os usuários para o URL de redirecionamento.

3. Mesmo se o aplicativo com o URL de redirecionamento malicioso for suspenso pelo GitHub, os usuários ainda serão redirecionados para o URL malicioso.

Ao contrário da Microsoft e do GitHub, a implementação OAuth do Google está lidando com erros de URL dentro de seu domínio com páginas de erro especiais do Google. Portanto, nossos pesquisadores não conseguiram encontrar vulnerabilidades de redirecionamento OAuth semelhantes. No entanto, existem vários fluxos de redirecionamento não errôneos nos quais um usuário pode ser induzido a uma página de phishing:

1. O registro de um aplicativo OAuth de login com um URL de redirecionamento malicioso na estrutura do Google não requer verificação pelo Google. O seguinte URL de exemplo fará com que o Google redirecione o usuário, logo após a autenticação, para o URL de redirecionamento malicioso (mencionado com o parâmetro de consulta “redirect_uri”), sem pop-ups de tela de consentimento adicionais:

Figura 12. URL OAuth do Google

2. Um caso mais grave de redirecionamento aberto foi encontrado no fluxo de consentimento do administrador para aplicativos de mercado. Qualquer aplicativo de mercado legítimo pode ser usado, e tudo o que é necessário é o identificador do aplicativo. Com esse identificador, um URL com o seguinte formato pode ser criado:

Figura 13. URL OAuth do Google Workspace

Depois que um usuário administrador clica no link e se autentica, a tela de consentimento desse aplicativo é exibida. Se o administrador clicar no botão “Cancelar”, o Google redirecionará o administrador para o URL malicioso fornecido, mesmo que esse URL não corresponda ao URL de redirecionamento definido pelo aplicativo.

Técnicas eficazes de mitigação

O phishing é mais fácil com ataques de redirecionamento secreto que exploram vulnerabilidades de implementação de OAuth e usam domínios legítimos da Microsoft. Esses ataques podem enganar até os usuários mais experientes em tecnologia. As implementações de outros provedores de OAuth que observamos, como Google ou LinkedIn, nos mostram que existem maneiras melhores de tratamento de erros para manter a estrutura OAuth mais segura.

Uma maneira é redirecionar o usuário para o domínio do provedor com uma explicação detalhada do erro. Se encaminhar o usuário para a URL de redirecionamento do desenvolvedor for essencial, isso pode ser feito de maneira segura para reduzir o risco de usuários inocentes de phishing. Técnicas de mitigação eficazes apresentam ao usuário um aviso claro de que ele está saindo do aplicativo atual, implementando um longo atraso antes do redirecionamento automático do usuário ou forçando o usuário a clicar no link antes do redirecionamento.

O phishing de usuários inocentes continua sendo o método de ataque mais bem-sucedido para comprometer as credenciais do usuário e violar a rede da sua organização no processo. Os sistemas de proteção de e-mail são indefesos contra esses ataques. Ao abusar da infraestrutura OAuth, esses ataques entregam e-mails maliciosos a seus alvos sem serem detectados. Esses ataques ao PayPal podem levar ao roubo de informações financeiras, como cartões de crédito. Ataques de phishing na Microsoft podem levar a fraude, roubo de propriedade intelectual e muito mais.

Domínios de URL de phishing

Abaixo está uma lista de todos os URLs que observamos aplicativos maliciosos usando para redirecionar usuários:

102871.z13.web.core.windows [.] Net / redirect.htm 

 118921.z13.web.core.windows [.] Net / redirect.htm 

 59328.z13.web.core.windows [.] Net / redirect.htm 

 91829.z13.web.core.windows [.] Net / redirect.htm 

 bewaio.z13.web.core.windows [.] net / redirect.htm 

 apqiuz.z13.web.core.windows [.] net / redirect.htm 

 cdoiaioa.z13.web.core.windows [.] net / redirect.htm 

 csadawzq.z13.web.core.windows [.] net / redirect.htm 

 cwasdcawz.z13.web.core.windows [.] net / redirect.htm 

 zoopqp.z13.web.core.windows [.] net / redirect.htm 

 7172981.z13.web.core.windows [.] Net / redirect.htm 

 287191.z13.web.core.windows [.] Net / redirect.htm 

 279102.z13.web.core.windows [.] Net / redirect.htm 

 901829.z13.web.core.windows [.] Net / redirect.htm 

 178710.z13.web.core.windows [.] Net / redirect.htm 

 391722.z13.web.core.windows [.] Net / redirect.htm 

 2910992.z13.web.core.windows [.] Net / redirect.htm 

 40192.z13.web.core.windows [.] Net / redirect.htm 

 618291.z13.web.core.windows [.] Net / redirect.htm 

 817892.z13.web.core.windows [.] Net / redirect.htm 

 528102.z13.web.core.windows [.] Net / redirect.htm 

 116258.z13.web.core.windows [.] Net / redirect.htm 

 29190.z13.web.core.windows [.] Net / redirect.htm 

 49281.z13.web.core.windows [.] Net / redirect.htm 

 23811.z13.web.core.windows [.] Net / redirect.htm 

 49187.z13.web.core.windows [.] Net / redirect.htm 

 39281.z13.web.core.windows [.] Net / redirect.htm 

 49287.z13.web.core.windows [.] Net / redirect.htm 

 12787.z13.web.core.windows [.] Net / redirect.htm 

 51871.z13.web.core.windows [.] Net / redirect.htm 

 19281.z13.web.core.windows [.] Net / redirect.htm 

 49271.z13.web.core.windows [.] Net / redirect.htm 

 39871.z13.web.core.windows [.] Net / redirect.htm 

 172914.z13.web.core.windows [.] Net / redirect.htm 

 127100.z13.web.core.windows [.] Net / redirect.htm 

 39182.z13.web.core.windows [.] Net / redirect.htm 

 cijuaiu.z13.web.core.windows [.] net / redirect.htm

 38e1-138-199-58-114.ngrok [.] I / informationssk

 66d0-185-91-121-4.ngrok [.] I / informationssk

 769b-216-131-110-210.ngrok [.] I / informationssk

 c578-143-202-163-94.ngrok [.] i / informationssk

 f1e7-185-108-106-250.ngrok [.] i / informationssk

 ff99-185-245-84-32.ngrok [.] i / informationssk

 www.lifetivate[.]com/wp-admin/js

 tuffgigmusic[.]com/imdmlm/pp

 tuffgigmusic[.]com/immmnf/pp

 tuffgigmusic[.]com/immmnn/pp

 tuffgigmusic[.]com/impho/pp

 i12313212111478.blogspot[.]com

 i8974541122.blogspot[.]com

 i98742138576.blogspot[.]com

 id2021serviceupp.blogspot[.]com

 montana.co [.] ke / pp

 persiken[.]com/in

Fonte: https://www.proofpoint.com/