Os administradores do Azure foram alertados pela Microsoft para desabilitarem o acesso de chave compartilhada, após pesquisadores de segurança da Orca Security descobrirem uma falha de design que permite que os invasores acessem todo o ambiente. O acesso compartilhado permite que as chaves compartilhadas de acesso do Azure sejam utilizadas como backdoor para invadir uma organização.
O problema é que a autorização de chave compartilhada é habilitada por padrão ao criar contas de armazenamento no Microsoft Azure, o que pode ser abusado por invasores para obter acesso a recursos adicionais no locatário de um cliente. Essa permissão (Microsoft.Storage/storageAccounts/listKeys/action) permite operações completas nos dados, também pode ser abusada para mover lateralmente dentro do ambiente de nuvem.
Como cita a Orca, a “a Microsoft já recomenda que as chaves compartilhadas de acesso sejam desabilitadas por conta de outros riscos conhecidos, e aconselha a usar a autenticação do Azure Active Directory em seu lugar”, mas pelo menos por enquanto, elas seguem como padrão na criação de novas contas.
O armazenamento do Azure está conectado ao Azure Functions, 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.
A conta de armazenamento de um Aplicativo de Função pode ser encontrada dentro da variável do ambiente AzureWebJobStorage em Configurações do Aplicativo, que inclui uma cadeia de conexão para a conta de armazenamento, juntamente com uma das chaves da conta de armazenamento.
Como funciona o ataque ao Microsoft Azure
Um exemplo de um cenário de ataque é quando um funcionário recebe a função de colaborador da conta de armazenamento e, se a conta dele for comprometida, os invasores podem manipular os dados da conta de armazenamento. É possível comprometer um aplicativo de função se o invasor puder filtrar todas as contas de armazenamento relacionadas à função e determinar os objetivos das funções.
Nesse cenário, a Orca Security selecionou uma conta de armazenamento com o nome “monitorvms98d0”, que sugere estar relacionada ao monitoramento de máquinas virtuais (VMs). Após baixar o arquivo de código, o invasor usa a identidade gerenciada atribuída a este aplicativo de funções para executar um comando no Provedor do Azure Resource Manager.
Depois de obter um token de acesso de identidade gerenciada, o invasor usa uma chamada de API para listar todas as VMs na assinatura, encontra uma VM rotulada como “CustomersDB”, carrega um shell reverso para a VM e, em seguida, define permissões de gravação para a VM. Isso permite que o invasor controle efetivamente a VM.
Problema será resolvido, mas data não foi revelada
O Microsoft Security Reponse Center determinou que o problema não era uma questão de segurança, mas a Microsoft recomendou que os clientes implantem ambientes com menos privilégios e defesa em profundidade para serem mais resilientes contra invasores.
A empresa Microsoft disse que as novas contas de armazenamento terão chave compartilhada e autorização de assinatura de acesso compartilhado desativada por padrão em uma data posterior, mas não especificou quando isso ocorrerá. A Orca Security e a Microsoft sugerem o uso da autenticação do Azure Active Directory como uma medida de segurança preventiva.
Assine nossa Newsletter para receber os melhores conteúdos do Itshow em sua caixa de entrada.
