Learning About Managed Identities at TEC
In this TEC session, Andy Robbins (SpectreOps) shared a few interesting thoughts on potential security implications associated with the use of Managed Identities. This is my overview of the session.
What are managed identities?
Whenever apps need to interact with resources, developers use credentials to gain access to the resources. Instead of having to store secrets in code, developers can leverage features like Azure KeyVault to retrieve secrets from a secure store. However, to retrieve secrets from the store, you’ve still got to authenticate. The challenge of dealing with credentials within code or a service isn’t entirely handled by having a secure store. The goal of Managed Identities is essentially to eliminate the need for developers to need to use stored credentials to interact with Azure resources
The challenge of Managed Identities
A typical example is a virtual machine that runs a scheduled script that requires access to an API, like the Microsoft Graph API. Traditionally, the script would include credentials to the backend API or to a Vault to retrieve the actual secrets to connect to the API. With a Managed Identity the script doesn’t need any of this, as the virtual machine is authorized to request a token for the Service Principal that has access to the backend API. Although this process is secure by itself, challenges arise when the configuration is made insecure, for example by misconfiguration or by granting too many permissions to the Managed Identity.
In the scenario of the virtual machine that leverages a Manage Identity, anyone with access to the virtual machine automatically inherits the ability to call upon the resources that the Managed Identity has access to, even when they do not have administrative access to the virtual machine. This is thanks to the Instance Meta Data Service (IMDS) that runs on the VM and is responsible for acquiring access tokens from Azure AD.
When a Global Admin logs on to the virtual machine and utilizes the permissions granted to the Managed Identity, there is very little to say. After all, the user already has Global Admin permissions. But a user without any permissions could log on to the virtual machine and grant themselves whatever permissions are held by the Managed Identity, even when those permissions are, for example, permissions that allow access to many resources, such as those held by a Global admin.
The latter case obviously constitutes some form of privilege escalation, even if there isn’t a bug or vulnerability in the system itself. Needless to say, once a regular user has the ability to escalate privileges, they could move from one resource to another, depending on the permissions granted to the Managed Identity. As regular user accounts are more prone to being phished, this creates is a security risk to consider. Just think about how a regular user account at the recent Uber hack resulted in a huge compromise of most of their environment!
So, is this something to panic about? Not necessarily. Some caution is warranted as Murphy’s Law is in effect: whenever there is a chance for a misconfiguration, one is more than likely to happen. As such, keeping control over managed identities and the permissions granted to these identities is important!
To that extent, SpectreOps has released a few cmdlets that administrators can use to analyze which permissions are granted to Managed Identities within the environment. Not only do they highlight the permissions granted to managed identities, but the scripts also correlate which of the permissions amount up to so-called ‘Tier-0’-permissions.
Tier-0 permissions refer to high-level permissions such as Global Admin, Privileged Authentication Admin, and others that either provide direct access to the root configuration of the tenant or allow the modification to accounts that may have such access.
Cybersecurity Risk Management for Active Directory
Discover how to prevent and recover from AD attacks through these Cybersecurity Risk Management Solutions.
Should You Avoid Managed Identities
Despite the challenges that might lie in using Managed Identities, they still are a great way to secure interactions between resources. Managed identities:
- Eliminate the risk of storing usernames and passwords in the resource or application
- Mitigate privileged account sharing between users and services,
- Preclude the need for potentially confusing conditional access policies,
- Simplify future privileged account monitoring,
Just make sure that when using Managed Identities, you follow a few ground rules to ensure the configuration is as secure as it can be:
- Where possible, implement a tiered administration model so that (user) accounts can only access Managed Identities with similar permissions. Do not allow lower-level accounts to access identities with higher privileges.
- Be careful with what permissions you grant to Managed Identities or to the Service Principals they have access to and ensure that you regularly audit the permissions granted to them, especially higher privileges. As explained in this article, it’s possible to create your own version of a tool to report high-priority permissions assigned to apps and managed identities.
- Get a list of Managed Identity assignments and compare those to a list of Service Principals that exist within the environment.
- Review the permissions granted to Service Principals and correlate them to the list in step 2, as Managed Identities may not have direct role assignments, but have access to roles through, for example, those Service Principals.
