O investigador de segurança Justin O'Leary revelou que a Microsoft terá corrigido uma vulnerabilidade crítica no Azure Backup para AKS, após inicialmente rejeitar o relatório e impedir a emissão de um código CVE. Segundo partilhado pelo investigador no seu blogue oficial, a falha permitia uma escalada de privilégios, mas a gigante tecnológica contesta a versão e afirma tratar-se de um comportamento esperado do sistema.
A recusa e o conflito na classificação
O'Leary descobriu o problema em março e comunicou-o no dia 17 do mesmo mês à equipa de segurança da empresa. A resposta, recebida a 13 de abril, rejeitou a submissão sob o argumento de que a execução da falha dependia de privilégios de administrador já existentes por parte do atacante.
O investigador refuta esta justificação, explicando que a falha permitia a um utilizador com permissões mínimas no sistema obter o controlo total como administrador do cluster. Além disso, a submissão para a entidade MITRE foi rotulada pela empresa responsável pelo Azure como conteúdo gerado por inteligência artificial, uma justificação que não abordava os aspetos técnicos do problema reportado. Perante a recusa, O'Leary encaminhou o caso para o CERT Coordination Center, que validou a vulnerabilidade a 16 de abril e atribuiu-lhe o identificador VU#284781. Contudo, a gigante tecnológica interveio a 4 de maio e recomendou a não atribuição de um CVE, exercendo a autoridade final que possui sobre os relatórios dos seus próprios produtos.
Alterações no sistema contrariam versão oficial
A vulnerabilidade funcionava através do Azure Backup para AKS, onde as configurações de acesso de confiança concediam permissões de administração de forma automática dentro dos clusters Kubernetes. Um atacante precisava apenas da função de contribuidor de cópias de segurança num cofre específico para ativar esta relação de confiança, contornando os controlos normais de autorização.
Apesar de um porta-voz da empresa ter afirmado que nenhuma alteração foi efetuada no produto por não considerarem o caso uma falha de segurança, a prática mostra um cenário diferente. O investigador notou que o método de ataque original deixou de funcionar, devolvendo erros que não existiam em março de 2026. O sistema exige agora configurações manuais para o acesso de confiança e foram implementadas verificações de permissões adicionais. A falta de um CVE público impede as equipas de segurança de rastrear a exposição da falha nas suas infraestruturas.
Nenhum comentário
Seja o primeiro!