Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
As políticas de Acesso Condicional do Azure são regras configuradas no Microsoft Azure para impor controles de acesso a serviços e aplicativos do Azure com base em certas condições. Essas políticas ajudam as organizações a proteger seus recursos aplicando os controles de acesso corretos nas circunstâncias adequadas. As políticas de acesso condicional basicamente definem Quem pode acessar O que de Onde e Como.
Aqui estão alguns exemplos:
Política de Risco de Login: Esta política pode ser configurada para exigir autenticação multifator (MFA) quando um risco de login é detectado. Por exemplo, se o comportamento de login de um usuário for incomum em comparação com seu padrão regular, como fazer login de um país diferente, o sistema pode solicitar autenticação adicional.
Política de Conformidade de Dispositivo: Esta política pode restringir o acesso aos serviços do Azure apenas a dispositivos que estejam em conformidade com os padrões de segurança da organização. Por exemplo, o acesso pode ser permitido apenas a partir de dispositivos que tenham software antivírus atualizado ou que estejam executando uma determinada versão do sistema operacional.
É possível que uma política de acesso condicional esteja verificando algumas informações que podem ser facilmente manipuladas, permitindo um bypass da política. E se, por exemplo, a política estiver configurando MFA, o atacante poderá contorná-la.
Ao configurar uma política de acesso condicional, é necessário indicar os usuários afetados e os recursos-alvo (como todos os aplicativos em nuvem).
Também é necessário configurar as condições que irão disparar a política:
Rede: IP, intervalos de IP e localizações geográficas
Pode ser contornado usando uma VPN ou Proxy para se conectar a um país ou conseguindo fazer login a partir de um endereço IP permitido
Riscos da Microsoft: Risco do usuário, risco de login, risco interno
Plataformas de dispositivos: Qualquer dispositivo ou selecionar Android, iOS, Windows phone, Windows, macOS, Linux
Se “Qualquer dispositivo” não estiver selecionado, mas todas as outras opções estiverem selecionadas, é possível contornar usando um user-agent aleatório não relacionado a essas plataformas
Aplicativos cliente: As opções são “Navegador”, “Aplicativos móveis e clientes de desktop”, “Clientes Exchange ActiveSync” e “Outros clientes”
Para contornar o login com uma opção não selecionada
Filtro para dispositivos: É possível gerar uma regra relacionada ao dispositivo usado
Fluxos de autenticação: As opções são “Fluxo de código de dispositivo” e “Transferência de autenticação”
Isso não afetará um atacante, a menos que ele esteja tentando abusar de qualquer um desses protocolos em uma tentativa de phishing para acessar a conta da vítima
Os possíveis resultados são: Bloquear ou Conceder acesso com condições potenciais como exigir MFA, dispositivo em conformidade...
É possível definir uma condição com base na plataforma do dispositivo (Android, iOS, Windows, macOS...), no entanto, isso é baseado no user-agent, então é fácil de contornar. Mesmo fazendo todas as opções exigirem MFA, se você usar um user-agent que não é reconhecido, você poderá contornar o MFA ou bloqueio:
Basta fazer o navegador enviar um user-agent desconhecido (como Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile) para não disparar essa condição.
Você pode alterar o user agent manualmente nas ferramentas de desenvolvedor:
Ou usar uma extensão de navegador como esta.
Se isso estiver configurado na política condicional, um atacante pode simplesmente usar uma VPN no país permitido ou tentar encontrar uma maneira de acessar a partir de um endereço IP permitido para contornar essas condições.
É possível configurar políticas de acesso condicional para bloquear ou forçar, por exemplo, MFA quando um usuário tenta acessar um aplicativo específico:
Para tentar contornar essa proteção, você deve ver se consegue entrar em qualquer aplicativo. A ferramenta AzureAppsSweep tem dezenas de IDs de aplicativos codificados e tentará fazer login neles e informá-lo, e até mesmo fornecer o token se for bem-sucedido.
Para testar IDs de aplicativos específicos em recursos específicos, você também pode usar uma ferramenta como:
Além disso, também é possível proteger o método de login (por exemplo, se você está tentando fazer login pelo navegador ou por um aplicativo de desktop). A ferramenta Invoke-MFASweep realiza algumas verificações para tentar contornar essas proteções também.
A ferramenta donkeytoken também pode ser usada para propósitos semelhantes, embora pareça não estar mantida.
A ferramenta ROPCI também pode ser usada para testar essas proteções e ver se é possível contornar os MFAs ou bloqueios, mas essa ferramenta funciona a partir de uma perspectiva whitebox. Você primeiro precisa baixar a lista de aplicativos permitidos no inquilino e, em seguida, tentará fazer login neles.
Uma opção de Azure MFA é receber uma chamada no número de telefone configurado onde será solicitado ao usuário que envie o caractere #.
Como os caracteres são apenas tons, um atacante poderia comprometer a mensagem de correio de voz do número de telefone, configurando como mensagem o tom de # e, em seguida, ao solicitar o MFA, garantir que o telefone da vítima esteja ocupado (ligando para ele) para que a chamada do Azure seja redirecionada para o correio de voz.
As políticas frequentemente exigem um dispositivo compatível ou MFA, então um atacante poderia registrar um dispositivo compatível, obter um token PRT e contornar assim o MFA.
Comece registrando um dispositivo compatível no Intune, depois obtenha o PRT com:
Encontre mais informações sobre esse tipo de ataque na página a seguir:
Az - Pass the PRTEste script obtém algumas credenciais de usuário e verifica se pode fazer login em alguns aplicativos.
Isso é útil para ver se você não precisa de MFA para fazer login em alguns aplicativos que você pode posteriormente abusar para escalar privilégios.
Obtenha todas as políticas.
MFASweep é um script PowerShell que tenta fazer login em vários serviços da Microsoft usando um conjunto de credenciais fornecido e tentará identificar se o MFA está habilitado. Dependendo de como as políticas de acesso condicional e outras configurações de autenticação multifatorial estão configuradas, alguns protocolos podem acabar sendo deixados como fator único. Ele também possui uma verificação adicional para configurações de ADFS e pode tentar fazer login no servidor ADFS local se detectado.
Esta ferramenta ajudou a identificar contornos de MFA e, em seguida, abusar de APIs em vários locatários AAD de produção, onde os clientes AAD acreditavam ter MFA aplicado, mas a autenticação baseada em ROPC foi bem-sucedida.
Você precisa ter permissões para listar todos os aplicativos para poder gerar a lista dos aplicativos a serem forçados.
Donkey token é um conjunto de funções que visa ajudar consultores de segurança que precisam validar Políticas de Acesso Condicional, testes para portais Microsoft com 2FA habilitado, etc..
Teste cada portal se é possível fazer login sem MFA:
Porque o portal Azure não é restrito, é possível coletar um token do endpoint do portal para acessar qualquer serviço detectado pela execução anterior. Neste caso, o Sharepoint foi identificado, e um token para acessá-lo é solicitado:
Supondo que o token tenha a permissão Sites.Read.All (do Sharepoint), mesmo que você não consiga acessar o Sharepoint pela web por causa do MFA, é possível usar o token para acessar os arquivos com o token gerado:
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
