Last updated
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Per ulteriori informazioni su questo servizio AWS, controlla:
AWS - Step Functions EnumQueste tecniche di escalation dei privilegi richiederanno di utilizzare alcune risorse delle funzioni step 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:
Oppure puoi anche andare alla documentazione API AWS e controllare la documentazione di ciascuna azione:
states:TestState & iam:PassRoleUn attaccante con i permessi states:TestState & iam:PassRole può testare qualsiasi stato e passare qualsiasi ruolo IAM senza creare o aggiornare una macchina a stati esistente, abilitando l'accesso non autorizzato ad altri servizi AWS con i permessi del ruolo. Potenzialmente. Combinati, questi permessi possono portare a estese azioni non autorizzate, dalla manipolazione dei flussi di lavoro all'alterazione dei dati, fino a violazioni dei dati, manipolazione delle risorse e escalation dei privilegi.
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 qualsiasi policy ad alta privilegio (ad esempio arn:aws:iam::aws:policy/AdministratorAccess) che consente allo stato di eseguire l'azione iam:CreateAccessKey:
stateDefinition.json:
Comando eseguito per eseguire il privesc:
Impatto Potenziale: Esecuzione non autorizzata e manipolazione di flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza.
states:CreateStateMachine & iam:PassRole & (states:StartExecution | states:StartSyncExecution)Un attaccante con states:CreateStateMachine & iam:PassRole sarebbe in grado di creare una macchina a stati e fornirle qualsiasi ruolo IAM, abilitando l'accesso non autorizzato ad altri servizi AWS con i permessi del ruolo. A differenza della precedente tecnica di privesc (states:TestState & iam:PassRole), questa non si esegue da sola, sarà necessario avere anche i permessi states:StartExecution o states:StartSyncExecution (states:StartSyncExecution non è disponibile per flussi di lavoro standard, solo per macchine a stati espressive) per avviare un'esecuzione sulla macchina a stati.
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.
stateMachineDefinition.json:
Comando eseguito per creare la macchina di stato:
Comando eseguito per avviare un'esecuzione della macchina a stati precedentemente creata:
Il bucket S3 controllato dall'attaccante dovrebbe avere permessi per accettare un'azione s3:PutObject dall'account 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:PassRoleUn 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.
A seconda di quanto permissivo sia il Ruolo IAM associato alla macchina a stati, un attaccante si troverebbe di fronte a 2 situazioni:
Ruolo IAM Permissivo: Se il Ruolo IAM associato alla macchina a stati è già permissivo (ha ad esempio la policy arn:aws:iam::aws:policy/AdministratorAccess allegata), allora il permesso iam:PassRole non sarebbe necessario per escalare i privilegi poiché non sarebbe necessario aggiornare anche il Ruolo IAM, con la definizione della macchina a stati è sufficiente.
Ruolo IAM Non Permissivo: In contrasto con il caso precedente, qui un attaccante richiederebbe anche il permesso iam:PassRole poiché sarebbe necessario associare un Ruolo IAM permissivo alla macchina a stati oltre a modificare la definizione della macchina a stati.
I seguenti esempi mostrano come aggiornare una macchina a stati legittima che invoca semplicemente una funzione Lambda HelloWorld, per aggiungere uno stato extra che aggiunge l'utente unprivilegedUser al gruppo IAM administrator. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati aggiornata, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo.
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).
Comando eseguito per aggiornare la macchina a stati legittima:
Impatto Potenziale: Esecuzione non autorizzata e manipolazione di flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza.
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
