AWS - EC2 Privesc
EC2
Para mais informações sobre EC2 confira:
iam:PassRole
, ec2:RunInstances
iam:PassRole
, ec2:RunInstances
Um atacante poderia criar uma instância anexando um papel IAM e então acessar a instância para roubar as credenciais do papel IAM do endpoint de metadados.
Acesso via SSH
Execute uma nova instância usando uma chave ssh criada (--key-name
) e então faça ssh nela (se você quiser criar uma nova, pode precisar da permissão ec2:CreateKeyPair
).
Acesso via rev shell em dados do usuário
Você pode executar uma nova instância usando um dado do usuário (--user-data
) que enviará uma rev shell para você. Você não precisa especificar o grupo de segurança dessa forma.
Cuidado com o GuradDuty se você usar as credenciais do papel IAM fora da instância:
Impacto Potencial: Privesc direto para qualquer papel EC2 anexado a perfis de instância existentes.
Privesc para ECS
Com este conjunto de permissões, você também poderia criar uma instância EC2 e registrá-la dentro de um cluster ECS. Dessa forma, os serviços do ECS serão executados dentro da instância EC2 onde você tem acesso e então você pode penetrar nesses serviços (contêineres docker) e roubar seus papéis ECS anexados.
Para aprender como forçar serviços ECS a serem executados nesta nova instância EC2, consulte:
Se você não pode criar uma nova instância mas tem a permissão ecs:RegisterContainerInstance
, você pode ser capaz de registrar a instância dentro do cluster e realizar o ataque comentado.
Impacto Potencial: Privesc direto para funções ECS anexadas a tarefas.
iam:PassRole
, iam:AddRoleToInstanceProfile
iam:PassRole
, iam:AddRoleToInstanceProfile
Semelhante ao cenário anterior, um atacante com essas permissões poderia mudar a função IAM de uma instância comprometida para que ele pudesse roubar novas credenciais.
Como um perfil de instância pode ter apenas 1 função, se o perfil de instância já tiver uma função (caso comum), você também precisará de iam:RemoveRoleFromInstanceProfile
.
Se o perfil da instância tiver um papel e o atacante não puder removê-lo, há outra solução alternativa. Ele poderia encontrar um perfil de instância sem um papel ou criar um novo (iam:CreateInstanceProfile
), adicionar o papel a esse perfil de instância (como discutido anteriormente) e associar o perfil de instância comprometido a uma instância comprometida:
Se a instância não tiver nenhum perfil de instância (
ec2:AssociateIamInstanceProfile
) *
Impacto Potencial: Privesc direto para um papel EC2 diferente (você precisa ter comprometido uma instância AWS EC2 e algumas permissões extras ou um status específico de perfil de instância).
iam:PassRole
(( ec2:AssociateIamInstanceProfile
& ec2:DisassociateIamInstanceProfile
) || ec2:ReplaceIamInstanceProfileAssociation
)
iam:PassRole
(( ec2:AssociateIamInstanceProfile
& ec2:DisassociateIamInstanceProfile
) || ec2:ReplaceIamInstanceProfileAssociation
)Com essas permissões, é possível alterar o perfil de instância associado a uma instância, então se o ataque já tiver acesso a uma instância, ele poderá roubar credenciais para mais papéis de perfil de instância, mudando o que está associado a ela.
Se tiver um perfil de instância, você pode remover o perfil de instância (
ec2:DisassociateIamInstanceProfile
) e associá-lo *
ou substituir o perfil da instância da instância comprometida (
ec2:ReplaceIamInstanceProfileAssociation
). *
Impacto Potencial: Privesc direto para um papel EC2 diferente (você precisa ter comprometido uma instância AWS EC2 e algumas permissões extras ou um status de perfil de instância específico).
ec2:RequestSpotInstances
,iam:PassRole
ec2:RequestSpotInstances
,iam:PassRole
Um atacante com as permissões ec2:RequestSpotInstances
eiam:PassRole
pode solicitar uma Instância Spot com um Papel EC2 anexado e um rev shell nos dados do usuário.
Uma vez que a instância é executada, ele pode roubar o papel IAM.
ec2:ModifyInstanceAttribute
ec2:ModifyInstanceAttribute
Um atacante com a ec2:ModifyInstanceAttribute
pode modificar os atributos das instâncias. Entre eles, ele pode alterar os dados do usuário, o que implica que ele pode fazer a instância executar dados arbitrários. Isso pode ser usado para obter um rev shell na instância EC2.
Observe que os atributos só podem ser modificados enquanto a instância está parada, então as permissões ec2:StopInstances
e ec2:StartInstances
.
Impacto Potencial: Privesc direto para qualquer EC2 IAM Role anexado a uma instância criada.
ec2:CreateLaunchTemplateVersion
,ec2:CreateLaunchTemplate
,ec2:ModifyLaunchTemplate
ec2:CreateLaunchTemplateVersion
,ec2:CreateLaunchTemplate
,ec2:ModifyLaunchTemplate
Um atacante com as permissões ec2:CreateLaunchTemplateVersion
,ec2:CreateLaunchTemplate
e ec2:ModifyLaunchTemplate
pode criar uma nova versão do Launch Template com um rev shell em os dados do usuário e qualquer EC2 IAM Role nele, mudar a versão padrão, e qualquer grupo de Autoscaler usando esse Launch Template que está configurado para usar a versão mais recente ou a versão padrão irá re-executar as instâncias usando esse template e irá executar o rev shell.
Impacto Potencial: Privesc direto para um papel EC2 diferente.
autoscaling:CreateLaunchConfiguration
, autoscaling:CreateAutoScalingGroup
, iam:PassRole
autoscaling:CreateLaunchConfiguration
, autoscaling:CreateAutoScalingGroup
, iam:PassRole
Um atacante com as permissões autoscaling:CreateLaunchConfiguration
,autoscaling:CreateAutoScalingGroup
,iam:PassRole
pode criar uma Configuração de Lançamento com um Papel IAM e um rev shell dentro dos dados do usuário, então criar um grupo de escalonamento automático a partir dessa configuração e esperar que o rev shell roube o Papel IAM.
Impacto Potencial: Privesc direto para um papel EC2 diferente.
!autoscaling
!autoscaling
O conjunto de permissões ec2:CreateLaunchTemplate
e autoscaling:CreateAutoScalingGroup
não é suficiente para escalar privilégios para um papel IAM porque, para anexar o papel especificado na Configuração de Lançamento ou no Template de Lançamento, você precisa das permissões iam:PassRole
e ec2:RunInstances
(o que é um privesc conhecido).
ec2-instance-connect:SendSSHPublicKey
ec2-instance-connect:SendSSHPublicKey
Um atacante com a permissão ec2-instance-connect:SendSSHPublicKey
pode adicionar uma chave ssh a um usuário e usá-la para acessá-lo (se ele tiver acesso ssh à instância) ou para escalar privilégios.
Impacto Potencial: Privesc direto para os papéis IAM do EC2 anexados a instâncias em execução.
ec2-instance-connect:SendSerialConsoleSSHPublicKey
ec2-instance-connect:SendSerialConsoleSSHPublicKey
Um atacante com a permissão ec2-instance-connect:SendSerialConsoleSSHPublicKey
pode adicionar uma chave ssh a uma conexão serial. Se a serial não estiver habilitada, o atacante precisa da permissão ec2:EnableSerialConsoleAccess
para habilitá-la.
Para se conectar à porta serial, você também precisa saber o nome de usuário e a senha de um usuário dentro da máquina.
Esse método não é tão útil para privesc, pois você precisa saber um nome de usuário e uma senha para explorá-lo.
Impacto Potencial: (Altamente improvável) Privesc direto para os papéis IAM do EC2 anexados às instâncias em execução.
describe-launch-templates
,describe-launch-template-versions
describe-launch-templates
,describe-launch-template-versions
Como os modelos de lançamento têm versionamento, um atacante com permissões ec2:describe-launch-templates
e ec2:describe-launch-template-versions
poderia explorá-los para descobrir informações sensíveis, como credenciais presentes nos dados do usuário. Para realizar isso, o seguinte script percorre todas as versões dos modelos de lançamento disponíveis:
Nos comandos acima, embora estejamos especificando certos padrões (aws_|password|token|api
), você pode usar uma regex diferente para procurar outros tipos de informações sensíveis.
Assumindo que encontramos aws_access_key_id
e aws_secret_access_key
, podemos usar essas credenciais para autenticar no AWS.
Impacto Potencial: Escalação direta de privilégios para usuário(s) IAM.
Referências
Last updated