From 06150a907c00beb0c05f690a6f859f2f18454d24 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 1 May 2025 11:40:02 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/ --- .../aws-codebuild-privesc.md | 2 +- .../aws-privilege-escalation/aws-ecs-privesc.md | 4 ++-- .../aws-stepfunctions-privesc.md | 16 ++++++++-------- .../aws-s3-unauthenticated-enum.md | 4 ++-- 4 files changed, 13 insertions(+), 13 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md index ef2bafc69..12dca7c5b 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md @@ -63,7 +63,7 @@ aws codebuild start-build-batch --project --buildspec-override fi - `StartBuild` attiva un singolo lavoro di build utilizzando un specifico `buildspec.yml`. - `StartBuildBatch` consente di avviare un batch di build, con configurazioni più complesse (come eseguire più build in parallelo). -**Impatto Potenziale:** Privesc diretto ai ruoli AWS Codebuild attaccati. +**Impatto Potenziale:** Privesc diretto ai ruoli AWS Codebuild allegati. ### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md index 4c6f75eeb..88016dd1d 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md @@ -140,7 +140,7 @@ aws ecs run-task \ ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** Questo scenario è simile ai precedenti ma **senza** il permesso **`iam:PassRole`**.\ -Questo è comunque interessante perché se puoi eseguire un contenitore arbitrario, anche se senza un ruolo, potresti **eseguire un contenitore privilegiato per evadere** al nodo e **rubare il ruolo IAM EC2** e i **ruoli degli altri contenitori ECS** in esecuzione nel nodo.\ +Questo è comunque interessante perché se puoi eseguire un contenitore arbitrario, anche se senza un ruolo, potresti **eseguire un contenitore privilegiato per fuggire** al nodo e **rubare il ruolo IAM EC2** e i **ruoli degli altri contenitori ECS** in esecuzione nel nodo.\ Potresti persino **forzare altre attività a essere eseguite all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come discusso nella [**sezione Privesc to node**](aws-ecs-privesc.md#privesc-to-node)). > [!WARNING] @@ -242,7 +242,7 @@ TODO: È possibile registrare un'istanza da un diverso account AWS in modo che l ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets` > [!NOTE] -> TODO: Testare questo +> TODO: Testa questo Un attaccante con i permessi `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` e `ecs:DescribeTaskSets` può **creare un set di attività malevole per un servizio ECS esistente e aggiornare il set di attività primario**. Questo consente all'attaccante di **eseguire codice arbitrario all'interno del servizio**. ```bash diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md index a1277bdc3..f8f405df4 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md @@ -12,9 +12,9 @@ Per ulteriori informazioni su questo servizio AWS, controlla: ### Risorse delle Attività -Queste tecniche di escalation dei privilegi richiederanno di utilizzare alcune risorse delle funzioni step di AWS per eseguire le azioni di escalation dei privilegi desiderate. +Queste tecniche di escalation dei privilegi richiederanno l'uso di alcune risorse delle funzioni step di AWS per eseguire le azioni di escalation dei privilegi desiderate. -Per controllare tutte le azioni possibili, puoi andare nel tuo account AWS, selezionare l'azione che desideri utilizzare e vedere i parametri che sta utilizzando, come in: +Per controllare tutte le azioni possibili, puoi andare al tuo account AWS, selezionare l'azione che desideri utilizzare e vedere i parametri che sta utilizzando, come in:
@@ -29,7 +29,7 @@ Un attaccante con i permessi **`states:TestState`** & **`iam:PassRole`** può te ```bash aws states test-state --definition --role-arn [--input ] [--inspection-level ] [--reveal-secrets | --no-reveal-secrets] ``` -I seguenti esempi mostrano come testare uno stato che crea una chiave di accesso per l'**`admin`** utente sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente allo stato di eseguire l'azione **`iam:CreateAccessKey`**: +I seguenti esempi mostrano come testare uno stato che crea una chiave di accesso per l'utente **`admin`** sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente allo stato di eseguire l'azione **`iam:CreateAccessKey`**: - **stateDefinition.json**: ```json @@ -59,7 +59,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn "status": "SUCCEEDED" } ``` -**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbe portare a significative violazioni della sicurezza. +**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza. ### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`) @@ -75,7 +75,7 @@ aws states start-execution --state-machine-arn [--name ] [--input # Start a Synchronous Express state machine execution aws states start-sync-execution --state-machine-arn [--name ] [--input ] [--trace-header ] ``` -I seguenti esempi mostrano come creare una macchina a stati che crea una chiave di accesso per l'utente **`admin`** ed esfiltra questa chiave di accesso in un bucket S3 controllato dall'attaccante, sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata qualsiasi policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente alla macchina a stati di eseguire le azioni **`iam:CreateAccessKey`** e **`s3:putObject`**. +I seguenti esempi mostrano come creare una macchina a stati che crea una chiave di accesso per l'utente **`admin`** ed esfiltra questa chiave di accesso in un bucket S3 controllato dall'attaccante, sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente alla macchina a stati di eseguire le azioni **`iam:CreateAccessKey`** e **`s3:putObject`**. - **stateMachineDefinition.json**: ```json @@ -132,13 +132,13 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1 } ``` > [!WARNING] -> Il bucket S3 controllato dall'attaccante dovrebbe avere permessi per accettare un'azione s3:PutObject dall'account della vittima. +> Il bucket S3 controllato dall'attaccante dovrebbe avere i permessi per accettare un'azione s3:PutObject dall'account della vittima. **Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza. ### `states:UpdateStateMachine` & (non sempre richiesto) `iam:PassRole` -Un attaccante con il permesso **`states:UpdateStateMachine`** sarebbe in grado di modificare la definizione di una macchina a stati, potendo aggiungere stati stealth aggiuntivi che potrebbero portare a un'escalation dei privilegi. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo. +Un attaccante con il permesso **`states:UpdateStateMachine`** sarebbe in grado di modificare la definizione di una macchina a stati, potendo aggiungere stati stealth extra che potrebbero portare a un'escalation dei privilegi. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo. A seconda di quanto permissivo sia il Ruolo IAM associato alla macchina a stati, un attaccante si troverebbe di fronte a 2 situazioni: @@ -151,7 +151,7 @@ aws states update-state-machine --state-machine-arn [--definition [!WARNING] -> Se la macchina a stati non ha un ruolo IAM permissivo associato, sarebbe anche necessaria l'autorizzazione **`iam:PassRole`** per aggiornare il ruolo IAM al fine di associare un ruolo IAM permissivo (ad esempio uno con la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata). +> Se la macchina a stati non ha un ruolo IAM permissivo associato, sarebbe anche necessario il permesso **`iam:PassRole`** per aggiornare il ruolo IAM al fine di associare un ruolo IAM permissivo (ad esempio uno con la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata). {{#tabs }} {{#tab name="Legit State Machine" }} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md index 4945d106c..de41f0f3b 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md @@ -104,7 +104,7 @@ oppure puoi accedere al bucket visitando: `flaws.cloud.s3-us-west-2.amazonaws.co #### Provando -Se provi ad accedere a un bucket, ma nel **nome di dominio specifichi un'altra regione** (ad esempio il bucket è in `bucket.s3.amazonaws.com` ma provi ad accedere a `bucket.s3-website-us-west-2.amazonaws.com`, allora ti verrà **indicato il luogo corretto**: +Se provi ad accedere a un bucket, ma nel **nome del dominio specifichi un'altra regione** (ad esempio il bucket è in `bucket.s3.amazonaws.com` ma provi ad accedere a `bucket.s3-website-us-west-2.amazonaws.com`, allora ti verrà **indicato il luogo corretto**: ![](<../../../images/image (106).png>) @@ -165,7 +165,7 @@ Se l'errore è "Access Denied" significa che l'ID dell'account era errato. ### Utilizzo delle email come enumerazione dell'account root -Come spiegato in [**questo post del blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), è possibile verificare se un indirizzo email è associato a un account AWS **cercando di concedere a un'email permessi** su un bucket S3 tramite ACL. Se questo non genera un errore, significa che l'email è un utente root di qualche account AWS: +Come spiegato in [**questo post del blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), è possibile verificare se un indirizzo email è associato a un account AWS **cercando di concedere permessi a un'email** su un bucket S3 tramite ACL. Se questo non genera un errore, significa che l'email è un utente root di qualche account AWS: ```python s3_client.put_bucket_acl( Bucket=bucket_name,