CISSP Domain 5.6: Stolen Sessions and Why MFA Never Saw Them (372)

Machine-generated from the episode audio, with names and acronyms corrected. Spoken wording is otherwise unedited, so expect the occasional rough sentence.

Welcome And CISSP Study Goal 0:00

Good morning, everybody. It's Shon Gerber with CISSP Cyber Training and hope you all are having a beautifully blessed day today. Today is Monday, and we are super excited to be here on Monday. It's very, very exciting. Got some awesome things we're going to be going over related to domain 5.6. And 5.6 talks about implementing authentication systems. That's the key factor. And we're going to get into the how CISSP typically works we have an article we go over, followed by training, and then some CISSP questions. And the goal is what? It's to get you to pass the CISSP exam the first time. Now, to kind of put a little context around that, we just finished up cohort one not too long ago, and we're in cohort two of the CISSP cyber training, and my cohort one stats are coming in.

I will tell you that I'm extremely excited about what I'm seeing is the fact that right now of the folks that have taken the exam, 100% have passed. Now, does that mean anything about me? No, it does not. It means these guys have studied really, really hard to get there. But the one thing I wanted to state is the fact that the cohort is giving people the structure and the skills they need to be able to pass the exam. So that's a good positive thing. Will everybody pass? I hope so. I truly do. But we all know that that doesn't always happen. So it's exciting, super exciting related to the cohort.

So if you're interested, go check it out at CISSPcybertraining. com.

Okta Findings On Stolen Sessions 1:47

Okay, so this article that we're going to get into is at Okta. So Okta put this on their blog post, and this is an interesting aspect. So we're talking about live session tokens and API keys. These are lifted from browsers of unsuspecting individuals. Now, the thing that was interesting about all of this is that this is an interesting part of they found lots of sessions that were alive. And then when Google did the analysis, they were still alive even after many, many days had gone by. And so we're going to kind of get into how does this work, what is actually going on, and what can be the factor related to it.

So there were 9,200 Google sessions that are sitting in a public file and they're still working. So what does that really mean? Well, the session file is just basically some way for you to log in, and they stole them off of people's browsers, and these are logged in access to different types of servers. So they're already logged in, they're already past the MFA. So that's an important part of things that you can't, you're not really protecting against. So every dollar that was spent hardening the log on was spent on a door that would basically never ever went through because of the fact that these sessions are in place.

So these sessions, these browser sessions, along with APIs, are gateways into your world, into your businesses, and they're important for you to understand why and what's the problem with them. Okay, so in early August, somebody posted about seven gigabytes of InfoStealer logs publicly. They were not sold, they were just posted out there. And so to understand what an infostealer is, it's basically malware that sits on a laptop and takes what is already there. So we would do this in the red team world. We would dump these different types of infostealers out there. They then would send data back to us, and then we could do something with it.

They're much better now than they were when I did it. It was they were very antiquated and they had tendencies to fail quickly. When Octus Threat Intelligence went through this a couple weeks ago, that they found the number of 9,800 Google tokens, and 9,200 of them were still working. Kind of we mentioned earlier. This is what makes it an important part of this. So this dump was weeks old by the time it was analyzed, and 94% of those sessions were still open. So that's that's huge. That's a big, big factor. So platforms that are issuing long-lived tokens are really doing a disservice to their customers.

Because what's happening is once they log in, once that session occurs, it should expire at a certain period of time. But it's not. And these folks are basically keeping this active connection open. So every hour of convenience is giving the bad guys and girls access to this data or to the environment. So it's important to understand, nobody stole a password. Nobody answered an MFA prompt. From the server side, this session was totally legitimate because it was the real original session. That's it, right? It just picked it off, they just picked it off somebody else's laptop. So let's talk about cost with this. So there was around a million dollars of unauthorized usage at one organization, 600,000 in AI credits at another.

So when it comes right down to it, because of this session was left open, it has cost these companies almost $2 million. Now, this is just of reported things. So you can see the importance of having timers on these sessions. They should not be left open. So this again, there's nothing to detect here in this situation. There was nothing that occurred that they could have found because the session was legitimate. It was fine. It was what they were expecting to see. Okay, so let's look at this from a manager's perspective.

Why Password Resets Do Not Help 5:26

And here's something you should consider as you're going into work. You know, if you're listening to this on Monday on your way into work, consider it. If you're listening to this sometime on Monday, think about it for Tuesday. But your mind might be thinking from a technical perspective, hey, let's go force a password reset. You know, it but the thing is, is it does nothing. The attacker never had a password and does not need it. And resetting it does not invalidate a session that they're already holding. It just ticks everybody off. It really does. So a password reset isn't going to be the problem. So authentication and session validation are two different security functions.

In the environment you assess, the first has the owner, the second usually does not, right? So we're dealing with session validations. They typically do not have an owner. So you need to ask who can revoke a session in your organization and how long does it take? If nobody answers, yeah, that tells you something right there. So that question is who owns the session and how long is that access good for? That's a domain five point. So let's go dig into that and just do this properly. So before we get started on the training, there's three things that I wanted to kind of quickly bring up.

Each of those can help you in your CISSP journey depending upon which one is right for you. My I've talked about the live cohort earlier, but if that's not something you want to do and dedicate a couple of months to do it, we can knock it out. You can take your time, work on it with your accelerator and the pro as well. So go check those out at CISSP Cyber Training. Those are there for you. They're gonna help you pass the CISSP exam the first time. Okay, so let's get into what we're gonna talk about today.

Domain 5.6 Auth Versus Validation 7:07

Okay, so this is domain 5.6. Implement authentication systems. We're gonna need tokens, assertions, and the check nobody runs, right? So a point of line with making this, and you can see in the bang box, a forged token is not a broken token. It is a correct token about an event that never happened. And yes, we see this a lot. And this is kind of the article that we got into. So there are six domains, and we're gonna be going over the last one. So we got 5.1 to 5.6 from control physical and logical access, identification, federated identity, manage authorization, and then manage identity and provisioning life cycles.

Finally, to implement authentication systems. So each of these do two jobs very differently. There's two different owners, two jobs, and you really need to think about this. We have authentication and we have token validation. So when you're dealing with authentication, it's basically are you are you who you say you are? That's a lot of R's in there, but are you who you say you are? This happens one time and it happens at sign in. This MFA is where that lives is in this space, the authentication aspect. And this is the part that most companies buy, and they buy the MFA piece of it, and then they feel like, okay, I'm good.

Now the token validation is very different. This happens on every request and at every application. There basically this part here has really typically no owner in many, many cases. So in the incident that we talked about earlier is falls within the token validation piece. And so without it, with doing this, without having some sort of owner and determining what how long these things can live, it can be a huge deal for a company, as we already heard in this the first part of this. So in an incident, the function one has never been attacked. It was bypassed. And those are not the same thing. Say again, when you have authentication and token validation, they're very different.

MFA hardens authentication, it does nothing for validation. So basically, you need to ask who owns the second one. Who is the owner of the second piece when you're dealing with token validation? So we're going to be getting into a signed statement about a past event. I checked this person. Here is who they are, here is what they reach, and this is good until this time, right? This is signed by the identity provider. This is someone who's coming in. This is your octus saying, Yep, I checked them. Here's who they are, here's how what they can touch, and this is for how long they can have access to.

That is the identity provider. So a SAML will call this assertions. OIDC calls this identity tokens. OAuth calls this an access token. It's the same idea, but there's three different vocabularies. The exam uses all three and expects you to notice they are the same object. Okay, so again, understand authentication. Yeah, SAML, it's an assertion. OIDC, it's identity token. OAuth, it's an access token. So all of those are the same. So it's a claim about an event, not the event. It's an about an event. Okay, so this is what one potentially looks like. So this is the as you look on the left hand side, it's gonna have a decoded payload.

On the right hand side, it talks about the different categories there. If you're listening to this going, I can't see it, well, go to CISSP Cyber Training, I'll have the video, we'll be there, you can check that out, but we'll walk through it so you'll get the gist the gist of it. So what one looks like is that you will have six different categories in this space, and these are all for the session. You have the issuer, which is is labeled ISS. This is who made the statement. You then have the subject, okay, and the subject is who it is about. The audience is who it is for, and then the expiration date is for how long is it good for, and the scope is what it can touch.

Okay, so this sits outside the block and it provides all the whole of it, right? This is everything there. Now, every part of this is correct, even on a forged token, and that's the point. It's the the everything is the same, it's all the same because it's wide. It wants you to have access to be able to go do it. So again, very, very important part of what a potential token will look like. So we don't talk about the thing that makes the credentials, the signing key. So it's the signing key itself is not a credential in of itself, it is what creates that, right?

So when you steal a password, you are the one user. One failed login is logged, one account gets reset. That is the person, that's the user. When you steal the signing key, you are anyone you want to be. Nothing logs as a failed login because there isn't one. It's all legitimate, it's all expected to be there. So again, that is an important part. This works to allow you in and out of it. Now, the key part of this is understanding the expiration dates. If they are set up to have persistent secession keys, then you know what? The door's open forever. So a key compromise is not an account compromise, it's much larger.

It's a different event than an actual account compromise. So let's look at it from a point of view of a door, somebody trying to get in through a door. So you have a legitimate user, okay? And this legitimate user will go ahead and they'll go to the security desk. Yep, they'll go and they'll check in. They usually scan their face. Like my daughter, when we saw her at Fort Gordon, they had a whole process by which she has to check in and check out. And then that MFA in this case would check you. It would check who you are. It sends you a PIN, or you go and you log into your app and you then enter it in that way.

It is then a badge is issued to you. Your badge is set up, you're you've got that access to it, and you go through, and the door reads the badge that you've been given, and you've got access, right? That's the part. It's amazing. And that's all the way it's supposed to work. That's the legitimate use of it. Okay, so now let's look at the forged one. You have the attacker, and the attacker bypasses the security desk. The attacker bypasses the MFA check because they're using the session, and guess what? They're automatically given a badge. So, what do they do? They have the badge because the session is still active.

The door reads the badge. Hey, bada boom, bada bing, you're in, baby. That's it. A forged token is not a broken token, it's the correct token about the event that has never ever happened. So again, the poor that's how you'd get through access to kind of put it all in perspection, perspective. The session token is letting you in if it hasn't expired. Okay, so what does the signature prove and what it does not? So it proves that this came from the holder of the key. So that's what it proves. That that signature says this person who had the key, that's where it came from. It hasn't been altered since, it's all good.

However, what it does not prove is that the holder is the person named. So is the person that's in going into it, is that the actual person? Did the authentication actually ever happen? And then who's being presenting this? Is that where it belongs? Is that the right person for it? So a stolen token passes every check because there's nothing wrong about it. That is why the lifetime ceiling exists at all. When you cannot detect the theft, you shorten the window instead, which makes the short token lifetimes a compensating move, not a preventative one. We talk about a compensating move. These are compensating controls that you're expecting to deal with.

And so this is why it's important for you to limit the lifetime of these tokens. Reduce them from being whatever amount, unlimited, to a period of hours, a period of days at the most. Days is pushing it even, but I would say you have it limited to a period of hours. Most tokens should be set up within an hour at the most, and then they are dumped. A lot of them will do 15 minutes, 20 minutes most. So again, you have to think about this as it relates to your organization and how you want to set it up within your company.

Audience Claims Lifetimes And Scope Checks 14:56

Okay, so let's figure out what this two-line fix nobody ever makes. The relying party must confirm scope, validity, source, integrity before granting access. Validity is the one everyone implements. Scope is the one that gets skipped because skipping it breaks nothing in testing. So if you skip the scope, and most folks do this, they get it, they have it enabled, it's active, boom, we're good. We're in business. So keep moving. A real badge that's correctly issued says building A. And then basically what ends up happening though is it's handed to a door in building B. That door reads it and sees that it's legitimate and it lets you in.

So what you need to ask your team this coming week, right, is name one application that accepts tokens from our IDP. Does it check the audience claim? Does it look at that? Who is the audience? And then show me the line of code that does it. If it does not, what stops a token being minted for anything else than being replayed in this different location? So again, you need to ask this question. Ask them more closely of your IDP. Is there any does it accept tokens from our IDP? Does any application do that? And if so, learn about that. What is the issuer? What is the scope?

What is the timing? What is the expiration dates on it? All of those are key things that you need to be aware of, especially if it's doing that. And if you start with one application, then start asking around and you figure that one out, you now can start digging deeper into other applications. Lifetime shrinks the window. Access tokens should be valid for no more than an hour. They shouldn't have any more than that. Anything more than an hour, you're really asking for trouble. I mentioned days before. That would be in testing, potentially you would allow that, but you have to go back and you have to think about how long these tokens should be valid for.

Expired tokens must be rejected outright by the authorization services. And then token validity should be configurable by the consumer and not fixed by the provider. And then lastly, tokens should never be put in logs. They shouldn't, especially if they're tied with any sort of personal data as well. All of that should not be kept into the log systems. Scoping shrinks the blast radius. It's an important part. We talked about this with compensating controls and how important all of these compensating controls are. But you need to really consider then if you're gonna put in, if you're gonna allow these access longer than, let's just say a couple hours, or maybe you go even a day, you need to ensure that the scoping is narrow so that your blast radius is limited.

So again, this should be the lowest reasonable level. This is a single tenant, a customer, a defined set of customers. A specific environment, development, testing, production. They should never be shared across them. They should all be individual. Now, you'll get into this in domain eight, but that happens a lot. People will share credentials, they'll share these things across multiple venues. Nothing else ever. A sign and key must not be used for any other purpose. It may give you access to stuff, but it shouldn't be used for anything else. Scoping is the only control in this entire setup that changes how far the compromise can go.

So again, we talk about this so much at CISSP Cyber Training. It's not a matter of if, it's a matter of when. If you have the ability for them to gain access to it and that something happens, you want to limit, you want to put a control in that limits their access through your environment. It's just an important part of any conversation that you're having, especially with your architecture people. Okay, so we're gonna talk about the storage and rotation of these keys and what the importance of those and something that you should be aware of. So when you're dealing with storage, when you're there's a moderate impact, these keys must be in hardware-backed or otherwise isolated storage.

You don't want to keep them just kind of sitting willy-nilly within a computer system. They have high impact, right? Because inside that, they will allow you to sign in in an isolated, executed environment. They work in that environment. Rotation will give you high impact. No more than 90 days of active use. You should basically have a rotation set up that if they're being used for that 90 days, let's just say hypothetically in this situation, they are rotated into a new one. So everything else should be under a year. But when you're dealing with keys, with these actual keys and how they, these sessions keys, it's important that you have them rotate often, right?

Document your crypto periods, automate the rotation. You want to have as much automation as you possibly can. So the span of time for a specific key is authorized for use. You need to understand how technically this works. You need to you may not be the person to go, I just don't understand this. I don't know how to actually do this. You can work with your technical people on how this works. I've mentioned this time and again at CISB Cyber Training. You have to be the person that understands the language. You may not totally understand all the technology that goes with it, but you must understand how the conversations are occurring.

And at the end of the minimum, know how to ask the right questions. Because you may not know this key piece, but don't be afraid to ask a question to someone. Because what you'll probably find out, which I've found out a lot, is especially when you go to meetings, ask lots of questions because most people in the room want to ask the question, they just don't know how to ask it, or they're just too afraid to ask it. So make sure that you ask the questions. So there's three dimensions, there's four good controls. So hardware-based hardware-backed key storage. Okay, this is kind of a likelihood place where people would keep these keys.

They are very hard to steal in the first place. They're hard to get them out of a hardware-backed key storage. A 90-day key rotation is a window. It's how long the key can be stolen and keep working. So, however you keep that 90 days. So that's or you went, maybe you go and do a 60-day key rotation. That's how long that stolen key could keep working. If you go a 30-day key rotation, that's how long that key could potentially keep working. Now the scope would keep it down narrow, but that's how long it could. So you have to decide how fast these keys get rotated.

One hour token lifetime. This is the token, the access token you have, how long a forged token will survive in the while. So if you have it indefinitely, like we saw with Google, it could happen for months. Or it could be shorter than that. You just have to decide, right? One hour's one hour would be a limited time. Narrow key scoping. This affects the blast radius. This is how far the compromise will reach in the event that they do get access to a key, they get access to a token. Um, those are all important parts. All four are recommended practice. They're not interchangeable, they're not something that you need to, you can go pull and play, remove and replace.

They are all important that you need to put in. So there's four things for you to carry in as you think about domain 5.6. Authentication and validation are two separate functions. Find out who owns the second, the validation piece. If not, you need to decide who owns it. A signature proves origin and integrity, nothing at all about its possession. And then in three, the audience claim is the check that gets skipped. Because skipping it breaks nothing. When your developers are out there working it, who is the audience? And they just usually skip it because if they don't have to worry about that, nothing breaks when they do it.

So just keep going. And then lifetime will shrink the window. Scoping shrinks the radius. Again, lifetime will shrink the window in which someone can do something. Scoping shrinks the radius in which they can gain access and they can cause all kinds of drama. Okay, they're not substitutes, they're not one or the other. They are both very

Key Storage Rotation And Blast Radius 22:29

important. Lifetime will shrink the window, scoping will shrink the radius. Okay, so let's roll into four CISSP questions that you all can see and we can kind of go through. Okay, question one. Reporting indicates that a signing key belonging to your cloud identity provider may have been compromised. Your IAM team propos uh proposes immediate forcing a password reset and MFA re-enrollment for all 12,000 users. Oh, yeah, that would be great. What should you establish first? Okay, let's roll out a password reset. A. Whether the provider has published indicators of compromise your SOC can hunt against. B. Whether your conditional access policies currently block sign-ins from unmanaged devices.

C. Whether your relying parties are still accepting tokens signed with different affected keys, or D, whether your password reset can be staged to avoid overwhelming the service desk. Okay, so there is a trap in here. What should you do first? Yeah, so A. Whether the providers published indicators have compromised your SOC and hunt. B whether the conditional access policies currently block sign-ins from unmanaged devices. C whether your relying parties can still are still accepting tokens signed with the affected key, or D, whether the password reset can be staged to avoid overwhelming the service desk. And the answer is C. Rely whether your relying parties are still accepting tokens with the affected key.

We talked about this. A password reset and an MFA re-enrollment both act on authentication. The exposure is a token validation, not authentication. Every user in the company can change their passwords and re-enroll in the MFA, and guess what? It'll still keep working. Because the force token never asks the user anything. So again, that's an important piece of this. Now the trap, staging a reset to protect the service desk. It's operationally sensible. It's what the real service desk lead would raise, and it makes you feel like you're running an incident. But it's not the correct one. So an important part that A, the SOC reflex, this is something that people think about.

Well, let's do it in the SOC, see if they can hunt it down. But that's not the problem, right? You need to understand the session and the dealing with the overall token. So that's an important piece of this. So let's roll into the next question. Okay, next question. Your architecture team keeps eight-hour access tokens for user experience reasons. Their argument is that every relying party verifies the token signature on every request, so stolen token would be detected. What is the flaw in that reasoning? A signature verification confirms who issued the token and that it is not altered. But a stolen token is unaltered and correctly signed.

B. Signature verification is too computationally expensive to perform on every request at that scale. C. Relying on parties typically cash the validation results so the signature is not actually checked every time. Or D, the signature does not cover the audience claim, so it cannot be relied upon for access decisions. So again, your architecture team says they want to keep an eight-hour access token for user experience reasons. Yes, it's always about user experience. Their argument is that every relying party verifies the token signature on every request. So a stolen token would be detected. And the answer is A. A signature verification confirms who issued the token and that it was not altered.

But a stolen token is unaltered and correctly signed. We talked about this a bit, that it again, you can have a token and it's correctly signed and it will work just fine, but you won't be able to detect it. And the trap is D. The signature does not cover the audience claim. So it sounds like it came from someone who read the spec, right? An audience. It's confidently technical and flatly false, right? The audience claim sits inside the signed payload, so the signature does cover it anyway. But if they say that, the signature does not cover the audience claim. Well, that makes sense, right? Because it's part of it.

So why are the others wrong? So D is it's confident, technical, but it's wrong. The audience claim is part of the signed payout. We kind of talked about that. C is the real defect, but it's not the flaw. Caching validation results does happen and it is a genuine weakness. But the question asks, what is wrong with the team's reasoning? Again, key point. They're reasoning, not what else might be wrong with the implementation. And then basically, the B is simply the wrong facts. You have signature verification, is computationally cheap, and therefore is performed at enormous scale routinely because really, really hard. Can't do that. There's nothing in this question that suggests that whatsoever.

So the next question: an access token your identity provider issued for your HR platform is replayed successfully against your finance API. Hmm. Both of those are fun. Both applications trust the same identity provider. The signature is valid, the token is not expired, and the username in the its real employee has its real employee with legitimate HR access. Okay, so again, access token with your identity providers issued to your HR platform, and it's replayed successfully against your finance API. So that same token is used against your finance API. Both say, yay, it works because it's trusted. So what failed? A, the identity provider overscoped the token when it was issued.

B, authorization failed because the employee held excessive privilege in the finance system. C, the token should have been cryptographically bound to the device that required it. Or D, the finance API did not validate the audience claim before granting access. Hmm. Which one could it be? Again, hard to say. Uh yeah, it's D. The finance API did not validate the audience claim before granting access. Now, the easy one that you might have clipped on, again, it's on A, because people read through these really quick, and A, as I read through it, I'm going, oh yeah, A was perfect. Let's do A. First time I went through this, I was like, Yeah, that'd be a great one to go after.

And so it was, right? Because you'd go, A, click, go. Okay, well, it would have been wrong. So you're spotting the trap, right? A is the provider overscope the token. This is the strongest distractor here. Because it overscoped tokens are a real and well-documented problem. This is where you run into, right? But this the question itself says the token was issued for the HR platform. So the scope was correct. The failure is entirely on the consuming side of this house. Okay, so again, really important piece to kind of keep in mind is that that first one seemed correct, but it wasn't. So take your time, read through all the questions.

All of them. Okay, next question. After the incident, your board asks a single question. Which change would most reduce the blast radius if one of our signing keys is compromised again? A are all four options are practices the guidance recommends. Alright, next question. After an incident, your board asks a single question. Which change would most reduce the blast radius if one of our signing keys is compromised again? Okay, so you come back to them with what? A storage signing keys hardware backed or otherwise isolated key storage. B scope each signing key to the narrowest reasonable boundary, the single tenant, a single environment, and use nothing else.

B or C rotate signing keys for high impact systems at at least every 90 days, or D reduce the token's lifetime for new more no more than one hour. Again. So the question again, break down the question which change would most reduce the blast radius if one of our signing keys is compromised again. Okay, and the answer is B. Scope each signing key to the nearest reasonable boundary. Again, scoping, important part, single tenant, single environment, and it's used for nothing else. That your scoping is what's going to save you. The trap is that 90 D day key rotation. It's most memorable number in the guidance, right?

So it's hey, 90 days. This feels like containment. I feel like I'm doing it. But that's the trap. It's not the correct one. It's you're looking again at scoping. That will limit your overall blast radius. Okay,

CISSP Practice Questions Explained 30:32

so we bring this up. It was never about the tokens. Which security function failed? Again, authentication and token validations are different jobs with different owners. What does a control prove? Ask the passing check that was never designed to detect. A signature proves the origin and integrity, never possession. And then receiver or source, a valid credential presented in the wrong place is a valid failure at the receiver, not the issuance of the failure at their source. And four, understand the risk dimensions and all the aspects related to it. So when you're thinking like a manager, thinking like someone like this, and it's reasonable people will understand and pass with less content memorization than people who don't.

Again, that's an important piece of this. If you're looking at this and you're going, what should I do? Remember that as you're thinking like, what would a manager do from a risk standpoint? How do I answer these questions? If it seems too technical, it's probably the wrong answer. If it seems more like what a manager would do, odds are high that is the correct answer. So again, think about all those aspects.

Final Takeaways And Study Options 31:36

Okay, that's it. One last thing. There's three different options you can study for at the CISSP Cyber Training. Go check them out. I got my accelerator, my pro, and my sprint cohort. Like I mentioned before, the sprint cohort is going great. I'm in my second cohort and it's moving along well. The last group, they've done awesome and they have just exploded, and they're actually all passing the CISSP. I'm extremely happy about that. The ones that have taken it have all passed it. So I'm super excited about how this is all playing out. Cohort 3 is open. You can gain access to it right now if you want.

So again, go check it out, cohort three, CISSP Cyber Training. com. All right, thank you all for everything and have a great day. And we'll catch you on the flip side. See ya. Thanks so much for joining me today on my podcast. If you like what you heard, please leave a review on iTunes. I would greatly appreciate your feedback. Also, check out my videos that are on YouTube and just head to my channel at CISSP Cyber Training, and you will find a plethora or a conocopia of content to help you pass the CISSP exam the first time. Lastly, head to CISSP Cyber Training and sign up for 360 free CISSP questions to help you in your CISSP journey.

Thanks again for listening.