Problem statement
There are lots of great tools that can illustrate attack paths in graphs, but they all lack the capability to map attack paths from the cloud to code or an inbound trust from cross-cloud. As part of our research into OIDC and Azure environments, we have discovered a common anti-pattern where privileged service accounts are associated with permissions to Azure environments, where often the only prerequisite to leverage the privileged credentials, is the ability to open a Pull Request on a code repository.
Our Tool
We hope that the tools out there will adopt the functionality we provided, and rather than trying to replicate successful tools, we created a tool to cater our research. The tool is built on our existing tooling for gathering data from Azure Resource Manager and Microsoft Graph, storing the data in JSON. We upload the data to a Neo4j database for interactive queries and visualization that can handle large datasets.
The process
By extracting and utilising this data, we can correlate the relation between the resources and create these as individual objects that are associated through a graph database.
Getting all Service Principals and Enterprise Applications
By fetching all Service Principals (App Registrations), we can inspect the service principals for Federated Identity Credentials, that indicates its configured with an external entity using OIDC. For each case where it’s Github, we can extract the subject string which indicates which GitHub entity trusts and under what condition.
We then proceed to gather all Enterprise Applications, these are linked to Service Principals and is the object that can be assigned to roles in Azure. We need to create a link between these objects, so we can create a correlation between the Federated Identity Credentials and the Role assignments that we’ll fetch in the next step.
Getting all Role Assignments
Lastly, we ned the role assignments from all Azure Management Groups, Subscriptions, Resource Groups and Resources. We export this into JSON data before we proceed to the next step.
Matching the data
Once all the data is gathered, we can perform the matching. We will presume that all Federated Identity Credentials are valid - as we are not validating the string. If a Federated Identity Credential has a string that doesn’t resolve to an organization or GitHub user, you might have Confused Deputy vulnerability worth investigating.
Querying the data and presenting in graphs
The end result is our graph that allows for interactive querying of the different entities to further research how OIDC is used in an organization, hunt for confused deputy, correlate with Branch Protection and apply what we know about our GitHub configuration and architecture.
If you want to run this in your own environment, you can find the tool in our GitHub.
Note: We don’t intend to actively maintain this tool, we have built it to work with our clients and partners to demonstrate a common security misconfiguration. The tool has been tested in large environments, and wed’d rather see the functionality adopted in the existing tools out there.