Privilege Escalation within Azure Logic Apps

We discussed this vulnerability as part of our weekly podcast on 06 September 2021

tl;dr Some research examining how an attacker could abuse Azure Logical Apps access to to escalate their privileges.

  • The first being that sensitive information can be exposed with reader access, secrets attached to components, the run history, and past versions (and their components)
  • The second being a consideration of how some components can be reused for other purposes. An API connection included for one purpose might have more permissions than expected that a contributor would have access to.

Azure Logical Apps is Microsoft Azure’s Low-Code Development Platform. Used to automate some types of workflows without needing to write code. Low-code development is becoming increasingly popular, I wouldn’t call it popular but it has a definite presence.

This post isn’t covering any specific vulnerabilities but rather a series of potential attacks should you have access to a Logic App, how you might escelate to further access.

Reader Access - Essentially you have access to read the logic apps, one of the more basic permissions available. Can’t write or “contribute” to them. A reader can simply read out the raw definition of a logic application. This includes an associated inputs including potential secrets.

What’s a bit more interesting to me are that they call out the Run History and Versions areas as being accesisble also:

  • Run History will give you access to all the previous runs of the application, including any secrets that might have been printed during development builds, by default even sensitive actions will print their output.
  • Versions area giving you access to all the previous versions of the application, whether or not it was executed, including any hardcoded credentials that might have been included during early development.

Contributor access - Access to modify the Logic Applications. A much higher ask in terms of permissions for an attacker, the issue detailed is also a bit more debatable, as it does not violate the permission model.

The attack scenario described is through abusing access that might be granted for one use-case but also offer other functionality. Imagining the scenario where a developer can contribute within the the dev environment resource group, but an admin adds an application that for its own purposes establishes an API Connection to something over in the production environment.

An attacker could then reuse that API Connection created by the admin for their particular application and reuse it to access other features of the API that might not be intended by the admin.

The author admits this is a contrived example, but it is illustrative of the types of issues to be looking for should you have this level of access. The fundamental principal of the attack being that the permissions granted to any API connection or other application the logic apps interact with are permissions granted to all contributors.

The post ends with a brief discussion of the defensive side, some best practices that are similar to standard application development. Things like not hard-coding sensitive information but retrieving it from a secure service, and being aware of the permissions the API connections have.