# AWS - IAM Post Exploitation

{{#include ../../../../banners/hacktricks-training.md}}

## IAM

Vir meer inligting oor IAM-toegang:

{{#ref}}
../../aws-services/aws-iam-enum.md
{{#endref}}

## Confused Deputy Problem

As jy **'n eksterne rekening (A) toelaat** om toegang tot 'n **role** in jou rekening te kry, sal jy waarskynlik **0 sigbaarheid** hê oor **wie presies daardie eksterne rekening kan toegang kry**. Dit is 'n probleem, want as 'n ander eksterne rekening (B) toegang tot die eksterne rekening (A) het, is dit moontlik dat **B ook toegang tot jou rekening sal hê**.

Daarom, wanneer jy 'n eksterne rekening toelaat om toegang tot 'n **role** in jou rekening te kry, kan jy 'n `ExternalId` spesifiseer. Dit is 'n "geheime" string wat die eksterne rekening (A) **moet spesifiseer** om die **role in jou organisasie aan te neem**. Omdat die **eksterne rekening B hierdie string nie sal ken nie**, sal hy, selfs al het hy toegang tot A, **nie in staat wees om jou role te toegang nie**.

<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>

Let egter daarop dat hierdie `ExternalId` "geheim" **nie 'n geheim is nie** — enigiemand wat die **IAM assume role policy kan lees** sal dit kan sien. Maar solank die eksterne rekening A dit ken, en die eksterne rekening **B dit nie ken nie**, sal dit **voorkom dat B A misbruik om toegang tot jou role te kry**.

Example:
```json
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}
```
> [!WARNING]
> Om 'n attacker 'n confused deputy te exploit, sal hy op een of ander manier moet uitvind of principals van die huidige account roles in ander accounts kan impersonate.

### Onverwagte Trusts

#### Wildcard as principal
```json
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" }
}
```
Hierdie beleid **laat alle AWS** toe om die rol aan te neem.

#### Diens as prinsipaal
```json
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}
```
Hierdie beleid **laat enige rekening toe** om hul apigateway te konfigureer om hierdie Lambda aan te roep.

#### S3 as prinsipaal
```json
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
```
As 'n S3 bucket as 'n principal gegee word, omdat S3 buckets nie 'n Account ID het nie, as jy jou **bucket verwyder het en die attacker dit in hul eie account geskep het**, kan hulle dit misbruik.

#### Nie ondersteund nie
```json
{
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}
```
'n Algemene manier om Confused Deputy-probleme te vermy is die gebruik van 'n voorwaarde met `AWS:SourceArn` om die oorsprong-ARN te kontroleer. Nietemin, **sommige dienste mag dit nie ondersteun nie** (soos CloudTrail volgens sekere bronne).

### Verwydering van kredensiale
Met enigeen van die volgende toestemmings — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kan 'n akteur toegangssleutels, aanmeldprofiele, SSH-sleutels, diens-spesifieke kredensiale, instansieprofiele, sertifikate of CloudFront openbare sleutels verwyder, of rolle van instansieprofiele ontkoppel. Sulke optredes kan onmiddellik wettige gebruikers en toepassings blokkeer en diensonderbreking of verlies van toegang vir stelsels wat op daardie kredensiale staatmaak veroorsaak; daarom moet hierdie IAM-toestemmings streng beperk en gemonitor word.
```bash
# Remove Access Key of a user
aws iam delete-access-key \
--user-name <Username> \
--access-key-id AKIAIOSFODNN7EXAMPLE

## Remove ssh key of a user
aws iam delete-ssh-public-key \
--user-name <Username> \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
```
### Identiteitsverwydering
Met toestemmings soos `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, of `iam:RemoveUserFromGroup` kan 'n akteur gebruikers, rolle of groepe uitvee — of groepslidmaatskap verander — en sodoende identiteite en geassosieerde spore verwyder. Dit kan onmiddellik toegang breek vir persone en dienste wat van daardie identiteite afhanklik is, wat denial-of-service of verlies van toegang veroorsaak, daarom moet hierdie IAM actions nougeset beperk en gemonitor word.
```bash
# Delete a user
aws iam delete-user \
--user-name <Username>

# Delete a group
aws iam delete-group \
--group-name <Username>

# Delete a role
aws iam delete-role \
--role-name <Role>
```
###
Met enige van die volgende toestemmings — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kan 'n akteur bestuurde of inline-beleide uitvee of loskoppel, beleidsweergawes of toestemmingsgrense verwyder, en beleide van gebruikers, groepe of rolle ontkoppel. Dit vernietig magtigings en kan die toestemmingsmodel verander, wat onmiddellike verlies van toegang of denial-of-service vir principals wat op daardie beleide staatgemaak het veroorsaak; daarom moet hierdie IAM-aksies noukeurig beperk en gemonitor word.
```bash
# Delete a group policy
aws iam delete-group-policy \
--group-name <GroupName> \
--policy-name <PolicyName>

# Delete a role policy
aws iam delete-role-policy \
--role-name <RoleName> \
--policy-name <PolicyName>
```
### Verwydering van Gefedereerde Identiteit
Met `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` en `iam:RemoveClientIDFromOpenIDConnectProvider` kan 'n akteur OIDC/SAML identity providers verwyder of client IDs verwyder. Dit breek gefedereerde authentisering, voorkom token validation en weier onmiddellik toegang aan gebruikers en dienste wat op SSO staat totdat die IdP of konfigurasies herstel is.
```bash
# Delete OIDCP provider
aws iam delete-open-id-connect-provider \
--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com

# Delete SAML provider
aws iam delete-saml-provider \
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
```
### Illegitimate MFA Activation
Met `iam:EnableMFADevice` kan 'n akteur 'n MFA-toestel registreer op 'n gebruiker se identiteit, wat die legitieme gebruiker verhinder om aan te meld. Sodra 'n ongemagtigde MFA geaktiveer is, kan die gebruiker uitgesluit word totdat die toestel verwyder of gereset word (nota: as verskeie MFA-toestelle geregistreer is, vereis aanmelding slegs een, so sal hierdie aanval geen effek hê om toegang te ontneem nie).
```bash
aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012
```
### Sertifikaat-/Sleutelmetagegewens-manipulasie
Met `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kan 'n akteur die status of metagegewens van publieke sleutels en sertifikate verander. Deur sleutels/sertifikate as inaktief te merk of verwysings te verander, kan hulle SSH-verifikasie breek, X.509/TLS-validerings ongeldig maak en onmiddellik dienste ontwrig wat van daardie geloofsbriewe afhanklik is, wat tot verlies van toegang of beskikbaarheid kan lei.
```bash
aws iam update-ssh-public-key \
--user-name <Username> \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
--status Inactive

aws iam update-server-certificate \
--server-certificate-name <Certificate_Name> \
--new-path /prod/
```
### `iam:Delete*`

Die IAM-wildcard iam:Delete* verleen die vermoë om baie tipes IAM-hulpbronne te verwyder — gebruikers, rolle, groepe, beleide, sleutels, sertifikate, MFA-toestelle, beleidsweergawes, ens. — en het dus 'n baie groot uitwerkingsradius: 'n akteur wat iam:Delete* toegeken is, kan identiteite, inlogbewyse, beleide en verwante artefakte permanent vernietig, oudit-/bewyse verwyder, en diens- of operasionele uitval veroorsaak. Sommige voorbeelde is
```bash
# Delete a user
aws iam delete-user --user-name <Username>

# Delete a role
aws iam delete-role --role-name <RoleName>

# Delete a managed policy
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
```
### `iam:EnableMFADevice`

'n actor wat die iam:EnableMFADevice-aksie toegeken is, kan 'n MFA-toestel op 'n identiteit in die rekening registreer, op voorwaarde dat die gebruiker nie reeds een aangeskakel het nie. Dit kan gebruik word om 'n gebruiker se toegang te ontwrig: sodra 'n attacker 'n MFA-toestel registreer, kan die regmatige gebruiker verhinder word om aan te meld omdat hulle nie beheer oor die attacker-registered MFA het nie.

Hierdie denial-of-access-aanval werk slegs as die gebruiker geen MFA geregistreer het nie; as die attacker 'n MFA-toestel vir daardie gebruiker registreer, sal die regmatige gebruiker uitgesluit word van enige flows wat daardie nuwe MFA vereis. As die gebruiker reeds een of meer MFA-toestelle onder hul beheer het, sal die toevoeging van 'n attacker-controlled MFA nie die regmatige gebruiker blokkeer nie — hulle kan voortgaan om te verifieer met enige MFA wat hulle reeds het.

Om 'n MFA-toestel vir 'n gebruiker te aktiveer (registreer) kan 'n attacker die volgende uitvoer:
```bash
aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012
```
## Verwysings

- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)

{{#include ../../../../banners/hacktricks-training.md}}
