Azure App Service
Last updated
Last updated
Azure App Service is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends. It supports both Windows and Linux environments.
Each app runs inside a sandbox but isolation depends upon App Service plans
Apps in Free and Shares tiers run on shared VMs
Apps in standard and premium tiers run on dedicated VMs
While there are default security features available with App Service (sandboxing/isolation), vulnerabilities in the code deployed are abusable. The classic web app vulns like SQL injection, OS command injection, etc do not disappear.
By abusing and vulnerability in an app service and it is possible to get command execution, the privileges will be of the low-privilege worker process. But if the app service uses a Managed Identity, we may have the ability to have interesting permissions on other Azure resources.
Once you have command execution, run envto check if the identity_headervariable and identity_endpointare set. If they are, the app has a managed identity
Now, to get a access_token for the app service, we can use the following command:
Once you have a access_token for the app service, use that to connect to Az Cli:
Now to check which Role Assignments our token has run:
To get the available resources run:
Found a app vulnerable to SSTI (Jinja2), use this payload to get the app's access_token:
A function app (also called Azure Functions), is Azure's 'serverless' solution to run code. A function app is supposed to be used to react to an event like:
HTTP Trigger
Processing a File upload
Run code on a scheduled time and more
Function apps also support managed identities!
It looks a lot like AWS Lambda
When you get the following error , it means the access_token has to access to any resources:
By default, managed identities (service principals), have no read access at all!
In this case, something like AzureHound comes in handy
