Como encontrar novas primitivas de ataque no Microsoft Azure

Como encontrar novas primitivas de ataque no Microsoft Azure. As primitivas de abuso têm uma vida útil mais longa do que bugs e zero-days e são mais baratas de manter. Eles também são muito mais difíceis para os defensores detectarem e bloquearem.

A receita de serviços em nuvem da Microsoft cresceu 46% no primeiro trimestre de 2022 e sua participação no mercado de nuvem aumentou quase 9%  desde 2017. Com o Azure finalmente sendo usado a sério pelo mainstream, agora é o momento ideal para se envolver e pesquisar o abuso do Azure. Existem muitas primitivas de abuso não descobertos por aí, muitas dívidas de configuração incorreta acumuladas e um número crescente de adversários começando a atacar o Azure com mais seriedade.

Por que gastar tempo procurando por primitivas de abuso em vez de bugs ou explorações de software? Os abusos têm uma vida útil muito mais longa do que os bugs e os dias zero, e são mais baratos de manter. Mais importante para os invasores, eles existem em quase todas as implementações do software em questão e são muito mais difíceis para os defensores detectarem e bloquearem. É por isso que é vital que os pesquisadores descubram novas opções de abuso para que possam ser corrigidas ou mitigadas.

Aqui está um processo de cinco etapas, escrito por Andy Robbins publicado pelo DarkReading, para pesquisar um sistema específico no Azure e tentar encontrar novas primitivas de ataque. Seguir essa abordagem ajudará você a economizar tempo, permanecer no caminho certo e produzir melhores resultados.

Primeiro passo: comece com o fim em mente

Primeiro, você precisará entender como o sistema de sua escolha funciona, como ele interage com outros sistemas no Azure e como pode ser abusado. Além disso, pense em qual será o seu produto final – uma postagem no blog? Uma sessão de conferência? Diretrizes de remediação defensiva ou atualizações para uma ferramenta de código aberto? Determine o que é necessário para criar esses ativos. Considere também a produção de código de auditoria, para que os defensores possam verificar essas configurações perigosas e também o código de abuso, para que outros possam verificar facilmente como essas configurações podem ser abusadas. Esses são os “critérios de sucesso” para sua pesquisa que o ajudarão a manter o foco, evitar tocas de coelho desnecessárias e garantir um resultado final valioso.

Etapa dois: estudar a intenção e o design do sistema

Depois de saber exatamente o que você precisa descobrir, comece a pesquisar como qualquer outra pessoa faria – fazendo pesquisas no Google e lendo a documentação oficial. Procure por qualquer coisa que pareça passível de abuso (como a capacidade de redefinir senhas e permissões necessárias), aprofunde-se nelas e faça anotações à medida que avança.

Use o LinkedIn para identificar quaisquer arquitetos de produtos ou outros funcionários da Microsoft envolvidos na criação do assunto de seu estudo. Revise os feeds do LinkedIn e do Twitter e procure os recursos que eles criaram ou republicaram (postagens em blogs, apresentações em conferências etc.). Aprofunde-se em recursos da comunidade, como fóruns ou repositórios GitHub associados a este serviço, pois esses grupos de usuários geralmente são muito mais abertos em seu discurso sobre problemas e fraquezas do que o pessoal da Microsoft. Continue anotando no sistema. Assim que você puder falar de forma inteligente sobre a arquitetura e a intenção do sistema e escrever um resumo não técnico e altamente preciso sobre ele, você estará pronto para seguir em frente.

Terceiro Passo: Explorar o Sistema

A documentação só pode levá-lo até certo ponto — ela não acompanha as alterações no Azure e quase sempre há conexões ocultas que não são documentadas. É tentador pular direto para esta etapa, mas sem o contexto do sistema que você construiu por meio da pesquisa, você provavelmente perderá muito tempo.

Comece a explorar o sistema com a interface mais fácil — geralmente essa é a GUI do portal do Azure. Se você abrir as ferramentas do desenvolvedor no navegador Chrome, poderá ver todas as solicitações de API que o navegador está fazendo. Copie-os para o PowerShell e você terá um bom começo para criar seu próprio cliente. Use as ferramentas oficiais da CLI no Azure (az binary, o módulo Az PowerShell e o módulo Azure AD PowerShell).

Quando você explorou o suficiente para construir seu próprio cliente básico para interagir com o sistema, é hora de prosseguir. Isso fornece uma base para um cliente mais maduro e para automatizar o processo de teste de recursos de abuso.

Etapa quatro: recursos de abuso do catálogo

Agora você pode usar seu cliente para enumerar todas as permissões que esse sistema pode atribuir e testar as primitivas de abuso que você já conhece em relação a cada uma dessas permissões (por exemplo, você pode se promover a administrador global ou alterar a senha de um administrador global?). Fique de olho em outras primitivas de abuso que possam se apresentar durante sua pesquisa – e teste-os também para revelar quaisquer discrepâncias entre o que a documentação oficial diz e como as coisas funcionam na realidade.

Realisticamente, você precisará automatizar esse processo. Quando o autor passou por essa metodologia de pesquisa examinando a API do Azure Graph, ele tinha uma lista de cerca de 175 permissões e uma dúzia de primitivas de abuso para testar em cada uma delas… faça as contas.

Etapa cinco: compartilhar descobertas

O passo final é ajudar os outros a aprender com o seu trabalho. Escreva um post no blog (pode enviar aqui e publicamos no Minuto da Segurança), faça uma palestra e/ou compartilhe seu código. O objetivo é ajudar os outros a economizar tempo e expandir ou complementar seu trabalho. Pense nisso como escrever o post do blog que você precisava no início de sua pesquisa.

Fonte: DarkReading

Veja também:

About mindsecblog 2774 Articles
Blog patrocinado por MindSec Segurança e Tecnologia da Informação Ltda.

Be the first to comment

Deixe sua opinião!