Azure Active Directory abre novos riscos de autenticação

Azure Active Directory abre novos riscos de autenticação. Gerenciamento de acesso e identidade de nuvem híbrida adicionam complexidade e oportunidade para os invasores.

Os serviços de gerenciamento de acesso e identidade de nuvem híbrida adicionam complexidade e oportunidade para os invasores aos processos de autenticação de rede, conforme demonstrado recentemente para o Azure AD.

É de conhecimento comum há anos que as redes locais do Windows Active Directory são vulneráveis a retransmissão NTLM e ataques pass-the-hash que podem permitir que os invasores se movam lateralmente pelas redes e acessem máquinas e recursos adicionais. Como alguns desses ataques exploram decisões de design nos protocolos de autenticação usados nas redes Windows, eles não podem ser simplesmente corrigidos pela Microsoft com alterações no software. As organizações precisam tomar medidas de defesa em profundidade que envolvam configurações mais rígidas e controles adicionais para se protegerem.

Com a adoção de redes híbridas, onde partes das redes são locais e partes estão na nuvem, as empresas agora contam com serviços como o Azure Active Directory (Azure AD) para permitir que suas várias máquinas se autentiquem. Mas o Azure AD é bem diferente do AD local, pois usa protocolos diferentes e possui novos recursos que ampliam as possibilidades de rede das organizações. No entanto, de acordo com apresentações no mês de agosto na conferência de segurança Black Hat USA, ele também oferece novas possibilidades para os invasores.

De pass-the-hash a pass-the-certificate

Pass-the-hash é um ataque que envolve hackers extraindo versões em hash de credenciais armazenadas localmente de uma máquina comprometida e usando-as para autenticar em outras máquinas. A retransmissão NTLM é um método que envolve interceptar solicitações de autenticação entre um cliente e um servidor e retransmitir os desafios e respostas entre os dois para que o invasor seja autenticado em vez do cliente. Esses métodos de ataque são comumente usados por grupos sofisticados de hackers em ataques direcionados.

No Azure AD, no entanto, os ataques tradicionais de passagem de hash e retransmissão não funcionam porque o Azure AD não usa NTLM ou Kerberos, que são os protocolos de autenticação padrão em redes Windows. Em vez disso, ele usa OAuth , SAML , OpenID e um novo protocolo chamado NegoEx, que é uma extensão da GSSAPI (Generic Security Services Application Program Interface) padronizada na qual o Kerberos se baseia.

De acordo com o pesquisador da Microsoft, Mor Rubin, o NegoEx será habilitado em qualquer dispositivo associado ao Azure AD e é o mecanismo através do qual diferentes dispositivos associados ao Azure AD serão autenticados entre si. O handshake de autenticação NegoEx depende de um certificado de cliente exclusivo para cada usuário e é emitido pelo Azure AD com validade de uma hora.

Na Black Hat, Rubin demonstrou como um ataque de retransmissão pode ser executado com sucesso no handshake NegoEx, de maneira semelhante à que pode ser executada contra o NTLM. Ele então mostrou como um invasor pode obter o certificado de cliente ponto a ponto usando um método semelhante e, em seguida, usar esse certificado para autenticar em outras máquinas. Em outras palavras, esses são equivalentes de retransmissão NTML e pass-the-hash, mas no contexto de dispositivos ingressados no Azure AD, apesar da diferença nos protocolos usados.

Ele também sugeriu que as empresas monitorassem seus logs nas máquinas do Azure AD para solicitações de autenticação provenientes de nomes de clientes com endereços IP que não correspondem ou para solicitações de autenticação por meio de certificados emitidos para usuários que não estão associados às máquinas para as quais as solicitações estão chegando. A apresentação de Rubin foi o ponto culminante da pesquisa que ele iniciou no ano passado e também incluiu o lançamento de uma ferramenta de retransmissão NegoEx de código aberto chamada Negoexrelayx .

Abusando de identidades externas no Azure Active Directory

Em uma apresentação separada do Black Hat que destacou as ameaças somente do Azure AD que não existem na implantação do Active Directory local, o pesquisador holandês Dirk-jan Mollema, da Outsider Security, demonstrou como encontrou uma maneira de abusar do recurso de identidades externas para contas de backdoor do Azure AD .

As identidades externas são um recurso do Azure AD em que as organizações podem conceder acesso a determinados recursos aos usuários externos. Esses usuários podem fazer parte de um locatário diferente do Azure AD ou podem ser autenticados por meio de um provedor de identidade externo e identificados apenas por meio de um endereço de email. Essa funcionalidade é popular para organizações que trabalham com contratados externos, bem como para conceder acesso a provedores de serviços gerenciados que gerenciam assinaturas.

Os usuários externos podem ser convidados por alguém com privilégios de administrador por meio da interface do Azure AD e isso fará com que um link de convite seja gerado e enviado por email ao usuário externo. O problema, descobriu Mollema, é que os convites também podem ser gerados e aceitos programaticamente por meio da API do Azure AD chamada AAD Graph.

Além disso, descobriu-se que, ao interagir com esse recurso por meio da API, poucas verificações foram realizadas. Primeiro, qualquer usuário dentro do locatário do Azure AD pode consultar a API e ver os convites que ainda não foram reivindicados. Em segundo lugar, qualquer convite pode ser resgatado por meio da API sem qualquer validação e pode ser vinculado a uma conta externa diferente da pretendida. Em terceiro lugar, os administradores não tinham como saber que um convite foi sequestrado por meio da interface.

O ataque também ignoraria a lista de nomes de domínio permitidos para colaboração externa no locatário do Azure AD porque o convite poderia ser gerado para um endereço de email em um domínio, mas depois ser sequestrado e vinculado a uma conta em um domínio não incluído na lista de permissões. Além disso, pode haver regras automatizadas para dar a uma conta que resgata certos privilégios automatizados de convite, levando ao escalonamento de privilégios.

Mollema levou o ataque ainda mais longe. Ao analisar a aparência das identidades externas no Microsoft Graph, uma API da Microsoft para desenvolvedores, em vez do AAD Graph, ele percebeu que algumas das propriedades associadas a uma identidade poderiam ser modificadas por meio do MS Graph com os privilégios corretos. Um desses atributos é a propriedade do emissor que define o provedor de identidade e uma das opções disponíveis é simplesmente “correio”. Isso é usado para usuários externos que são identificados apenas por email e ainda não possuem uma conta Microsoft ou Azure AD.

Ele então examinou quem pode modificar esses atributos e descobriu que, além dos administradores, os aplicativos nos quais os usuários se conectam e têm os privilégios corretos também podem modificar identidades e os usuários podem modificar sua própria identidade por meio do gráfico do MS. Isso abriu a porta para ataques interessantes, como backdooring de contas existentes, se um invasor obtiver acesso temporário a elas roubando um token de acesso ou obtendo controle temporário sobre um computador em que ele tenha uma sessão ativa.

Além disso, se a conta for um administrador de usuários, eles podem fazer o backdoor de todas as contas adicionando identidades externas a elas e vinculando-as a endereços de e-mail sob o controle dos invasores. Eles também podem fazer isso para administradores globais, pois têm permissão para modificar suas identidades por meio do MS Graph.

O problema com isso é que modificar uma identidade dessa maneira apenas altera seu método de autenticação principal, de um nome de usuário e senha para autenticação por e-mail externo. No entanto, se a conta também tiver autenticação multifator (MFA) configurada, o invasor ainda não conseguirá fazer login.

Mollema também encontrou um desvio para isso. Primeiro, ele usou a conta da vítima temporariamente comprometida para gerar um convite para a conta externa do invasor. O invasor então aceitou o convite, o que resultou na criação de uma conta de convidado para ele no inquilino da vítima. O invasor fez login na conta de convidado e configurou o MFA para ela.

Em seguida, usando a conta da vítima, ele excluiu a conta do convidado. Embora isso exclua a conta de convidado associada à conta externa do invasor, isso não limpa o token MFA, que é armazenado em cache. Portanto, a conta externa do invasor continua a ter um token MFA ativo no locatário do Azure AD da vítima, embora a conta de convidado associada tenha desaparecido. O invasor pode então fazer o backdoor da conta da vítima e adicionar sua conta externa como uma identidade e, então, não será mais solicitada a autenticação MFA. Isso ignora a proteção MFA da vítima.

Mitigação do Azure AD e outras vulnerabilidades de autenticação na nuvem

A Microsoft já corrigiu a maioria dos problemas que Mollema descobriu, então os ataques que ele descreveu não funcionam mais. No entanto, suas descobertas mostram como a autenticação pode ser complexa nos novos ambientes de nuvem. A introdução de novos recursos, como permitir OTP de e-mail como um provedor de identidade ou identidades externas, sempre pode resultar em falhas lógicas que podem permitir desvios.

Mollema aconselha as organizações a remover regularmente todas as contas de convidados com convites não resgatados, bloquear os direitos de convite de convidados e as configurações de acesso de convidados, restringir os locatários permitidos para colaboração externa, impor MFA em todos os aplicativos e procurar logs de acesso em busca de sinais de possível abuso de contas de convidados.