Sharon Goldberg – What to Do if Your SSO Gets Hacked

This is texturing TV. So this is a talk that I I'm going to be giving and besides SF in a couple of weeks. So you're getting a preview.

I was gonna give a talk on what to do if your SSO got hacked and then I decided since in like two weeks. I'm giving this talk. Anyway, I just wish them both together.

So it's a bit of like a mashup of two kind of like blog posts and talks that I've done. So I apologize for this slightly like bait and switch part of this talk. So the last like five 10 minutes, I'm gonna talk about SSO compromise, but the majority of the talk is gonna be on infrastructure access systems and how they get compromised.

So the reason I am talking about this is because I am the CEO of Bastion zero it is a startup in Boston where We are building solutions for providing access to your infrastructure for your engineering teams. And a lot of you know, the principles behind what we built. Are have been learned over 20 years of pain and cyber attacks?

And so what I'm going to be doing in this talk is walking through all of the different historical cyber incidents that led to some of the security principles we have in designing these kinds of systems today. So this will just be a fun talk talking through a bunch of incidents that have happened historically and what we can learn from them. So these are so how many have you heard of any of these people here?

So fluffy bunny has any hurt anyone heard of fluffy buddy this like super old. This is more than 20 years old now operation Aurora. Has anyone heard of that one?

So that was a Chinese cyber attacks. Did you know tarv for me? One of the biggest moments in in security history at least for me was 2011.

So I guess a couple people have heard of that petia not petia. That was even more relevant these days because this is Russians attacking Ukraine in 2017. So it becomes actually even more relevant to have another look at this attack and then the solar winds which I'm sure everyone here has heard of so I'm gonna be walking through all these incidents and what we can learn and how they can help us think about building secure access systems.

Okay, so as the CEO of Bastion zero, I like talking about Bastion hosts a Bastion host is basically like a box that sits there in your infrastructure and it is used to give your engineers access to systems. So first you log into the Bastion host and then you log from the Bastion host into your targets. So as you can see in this picture, we have Alice over here.

She's logging into the Bastion host. She has an SSH key, and then once she gets into the Bastion hose, she would have additional SSH keys that allow her to log into additional targets that are behind the Bastion. So the reason that you do this that you build this kind of Architecture is to avoid having a lot of different entry points into these targets, right so that you can control access you can know that it's coming from one place.

And that you can you know, make sure that this is a hardened host that it's not a tackable or that it doesn't have a lot of problems in terms of like unpatched operating system and things like that, right? So this is the fluffy bunny incident that I'm sure no one no one here really has heard of this was told to me by Andy Ellis who's the ciso of Akamai for whom this actually happened to while he was the Seesaw of Akamai. He's for the former seesaw of Akamai up until about a year and a half ago.

And so what happened was there was this adversary And what they did was they took the SSH client, which is just the software that speaks SSH and replaced it with malware. And the malware what it did was it would steal SSH passwords? So you would log in you'd enter your SSH password for a particular service server the adversary would steal the password and run away and now they have passwords for Access into lots of different things.

And so what happened was they compromise one user's machine replace their SSH client with malware stole their SSH passwords for the Bastion host and now they could log into the Bastion host. Once they were in the Bastion host. They did a privilege escalation to own the SSH client on that Bastion host as well.

Now all the users that were logging into this fashion host. Right? They were SSH into the targets that were behind the Bastion host.

And those were then compromised too. So think about all the keys that are associated with all the targets that you can see over here all of those were then stolen and now the adversary could basically steal credentials into those targets and move through the network. So this is what happened with fluffy bunny in 2001 very early days.

So so what did what did we learn from this incident? This is one of the early incidents that taught us that standing credentials are bad. Right?

So if you have a credential like an SSH password, that doesn't change. And you know 20 to 2001. We didn't have things like multi-factor authentication.

Right? So if you have a password that doesn't change and just sits there. This is very dangerous because in adversary can steal it and use it to log into your systems at any point in the future.

Another thing is if you look at this architecture of the Bastion host Bastion host is something that makes a lot of security people nervous because it's a single point of compromise. If you are storing credentials for other machines on the Bastion host and you then compromise the Bastion host. You've just compromised something very valuable for your infrastructure, right?

So building secure Bastion host and making sure those don't get hacked is a really big deal. Right? So this is this is sort of the lesson that we learned from from fluffy bunny.

And this is what started people thinking about eliminating these long-term credentials the long-lived credentials. Okay. So that's 2001.

All right. So vpns what's a VPN everyone knows but we'll review a VPN is a system that basically allow you log into the VPN and that VPN puts you into an IP address range and then being in that IP address arrange it allows you to access a bunch of things that are within that same IP address range. So look kind of looks a lot like the picture looks very much like a Bastion host.

But instead of logging into a physical server. You're just logging into a bunch of basically you're being pushed into a group of network addresses from which you can access other things that are behind the VPN. All right, so that's a VPN.

So Operation Aurora, this was in 2009 compromised a number of entities one of which was Akamai another one of which was Google and if I Channel and ndls who told me this story, this is a talk that we worked on together. What happened was that they actually had the adversary had had compromised and entered their systems and was sitting there for a while and they didn't even know that there was an adversary in here and they had basically gotten in behind the VPN. And because at that time again, this is really long ago 2009 at that time.

There wasn't a lot of very good segmentation of the network. So once they were in behind the VPN, they were able to move laterally and compromise more and more systems because a lot of these systems were basically just relying on the fact that someone was within the VPN and using that as what they used to decide whether someone should access the system or not, right? So there weren't a lot of protections for systems, you know on same network behind the same VPN and so they did see a lot of lateral movement before they eventually figured out that this was happening this Again, this gives us that you know, another additional lesson that something that's become very popular, you know even just this year in this industry, which is the idea of like segmenting your architecture and that vpns are not enough.

So don't based trust just on what network address people are using you need to segment your architecture and have a better system of authenticating users or access even for people or things or machines that are on the same group of network addresses, right? So VPN protection is not enough. I don't know how many people saw for the large number of people in this room.

Like did anyone see the federal government zero trust memo that came out at the beginning of this year. So at the beginning of this year, there was a memo that the White House put out. It was January 26th.

Where they said that the federal government can no longer rely on perimeter-based protections. So using vpns as the protection for networks and systems was no longer acceptable. That's the majority of you know, federal government systems are using this type of mechanism.

What was hacked in operation Aurora in 2009 still using it today. So there's starting to be a move across the industry to get away from these architectures, but it's very interesting because this attack happened in 2009 to Google and Akamai and if you listen to Andy, right he will tell you that this is actually the two of the organizations that were most behind the zero trust movement. We're actually compromise and operation Aurora and they started this idea of like segmenting networks and not using vpns as your main form of access started around this time after this attack.

Okay, right. So we do not want to only trust Network location as the basis of who gets access to what we want to move away from that. so Alternatively, right you can start to move into a more zero trust type of architecture and what I'm showing you here is an example of the kind of architectures that are currently being touted as Cutting Edge in our industry in the industry of interest in infrastructure access.

So what is currently considered Cutting Edge in this industry is to have a certificate Authority that issues short-lived certificates to users to facilitate their access to Target. So what is a certificate Authority it is something that has that is trusted and it has a key. Public-private key pair that key is used to sign certificates, right?

So here we have sorry. Spoiler. So here we have a certificate Authority that has this yellow key.

And what is it doing? It issues this thing called a certificate which contains a few important things. It has the key of Alice.

Right, that's her cryptographic credential that is going to be used for access to stuff. So here it's in blue. It's got her name and it's got the name of the certificate Authority.

And then all of that is signed by the yellow key. Okay. So basically what's that saying?

It's saying that Alice's credential this blue thing is trusted and trustable because the certificate Authority is signed off on it. Right. So at the end of the day what's happening is that all of these servers?

All of these targets are relying on the certificate authorities key to determine who should get access to what Target? Okay, so if the certificate Authority signs off on it, then access is good. If the certificate Authority does not sign off on it then access is not good.

And so this notion of zero trust really what it means is we're not going to give the users long-lived credentials, right? They don't have a long-lived credential every time they want to get access to something they prove their identity to the certificate Authority and then they get this short-lived certificate that would last for a few hours or a few days or whatever it ends up being. Okay.

So the idea is that now there's no longer like these passwords the SSH passwords that are sitting around or just trusting the VPN for making decisions. Now, what you're going to do is every time you want to access something this CA is going to make the decision of like whether you should have access to something for how long right and then it issues this short-lived certificate to you that's being used for Access. So that is basically what most zero Trust Systems do right now that is Zero trust looks like yeah, go ahead.

Exactly. Should we blindly trust the certificate Authority? So in fact majority of zero trust products today do require you to blindly trust the certificate Authority by the way, my company does not do this.

This is our big, you know unique selling point. But yes majority of these products when they're called zero trust. They require you to put zero trust in the user but a hundred percent trust in the authentication system and the certificate Authority.

That's that's what you see. When you see in most of these your interest systems. They're based on this type of architecture.

Um this type of architecture failed in 2011 in in what to me is a watershed moment, at least for me in my career. This happened when my second year of as a professor at bu what happened that year was this certificate Authority in the Netherlands, which was used for issuing certificates for like Dutch assets like the Dutch RMV the registry of motor vehicles the Dutch government, whatever it was they were hacked and the thing is the problem with this certificate Authority is that the public key for the certificate Authority this yellow key is was trusted by browsers all over the world, right because I should be able to use a computer in the US to check, you know to connect securely connect to the Dutch RMV, right? There's no restriction that I can only like connect to the Dutch RMV in in Holland I can call I can connect to them from here too.

So it was trusted by browsers across the world and then in fact the Dutch did you know to our certificate Authority was trusted to issue certificates for any website in anywhere in the world? Because there's no restriction in TLS right for TLS is just what you use in your web browser to connect securely to websites. There's no restriction in TLS certificate Authority world of which which websites a particular certificate authorities supposed to issue issue certificates for so what happened did you know Tara got hacked and the adversary started issuing a certificates for Google actually fraudulent certificates for Google that allowed it to forge.

Google's public key this fraudulent certificate allowed it to then decrypt all the traffic that was going to Google and they actually used it for targeted attacks on Iranian internet users. So this happened in 2011? Huge shock.

Basically, we discovered that the whole security of TLS was built on this very very shoddy shoddy system that could be compromised. and it was and so as a result, you know, we learned that single root of trust is very dangerous right this idea of a single point of compromise where if you pop a CA in the security of the entire ecosystem collapses, this is not good and so over broad scope for a single Authority is very dangerous. Right and I would like to say that a lot of the products in the industry right now that are called zero trust are based on this very over broad scope certificate Authority or some other sort of authority, which is usually a single sign on like an SSO something like an OCTA or something like this.

Okay. So, okay. So let's do quickly this this knot pecha incident so Ad is another very yeah, go ahead.

Yeah, so there a lot of different products are called zero trust in this type of context for access to infrastructure. It's usually a system that gives users access to specific targets machines databases kubernetes clusters, whatever it is, right? That's what's typically it's for and it consists of an authentication system that issues short-lived tokens to users to access the targets the way that it usually works is that the targets that the user is trying to access all trust the issue of those tokens.

And so if the issuer of those tokens gets compromised then all those machines can be compromised. So that that is what it generally looks like and and in a lot of products if you look at them what that issuer of tokens is is a certificate Authority. It's it's actually a certificate Authority.

There are other systems where there's like slightly other ways of doing it. Like it's a proxy that has the ability to decrypt a bunch of keys that it's storing but in each case, it's like this very centralized authentication system that first does the authentication it also does authorization to like say like, okay. Does Alice have access to this machine, you know in this in this way if yes, you know, give her the token but at the end of the day that that is the central it's a point of compromise that Authority has is controlling access to everything.

So if you go after that Authority, then you compromise the entire system what I'm going to do actually because I don't know how much time I have is actually go to the solar winds incident which was an example of this failing dramatically. So another way to build these zero trust system is instead of having a certificate Authority. You have an SSO.

So an example of an SSO is your G Suite login your Microsoft. Login Azure ad whatever it is. And so instead of having a certificate Authority, what you do is you do your single sign-on and then when you finish your single sign-on you get this SSO token, which basically for our purposes in this conversation looks exactly like a certificate, right?

It has your name your your information and it's signed by this SSO provider. And then again, the targets will validate this token against the SSO provider and allow you to have access right? So same idea of the SSO provider gets compromised then all of these targets are at risk of being compromised.

So if you look at what happened with solarwinds, that's exactly what happened. So solarwinds had many components. You probably heard about the fart where the solar winds solarwinds is a software that you install on your machine that allows you to manage your machine.

That that agent was compromised. So once that agent was compromised the adversary was able to you know, own the machines for which that agent was compromised on and then what they ended up actually doing was they had actual human beings who were then logging into those machines and attacking from those machines because they had like owned machines inside their victims networks from there. They went and actually hands on keyboard attacked manual attacks from those machines.

The manual attacks that they were launches were against the their IDP their their identity provider of their victim that Network that's what they hacked what they did was they stole the key the signing key of the identity provider and used it to issue fraudulent tokens to themselves. So now they could authenticate to any place in the network because they had owned the identity provider that was controlling the entire network. That's what happened in solarwinds.

And from there. They could only entire network. So there was a lot of focus on the attack of the specific like user machines like my laptop got compromised, right?

Once my laptop got compromised. The attacker was using my laptop to attack the identity provider. And then once they attack the identity provider they could log into anything they wanted from there.

And so that was the disaster of solar Wings because now they had tokens to access anything. They wanted anywhere in the network and then they could go after they're really high value assets. So that's why you don't want your SSO to get compromised.

Again, very similar the very similar lesson learned from what we learned in TLs, but this time we're learning it not in TLs, but in sort of corporate infrastructure access management and access management in general. This was not restricted to infrastructure. This was the entire corporate Network that they compromise this way.

So again single root of trust is dangerous over abroad scope of an authorities dangerous. And then of course the other issue of like keeping track of your agents. There was a very important lesson learned here, which is that if you have agents installed in their auto updating it can be quite dangerous when you don't see how they updates are being run and what's coming in the updates because this was a case where the auto update was auto updating with malware and now malware was installed on all these laptops that were managed by solarwinds.

um Right. So this is now the fun part. Yeah, go ahead.

No, I mean it's a deadly attack right it's a deadly attack because there was no real way for anyone to be able to tell that this that this was coming in. So this was a truly a deadly attack. Yeah when you Haven't installed on all your machines that are controlled by a third party then then if you're if you're if you're if you're allowing auto updates there, then then that can be deadly and I have to say that like, you know for us when we we actually have software and we for our software we don't auto update on our customers machines like our our customers have to update themselves because we don't want to risk this kind of like architecture where you know, there's an auto update and and the customer doesn't know it's coming but you're right.

I mean this this is the kind of this is one of those cases where If you've got an agent or a software installed across everything then you are at big risk that that agent becomes a malware right like that can happen almost for any agent. It could become a malware. So that is a really scary thing.

And that's one of the reasons why things like segmenting your network are super important. right like yeah, like I mean this one this case by the way is so interesting this this not Patia case. Do you know what happened here?

This was an it's even it's even more pointed today. This was a tax software in Ukraine. And a lot of companies do business in Ukraine.

And so if you do business in Ukraine, you need tax software. It's like the Ukrainian TurboTax. So what happened was there was an auto update to the Ukrainian Turbo Tax on one computer.

There's an article about this in wired. You can read it. It was by Maersk immerse cat an auto update of one computer that ran this Ukrainian tax software what that computer had was then the auto update was a malware and the malware was on that computer and it actually picked up the adminton credential for the admin credential that was used.

Now. It turned out that marisk was using the same admin credential on all of its managed laptops across all the laptops. It's insane.

And so from there it spread like crazy through through all these computers because it had the admin credential and it was able to log in as admin across all the laptops and all the computers at marisk and if you read the stories from that period it was like within hours like people were like literally running down the hall like screaming on like pulling laptops out of the wall in order to stop them from getting disabled by this ransomware. And and this was actually one of probably one of the most scary attacks because it hit Ukraine and hit a lot of companies in Ukraine, but also hit all these companies that did business in Ukraine and plenty of companies do business in Ukraine. And and what was learned from this was segmentation of admin credentials, right?

Because for some reason at that time, they were still using the same admin credentials across all their computers, right? So in a sense like, you know that there could be software updates or software that could become malware at any given point you want to make sure your network is segmented so that you don't have the same software on all your machines and that if one of them gets popped, it doesn't pop everything across all your all your software, right? It gets restricted to a certain subset of the network.

so this is this is a this is sort of another another case of like making sure that that you are segmenting your network. Okay, so getting back to getting back to sort of the case of the SSO being compromised. How do we typically do multi-factor authentication does multi-factor authentication help us against any of the attacks.

We've been talking about so far today. So generally when you do a multi-factor authentication with Google or something like this or okta your multi-factor authentication goes directly back to the authentication provider, right? It goes back to OCTA.

Right? So if we think about the solar winds attack, if you had MFA in addition to your password login to your identity provider, you know you log in with your password. You also did a multi-factor authentication would that have stopped the solar winds attack?

Right? The answer is no, right. The answer is no because the MFA goes to the identity provider and if the identify providers key is stolen, it doesn't matter the adversary can still issue tokens to itself.

right and so MFA is a wonderful thing, but it is not a Panacea. It doesn't solve all your problems if you do it like this. what if you what if you do it like that?

What if the MFA that you're doing does not go to the identity provider, but it actually goes to the Target itself. Would that have stopped the solar winds attack? Yes or no?

No. Target's not compromised. Yeah, so, you know what?

It turns out that this actually does help if you set it up properly. And the reason why is because the the target I didn't really Define this clearly for you. So that's to be fair like to Define.

It clearly is if this authentication MFA was being done directly to the Target using some sort of totp or some sort of thing. Like you can have something called like a Linux Pam module that will do things like this. There are Duo modules that we can do like this that should zero does something similar to this the MFA is being done to a separate root of trust then the identity provider.

So the identity provider gets popped. The separate purple MFA is still is not necessarily going to be popped by the adversary. The adversary would also have to pop the MFA, right?

And so and so what this what this actually does is it this in this case? It does help in this case. It does help because the the adversary is able to issue this SSO token, which is fine, but it can't actually break the MFA unless it's also popped the MFA so under the assumption that it hasn't popped the MFA as well as he has a supervisor you have protection here.

Right? Does that make sense that yeah. Yeah, so effectively to build something like this.

It's quite a pain, right? So there's different ways of doing this you could buy yubikeys and you could kind of build a parallel you be key system for access to your Targets on top of your SSO system, which is a real pain, right or you can or you can build some sort of totp system that's separate from your MFA which is a real pain. But like when you see this in the field for the most part, it's like people have integrated SSO and then they've separately integrated like a ubq system or like some kind of Duo Pam module or they're using something like Bastion zero, which does this for you in a box see?

Yeah. It's almost like as if it's almost like, you know, let me show you a picture. It's almost like as if you have look at the picture at the bottom parallel, it's almost as if you have two completely separate authentication systems one is your SSO provider and the other one is a separate MFA provider.

And so the idea is that you're if you're SSO gets compromised, you know, and they also have to compromise your MFA provider as well in order to completely compromise your system, right? So what you want to have right when you're using MFA. Right is you want to have this sort of parallel architecture where MFA is a separate parallel root of trust for your system as opposed to having MFA being just another input to your SSO and everything else relies on your SSO.

And I would say that a lot of organizations will go with this architecture because they know they need MFA and they're not necessarily thinking about what it means and the way it's being put in place right versus doing something like this where the MFA and the SSO are separate so that if the SSO gets popped the MFA should still be secure right? Because for the most part for the most part the MFA is just a subsystem of the SSO, right? So if you're using OCTA you can you can turn on SSO with OCTA and you kind of feel like you're good you're done right but these type of attacks like what we saw did you know tar that type of attacks?

We saw with solar winds are still going to be possible if you're up to get compromised. And by the way, I choose OCTA very deliberately because they actually work compromised about a month ago, right? So I guess what I'm saying is like what to do with your SSO gets compromised is to think about an architecture that doesn't put a hundred percent of your trust in your SSO provider.

And so if you saw after the after after octo is compromised, for example, there was articles that came out and said well, you know cloud. uses OCTA so then cloudflare was Ox was compromised. And actually what happened was the CEO of cloudflare tweeted out.

We aren't compromised because we have the architecture at the bottom here and not the architecture at the top. So this is really something that's worth thinking about when you're thinking about architectures the build-out SSO not to put too much, you know too much Reliance on your SSO because that puts you at risk and that's actually what we've done at Bastion zero architecture really looks like that where what we have is we have our SSO provider that we integrate with to provide you access to your targets that is going to be the the short-lived credentials right because that's so does not provide you along with credential so we are moving in the zero trust Direction, but we also have a separate root of trust here, which is your which is the best and zero service which provides you with the MFA in additional root of trust so that if the SSO gets compromised your targets don't get compromised similarly if we get compromised in your SSO doesn't get compromised your target, so don't get compromised. So kind of popping this up a level to wrap this up because I'm over time, you know.

Starting from you know, the early 2000s. We've learned that long lived credentials or shared credentials are very dangerous right in the not petcha incident and that fluffy bunny incident segmenting. Your architecture is really important as we saw from fluffy bunny on Aurora and also from not petcha, right?

Where was this Ukrainian staff tests software on one computer at Merck compromised all of Merck and shut Merc down for about two weeks. Secure your supply chain. So being careful with where you have agents installed and how they're auto updating themselves.

And then finally like, you know in in moving to a zero trust architecture don't over rely on a single root of trust because then what you've done is you've created a very very desirable Target for adversaries to go after and we see they do go after those targets like they did with solarwinds. Okay, that's it. Thank you.

Well, yeah, it does unless you build it properly right? But that's it from the user's perspective. If what you're asking them to do is to do SSO and MFA.

They don't find that tedious. They do SSO at MFA for everything. Right?

Like if you look at this architecture, right? The user doesn't know which world they're in right? You're just telling the user doing so do and MFA.

It doesn't feel tedious for the user. Right what you've done as the architect is you've made sure that the MFA is independent of the SSO. The user doesn't have any idea that this is happening.

So it doesn't have to feel tedious for the user if you do it properly. Yeah, it may be more tedious for you as the architect but there are products. You know that we'll do this for you or you can put multiple products in a row.

You can do like an SSO plus you be key or you can do an SSO plus a Pam module or you can do like Bastion zero which puts it in one blob for you. Yeah. It's very similar to that concept except from the user's perspective.

It doesn't feel that way. From the target's perspective. It's like you have two keys one key from the SSO provider and one key from the MFA provider.

So from the target's perspective, it feels like there's two. There's two separate keys from the user's perspective. They're just they just feel like they're doing us so plus MFA they doesn't feel like they're doing anything weird.

Do they feel like they're signing in and then they have a UB key or they feel like they're signing in and then they have to put a code on their phone. Yes, multiple roots of trust. Yes.

I'm done. All right. Thank you everyone.

That was fun.