.
Uma falha de design no Microsoft Azure – que a autorização de chave compartilhada é habilitada por padrão ao criar contas de armazenamento – pode dar aos invasores acesso total ao seu ambiente, de acordo com os pesquisadores da Orca Security.
“Semelhante ao abuso de baldes públicos AWS S3 vistos nos últimos anos, os invasores também podem procurar e utilizar as chaves de acesso do Azure como um backdoor em uma organização”, Roi Nisimi da Orca disse.
Em uma postagem subsequente, Redmond admitiu que “essas permissões podem ser abusadas para obter acesso a recursos adicionais no locatário de um cliente”.
No entanto, após uma investigação mais aprofundada, o Microsoft Security Response Center “determinou que não era um problema de segurança”. Ainda assim, uma vez que “garantia discussão e melhoria para ajudar os clientes a implantar ambientes com menos privilégios e defesa em profundidade para serem mais resilientes contra invasores”, há um blog que visa fornecer essa discussão.
Além disso, em uma data posterior, Redmond diz que as novas contas de armazenamento terão chave compartilhada e autorização de assinatura de acesso compartilhado desativada por padrão, mas não há nenhuma palavra sobre quando isso acontecerá.
A notícia também coincide com o Patch Tuesday de abril, mas definitivamente merece uma pausa rápida na atualização do Windows para desativar o acesso à chave compartilhada. Tanto a Orca quanto a Microsoft sugerem o uso da autenticação do Azure Active Directory.
O problema aqui é que a permissão Microsoft.Storage/storageAccounts/listKeys/action permite operações completas nos dados. Embora os clientes possam conceder essa permissão a usuários dentro de sua organização que precisam de acesso somente leitura aos dados, ela também permite que os dados sejam manipulados ou até excluídos.
Isso, por si só, representa um risco de segurança de dados para as organizações, mas Nisimi explica que chaves de conta de armazenamento excessivamente permissivas também podem ser abusadas para mover lateralmente dentro do ambiente de nuvem.
Como observam Nisimi e Microsoft, há uma conexão entre o Armazenamento do Azure e o Azure Functions, que é o serviço sem servidor do provedor de nuvem. Quando um desenvolvedor implanta um aplicativo de funções, essa ação cria uma conta de armazenamento dedicada que hospeda o código-fonte de todas as funções. Como Nisimi explica:
No cenário de ataque do Orca, um funcionário fictício, Chris Green, recebe a função de colaborador da conta de armazenamento. Se a conta dele for comprometida, os invasores podem manipular os dados da conta de armazenamento.
A partir daqui, no entanto, também é possível comprometer um aplicativo de função, desde que o invasor possa filtrar todas as contas de armazenamento relacionadas à função (e seus compartilhamentos de arquivos relacionados com o código-fonte) e, a partir dessa lista, determinar os objetivos das funções.
Para este exemplo, Orca seleciona uma conta de armazenamento chamada “monitorvms98d0”, porque o nome sugere que ela tem a ver com o monitoramento de máquinas virtuais (VMs). Depois de baixar o arquivo de código, o invasor pode ver que a identidade gerenciada atribuída a este aplicativo de funções pode executar um comando no Provedor do Azure Resource Manager.
“Neste ponto, roubar credenciais e privilégios escalonados, por mais assustador que pareça, é bastante fácil”, disse Nisimi. “Depois que um invasor localiza a conta de armazenamento de um aplicativo de funções atribuído a uma identidade gerenciada forte, ele pode executar o código em seu nome e, como resultado, adquirir uma escalação de privilégio de assinatura (PE)”.
Depois de obter um token de acesso de identidade gerenciada, o invasor fictício de Orca usa uma chamada de API para listar todas as VMs na assinatura, encontra uma VM promissora rotulada como “CustomersDB”, carrega um shell reverso para a VM e, em seguida, define permissões de gravação para a VM, que o invasor agora possui efetivamente.
“Esse cenário de fluxo de ataque é possível se um usuário do AD com permissões listKeys estiver sendo comprometido (como em nosso exemplo), mas também se as strings de conexão/chaves de acesso das contas de armazenamento vazarem”, escreveu Nisimi. “Ao substituir arquivos de função em contas de armazenamento, um invasor pode roubar e exfiltrar uma identidade com privilégios mais altos e usá-la para mover-se lateralmente, explorar e comprometer as joias da coroa mais valiosas das vítimas”.
De sua parte, a Microsoft diz que a pesquisa da Orca “destacou oportunidades para continuarmos a melhorar para ajudar os clientes a configurar corretamente seus ambientes com o mínimo de privilégio”.
“Também estamos planejando orientação e suporte para que novas contas de armazenamento possam ter chave compartilhada e autorização de assinatura de acesso compartilhado (SAS) desativada por padrão para incentivar o uso de acesso baseado em função”, escreveu Redmond. Mas, enquanto isso, sugere que os clientes verifiquem seus atualizar sobre como impor o uso de autorização baseada em identidade para armazenamento usando a Política do Azure. ®
.
