The Attacker’s Guide to SSO and Passwordless Technologies
- Hello, everyone. It is great to have you all here and I think it's going to be a great session and we will all can learn from it valuable things. I'm Asaf Hecht, a team leader of one of the technical research team at CyberArk Labs. The team and I did lots of research working around cloud and modern authentication and authorization techniques. Today, we are going to dive into the minds of the attackers and talk about how they see the latest security trends of passwordless and single sign-on. Are these promising security concept indeed bulletproof? Let's start.
Well the best way to start the session is with something personal to break the ice. And I, like I guess many of you, worked a lot from home last year due to the corona virus situation. And one day I saw this nice guy with his dog in the background and just felt the same because I also have a dog running around in my house and so the video captures my daily feeling. - Maple could you stop just for a second? Three, two one. More cold air. Three, two, one. (dog barking)
Cold air continues across the area tonight potential for some frost and freeze for some of us. To warm up it's gonna take. (dog barking) (man clapping) Hey, Hey.
Come here, come here, come here. Sit. Three, two, one. Frost and freeze for some of us again tonight.
The cold air is lingering through much of the week. We'll show you when the best chance of precipitation is with future casts. (dog barking) Maple. Three, two, one. (dog barking) Maple. Excuse me. Hello. Come here. Come here, come here. Do you wanna be in this tease? Is that what you want? Come here. Just lean up here I can do this. Three, two, one.
- Well, so do you also feel like him sometimes? Personally I do. Anyway, let's begin. Modern environments are built from hundreds, hundreds of devices like laptops, servers, mobile phones, application and cloud services. And they are all connected together with thousands of (indistinct) communication and serving access needs.
The way that these access requests are being validated are with SQL element and it's only the valid identity source should know. Most of the time it will be done with passwords or binary keys like SSH keys, cloud access keys, and so on. From the attackers side these passwords and keys are the main targets. If the attacker's succeeding in the efforts of stealing these secrets they can easily impersonate the compromised identity and do whatever they want on the victim's behalf. For long decades these passwords and keys are the core problem of the cybersecurity field.
We all can agree that the amount of these password and keys is huge. Just think of yourself how many passwords do you have? How many online websites and system you are registered to? And how it's awful to manage all these passwords and also click them again and again into different applications. That's why in the recent years the world introduced two promising concepts. The first is passwordless authentication and the second is single sign-on also known as SSO. With SSO user can authenticated, can authenticate once and afterwards they can access all the connected devices and services. Therefore the users only have one password so it should be easier to make the password stronger and protect it better.
Now, does it really protect us from attackers? Well the answer is it's complex but in the bottom line no. No because there are two major break-in points. The first is the initial authentication. Many times it is still done with a password and we know that password are still one of the weak spots. Definitely when it is used by human users we tend to use weak password. We use them and even tend to write them down on a piece of paper.
And on top of all they are easy target for phishing attacks. The second break-in point is after the SSO is completed the initial, completed the initial authentication there is an identity token that is valid to multiple services and resources. If this one security token is compromised all the related services are compromised with it. Moreover it will also bypass multifactor authentication because the SSO token is being issued after the multifactor check was passed successfully.
So we don't love password and that's why passwordless' gaining more and more popularity. With passwordless methods you can authenticate yourself with biometrics attributes like face recognition and fingerprint or using a simple pin code. And in the background an extra layer of security was added that is using the local PPM of the device the trusted platform model. And after all of this, does it help? This is what we are going to discuss.
Let's dive into the details and see what attacker can still do. First we will focus on passwordless trend. Microsoft leads the market with their great and popular solution Windows Hello. With Windows Hello you don't need password anymore. Of course, only for the things that Windows Hello supports and currently has integration with but becomes more and more.
You can have a Windows Hello for business in the network environment with active directory and Azure active directory or even set it up locally without external active directory and replace your local login password. To be clear under the (indistinct) there are still password to every user. The user will not need to use them regularly but their password still exists for them and stored in the active directory just like before. With Windows Hello to each user who will be added additional authentication method additional keypass I would say and Windows Hello authentication is built on top of key-based and certificate-based authentication. Again in simple words you can think of a private and public keeper. The public key of the alarm mechanism is being stored in a new attribute in the active directory that you can see here.
It's called msDS-KeyCredentialLink. And the private key of the user is stored on the device itself. In the best case the private key will be stored inside the local TPM.
TPM is ultimately a physical trusted platform model that makes the private key inaccessible for the operation system and prevent remote access to the keys from the network. You can see here a nice diagram. Now here come the tricks. The private key in the TPM is secure by a passwordless method. It is locked unless the passwordless method was successfully passed. In Windows Hello these methods could be using a face recognition, fingerprint, pin code, and more as you can see in the picture.
Only when the initial passwordless check was passed successfully then the private key is unlocked in the TPM and the domain authentication process is starting with the active directory. In general Windows Hello is a great thing because the private key never leaves the local device and supposedly cannot be extracted by regular users and used from a different computer. If a user configured Hello on different machines there will be different unique private key for each one of these machines. Hello is also considered as a multifactor solution because it involves a key or certificate that is tied to the physical device and there is also the additional method for starting the Hello authentication process if it's a biometric element or other secrets like a pin code. Here you can see the full authentication process. First, the user start the process and needs to pass the face recognition check as in the second example here.
Then the private key is unlocked from the TPM and is used for starting a Kerberos authentication in the domain. The active directory validates the usage of the private key against the related users public key. And if the validation is successfully the authentication process is completed by sending a TGT, ticket granting ticket, to the endpoints. From here the access to the resources by the endpoint and by the user are the same as before as being done without Windows Hello. You can see the Hello only chains the first authentication phase and not the ongoing process of accessing the network resources after the first authentication is completed.
So sounds great isn't it? But what the attackers still do? This is our main goal for today. Well, the fact is the most of the active directory attacks still work. The reason is Windows Hello just changes the first authentication step. After this it's still Kerberos and NTLM authentication in the environment. Therefore attackers can still perform the notorious domain attacks of pass the hash, pass the ticket, and over-pass the hash.
And this is one of the important slide here. We should all realize this one and let's see a demo for pass the ticket attack in the an environment that is a full adoption of Windows Hello. Well here is an endpoint of a user name U. You can see U can log in with a password and with a pin. Now I will login with the pin code. It means that I'm login currently with windows Hello.
Now I locked the computer and change the user for an administrator. I'm loading Mimikatz and performing the log-on passwords command. And you can see here user U, also even when it's configured with Windows Hello passwordless solution it's still as NTLM hash.
Now what about Kerberos tickets? I will use Mimikatz to export them from the memory. Here they are. You can see that the end point the machine and the U is Kerberos tickets even in these passwordless methods. Next thing as an attacker I could take these Kerberos tickets and copy them to a different machine. Now I'm changing the look to a different server and I'm logging in to the different server as an administrator. Next thing is you can see here the Kerberos tickets the free tickets I copied earlier.
Now you can see that currently in my memory, device memory, there are a bunch of Kerberos tickets for the administrator user. I remove them. You can see currently there are no tickets in the memory. The next step in the pass the ticket attack is to use Mimikatz to load the copied Kerberos tickets of U user to the memory. Here it is done.
You can see that I loaded the TGT of U into the memory but I still administrator. Now when I'm doing the action on the network you can see that TGT is getting more TGS for the U users. And this is how pass the ticket attack still happens in passwordless authentication environment. In addition to all the popular domain attacks that are still valid in Windows Hello environment there was also some attack surface around Windows Hello itself. The researcher Michael Grafnetter described three attack vectors in the past.
Injecting a Windows Hello key into the user. In this attack vector the attackers injects a custom NGC next generation credential key to the user active directory attributes. The attack steps are generate an RSA key pair, create NGC blob from the RSA public key, write the NGC blob to the active directory, and authenticate using PKINT. Prerequisite to this attack is to have write permission on the target user account. That's means it could be done only as a post-exploitation action but it's still useful for attackers. In addition Windows Hello's keys that were created by TPM version older than 2017 are vulnerable to be cracked in an easier way.
You can see the publication about this ROCA vulnerability that's made big waves a few years ago. Another thing is when someone sets up Windows Hello the Hello's public key is written to the on-premises active directory and also to the Azure active directory. And this key is tied to the user and to the device. If the device is removed, it's attached Windows Hello key is considered orphaned. However this orphaned keys deleted and sometimes even if they're corresponding device is remove.
While any authentication to Azure active directory using an orphaned key will be rejected some of these keys cause security issues in active directories on-prem in the version of 2016 and 2019. So be careful. Now it's time to talk about single sign-on. Most of the organization progressed in the recent years to hybrid networks architect tools.
In hybrid environments you can easily enjoy the advantages of both worlds, right? The cloud and your old on-prem systems and networks. The connectivity to the cloud could be done with different IAM and single sign on solutions with federation solution like ADFS and also there are a few synchronization solution like Azure AD Connect. In the case of Azure AD Connect, you can install it on an on-prem server and it will connect and kind of replicate the on-prem active directory to the Azure active directory. In that way, all the users could also be authenticated to the cloud in a convenient way over the internet and from anywhere (indistinct) access the different online application without any limitation of being inside the on-prem network or using VPNs. The synchronization also applies to the domain device accounts. A machine in the hybrid environment will be defined as a joint device both in the on-prem active directory and in the Azure active directory.
Here you can see an example. On the right you can see the on-prem domain of the machines and on the left you can see that in the same time the machine is also defined as an Azure AD join device. In addition you can see the connected Azure tenant ID and tenant name.
In hybrid environments there are many advantages and they're related one to our talk is the ability to do an out of the box SSO. You log on once to your local machine and then can access a different and more cloud services and online applications. You can access this online services with your web browser. In Chrome there is a great extension by Microsoft that will do the connectivity work for you. And in Edge browser this functionality comes built in natively. Here is an example to a list of several connected online application that I can access automatically with my previous initial authentication and without the need to enter my password again.
This is a great thing. Now a short background on modern authentication and authorization. Where the OAuth protocol which provides authorization and access to resources and with open ID connect that is based on OAuth and adds a layer of authentication and SSO capabilities. Both are super, super popular.
OAuth is built from validation of different security's tokens. First you get the refresh token and with it you get an access token and with the access token you are being authorized and get the final access to the desired application. In the case of Azure browser SSO here is the main stream.
The users logs on then gets a PRT, primary refresh token. The PRT is more of a long-term persistent token that reminds the ticket granting ticket, the TGT, in Kerberos in the domain active directory. With the PRT you get a PRT cookie that is in a JWT structure.
Then to access the online application the PRT is in use for getting refresh tokens and access tokens like we saw earlier in the hall of logic. In real life in this process there is some more complexity and some use of dynamic and derives keys that's add more security. These keys are issued per device and per session.
The question you should ask yourself is, where all these keys are being stored on the machine? Because they are sensitive right? They are providing access and here is the answer. The PRT is stored in the TPM or in the registry if no TPM is available. And the PRT cookie is stored in the Lsass memory in the CloudAP one of the authentication packages. The refresh and access tokens are used a lot by the browser and they are stored by using for example DPAPI mechanisms. The next and an important question from the attacker's side is how you can extract these keys and what are the required privileges for doing it.
You can see that with local admin rights on the machines you can extract the PRT itself and therefore steal the entire SSO authentication context. And even without admin rights, attacker can still access the browser data of the compromised user and then impersonate his SSO context and access on his behalf or our behalf the target application and make lots of damage. Here is a summary of the two attack vectors we discussed.
With the regular user privileges attacker can request regular refresh tokens like the user and access Azure AD connected resources. Additionally with local administrator privileges attacker can extract the entire PRT and even use it from a different machines. Very risky. That is how new attack is introduced to the world.
The attack of pass the PRT. This is what we described here. The amazing thing is that it's already supported in the famous Mimikatz tool and you can see here a tweet by Benjamin Delpy.
So great research work in the past in this field was done by Dirk-jan Mollema and again Delpy and you can see here another tweet on the proof of concept they did on these methods of attacking the browser SSO. When talking on OAuth protocol it's important to also mention the weakness in OAuth application that our cyber labs discovered. We called it BlackDirect Vulnerability. In every OAuth application there is a list of URLs that are that the tokens are allowed to be transferred to. This also, this is also known as the list of the allowed redirect URLs.
In the research we did we discovered orphaned URLs, URLs in sensitive OAuth application and potential attackers could reduce that, these sub domains to themselves and then hijack the security token of this sensitive application. Here is the main flow in OAuth. The user browses to the target application, office.com as an example. The application, the online service redirect the user to the authorization server forgetting his access token. Then the browser sends a request to the authorization server for creating access token. The browser gets the access token and with it provide it to the office.com and get his data.
And here is the attack scenario when attackers exploit BlackDirect vulnerability. When they registered took over a domain that was trusted by one of the OAuth application. The clients surf to the compromised subdomain then the subdomain that is being handled by the attacker is transfer them to the authorization server and authorization server provides in creating an access token and this time the access token is being sent to the attacker's server. And in his (indistinct) he can access the user's data on his behalf and do whatever you want with it. The reason for this vulnerable OAuth application is because it is an hard task to correctly manage all the connected subdomains. You can see on the right some example, real examples for the orphaned subdomains URLs that we discovered and were reported to Microsoft so it's okay, they are fixed now.
Yeah but you can see the quite complex subdomains and but still they're important ones and the application trusts them. Access token could be sent to them. It's part of this (indistinct) research we develop and publish a free scanning tool. You can see you can easily scan your environment by going to the, this website here black.direct. Many companies already scanned themselves and were amazed by the findings.
You can see that in the average there are about six vulnerable URLs in each company. So we'll commend you as well to scan your OAuth application and their trusted URL. Then be sure to handle the orphaned URLs that attacker might take over. Protect your OAuth application before something bad happens.
That's it for today. Let's talk on what you can do for mitigating the attack vectored we discussed. First make sure all your SSO and passwordless solution are implemented according to their best practices and make sure to install the latest updates.
Then focus, and this is the most important step, focus on the important things of securing your privilege accounts, including local admins, sensitive application, and your remote access procedures. Remember if the security fundamentals will be compromised SSO and passwordless will not help and the attackers will celebrate with the attack vector we covered today. In addition, we recommend on performing periodic scans for the threats we presented including removing unused Windows Hello keys, go for the logging, login logs in your environments and scan yourself against BlackDirect Vulnerability. To sum it up we reviewed the real life threats in the field of passwordless, SSO, and OAuth.
More details are available online. We invite you to check them out. Follow the best practices when implementing these new technologies and the most important thing is ensure the security fundamentals are in place like protecting the access point of our network and secure your privilege accounts. Thank you for joining the session today. I hope you learned several important things and if you have any question or feedback feel free to contact me through my Twitter account @Hechtov.
Also we invite you to have a look at our CyberArk Labs dedicated website. It is more useful security open source tools and publication of the research work we do. Thank you and have a good day.
2021-07-21 12:44
