Resumo executivo da vulnerabilidade do AutoWarp

• O AutoWarp é uma vulnerabilidade crítica encontrada no serviço de automação do Azure que permite acesso ao servidor interno que gerencia o Azure Sandbox.
• Os serviços da Web estão sendo executados localmente em portas altas aleatórias e os tokens JWT têm ID de assinatura, ID de inquilino e ID de recurso da conta de automação.
• Essas portas aleatórias fornecem o JWT das contas do Azure de outras pessoas aos invasores, que podem ser usadas posteriormente para acessar as contas.

Serviço de automação do Microsoft Azure

O Microsoft Azure é um serviço de automação de processos baseado em nuvem que também oferece serviços de computação, análise, rede e armazenamento. Os usuários podem aproveitar a Automação do Microsoft Azure para executar o código de automação em um ambiente controlado. Eles também podem criar e programar trabalhos, além de fornecer entradas e saídas. O código de automação de cada usuário é separado do código de outros usuários em execução na mesma máquina virtual em uma sandbox.

O que é a vulnerabilidade de segurança de automação do AutoWarp?

O AutoWarp é uma vulnerabilidade crítica no serviço de Automação do Azure que permite acesso não autorizado a outras contas de clientes do Azure. Dependendo das permissões concedidas pelo cliente, esse ataque pode resultar em controle total sobre os recursos e dados da conta de destino. Usando JWT (JSON Web Tokens) expostos, a vulnerabilidade permite acesso não autorizado às contas do Azure de outras pessoas. Essa exploração foi executada fazendo uma solicitação GET para descobrir endpoints locais, o que, por sua vez, expôs o token JWT ao pesquisador. Se for concedida permissão suficiente, o token JWT será mapeado diretamente para a identidade gerenciada, concedendo acesso à conta. Qualquer usuário que esteja usando o serviço de Automação do Azure está vulnerável à vulnerabilidade do AutoWarp. Além disso, qualquer conta de usuário que tenha o recurso de identidade gerenciada da conta de automação ativado (geralmente ativado por padrão) fica imediatamente suscetível à vulnerabilidade. A Microsoft mitigou o problema bloqueando o acesso aos tokens de Identidades Gerenciadas em todos os ambientes de sandbox, exceto aquele que tinha acesso legítimo. O AutoWarp é a terceira grande falha divulgada no Azure mais recentemente. O Azure também expôs a vulnerabilidade de execução remota de código OHMIGOD em setembro de 2021 e a vulnerabilidade NotLegit hole em dezembro de 2021, que permitia downloads não autorizados de arquivos e persistiu por quatro anos.

Cronograma do AutoWarp Discovery

• 6 de dezembro de 2021: A vulnerabilidade do AutoWarp foi identificada e divulgada à Microsoft.
• 7 de dezembro de 2021: Grandes empresas, incluindo uma empresa global de telecomunicações, dois fabricantes de automóveis, um conglomerado bancário, quatro grandes empresas de contabilidade, etc., foram identificadas como afetadas por essa falha.
• 10 de dezembro de 2021: A Microsoft corrigiu a vulnerabilidade e começou a examinar mais iterações do ataque.
• 7 de março de 2022: A investigação da Microsoft foi concluída e os resultados foram divulgados.

[caption id="attachment_19252" align="alignnone” width="1582"] Cronograma de descoberta de vulnerabilidades do AutoWarp [/caption]

Informações da Pesquisa

• A estrutura do arquivo tem dois diretórios dentro do C: Dirija nomeado Orquestrador e temperatura. O orquestrador, por sua vez, contém um nome de arquivo chamado caixa de areia que pode conter detalhes sobre como executar a sandbox. O diretório temporário contém um arquivo chamado”trace.log” dentro do diretório “diags”.

[caption id="attachment_19253" align="alignnone” width="778"] Imagem da estrutura do arquivo [/caption]

• O arquivo trace.log contém um endpoint muito intrigante que indica a presença de um serviço web executado localmente em portas aleatórias com números de portas muito altos, em torno de 40.000.

[caption id="attachment_19254" align="alignnone” width="1178"] Imagem do arquivo de log presente no Orchestrator Directory [/caption]

• O diretório do Orchestrator contém código.NET, que divulga duas rotas, a saber”/oauth2/token” e”/metadados/identidade/oauth2/token,” mapeado para um controlador chamado MSIController.

[caption id="attachment_19255" align="alignnone” width="1024"] Código-fonte dos serviços de automação [/caption]

• Essa classe MSIController contém um método chamado”Obtenha o token MSI,” que pode ser usado para obter o token de acesso usando o parâmetro GET mencionado na função.
• Depois que a solicitação é enviada com sucesso, o JWT, que contém informações como ID de assinatura, ID do inquilino e ID do recurso da conta de automação, é fornecido.
• O token recebido pode ser validado usando a CLI do Azure e, se as permissões apropriadas estiverem habilitadas para scripts de automação, ele será mapeado com a identidade gerenciada.

[caption id="attachment_19256" align="alignnone” width="1024"] Código-fonte para obter o token de acesso usando o método GET [/caption]

• Não há mal nenhum em mapear o token com a identidade gerenciada. A principal falha ocorre com o serviço local em execução nessas portas altamente aleatórias. Quando uma operação automatizada é executada, as portas mudam, mas permanecem dentro de um determinado intervalo de 40.000.
• Agora que cada porta aleatória é conhecida por fornecer um JWT. Como essas portas fornecem um novo endpoint que pertence às contas do Azure de outros usuários, isso indica diretamente que podemos acessar o JWT de outras contas do Azure de usuários. E se as permissões fornecidas forem suficientes, o invasor obterá acesso completo à sua conta do Azure.

Impacto e mitigação

ImpactoComo você pode mitigar a vulnerabilidade do AutoWarp

• Um invasor tem acesso a informações confidenciais vinculadas à conta do Azure, como ID de assinatura, ID de inquilino etc.
• Um invasor pode obter acesso não autorizado à conta do Azure de qualquer usuário.
• Um invasor também tem acesso total aos recursos e dados que podem ser abusados.
• Um atacante remoto pode aproveitar as informações para encadear o ataque e expandir a superfície de ataque.

• A Microsoft introduziu um novo cabeçalho HTTP chamado “X-IDENTITY-HEADER”, que é necessário ao solicitar identidades e deve ser definido como um valor secreto nas variáveis de ambiente. O valor dentro dele é comparado com o valor secreto armazenado na variável de ambiente e, se esses valores corresponderem com sucesso, a identidade será confirmada, caso contrário, o acesso será negado.
• Por favor, consulte Diretrizes de segurança de automação do Azure.

Referências

1. Blog de Yanir Tsarimi: https://orca.security/resources/blog/autowarp-microsoft-azure-automation-service-vulnerability/
2. Lançamento oficial do MSRC:https://msrc-blog.microsoft.com/2022/03/07/13943/