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.
Github: https://github.com/wunderwuzzi23/ropci
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.
It uses username
and 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:
grant_type=password
This highlights the resource owner password credentials
flow.
A complete ROPC
request looks as follows:
As can be seen, the request contains username/password
and the client_id
.
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.
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?
Introducing ropci
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!
Basic Usage
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_TENANT
and $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 test@example.org -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.
Configuration
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:
That’s it.
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
).
Getting offensive
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
)
fyi: 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.
Greetings.
知己知彼,百戰百勝.
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,…