BlueHat Seattle 2019 || I'm in your cloud: A year of hacking Azure AD
1 like879 views
The document discusses various aspects of Azure Active Directory (AAD), focusing on unauthorized access and privilege escalation vulnerabilities. It covers terminologies, service principals, permission models, and security risks associated with OAuth2 grants and administrator roles. Conclusively, it emphasizes the importance of monitoring and enforcing strong security measures, including multi-factor authentication and conditional access policies for all accounts, particularly those linked to on-premise systems.
BlueHat Seattle 2019 || I'm in your cloud: A year of hacking Azure AD
- 1. 1
- 2. A YEAR OF HACKING AZURE AD DIRK-JAN MOLLEMA / @_dirkjan I’m in your cloud… 2
- 3. - Lives in The Netherlands - Hacker / Red Teamer / Researcher @ Fox-IT since 2016 - Author of several Active Directory tools - Mitm6 - ldapdomaindump - BloodHound.py - aclpwn.py - Co-author of ntlmrelayx - One of the MSRC Most Valuable Security Researchers 2018/2019 - Blogs on dirkjanm.io - PrivExchange - Tweets stuff on @_dirkjan Whoami
- 4. • Azure AD terminology – Portal vs API • “Reversing” Azure AD via undocumented APIs • Digging into service principals • Linking up cloud and on-premise This talk
- 5. • Not related to on-premise Active Directory • Source of authentication for Office 365, Azure Resource Manager, and anything else you integrate with it. Azure AD
- 6. • Users • Devices • Applications Azure AD Principals
- 7. • Examples: • Microsoft Graph • Azure Multi-Factor Auth Client • Azure Portal • Office 365 portal • Azure ATP • A default Office 365 Azure AD has about 200 service principals (read: applications) Everything is an application
- 8. Applications and multitenancy – your apps
- 9. Applications and multitenancy – third party apps
- 10. Applications and multitenancy – Microsoft apps
- 11. • Two types of privileges: • Delegated permissions • Require signed-in user present to utilize • Application permissions • Are assigned to the application, which can use them at any time • These privileges are assigned to the service principal Application privileges
- 12. • Every application defines permissions • Can be granted to Service Principals • Commonly used: • Microsoft Graph permissions • Azure AD Graph permissions Permissions model
- 15. How permissions actually work API definition Portal terminology Every application defines: - OAuth2 permissions - Application roles App registration: - Delegated permissions - Application permissions An application requires: - Resource access App registration: - API permissions A service principal has: - OAuth2 permission grants - Application roles An enterprise application has: - Delegated permissions - Application permissions
- 16. • Normal flow: • Define required permissions in application • Approve permissions • Alternative flow: • Assign a service principal to a role in MS Graph/AAD Graph directly Hiding in plain sight
- 17. Application view
- 19. • No way to tell from portal or API which permissions they have The exception: Microsoft applications…
- 20. JWT
- 21. • Some admin roles allow managing all applications • Global Administrator • (Cloud) Application Administrator • Including assigning credentials • Possibility for backdooring Azure AD • No MFA for Service Principals • Possible to escalate privileges • If you control an application with more privileges than you • Default applications with more permissions than Application Administrator Why does this matter?
- 22. Application name Access Microsoft Forms Sites.ReadWrite.All Microsoft Forms Files.ReadWrite.All Microsoft Cloud App Security Sites.ReadWrite.All Microsoft Cloud App Security Sites.FullControl.All Microsoft Cloud App Security Files.ReadWrite.All Microsoft Cloud App Security Group.ReadWrite.All Microsoft Cloud App Security User.ReadWrite.All Microsoft Cloud App Security IdentityRiskyUser.ReadWrite.All Microsoft Teams Sites.ReadWrite.All Microsoft StaffHub Directory.ReadWrite.All Microsoft StaffHub Group.ReadWrite.All Microsoft.Azure.SyncFabric Group.ReadWrite.All Microsoft Teams Services Sites.ReadWrite.All Microsoft Teams Services Group.ReadWrite.All Office 365 Exchange Online Group.ReadWrite.All Microsoft Office 365 Portal User.ReadWrite.All Microsoft Office 365 Portal AuditLog.Read.All Azure AD Identity Governance Insights AuditLog.Read.All Kaizala Sync Service Group.ReadWrite.All Default app permissions 22https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/
- 23. • Log shows actions were performed by application Logging?
- 24. Application API Permissions Microsoft.MileIQ https://graph.windows.net/ user_impersonation SharePoint Online Client Extensibility https://graph.windows.net/ user_impersonation Microsoft Teams - Device Admin Agent https://graph.windows.net/ user_impersonation Microsoft Stream Mobile Native https://graph.windows.net/ user_impersonation SharePoint Online Client https://graph.windows.net/ user_impersonation Outlook Online Add-in App https://graph.windows.net/ user_impersonation Microsoft.MileIQ https://graph.microsoft.com/ user_impersonation SharePoint Online Client Extensibility https://graph.microsoft.com/ user_impersonation Outlook Online Add-in App https://graph.microsoft.com/ user_impersonation OAuth2 permissions – password grant 24
- 25. • OAuth2 password grant does not require verification • Any APP ID can be used • Interact with API’s with full user permissions • Run AAD PowerShell without the PS App ID • Makes defender’s life harder Abusing password grant permissions 25
- 26. 26
- 27. • At least nine depending on how many apps have impersonate privs How many different PowerShell usage records? 27 9
- 29. • No low-level access to Azure AD backend • No way to use traditional reversing to find out more How does it actually work? 29
- 30. • Portal • PowerShell modules • API’s Interacting with Azure AD
- 31. • Nice and shiny • Offers (almost) all configuration options • Does simplify concepts Portal
- 32. • Azure AD Graph • Microsoft Graph • Exchange Provisioning service API’s
- 33. • All of them have limitations • Unique features, yet deprecated • Different authentication methods supported • Different terminology Which one to use?
- 34. Front-end vs backend (Azure AD) 34 Azure portal Azure portal API Internal API? Database? ? ? Azure AD graph? Microsoft graph?
- 35. Once upon a time in the Azure Portal 35
- 36. 36
- 37. Front-end vs backend (Azure AD) 37 Azure portal Azure portal API Internal Azure AD graph API Database? ? ? Attacker/researcher
- 38. Azure AD graph metadata – internal version 38 File size
- 40. More unannounced features (DPAPI) 40
- 42. 42 Can be queried by any authenticated user
- 43. • Change “Mfa” control to “Allow” • Invisible in portal The Access Policy that wasn’t 43
- 44. • No details on properties Logs 44
- 45. • Passes checks Sign-in logs 45
- 46. • Details only available via undocumented API • Impossible to see in the portal • Not really visible in logs • Attack possibilities: • Exclude specific users • Disable entire policy • Change trusted networks • Fixed in October 2019 Conditional access policies backdooring TL;DR 46
- 47. 47 Digging into Service Principals
- 48. • Used for OAuth2 implicit grant (web) • Whitelist of URLs • Sends access token to URL in fragment (#) ReplyUrls 48
- 49. • Non-https URL • Portal refuses, API accepts • Expired domain • Relative URL ReplyUrls don’ts 49
- 50. Demo 50
- 51. • Microsoft Teams Web Client • Whitelisted http://dev.local • Has read/write access to Email, SharePoint, OneDrive • Allows for man/person in the middle attack • Not possible to identify in logs (Reply URL is not logged) • Fixed for new Office 365 tenants in September 2019, existing tenants in October 2019 • More details: https://dirkjanm.io/office-365-network-attacks-via-insecure- reply-url/ Office 365 insecure Reply URLs 51
- 52. • Hidden property “appMetaData” – only visible in internal API • Mostly for custom apps (Federated Certificate Storage) • Only used for a few apps by default • Interesting case “Device Registration Service” appMetaData 52
- 53. 53
- 54. • Property of service principal • Can be edited by Application Administrator Device settings 54
- 55. • Following principals have security identifiers • Users • Groups • Roles • Stored in “cloudSecurityIdentifier” property (internal API only) Security Identifiers in Azure AD 55
- 56. • Application Administrator can add SIDs to policy in metadata • Can be users/groups/roles • New device joined? User gets added to Administrators group • Rogue user is now admin on device • Not yet fixed (by design) Application Administrator to local Admin on devices 56
- 57. Portal doesn’t seem to like it… 57
- 58. 58 Linking up Cloud an on-prem
- 59. • Application administrator is high-privilege cloud account • Hopefully protected with MFA • What about on-premise? Exploiting the link with on-premise
- 60. • Tool that resides on-premise and syncs AD data to Azure AD • Installed in both Password Hash Synchronization and ADFS scenario’s Azure AD connect Source: https://docs.microsoft.com/en-us/azure/active- directory/hybrid/whatis-phs
- 61. • Possible to link new on-premise account to existing cloud-only account • Anyone with user creation privileges on-premise could overwrite the password of (admin) accounts in the cloud Previous vulnerability – Password Hash Sync https://blog.fox-it.com/2019/06/06/syncing-yourself-to-global-administrator-in-azure-active-directory/
- 62. • If Password Hash Synchronization is in use, the Sync account can sync all password hashes • Means it’s basically Domain Admin on-premise • Both with PHS and ADFS sync account has high privileges in the cloud • Cloud assets may extend beyond the AD Domain Sync account privileges
- 63. • Adconnectdump: 3 ways to dump the password on-premises • Technical explanation: see my Troopers presentation Azure AD Connect password extraction https://github.com/fox-it/adconnectdump
- 64. AD Sync account privileges in Azure AD
- 66. • Dump all on-premise password hashes (if PHS is enabled) • Log in on the Azure portal (since it’s a user) • Bypass conditional access policies for admin accounts • Add credentials to service principals • Modify service principals properties • Modify/backdoor/remove conditional access policies (internal API) Fun bad stuff to do with the Sync account
- 67. • RBAC roles can be assigned to service principals • These can be managed by Application Administrators • Also by the on-premise sync account • High privilege applications might need an account • Example: Terraform • Service principals credentials can be assigned by these accounts • Control over cloud resources Azure Resource Manager RBAC
- 68. 68 Conclusions
- 69. • Internal API version gives some insight into inner Azure AD workings • Application Administrators are more powerful than you’d think • Avoid using “global” Application Administrators, use scoped/custom roles instead • Service Principals can be backdoored and abused • Monitor for credential modification • Review credentials/owners • Review permissions and reply URLs for security issues Conclusions / recommendations 69
- 70. • Enforce MFA for all admin accounts • (Preferably for all accounts) • Use conditional access policies • Monitor modifications made • The AD Sync account is highly privileged on-prem and in the cloud • Treat it’s system as Tier 0 • Monitor for sign-ins from strange IP addresses • Implement recommendations from Sean Metcalf and Mark Morowczynski’s talk “Attacking and Defending the Microsoft Cloud” Conclusions / recommendations (2) 70