Confused Deputy no Azure Backup e AKS expõe organizações sem CVE

Um pesquisador em segurança afirma que a Microsoft resolveu de forma silenciosa uma vulnerabilidade crítica no Azure Backup para AKS após recusar seu relatório e bloquear a emissão de um CVE, deixando as organizações sem uma forma clara de medir sua exposição. Segundo o pesquisador, a falha permitia escalar privilégios desde o papel de baixa confiança "Backup Contributor" até permissões de cluster-admin em Kubernetes, explorando a forma como o Azure configura relações de Trusted Access para backups.

A técnica descrita encaixa no que a comunidade conhece como um ataque de tipo Confused Deputy, onde a interação entre Azure RBAC e Kubernetes RBAC quebra as barreiras de autorização esperadas e permite que uma identidade com permissões limitadas active a elevação. O próprio relatório técnico do pesquisador explica como ativar o suporte de backup em um cluster objetivo forzaba ao Azure para criar links de confiança com privilégios de administrador em Kubernetes, operações que poderiam ser usadas para extrair segredos ou restaurar cargas maliciosas no cluster; ver a explicação original aqui: olearysec.com.

A cronologia que facilita o caso mostra tensões habituais em processos de divulgação responsável: a descoberta e envio inicial ocorreu em março, a Microsoft Security Response Center (MSRC) recusou a qualificação como vulnerabilidade alegando que o ataque requeria acesso administrativo prévio, e a discussão escalou a CERT/CC, que validou a falha e atribuiu-lhe um identificador (VU#284781). Posteriormente, a Microsoft pediu ao MITRE que não lhe fosse atribuído um CVE, e a aplicação das regras de hierarquia da CNAs deixou nas mãos da Microsoft a faculdade final para emitir ou não o CVE; as regras CNA estão disponíveis em: cve.org. O episódio foi relatado publicamente por meios especializados que cobrem a disputa e a aparente correção: BleepingComputer.

O mais preocupante para defensores é que, após a divulgação, o pesquisador observou mudanças operacionais que impediram reproduzir o exploit original: agora são necessários passos manuais para configurar Trusted Access e aparecem verificações de permissões adicionais nas identidades geridas pelo vault e pelo cluster, algo que sugere uma correção aplicada do lado do fornecedor sem aviso formal. Microsoft afirma que não se fizeram "mudanças de produto" porque o comportamento anterior, segundo sua avaliação, era esperado; o pesquisador e CERT/CC discrepan dessa interpretação.

Este caso tem várias implicações práticas e de governo de segurança. Sem um CVE nem um advisory público, as equipes de segurança não podem quantificar o número de recursos expostos, a janela temporária do risco ou priorizar remediações em função de um inventário afetado. Além disso, as correcções silenciosas dificultam a validação independente de mitigações e reduzem a rastreabilidade legal e operacional em ambientes regulamentados. A disputa também revela frições na triage de relatórios, incluindo a menção, controversa, de conteúdos "gerados por IA" como fator que distrai da análise técnica.

Para equipes de segurança que gestionem AKS e Azure Backup, recomendo agir imediatamente: audite e liste todas as designações do papel Backup Contributor em todos os vaults e assinaturas, confirme se alguma identidade gerenciada (MSI) tem permissões inesperadas sobre clusters ou grupos de recursos de snapshots, e verifique a configuração do Trusted Access nos clusters AKS. Active e reveja logs de controle de acessos, alertas de mudanças em bindings de RBAC e operações de habilitação de backups, e considere rotar segredos/credenciais que poderiam ter sido comprometidas. Implemente políticas de menor privilégio e restrições administrativas sobre quem pode ativar backups e gerenciar identidades do vault, e use Azure Policy e Azure Monitor para automatizar detecção e bloqueio de mudanças não autorizadas.

Além disso, documente e registre qualquer interação com o fornecedor: solicite confirmação escrita das mudanças aplicadas, prazos e escore de mitigação, e exija um advisory técnico ou um CVE que permita rastrear a exposição em ferramentas de gestão de vulnerabilidades. Se gerir ambientes com requisitos de conformidade, inclua esta revisão na próxima auditoria de controlo de acesso e nos processos de gestão de riscos.

O episódio sublinha uma necessidade mais ampla: os programas de divulgação e as hierarquias da CNAs devem equilibrar a proteção do ecossistema e a transparência para os clientes. Enquanto não houver um mecanismo que alinhasse incentivos para notificar as correcções e emitir CVEs de forma imparcial quando adequado, organizações e defensores continuarão a enfrentar uma janela de visibilidade insuficiente que complica a mitigação efetiva de riscos na nuvem.