Blog

A anatomia de um ataque IAM em um ambiente AWS

Imagine a seguinte situação: Após cerca de duas horas, a varredura do site da Acme Inc. estava quase completa. Adriana não tinha encontrado nada e estava prestes a desistir quando de repente: Acesso negado! Com um pouco de pesquisa, ela encontrou um URL com “newtest” nele.

Parecia ser um teste para uma nova página. Interessante, ela pensou, a mudança de idioma se referia a um arquivo local, poderia ser alguma coisa? Sim! A tentativa no IP 169.254.169.254 teve sucesso e ela conseguiu extrair as credenciais da AWS. Ela olhou para ver se alguma das permissões da credencial era útil. A maioria deles tinha baixa permissão de acesso, mas então ela percebeu algo interessante … uma “função” com uma política anexada chamada “devops_stuff_do_not_delete”. Ela examinou esse arquivo. Sim, uma função de administrador que pode ser assumida por qualquer pessoa. Bingo!

Esse tipo de risco de gerenciamento de identidade e acesso (IAM) é muito real. Durante a depuração de um problema, o DevOps dá permissões de administrador para seus testes. Em seguida, um invasor encontra uma vulnerabilidade não corrigida esquecida (neste exemplo, uma vulnerabilidade de falsificação de solicitação do lado do servidor) que permite que ele comprometa uma instância e obtenha credenciais. O invasor então usa essas credenciais para usar a função DevOps com a política permissiva e – a violação ocorre.

IAM em AWS: premissas básicas

Para entender como esse cenário de ataque cibernético do IAM funcionou, vamos começar com uma explicação simples de como o AWS Identity and Access Management funciona. Podemos dividir as políticas de IAM em três componentes principais:

  1. Quem tem acesso ao ambiente? – principal – identidade como um serviço, usuário, função, etc.
  2. O que eles podem fazer? – ações – políticas com permissões como s3: GetObject, ec2: DescribeInstances, etc.
  3. Quais ativos eles podem acessar? – recursos como S3, EC2, Lambda, etc.

ataque IAM

Vulnerabilidade SSRF

Agora, vamos supor que um invasor cibernético encontre um site que está executando um aplicativo sem patch que contém uma vulnerabilidade comum de falsificação de solicitação do lado do servidor (SSRF).

Uma vulnerabilidade SSRF pode permitir que um invasor induza um aplicativo do lado do servidor a fazer solicitações HTTP para um domínio arbitrário de escolha do invasor, por exemplo, a URL da web http://coolwebsite.com/url?eng.php.

Em circunstâncias normais, o site fornecerá a página em inglês via eng.php . No entanto, se um invasor alterar o nome do arquivo eng.php para apontar para um caminho diferente, como um site da Web, o servidor da web obedecerá devidamente a essa solicitação. Agora, se o destino da solicitação for um recurso interno (como o servidor de metadados da instância), ele responderá, pois a origem da solicitação vem de uma fonte interna.

Na AWS, as identidades do usuário são fornecidas com um token de autenticação. Mas e se você quisesse conceder acesso a um serviço ou ferramenta de terceiros ao seu ambiente, ou talvez a um aplicativo como o servidor da web acima?

Não seria fácil criar e manter um usuário para cada serviço / aplicativo / fornecedor. A AWS pensou sobre esse problema e forneceu uma solução chamada função IAM. Uma função não tem nome de usuário / senha ou chave de acesso. Uma função é uma identidade autônoma sem nenhum usuário explícito. Pense nisso como um cartão de embarque para uma conta ou recurso. Este cartão de embarque é pré-concedido com permissões específicas (ou todas as permissões) para ser usado em um serviço específico (ou todos os serviços). As funções podem ser assumidas por outros usuários, outras funções ou serviços AWS.

A capacidade de assumir outro papel

Agora, vamos voltar à Adriana, nossa hacker. Ela usou a função que encontrou na instância por meio de uma vulnerabilidade de SSRF e descobriu que essa função não fornece muito, mas também encontrou uma permissão muito simples e importante que essa função TEM, que é a capacidade de assumir outra função. 

A identidade que deseja assumir a função precisa ter permissões para fazer isso, o que significa que nossa instância de servidor da web (neste exemplo) recebeu permissões para assumir a função que foi encontrada nos metadados da instância. Essa função também tinha suas próprias permissões para assumir outra função. Olhando ao redor, nossa invasora descobriu que havia uma função com permissões pré-concedidas (política) que tinha um nome muito interessante (“devops_stuff_do_not_delete”).

A tentativa de assumir a função foi bem-sucedida, pois a função do servidor da web (agora usada pela nossa hacker) foi autorizada a assumir essa função DevOps E a função DevOps foi permitida a ser assumida por qualquer pessoa. Neste exemplo, a função DevOps tinha permissões muito extensas que davam ao nosso hacker permissões totais para a conta.

A anatomia de um ataque IAM

Agora, podemos dividir a anatomia desse vetor de ataque nas seguintes fases:

  • Vulnerabilidade de SSRF em um servidor da web voltado para a Internet
  • Capacidade de acessar facilmente o serviço de metadados da instância no servidor da web local (sem usar IMDSv2)
  • Ações permitidas (permissões) anexadas à instância, permitindo que ela assuma uma função (sts: PassRole)
  • Ações permitidas (permissões) anexadas à função “DevOps” (política de confiança) que permitem que qualquer pessoa assuma essa função sem restrições
  • Ações permissivas permitidas (permissões de administrador) anexadas à função DevOps sem condições estritas (abordagem de privilégios não mínimos) para usuários, outras funções ou serviços AWS

A configuração do IAM pode ser muito complexa e podem ocorrer configurações incorretas quando as práticas recomendadas não são seguidas. As configurações incorretas do IAM também fornecem muito mais possibilidades para os invasores usarem vetores de ataque de escalonamento de privilégios.

Por exemplo, quando uma função IAM é assumida por uma identidade, essa identidade pode ser uma identidade externa. Isso significa que um usuário ou função que não faz parte da mesma conta que o serviço pode usar essa função para acessar a conta com base nas permissões da função.

Como detectar a configuração correta

A equipe de pesquisa de segurança da Orca Security tem vários exemplos sobre esse erro de configuração que leva ao ataque IAM. Na maioria das vezes, eles são causados ​​pela falta de um esquema IAM complexo ou apenas por erro humano (como quando um engenheiro de QA precisa de uma “função” para conduzir um teste urgente e coloca um * no recurso e se esquece de limpá-lo mais tarde). Uma boa limpeza do IAM significa seguir a abordagem de privilégios mínimos e limpar funções / usuários / grupos e permissões não mais necessários ou nunca usados. Vejamos alguns exemplos de configurações incorretas comuns que encontramos diariamente no Orca:

Acesso entre contas sem ID externo: alerta para qualquer função que permite que seja usado de uma conta externa sem medidas de segurança extras, como condições. Já vimos esse alerta pelo menos uma vez em 73% de nossos clientes, enquanto o maior número de alertas por organização é de 50%.

Perfil de instância com privilégios de administrador – alerta em qualquer instância que tenha uma função anexada com políticas de administrador anexadas. Já vimos esse alerta pelo menos uma vez em 33% de nossos clientes, enquanto o maior número de alertas por organização é de 58%.

A maioria das organizações tem informações confidenciais que os invasores procuram, como bancos de dados, repositórios privados, documentos, e-mails, etc. Algumas são protegidas usando o mecanismo de IAM das Políticas de Controle de Serviço e outras são protegidas por outros meios, como chaves privadas, senhas, limites de rede (como segurança grupos e ACLs). De qualquer forma, uma vez que um invasor encontre uma maneira de se mover lateralmente na conta, é apenas uma questão de tempo (e um pouco de sorte) até que suas informações mais confidenciais se encontrem magicamente fora de sua organização.

Como detectar configurações incorretas do IAM antes de um hacker

Para evitar o cenário acima, as equipes de DevOps precisam ser capazes de detectar configurações incorretas de IAM e oportunidades de movimento lateral antes de um invasor. É improvável que isso aconteça se você estiver usando uma solução de gerenciamento de postura de segurança em nuvem (CSPM), que se concentra apenas nos dados do plano de controle. Olhando apenas os dados que vêm da API do provedor de nuvem (e não dados de carga de trabalho), pode-se perder as chaves de autenticação salvas em ativos locais, configurações incorretas em servidores, segredos ocultos à vista de todos como em documentos, notas, scripts, variáveis ​​de ambiente, e assim por diante.

A resposta é usar algo que o Gartner chama de plataforma de proteção de aplicativos nativos em nuvem (CNAPP), como o Orca. Um CNAPP analisa o plano da infraestrutura em nuvem e as cargas de trabalho para fornecer a você uma visão completa de ambos. Assim, o Orca encontra segredos, configurações incorretas de IAM e vulnerabilidades no plano da infraestrutura da nuvem E nas cargas de trabalho.

E com sua abordagem sem agente, o Orca oferece 100% de cobertura ao verificar todas as cargas de trabalho sem lacunas na cobertura, para que você possa trabalhar na velocidade de DevOps.

Quer saber como podemos ajudar a sua empresa a proteger os dados na nuvem? Agende uma demonstração conosco e aumente a segurança da sua estrutura cloud.

A transformação começa agora.