Visão geral
Este projeto demonstra um fluxo de investigação de segurança em nuvem usando evidências da aplicação e serviços nativos da AWS:
- implantei uma aplicação Flask em uma instância EC2 com um endpoint capaz de buscar URLs;
- gerei uma requisição no estilo SSRF direcionada ao serviço de metadados da instância;
- revisei atividades de identidade e chamadas de API no CloudTrail;
- reduzi o risco exigindo IMDSv2, bloqueando destinos internos na aplicação e aplicando menor privilégio à função IAM.
Configuração controlada: aplicação no EC2 e função IAM excessivamente permissiva
Executei um pequeno serviço Flask em uma instância EC2 com um endpoint capaz de buscar URLs. Para fins de laboratório, a instância utilizava uma função IAM com permissões mais amplas do que o necessário, demonstrando como o acesso ao serviço de metadados pode ampliar o impacto de uma falha de SSRF.
Este foi um cenário controlado, utilizando apenas recursos descartáveis e dados não sensíveis.
Sinal: requisição no estilo SSRF na telemetria da aplicação
Enviei uma requisição ao endpoint /fetch direcionada ao endereço de metadados do EC2 (169.254.169.254), simulando uma tentativa de SSRF contra o IMDS.
O foco do projeto foi a investigação, não a exploração. O sinal relevante foi a aplicação ter recebido uma requisição destinada ao serviço de metadados da nuvem.
Investigação no CloudTrail
O acesso ao endereço 169.254.169.254 era relevante porque o IMDS pode disponibilizar informações da instância e credenciais temporárias associadas à função IAM.
Por isso, revisei no CloudTrail as atividades de identidade e as chamadas de API próximas ao horário da requisição suspeita.
Na janela analisada, identifiquei eventos como:
GetCallerIdentity;DescribeRegions;DescribeInstances.
Esses eventos permitiram observar a atividade de identidade e enumeração associada ao período investigado.
Caso as credenciais temporárias tivessem sido expostas, uma chamada como
sts:GetCallerIdentityseria relevante para confirmar a conta AWS e o contexto da função utilizada.
Remediação: reduzindo o caminho de risco
Apliquei três medidas de hardening no laboratório para reduzir o caminho de risco entre SSRF e exposição de recursos em nuvem:
- exigi IMDSv2 na instância EC2;
- bloqueei, no endpoint /fetch, requisições destinadas ao serviço de metadados e a endereços locais;
- reduzi as permissões da função da instância com base no princípio do menor privilégio.
Na aplicação, o controle incluía destinos como 169.254.169.254, 127.0.0.0/8, localhost e faixas 169.254.*.
Após a alteração, uma nova tentativa de acesso ao serviço de metadados retornou 403 Forbidden.
Como melhoria, esse controle poderia ser ampliado para validar os endereços resultantes da resolução DNS e bloquear outras faixas privadas, loopback, link-local e endereços locais IPv6.
Conclusão
Após o hardening, a mesma requisição passou a retornar 403 Forbidden, enquanto o sinal continuou visível na telemetria da aplicação. O IMDSv2 também permaneceu obrigatório e a função IAM foi restringida.
O laboratório reuniu um fluxo de investigação em nuvem:
detectar → investigar no CloudTrail → remediar → repetir o teste → validar