ROPC - So, you think you have MFA?
This post will highlight a pattern I have seen across multiple production Microsoft Azure Active Directory tenants which led to MFA bypasses using ROPC.
The key take-away: Always enforce MFA! Sounds easy, but there are often misconfigurations and unexpected exceptions. So, test your own AAD tenant for ROPC based MFA bypass opportunities.
Update: The latest free issue of Pentest Magazine has a ropci article. Check it out.
What is ROPC?
Resource Owner Password Credentials (ROPC) is an OAuth2 authorization grant type (“flow”) defined in RFC 6749.
password directly to obtain an access token.
This is problematic because:
- The client process sees the user’s password.
- It maintains the password “anti-pattern” that OAuth2 otherwise solves.
The reason it exists is to support a smoother migration from legacy applications to OAuth2.
Microsoft highlights this in their documentation:
And OAuth 2.0 Security Best Current Practice states it even more clearly:
So, the take-away is: ROPC MUST NOT be used
Wait, but what is this ROPC and am I using it?
How does the ROPC flow look like?
At a high level the
grant_type in the OAuth2 POST request will contain this parameter:
This highlights the
resource owner password credentials flow.
ROPC request looks as follows:
As can be seen, the request contains
username/password and the
Microsoft refers to
client_id often as
appID in their internal documentation and UI. There is no
client_secret with these appIDs - they are also called public clients.
If authentication succeeds, the response will contain an
access_token amongst other information:
Wait, I don’t have ROPC OAuth apps in my tenant!
AAD ships 50+ apps by default that support ROPC and are active (as service principals) in every tenant.
Here are a few examples:
Combined the various applications have permissions such as reading AAD info (users, groups, permissions), reading/sending emails, accessing Azure, access and uploading information to SharePoint, etc.
So, what do I do with this info now?
From an offensive security perspective, the following questions are interesting:
- How to test for ROPC exposure?
- What kind of tests to run?
- What questions to ask or AD admins?
To aid with testing I wrote
./ropci which is a Microsoft AAD ROPC assessment and attack tool.
You can download the code and pre-compiled binaries for Windows, Linux and macOS from Github: https://github.com/wunderwuzzi23/ropci
I will do another post to highlight its usage more clearly, but if you go over to the Github it should have everything needed to get you started!
To test a single account of your AAD tenant run:
./ropci auth logon -t $YOUR_TENANT -u $YOUR_USER -P --discard-token
Where you set or replace
$YOUR_USER with the account and tenant to test.
-P: means to prompt for password, rather than reading from config file or command line.
--discard-token: if authentication succeeds, the returned access token will not be stored.
It will look something like this:
./ropci auth logon -t contoso.onmicrosoft.com -u email@example.com -P --discard-token
- If authentication succeeds, you will see a success message and the retrieved scopes.
- If authentication fails, you will see the AAD error message that was returned.
To use all features run
./ropci configure. This will ask you for tenant, username, and password.
Afterwards you can run
./ropci logon to use the configuration, get a token and run commands:
Note: Even if ROPC logon doesn’t work and you’d like to use
ropci, you can attempt devicecode phishing, or just use devicecode auth to get a token for yourself (see
./ropci auth devicecode).
If you get a token, you can use all the other features of ropci to access the AAD tenant, including:
- Accessing Graph APIs and information such as users and groups in the tenant
- Search the user’s mailbox, and send mail
- Download or upload files to SharePoint,
- Call Azure Resource Manager and run commands on VMs
- Enumerate applications and scopes
I will write about how to use these features more in upcoming posts. For this post, let’s just discuss the basic test to see if there is an ROPC based attack avenue.
Go and Test ROPC scenarios!
Test your own tenant for these attacks to make sure an adversary can’t exploit them:
Attempt ROPC logons for your AAD tenant using
These are some of the basic accounts you should try this out for:
- Your own user account
- Service accounts
- AAD only accounts (consider hybrid and federation scenarios)
Its also good to discuss this topic with your IT admins.
Identify applications that support ROPC (the offsec way)
Check all apps in your tenant (in case you also have custom ones) and attempt an ROPC logon through them and what scopes are retrieved.
./ropci apps list: Enumerate all OAuth apps in your tenant
./ropci auth bulk: Test all apps, and review results and granted scopes
ROPC Password Sprays
- An adversary can use ROPC to perform a password spray (
./ropci auth spray)
ropci doesn’t change IPs during sprays. Checkout TeamFiltration if you need that capability.
Take-aways for ROPC
- Always explicitly enforce MFA!
- Security defaults might not adequately protect your user accounts
- Hybrid and federated MFA enforcement can leave “native” AAD accounts vulnerable
- Test and validate your configurations from an offsec point of view!
- Some scenarios might remain vulnerable to SFA => Should a conscious decisions
- Know your weaknesses, monitor exposure, and continue mitigating and locking down exposures
Hope this post and tool will help in improving the security posture of AAD tenants.
Related Research and Tools
A lot of relevant and great research and tooling out there, e.g.:
- AADInternals by @DrAzureAD
- “Abusing Family Refresh Tokens” by SecureWorks
- ROADTools and more recently TeamFiltration,…