![]() The below command shows that when logging in with such a certificate, we do have the power to modify group memberships (something the application admin normally doesn’t have): I use Python for logging in with a service principal password since the PowerShell module doesn’t support this (it does support certificates but that’s more complex to set up). You can exploit this by assigning a password or certificate to a service principal and then logging in as that service principal. This is done by assigning credentials to an existing service principal with these permissions and then impersonating these applications. So the TL DR is that if you compromise an Application Administrator account or the on-premise Sync Account you can read and modify directory settings, group memberships, user accounts, SharePoint sites and OneDrive files. Below is an overview of the most interesting permissions that I’ve identified. ![]() If we perform this action for all ~200 default apps in an Office 365 tenant, we get an overview of all the permissions these applications have. I am unsure if this is because no apps have permissions on the Azure AD graph or if the system used for these permissions is different. This method only seemed to work for the Microsoft Graph (and not for the Azure AD graph). Assigning credentials is possible using PowerShell: An Application Administrator (or the On-premise Sync account if you are escalating from on-premise to the cloud) can assign credentials to an application, after which this application can log in using the client credential grant OAuth2 flow. So to enumerate this we have to get a bit creative. There is however no way to query within an Azure AD which roles have been assigned to default Microsoft applications. When we try to query for applications that have been assigned one or more roles, we can see that in my test directory the appadmintest app has a few roles assigned (though it’s not exactly clear what roles that are since there’s a lot of GUID references): The roles defined in the Microsoft graph application can be queried using the AzureAD PowerShell module: In the documentation and Azure Portal, these roles are called “Application permissions”, but we’re sticking to the API terminology here. These are actually roles defined in the Microsoft Graph application, which can be assigned to service principals. If you read the documentation for the Microsoft Graph permissions you can see permissions such as. The way Azure AD applications work is that they can define roles, which can then be assigned to users, groups or service principals. In an Office 365 tenant, service principals are created for these applications automatically, giving an Office 365 Azure AD about 200 service principals by default that all have different pre-assigned permissions. For Office 365 and other Microsoft applications, the Application definition is present in one of Microsoft’s dedicated Azure directories. The Azure portal makes it even more confusing by calling Service Principals “Enterprise Applications” and hiding most properties of the service principals from view. ![]() This can be quite confusing as in the documentation they are usually both called applications. An application is the configuration of an application, whereas the Service Principal is the security object that can actually have privileges in the Azure Directory. In Azure AD there is a distinction between Applications and Service Principals. The escalation is still possible since this behaviour is considered to be “by-design” and thus remains a risk. ![]() When revisiting this topic I found out the vulnerability was actually not fixed by Microsoft, and that there are still methods to escalate privileges using default Office 365 applications. ![]() Azure AD privilege escalation - Taking over default application permissions as Application Adminĭuring both my DEF CON and Troopers talks I mentioned a vulnerability that existed in Azure AD where an Application Admin or a compromised On-Premise Sync Account could escalate privileges by assigning credentials to applications. ![]()
0 Comments
Leave a Reply. |