Microsoft “nOAuth” é vulnerável à falsificação simples de e-mail

Em junho, pesquisadores revelaram uma vulnerabilidade no Azure Active Directory e aplicativos de terceiros chamados “nOAuth,” isso pode resultar em uma aquisição completa da conta. Esta é apenas uma das muitas vulnerabilidades em softwares e sistemas da Microsoft como o Active Directory que podem ser exploradas, colocando organizações em risco. Embora a Microsoft tenha respondido à vulnerabilidade, os desenvolvedores devem fazer alterações no código em seus aplicativos, e organizações precisam de proteção de identidade robusta para evitar uso indevido de contas privilegiadas por administradores desonestos.

O que é OAuth?

O nome “nOAuth” é uma implementação da Microsoft do protocolo de autorização OAuth. OAuth supõe que o provedor de identidade enviará ao aplicativo que você está tentando autenticar um conjunto de dados necessários para fazer login. Esta informação também deve contém um identificador exclusivo que prevents spoofing the login attempt.

A vantagem de usar OAuth é sua conveniência quando você usa dezenas de serviços. Como você precisa de apenas uma conta para fazer login em qualquer lugar, não há necessidade de lembrar as senhas de todos eles. É possível revogar permissões a qualquer momento se você não quiser mais aplicativo para acessar seus recursos. Você provavelmente já usou pelo menos uma vez, se você tiver o Google, Maçã, Facebook ou outra conta. Sempre que você vir a opção de “Faça login com a Microsoft” ou “Entrar com o Facebook” - é isso.

Vulnerabilidade nOAuth permite falsificação de e-mail

Pesquisadores encontraram a “nOAuth” vulnerabilidade, que fica na confiança entre o Azure AD (provedor de identidade) e um aplicativo (parte confiável). Em cenários do Azure AD, qualquer um pode facilmente gerar essa afirmação simplesmente falsificando o endereço de e-mail. Isto é possível para 2 razões: O pacote Azure permite alterar domínios de endereços de e-mail mesmo sem validação de propriedade de domínio. Também pelo uso endereço de e-mail como identificador de usuário no “nOAuth”.

Qual é a configuração incorreta do Azure?

O problema se origina de uma configuração incorreta que permite que atores mal-intencionados modifiquem atributos de e-mail em contas do Azure AD’ “Informações de contato” seção. Attackers can hijack victim accounts explorando o “Faça login com a Microsoft” recurso. Para executar o ataque, o adversário deve criar e acessar uma conta de administrador do Azure AD, mudar seu endereço de e-mail para o da vítima, e aproveite a funcionalidade de logon único em um aplicativo ou site vulnerável. Se o aplicativo de destino combinar contas de usuário sem a validação adequada, o atacante ganha controle total na conta da vítima, mesmo que o a vítima não tem uma conta da Microsoft. Isso permite que o invasor estabeleça persistência, extrair dados, e realizar outras atividades pós-exploração com base na funcionalidade do aplicativo.

A captura de tela abaixo mostra dois logins OAuth diferentes para o mesmo aplicativo, com todos os valores de reivindicação sendo os mesmos, exceto o “e-mail” alegar.

A natureza mutável e não verificada dos endereços de email causa a vulnerabilidade no Azure AD. A Microsoft não recomenda solicitações de autorização por e-mail.

Como combater ataques baseados em identidade no AD e no Azure AD ?

A Microsoft tem lançou orientações para desenvolvedores lidarem com vulnerabilidades em seus aplicativos. A empresa não recomenda o uso de solicitações de e-mail para identificação ou autorização do usuário e, em vez disso, sugere seguir as práticas recomendadas para validação de token. Adicionalmente, desenvolvedores devem revisar o código-fonte do aplicativo para verificar padrões de autenticação incorretos.

Para garantir que sua lógica de autorização seja segura, validar as seguintes informações nas reivindicações:

• O ator (aplicativo cliente) está autorizado.
  Um aplicativo cliente agindo em nome de um usuário deve ser autorizado. Use o SCP reivindicação para validar permissões, limitado a usuários’ necessidades e princípios de privilégio mínimo.
• O ID do locatário do token corresponde ao ID do local de armazenamento.
  Sempre verifique se o token está TID corresponde ao ID usado para armazenar dados do aplicativo. Os dados armazenados no contexto de um locatário só devem ser acessados ​​dentro desse locatário. Never allow data from one tenant ser acessado por outro.
• O token especifica o público-alvo.
  O AUD reivindicação especifica o público-alvo do token. Antes de validar reivindicações, sempre verifique se o valor da declaração aud no token de acesso corresponde à API da Web – já que o valor pode variar dependendo de como o cliente solicitou o token.
• O assunto do token é apropriado.
  Determine se o usuário ou aplicativo está autorizado verificando declarações específicas para SUB ou OID ou se o sujeito pertence a uma função ou grupo relevante usando ROLES, GROUPS, and WIDS reivindicações. Use o TID and OID valores de declaração imutáveis ​​como uma chave combinada para dados de aplicativos e acesso de usuário.