Risks Using a Third Party Identity Provider with Azure
ACM.177 Did the US government say you should not use third-party Identity Providers with Azure?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: Azure Security | Multicloud Security | Data Breaches
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I was recently informed by someone that the US government recommends against using a third-party Identity Provider with Azure. He pointed me to this document at the end of the post so I could read the in-depth report to understand the threat.
I really appreciate this because I am, at this moment, researching security related to identity providers and anything that helps in this effort is much appreciated. The report is from 2020 — about the same time the Solar Winds breach occurred. I wrote about that breach at the time and have some related information below.
My question: Is that really what the document says and why?
Considering Context of Threats
It is important to understand the context and details when you are trying to analyze the best approach for security in your environment. I haven’t read the document yet. I copied and pasted key bits below and will read through it as I write this.
But my first reaction is, does this document actually make a blanket statement that you should never use a third-party IdP with Azure? Because there are potentially architectural benefits to segregating authentication from the cloud providers themselves. That comes with definite risks we need to assess and address, but can they be adequately addressed?
There was a time when everyone said “The cloud is not secure.” and “No one will ever use the cloud.” These statements are very broad, general, and lack a big picture understanding of what “cloud” is.
I looked at cloud differently. Although I understood the security challenges associated with cloud and did not initially want to move to the cloud myself, over time, my opinion changed. I saw additional controls implemented by AWS, specifically, and I saw security weaknesses and gaps in the way software got deployed at my own organization.
But let’s find out what the problems are with identity providers according to the document below and see if they can be addressed. Perhaps there is a particular vulnerability I need to be aware of with a certain Identity Provider or a specific problem with the way a particular technology works that I am not aware of yet.
What problem am I trying to solve by investigating a third-party identity provider?
Let’s consider the problem I’m trying to solve before we did into the actual risks. I wrote about the concept of privilege escalation when users have the ability to both create users and assign them permission in a few posts and how to mitigate it here:
I also explained the differences between the various Identity Provider (IdP) implementations here. These differences are important to understand as you build out your identity and authentication architecture. Where do your passwords exist? In how may places and systems? Would access to one system grant access to all your systems?
I recently showed (partially, not done) how you can alleviate the above Create User problem using Okta, but that’s only one of our security concerns:
I’m still assessing the product and considering the big picture and this document that was sent to me helps me think through some future blog posts I hope to write and things I will be testing.
Risks when using an IdP
One of the risks with Identity Providers is the way in which enable authentication as noted in my above post about IdPs. In some cases an IdP will “federate” authentication in such a way that passwords are not shared between systems. In other cases the passwords are “synced.”
If you use Microsoft Azure Active Directory, it does not support using certain Identity Providers in a federated manner (like Okta). You must sync passwords. In that case, all your passwords are visible to Microsoft at the point of entry. Though I’m sure Microsoft has a secure process around this syncing, I haven’t dug into the details, nor would I likely be able to get access to truly analyze these systems for any possible security weaknesses. Large companies may have more leverage to do a deep dive into this process.
Are those the same passwords you use to log into everything else? Hopefully you have configured solid MFA not susceptible to phishing attacks so that the password alone, if compromised, cannot be used to log into all your systems. That may include other cloud systems where you use the same username and password.
After syncing the passwords, Microsoft does a separate hash the passwords that is different from the original source, which is good. But there’s still a risk associated with the password exposure during the syncing process. What about access to an active session or a token in transit? I’d have to dig into this a lot more to truly understand the risk in that case and how cross-cloud compromise might be possible.
If you use Azure AD as your IdP, Microsoft has visibility into all the products and services you use. Also, all your passwords exist on Azure if you must sync them as just noted. This risk is true of any SSO provider, IdP, or password manager. Having all your passwords in one place makes that system a target.
Take the example of a the breach at LastPass, a password manager. If all your passwords are in one place and someone can access them and you are using a weak form of MFA, an attacker that can obtain them all from your password management system and log into anything you can access.
You need to ensure whatever system you use for passwords or authentication is secure. If you choose Azure as an IdP you have to understand all the details about where and how passwords are stored.
You’ll also want to understand all the ways someone can create a mechanism on Azure that allows someone to authenticate and access resources in Azure. That topic is bigger than this blog post but some helpful references for securing Azure exist in the links below from Microsoft. It is up to you to secure things properly and evaluate the risk.
Azure has many different ways to authenticate requests, depending on which service and feature you use. They have different mechanisms for authenticating application users, accessing objects in storage accounts, and even different flavors of Azure Active Directory. You’ll want to understand them all and who can use them or grant access to use them, no matter how you choose to authenticate.
If you only allow authentication by a third-party IdP and lock down all Azure mechanisms for authentication, then you have to worry about all the security risks that may exist when using an IdP to authenticate to Azure. Now your IdP may have all your passwords.
The one nice thing with using an IdP is that you have logging related to authentication requests and access in two separate systems. An attacker may need access to two systems to carry out an attack, depending on the nature of the attack and your security architecture. What if an attacker wants to create a back door user to access your cloud system? By create a multi-layered approach to adding new users to the system and giving the new user access, you might be able to make that harder to do.
Another concern has to do with downtime associated with the Identity Provider. If your Identity Provider is down — you may not be able to log into anything. Microsoft has had a number of outages recently, including this recent 5-hour self-inflicted outage. These outages are not caused by some malicious actor. They are simply mistakes. Microsoft is too critical to be making mistakes like this that take down systems for such a long period of time. I hope they can get a handle on the internal governance and processes that are allowing these things to happen.
Networking between the IdP and the systems to which you are trying to authenticate is another concern. How can you keep all the interactions private when your employees authenticate to your cloud platform. While reviewing Okta I was surprised to find they do not have a networking option for AWS PrivateLink. Without even looking at vendor documentation I almost assume that any major vendor that integrates with AWS will offer this option. Perhaps this feature is in the works.
I also wrote about the challenges of keeping authentication on a private network when using a SAML solution where the integration point is a user’s browser. If your user is not on a private network, then your SAML interactions with their browser won’t be either.
We’ll need to consider things like Golden SAML. That attack applies to ANY IdP that leverages SAML — whether you’re using SAML with Azure as the IdP to access other clouds or a third-party IdP that accesses Azure using SAML. That attack depends the credentials leveraged to sign SAML tokens.
The Golden SAML attack leverages a compromised account to get the necessary pieces of information that allow an attacker to log in as any user via your IdP Integration. The attacker can forge tokens that are used in the SAML process to authenticate to systems.
Note that this attack is similar to a Kerberos-related attack called the Golden Ticket attack which similarly obtains the necessary information from a Domain Controller to login as any user by forging tickets.
If you are using an on-premises Active Directory system and no third-party access via SAML and ADFS, you won’t have to worry about the Golden SAML attack, but you’ll have to worry about the Golden Ticket attack.
If you use Azure AD to allow users to log into Azure, you won’t have the Golden Ticket attack to worry about since Azure AD does not use Kerberos.
You also won’t have to worry about the Golden SAML attack — unless you use Azure AD with SAML to allow users to log into other systems. Then you have to worry about where the credentials exist that can sign SAML tokens, whether controlled by Azure or your own company. You will also want to understand who can configure systems to leverage SAML and it’s capabilities. For example, who can set up and configure a new IdP on Azure?
What if you are only using Azure AD to login to Azure? Well, now you need to be concerned about how sessions can be hijacked and credentials can be stolen. A myriad of ways to do that exist.
Another concern is the risk associated with support teams related to Identity Provider solutions — including specific interactions with both Okta and Microsoft support. Organizations need to perform appropriate security assessments and ensure their own users are not providing too much information to vendor support teams.
The bottom line is that no matter which authentication mechanisms you choose, you have to ensure that they are secure.
So my question is now:
Can we secure a third-party Identity Provider in conjunction with Azure and what is the risk presented in the document I was provided. Is it enough to make me want to only use Azure as my identity provider for Azure? What about other systems I might need to integrate with using SAML or some other password syncing process?
In my case, I need a solution to log into all the things…if I use Azure as an IdP to log into all the things I have simply shifted the risk from the third-party IdP to Azure.
Understanding the risks addressed the document
Let’s take a look at the document and see what risks it addresses out of the above list, or is there something else like a specific vulnerability at certain IdPs?
The first thing I noticed was this:
The exploitation occurs after the actors have gained access to the victim’s on-premises network.
Right there, we see that the attack doesn’t start with a third-party identity provider or Azure for the particular attack this document addresses. It starts with obtaining credentials in an on-premises Active Directory environment and does not apply to third-party vendor IdPs.
The attackers appear to be using the Golden SAML attack I just mentioned. That attack was leverage in the Solar Winds breach I wrote about here and the document below came out around the same time:
The root problem was not with a third-party identity provider or ADFS or federation. The problem was that the attackers got administrator credentials that allowed them to get the bits that allowed them to forge requests that grant them access to resources similar to obtaining the infamous “domain admin” on a penetration test. Game over.
From an article by CyberArk on the Golden SAML attack:
To perform this attack, you’ll need the private key that signs the SAML objects (similarly to the need for the KRBTGT in a golden ticket).
For the private key you’ll need access to the AD FS account, and from its personal store you’ll need to export the private key (export can be done with tools like mimikatz).
…
This attack doesn’t rely on a vulnerability in SAML 2.0. It’s not a vulnerability in AWS/ADFS, nor in any other service or identity provider.
Golden ticket is not treated as a vulnerability because an attacker has to have domain admin access in order to perform it.
In that last statement above, I think they meant to say access to the ADFS account that can sign SAML tokens, because earlier in the post they mention that Domain Admin access is not required.
The document below states that without administrative access to the on-premises IdP actors would not be able to generate tokens.
In the case of Solar Winds, attackers obtained administrative access by breaching Solar Winds, inserting malware into the product, and using the product to steal administrative credentials. The administrative credentials had the necessary permissions to facilitate the attack.
The document is recommending moving on-premises Active Directory federation to Azure. I do not see that it recommends against a third-party IdP.
That said, the same type of attack would be relevant to a third-party IdP if using SAML. The concern would also be relevant if you use SAML with Azure as an IdP to access third-party systems. If the credentials get compromised that have access to signing forged requests in any scenario where SAML is in use, you have a problem.
Microsoft does recommend an HSM to help alleviate this problem in some documentation below, but if someone has permission to leverage the HSM to forge a request, that may not solve the problem either. It depends on the permissions users and applications have to leverage the keys in the HSM.
Bottom line:
You need to secure your systems and credentials involved in any form of authentication process.
What does the document recommend in terms of third-party identity providers for Azure?
Taking a look at the document specifically, it states that there is no vulnerability related to identity providers.
The document seems to be concerned specifically with compromise of on-premises ADFS servers that authenticate users to access Azure. They recommend consolidating in Azure because it might help prevent some of the on-premises misconfigurations and attacks.
But are we just kicking the can down the road? Now we have to make sure the Azure configuration is secure and limit the credentials of the user accounts who may be assigned privileges to perform the same or a similar attack, coming from Azure rather than on-premises servers.
In the end, the document gives the same caveat I presented above: If you use Azure AD instead of on-premises Active Directory, now all your passwords are in Azure.
Consolidation of accounts may be helpful if you are all-in on Microsoft. Just make sure you’re not making the assumption that moving Active Directory to Azure Active Directory immediately solves all your problems.
If you do move to Azure Active Directory you have some amazing tools that can help. Consider using conditional access and just-in-time access for critical credentials and actions that could be used to set up new authorization mechanisms or leverage existing mechanisms in an unauthorized manner. Use an MFA solution that is not accessible to the cloud provider so that a malicious insider or attacker in the cloud environment cannot initiate a session. Monitor active sessions with high privileges. Make sure you follow the recommended configuration guidance from Microsoft.
This document below does not actually address third-party IdPs or present any particular vulnerability associated with them. If you are going to use Azure to log into other cloud systems, then Azure is essentially your third-party IdP as far as those systems are concerned. Then all the risks associated with third-party IdPs with Azure apply to Azure from the perspective of other cloud providers like AWS or GCP.
If you understand the potential attacks, you will understand how some of those attacks may or may not be mitigated by using Azure as an IdP, or may still exist in other forms. So far, I don’t see anything in this document that convinces me I should never use a third-party IdP. But this is still really good information to have and I appreciate the person who sent it over to me for review.
I have a specific problem I’m trying to use by leveraging a third-party IdP as noted above. I want to segregate my credentials and authentication from any one cloud platform. I don’t particularly like some aspects of Azure for my particular use case. It is probably a fine solution for other companies but not the one I’m choosing at the moment.
I’m also not finished evaluating Okta. And I’m not through digging into SAML and SSO security…we’ve only scratched the surface. I might write more about the Golden SAML attack in upcoming posts and other security issues that could exist — regardless of where you host your SSO configuration or Identity Provider. How is the key protected that can facilitate that attack? That’s something you’ll want to figure out no matter which solution you choose.
Read the full document here:
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab