Hack Alerta

Escalada em AWS: execução sob roles atinge EC2 e SageMaker

Pesquisa de Daniel Grzelak demonstra que modificações pós‑criação em EC2 (userData) e SageMaker (lifecycle configs) permitem execução de código sob execution roles, criando vetor de escalada que exige revisão de permissões como ec2:ModifyInstanceAttribute e sagemaker:UpdateNotebookInstance.

Introdução

Pesquisas recentes reavivaram uma técnica de escalada que permite a execução de código com privilégios de roles de execução em instâncias EC2 e notebooks Amazon SageMaker, explorando atributos de configuração modificáveis após a criação.

Descoberta e escopo / O que mudou agora

O padrão foi descrito por Daniel Grzelak (Plerion). Originalmente documentado em 2016 para EC2, o método permanece viável e foi demonstrado para SageMaker: invasores com permissões específicas de controle de instância ou notebook podem alterar configurações de inicialização e provocar execução sob o contexto do execution role associado ao recurso.

Vetor e exploração / Mitigações

No caso de EC2, o fluxo identificado é: parar a instância, alterar o atributo userData (por exemplo usando um #cloud‑boothook) e reiniciar. O script definido em userData é executado no boot no contexto do execution role presumido pela instância, permitindo exfiltração de credenciais ou ações com as permissões do role.

Para SageMaker, a superfície é a configuração de lifecycle scripts: com permissões para sagemaker:StopNotebookInstance, sagemaker:UpdateNotebookInstance (com lifecycle config) e sagemaker:StartNotebookInstance, um ator pode associar ou criar um lifecycle config contendo código malicioso (codificado em base64) que é executado na reinicialização do notebook sob o execution role.

Impacto e alcance / Setores afetados

Ambos os vetores permitem que um ator com permissões aparentemente de baixo risco execute código com os privilégios do role atrelado à instância/notebook. Em ambientes onde roles concedem acesso amplo (S3, APIs de ML, deploy de modelos), o impacto pode incluir exfiltração de dados, comprometimento de pipelines de ML e uso indevido de capacidades de computação.

Limites das informações / O que falta saber

O relatório de Grzelak demonstra prova de conceito, mas não quantifica ocorrências em ambientes na produção nem descreve casos públicos de exploração ativa em massa. Também depende das permissões disponíveis ao atacante: sem as ações de parada/atualização/reinício, o vetor não se aplica.

Repercussão / Próximos passos / Recomendações

  • Tratar ações que modificam atributos de inicialização (ec2:ModifyInstanceAttribute, sagemaker:UpdateNotebookInstance) como sensíveis e restringi‑las a administradores confiáveis.
  • Monitorar CloudTrail para sequências anômalas Stop → Modify → Start em instâncias e notebooks.
  • Aplicar políticas de menor privilégio a roles e usar Service Control Policies (SCPs) para impedir alterações não autorizadas em ambientes organizados por AWS Organizations.

Fontes: análise de Daniel Grzelak (Plerion) e documentação AWS mencionada no relatório.


Baseado em publicação original de Cyber Security News / Plerion (Daniel Grzelak)
Publicado pela Redação Hack Alerta com base em fontes externas citadas e monitoramento editorial do Hack Alerta. Para decisões técnicas, operacionais ou jurídicas, confirme sempre os detalhes na fonte original.