Os 5 Erros de Configuração Mais Críticos em Ambientes AWS Encontrados em Pentests

A migração acelerada para nuvem trouxe flexibilidade sem precedentes, mas também transferiu a superfície de ataque para erros de configuração em Identity and Access Management (IAM) e arquitetura de rede.

Em auditorias recentes conduzidas pela Nexo Security em fintechs e empresas de software, mapeamos padrões recorrentes de configurações permissivas que transformam uma aplicação web com vulnerabilidade modesta em um comprometimento total da infraestrutura de nuvem.

Abaixo, detalhamos os 5 vetores mais críticos e como solucioná-los.

---

1. Persistência do IMDSv1 em Instâncias EC2

O Instance Metadata Service (IMDS) permite que códigos em execução dentro de instâncias EC2 obtenham credenciais temporárias do perfil IAM anexado à máquina.

Na versão 1 (IMDSv1), a comunicação é baseada em simples requisições GET HTTP sem autenticação por cabeçalho:

# Vetor explorado via Server-Side Request Forgery (SSRF)
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/AppRole

Se sua aplicação web possuir qualquer falha de SSRF (mesmo simples geradores de PDF ou webhooks), um atacante externo pode extrair AccessKeyId, SecretAccessKey e Token em segundos.

Como Corrigir:

Force a exigência do IMDSv2, que demanda um token de sessão obtido via PUT com contagem de saltos (hop-limit configurado para 1):

aws ec2 modify-instance-metadata-options \
    --instance-id i-0123456789abcdef0 \
    --http-tokens required \
    --http-put-response-hop-limit 1

---

2. Permissões de Escalação de Privilégio em Políticas IAM

Políticas que contêm combinações como iam:PassRole e ec2:RunInstances (ou lambda:CreateFunction + lambda:InvokeFunction) permitem que um desenvolvedor com privilégios limitados crie um recurso com permissões de AdministratorAccess e execute comandos dentro dele.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole",
        "lambda:CreateFunction",
        "lambda:CreateFunctionUrl"
      ],
      "Resource": "*"
    }
  ]
}

Em nossos pentests, uma chave vazada com essa política é suficiente para assumir o controle total da conta da organização.

---

3. Buckets S3 com ‘Block Public Access’ Desabilitado

Apesar dos alertas visuais da AWS, ainda encontramos buckets S3 contendo dumps de banco de dados, backups de sessões e uploads de clientes sem a flag global de bloqueio ativada:

• Falha em habilitar o bloqueio no nível da conta AWS (Account-Level Block Public Access).
• Utilização indevida de políticas com Principal: "*" combinada a condições frouxas.

---

4. Grupos de Segurança Expondo Portas Administrativas (0.0.0.0/0)

Regras de Security Group expondo portas sensíveis para toda a internet ainda são a causa primária de ataques automatizados de força bruta e exploração de zero-days:

Porta	Serviço	Risco Principal
22	SSH	Força bruta e credenciais vazadas
3389	RDP	Ransomware inicial e BlueKeep
5432 / 3306	Postgres / MySQL	Acesso direto ao banco de dados
6379 / 9200	Redis / Elasticsearch	Execução remota de código sem auth

---

5. Falta de Restrição de Regiões não Utilizadas (SCP)

Muitas empresas operam exclusivamente em sa-east-1 (São Paulo) e us-east-1 (Norte da Virgínia). Porém, quando credenciais são comprometidas, atacantes iniciam clusters de mineração de criptomoedas em regiões remotas como ap-southeast-1 ou me-central-1, onde os alarmes do CloudWatch geralmente não estão monitorando.

Mitigação com AWS Organizations:

Implemente uma Service Control Policy (SCP) restringindo ações fora das regiões autorizadas.

---

Precisa de um diagnóstico rigoroso na sua nuvem? Conheça os serviços de Auditoria de Segurança Cloud.