Az - Tokens & Public Applications
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Entra ID é a plataforma de gerenciamento de identidade e acesso (IAM) baseada em nuvem da Microsoft, servindo como o sistema fundamental de autenticação e autorização para serviços como Microsoft 365 e Azure Resource Manager. O Azure AD implementa o framework de autorização OAuth 2.0 e o protocolo de autenticação OpenID Connect (OIDC) para gerenciar o acesso a recursos.
Principais Participantes no OAuth 2.0:
Servidor de Recursos (RS): Protege recursos pertencentes ao proprietário do recurso.
Proprietário do Recurso (RO): Normalmente um usuário final que possui os recursos protegidos.
Aplicação Cliente (CA): Uma aplicação que busca acesso a recursos em nome do proprietário do recurso.
Servidor de Autorização (AS): Emite tokens de acesso para aplicações clientes após autenticar e autorizar.
Escopos e Consentimento:
Escopos: Permissões granulares definidas no servidor de recursos que especificam níveis de acesso.
Consentimento: O processo pelo qual um proprietário de recurso concede a uma aplicação cliente permissão para acessar recursos com escopos específicos.
Integração com Microsoft 365:
O Microsoft 365 utiliza o Azure AD para IAM e é composto por várias aplicações OAuth "de primeira parte".
Essas aplicações estão profundamente integradas e frequentemente têm relações de serviço interdependentes.
Para simplificar a experiência do usuário e manter a funcionalidade, a Microsoft concede "consentimento implícito" ou "pré-consentimento" a essas aplicações de primeira parte.
Consentimento Implícito: Certas aplicações são automaticamente concedidas acesso a escopos específicos sem aprovação explícita do usuário ou administrador.
Esses escopos pré-consentidos geralmente estão ocultos tanto para usuários quanto para administradores, tornando-os menos visíveis nas interfaces de gerenciamento padrão.
Tipos de Aplicações Cliente:
Clientes Confidenciais:
Possuem suas próprias credenciais (por exemplo, senhas ou certificados).
Podem se autenticar de forma segura no servidor de autorização.
Clientes Públicos:
Não possuem credenciais únicas.
Não podem se autenticar de forma segura no servidor de autorização.
Implicação de Segurança: Um atacante pode se passar por uma aplicação cliente pública ao solicitar tokens, pois não há mecanismo para o servidor de autorização verificar a legitimidade da aplicação.
Existem três tipos de tokens usados no OIDC:
Tokens de Acesso: O cliente apresenta este token ao servidor de recursos para acessar recursos. Ele pode ser usado apenas para uma combinação específica de usuário, cliente e recurso e não pode ser revogado até a expiração - que é de 1 hora por padrão.
Tokens de ID: O cliente recebe este token do servidor de autorização. Ele contém informações básicas sobre o usuário. Ele é vinculado a uma combinação específica de usuário e cliente.
Tokens de Atualização: Fornecidos ao cliente com o token de acesso. Usados para obter novos tokens de acesso e ID. Ele é vinculado a uma combinação específica de usuário e cliente e pode ser revogado. A expiração padrão é 90 dias para tokens de atualização inativos e sem expiração para tokens ativos (é possível obter novos tokens de atualização a partir de um token de atualização).
Um token de atualização deve estar vinculado a um aud
, a alguns escopos, e a um inquilino e deve ser capaz de gerar tokens de acesso apenas para esse aud, escopos (e nada mais) e inquilino. No entanto, este não é o caso com tokens de aplicações FOCI.
Um token de atualização é criptografado e apenas a Microsoft pode descriptografá-lo.
Obter um novo token de atualização não revoga o token de atualização anterior.
Informações para acesso condicional são armazenadas dentro do JWT. Portanto, se você solicitar o token de um endereço IP permitido, esse IP será armazenado no token e então você pode usar esse token de um IP não permitido para acessar os recursos.
O campo indicado no campo "aud" é o servidor de recursos (a aplicação) usado para realizar o login.
O comando az account get-access-token --resource-type [...]
suporta os seguintes tipos e cada um deles adicionará um "aud" específico no token de acesso resultante:
Note que os seguintes são apenas as APIs suportadas por az account get-access-token
, mas há mais.
O escopo de um token de acesso é armazenado dentro da chave scp dentro do JWT do token de acesso. Esses escopos definem a que o token de acesso tem acesso.
Se um JWT tiver permissão para contatar uma API específica, mas não tiver o escopo para realizar a ação solicitada, ele não poderá realizar a ação com esse JWT.
Anteriormente, foi mencionado que os tokens de atualização devem estar vinculados aos escopos com os quais foram gerados, à aplicação e ao inquilino para os quais foram gerados. Se qualquer um desses limites for quebrado, é possível escalar privilégios, pois será possível gerar tokens de acesso para outros recursos e inquilinos aos quais o usuário tem acesso e com mais escopos do que originalmente pretendido.
Além disso, isso é possível com todos os tokens de atualização na plataforma de identidade da Microsoft (contas Microsoft Entra, contas pessoais da Microsoft e contas sociais como Facebook e Google) porque, como mencionam os docs: "Os tokens de atualização estão vinculados a uma combinação de usuário e cliente, mas não estão vinculados a um recurso ou inquilino. Um cliente pode usar um token de atualização para adquirir tokens de acesso em qualquer combinação de recurso e inquilino onde tenha permissão para fazê-lo. Os tokens de atualização são criptografados e apenas a plataforma de identidade da Microsoft pode lê-los."
Além disso, observe que as aplicações FOCI são aplicações públicas, portanto nenhum segredo é necessário para autenticar no servidor.
Então, os clientes FOCI conhecidos relatados na pesquisa original podem ser encontrados aqui.
Seguindo com o código de exemplo anterior, neste código é solicitado um novo token para um escopo diferente:
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)