The Economy of Mechanism – Office365 SAML assertions vulnerability popped up on my radar this week and it’s been getting a lot of attention. The short version is that you could abuse the SAML authentication mechanisms for Office365 to access any federated domain. It’s a really serious and interesting issue that you should totally read about, if you haven’t already. I have a feeling that this will bring more attention to domain federation attacks and hopefully some new research into the area.
Since I’m currently working on some ADFS research (and had this written), I figured now was a good time to release a simple PowerShell tool to enumerate ADFS endpoints using Microsoft’s own APIs. The SAML assertions blog post mentions using this same method to identify federated domains through Microsoft. I’ve wrapped it in PowerShell to make it a little more accessible. This tool should be handy for external pen testers that want to enumerate potential authentication points for federated domain accounts.
If you are trying to authenticate to the Office365 website, Microsoft will do a lookup to see if your email account has authentication managed by Microsoft, or if it is tied to a specific federation server. This can be seen if you proxy your traffic while authenticating to the Office365 portal.
Here’s an example request from the client with an email address to check.
GET /common/userrealm/?user=karl@example.com&api-version=2.1&checkForMicrosoftAccount=true HTTP/1.1 Host: login.microsoftonline.com Accept: application/json Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate X-Requested-With: XMLHttpRequest Connection: close
You will get one of two JSON responses back from Microsoft:
{ "MicrosoftAccount":1, "IsDomainVerified":0, "NameSpaceType":"Federated", "federation_protocol":"WSTrust", "Login":"karl@example.com", "AuthURL":"https://adfs.example.com/adfs/ls/?username=karl%40example.com&wa=wsignin1.0&wtrealm=urn%3afederation%3aMicrosoftOnline&wctx=", "DomainName":"example.com", "FederationBrandName":"ExampleCompany" }
{ MicrosoftAccount=1; NameSpaceType=Managed; Login=support@OtherExample.com; DomainName=OtherExample.com; FederationBrandName=Other Example; TenantBrandingInfo=; cloudinstancename=login.microsoftonline.com }
To make this easier to parse, I wrote a PowerShell wrapper that makes the request out to Microsoft, parses the JSON response, and returns the information from Microsoft into a datatable. You can also use the -cmd flag to return a command that you can run to try and authenticate to either federated domain servers or to the Microsoft servers.
Here’s a link to the code – https://github.com/NetSPI/PowerShell/blob/master/Get-FederationEndpoint.ps1
Here’s an example for each scenario:
PS C:\> Get-FederationEndpoint -domain example.com -cmd | ft -AutoSize Make sure you use the correct Username and Domain parameters when you try to authenticate! Authentication Command: Invoke-ADFSSecurityTokenRequest -ClientCredentialType UserName -ADFSBaseUri https://example.com/ -AppliesTo https://example.com/adfs/services/trust/13/usernamemixed -UserName 'test' -Password 'Summer2016' -Domain 'example.com' -OutputType Token -SAMLVersion 2 -IgnoreCertificateErrors Domain Type BrandName AuthURL ------ ---- --------- ------- example.com Federated Example Company LLC https://example.com/app/[Truncated]
If you’re trying to authenticate with this command, it’s important to note that this does require you to guess/know the domain username of the target (hence the warning). Frequently, we’ll see that the email address account name (ex. kfosaaen) does not line up with the domain account name (ex. a123456).
PS C:\> Get-FederationEndpoint -domain example.com -cmd | ft -AutoSize Domain is managed by Microsoft, try guessing creds this way: $msolcred = get-credential connect-msolservice -credential $msolcred Domain Type BrandName AuthURL ------ ---- --------- ------- example.com Managed example NA
If you get back the “managed” response from Microsoft, you can just use the Microsoft AzureAD tools to login (or attempt logins).
Since this returns a datatable, it’s easy to pipe in a list of emails to lookup federation information on.
*Screenshot Note – This was renamed from Get-ADFSEndpoint to Get-FederationEndpoint (10/06/16)
Both of the authentication methods that the script returns are taken from Microsoft, and since I don’t own that code, I can’t redistribute it. But here’s some links to get the authentication tools from them.
The code for Invoke-ADFSSecurityTokenRequest comes from this Microsoft post:
The Microsoft managed authentication side (connect-msolservice) comes from the Azure AD PowerShell module. See Here:
Finally, here’s a nice run down from Microsoft on how you can connect to any of the Microsoft online services with PowerShell:
Taking this further, you could wrap both of these authentication functions to automate brute force password guessing attacks against accounts. Additionally, you could just use this script to enumerate the federation information for the Alexa top 1 million sites. Personally, I won’t be doing that, as I don’t want to send a million requests out to Microsoft.
I actually have some other stuff in the works that is directly related to this, but it’s not quite ready to post yet. So keep an eye on the blog for more interesting ADFS attacks.
PTaaS is NetSPI’s delivery model for penetration testing. It enables customers to simplify the scoping of new engagements, view their testing results in real time, orchestrate faster remediation, perform always-on continuous testing, and more - all through the Resolve™ vulnerability management and orchestration platform.
Learn More
We help organizations defend against adversaries by being the best at simulating real-world, sophisticated adversaries with the products, services, and training we provide. We know how attackers think and operate, allowing us to help our customers better defend against the threats they face daily.
At NetSPI, we believe that there is simply no replacement for human-led manual deep dive testing. Our Resolve platform delivers automation to ensure our people spend time looking for the critical vulnerabilities that tools miss. We provide automated and manual testing of all aspects of an organization’s entire attack surface, including external and internal network, application, cloud, and physical security.
Our proven methodology ensures that the client experience and our findings aren’t only as good as the latest tester assigned to your project. That consistency gives our customers assurance that if vulnerabilities exist, we will find them.