This video is number five of the Zero Trust Authentication Master Class series.  

Transcription

So, previously we were talking about weaknesses of username passwords, and we introduced a common mitigation that people do for data at rest on passwords in the database, which is salting. And we kind of talked about how offline attacks take advantage of that still, and still, from a data-at-rest surface area perspective, that password is leaving a residue in a lot of different places. 

And then we kind of briefly tease the idea of introducing second factors or multi-factors as a way of trying to deal with the weakness of the password. So, now, we're going to really kind of dive in and talk about what we mean. So, everyone has heard MFA, right, multi-factor authentication. And you can think of MFA as really having three dimensions, right? And there's lots of authentication techniques in each dimension, but fundamentally, there's three dimensions. 

So, the first dimension that everyone kind of knows and loves is... we'll call it the knowledge dimension, right? Something you know. Clearly, a password is something you know. Unfortunately, it's something other people know too. You probably run into other knowledge-based authentication schemes. There are these schemes called...what is it? 

KBA, Knowledge-Based Authentication, where they're asking you, you know, what's the name of your dog from school and the first street that you lived on. And honestly, the questions seem to be either things that everyone knows or a question that you don't know the answer to, but other people who have access to records and whatnot can actually find easier. 

In my mind, I usually think those are kind of worthless and I don't really worry about them too much. So, password's really the main example of knowledge-based authentication, but I guess, you know, where you lived, etc. Okay. 

Next, let's talk about possession. Here's where you learn that I can't spell, and I'm not sure if it's a bad spelling of a French fish or if I actually mean the word possession, but I gotta keep you guessing. Okay. So, what do we mean by possession? We mean physically possessing a thing that I know is unique, physically having a unique thing, right? Some of you used to log in with RSA tokens, right? 

A physical thing that you have. That token, just like the TOTP example I talked about earlier, it's bound, in a way, where it produces a unique sequence of digits. And by representing those digits, it proves that, in fact, you possess that token, right? Other forms of possession, maybe those tokens can actually be hardware tokens that are embedded in computing devices. 

So, by possessing that computing device, you can prove possession of that computing device and kind of solve one of those things. And then finally, inherence, which almost sounds like a made-up word, and maybe it is because I don't know if it's spelled that way, but you typically hear of inherence as something that you are. 

And biometrics are, like, the easiest example to give on inherence, right? I am Jason because I have this fingerprint and this fingerprint is Jason, or my face, or my iris, or my DNA, right, some sort of biometric. So, when we talk about MFA, we're always talking about some combination of data points from these three dimensions. 

And because I'm physically oriented, I like to just kind of remind myself, right? So, I've got knowledge, I've got possession, and then I've got inherence. And so, when I'm thinking about different authentication schemes, again, it's just how many data points do I want from these various areas? So, now let's talk about things that you may have heard about, right? This may sound a little too abstract and more out of a NIST document, but I guarantee you, you have heard about one-time codes, right? 

One-time codes. I guarantee you have heard about things like magic links, right? These emails that you get or SMSs that you get with a link that when you click the link, it kind of logs you in. I guarantee you have probably heard of things like push notification where essentially, you know, your mobile phone chirps, and when you open the app that chirped and you actually hit approve or deny, then that serves essentially as a way of letting you through, right? 

And then finally, TOTP, right, which is really just a timed one-time code or password. Anyway. So, most of these techniques that you've heard of are a form of possession proof, right? So, when you see one-time codes, one-time codes are typically delivered over SMS or email, right? 

So, you'll go to log to a service, you'll successfully pass the password prompt, and then you'll get a text message on your phone, right? The SMS prompt, or you'll get an email where there's a code in the email. And by taking that code and entering that code into that code prompt, you then move forward. So, what is the proof that's being established? 

Essentially, in a roundabout way, they're trying to prove that you control an E. 164 number, which is really a phone number, right? They're trying to prove that you control this because only the person in control of that will receive the code and then can log in to the service or complete the prompt. Same thing with email. 

What they're trying to prove is they're trying to prove, well, at least you're demonstrating proof that you can access the email that I'm going to send this code to. Because if you couldn't, then in theory, you couldn't fall in. Now, we'll clearly come back and knock these assumptions down. Magic link is, again, can also be delivered over SMS or email. Magic link typically falls in the category. 

It's not really a code being delivered that you physically have to type in. It's actually a link. So, if you click the link, the link usually has a code embedded as a parameter, and it will successfully kind of take you through the prompt. Push note, so what is it doing? Again, it's proving really the same thing, that you possess control of a E. 164 phone number, or that you... 

Oops, I didn't mean to do that. I meant to do this. That you prove that you have possession or access to an email, right? And it's not exactly possession, because it's not physically a thing. Because E. 164 number is not physically a thing. They're making a leap basically saying yes, but if you don't have a phone bound to it, you're not really accessing it. 

And well, is that true? And that's technically SMS messaging, but what about Apple messaging? And so, it gets a little messy, but that's roughly how it works. All right. Push notification. You have an application bound usually on a mobile device, and so it's basically proving possession of a mobile device of some sort. And then TOTP, this is not being delivered through some alternate channel that you then have to prove you have possession of. 

It's typically through possession of a token, right? So, again, this token gets paired. So, every token is going to produce this signal, right? And the signal is random enough to where no two tokens have the same pattern, right? And you can divide this pattern up into time chunks in a regular way. And it turns out that the signal is actually comes from a function that's well-known and essentially a random seed. 

So as long as someone knows the random seed and the current time, they can basically compute what the signal ought to be. So, when you're given this token, this token was initialized against someone executing this algorithm on a database as well, and they're comparing it. So, it's actually a stronger possession proof than these. But fundamentally, they're all in, at least, the category of possession. 

So, now, let's go through and kind of ask the question, how secure are all of these things? So, first let's start with these proof of possessions that are proving control of a channel, right? So, one-time codes and magic links, honestly, there isn't much of a difference between the two in my mind because they're both boiled down to, do you possess control of the number tied to this device from an SMS or do you possess email? 

Well, the weakness there is pretty obvious, right? So, number one, SMS is not a network that guarantees privacy, right? So, when I think about data at rest, data in transit, so when I'm transmitting things that are secret, i.e., magic links and one-time codes over SMS networks, it turns out every operator of the network actually has an ability to look at what's going on there, right? 

There's no privacy guarantees in SMS. Number two, there's no uniqueness guarantees of SMS. Any of you that have an Apple device with Apple messaging and an iPhone will know what I'm talking about, right? You're going to get messages in both spots, right? So there's no uniqueness there. So, the whole idea of it's just one thing kind of goes out the window. 

Email, interesting thing about email. How many of you think email provides any sort of privacy, right? There's generally privacy between your client browser and the email service provider or the client. But email generally is not a privacy-protected service. So, again, the administrators and operators of the email services have access. 

Now granted, I'm sure controls and mitigations have been put in place, but there's nothing about the protocol, right, SMTP, that guarantees privacy of payload between end recipients without users doing things that users typically don't do. So, what's my point? My point is these are insecure channels to begin with. So, from a data-in-transit perspective, I'm not protecting any of that data. 

Number two, there's no real uniqueness guarantees on either of these sites, right? I can receive...one SMS message can equal receipts in multiple locations, same thing on email, right? So it kind of weakens the whole possession proof. Now, that's one angle to look at. Another thing too is what about email ATO, right? What about access tokens? 

So, for instance, if I walk away from my laptop and my laptop's open and I've recently logged into email, there's an access token, as we talked about earlier, that has some time to live that's probably longer than an hour, right? It's probably a couple of days. So, anyone could walk up to that device and use the service that access token is providing. Okay. 

So, there's a lot of different things we could talk about here. Obviously, there's SIM jacking, SIM swapping, where I convince the phone company I own your number, not you. And the minute I get that switched over, then I can do account resets, which then use SMS. And so then I can just receive that directly. So, the real point of the story in these top two links is weak forms of possession, very insecure, no guarantee of privacy, arguable whether it's really providing much benefit over just... 

I mean, it is providing a benefit over username, password, but how much benefit is very arguable. All right. Push notifications. So, push notifications are a little bit more like TOTP than the other two, right? Because in a push notification, there's some sort of seed with a particular device and its application, right? 

Unfortunately, humans being what they are, one of the most common attacks, although we'll show a different one here in a minute, with push notifications is this thing called push fatigue, right? So what is push fatigue? It's exactly what it sounds like. It's kind of like alert fatigue. If an adversary has access to username, password, they start logging in, you get the push notifications, you say decline, and you go back and watch your Netflix show. 

You get it again, decline. Go back and watch your Netflix show. You get it again, why is this happening? Accept, I want it to stop happening. So, blindly accepting a push accept turns out to be a common human behavior to make the annoyance go away so much so where many organizations are moving away from push-based authentication for that particular problem. 

Okay. And then finally, TOTP. TOTP is actually not a bad mechanism because, of these, it's the only one that requires you to physically possess the device that was actually bound and is not susceptible to things like push attack that we described before. 

But all of these are susceptible to man-in-the-middle phishing, and that's what we're going to demonstrate now. So, we're going to start with our usual example, Alice. But then we're going to introduce someone who is an adversary, a little bit evil. Let's give them a goatee from the evil universe. 

And we will call...What's a name? What's an e-name? Oh no, I'm blanking. We're going to do Bob because Bob's after Alice. And Bob's going to be evil. Bob's going to be our adversary. Typically, they use Eve as the evesdropper, but we're not really eavesdropping here. 

We're kind of being much, much more active. And then, we'll have our example of the bank, and I'll simplify it again, right? So, in this scenario, Bob is going to send a phish to Alice, and this phish could be in the form of an email or a text message. 

Doesn't really matter. But in both cases, there's a link in the phish, and some sort of call to action, which is the call to action is scary in some way. So, Alice gets this phish, and it purportedly is coming from her bank, and it's trying to say something like, "Oh my God, we're detecting fraudulent activity on your bank. 

I need you to log in immediately and change your password," which is ironic. But the phish doesn't actually point to the bank. The phish points to some sort of infrastructure under Bob's control, right? So Alice goes to that infrastructure, and Bob can really just kind of do a substitution and replacement, where then Bob goes to the bank and says, "Hey, give me access." 

And the bank comes back with 200 OK, and the login page, right, username, password. And we basically just present that right back to Alice. And then Alice inputs our username and password and, of course, we get it, right? And again, we just do a substitute and replace and patch that into our own session over to the bank. 

They do their verification step. And lo and behold, let's say we're using the strongest form here, TOTP, they see Alice has a seed, so they then issue back the 200 OK with the TOTP challenge. And again, we just patch that back to Alice. 

And Alice, of course, puts in her TOTP because, again, Alice is trying to fix a problem. She's trying to log in to reset her password because some fraudulent activity is happening on her account. So, again, we put that data in, and again, we just patch that over on our connection. That gets verified and I'm in. 

So, at this point, I now get access to Alice's bank. Now, what I do at this point with Alice doesn't really matter, right? I can patch it through and let her actually come through and change the password. And knowing that I'll have the new password, I could give her an error message, right, and tell her to try again. 

And then she could go... And the error message could point to the real bank, that way we step out of the conversation, right? There's all sorts of possibilities that can happen here. But couple of things of interest. We learned Alice's username and password at this stage. We learned Alice's TOTP at this stage. And at this stage, we got Alice's access token. 

And remember, once you're logged in and have created a session with any service, the service doesn't... You know, when you start navigating around the service, it doesn't keep asking you for your username and password, it asks you for your access token. And it turns out it's not asking you, it's asking your browser and your browsers conveniently stash that in a cool location. 

So, a lot of people don't even implement access tokens with a lot of control. So, this access token might be viable for a year, or a month, or a full day, or in the world where Bob's not really Bob but a robot. It might only be valid for 30 minutes or 60 minutes, but that's an eternity because I can then use that access token and drop it into a session really from anywhere and start accessing and impersonating Alice. 

So, what I just described, it actually works in all of these techniques. We just demonstrated it on TOTP because TOTP is the strongest form of possession of everything that's actually up here. Now, clearly, I'm talking about the vulnerabilities of the protocol. There's a lot of mitigation techniques where I can... 

Clearly, Alice went to an invalid site. Well, Bob set up a proper domain and actually got a legitimate certificate to sign over that site. And if Bob hasn't been using that a lot, he's not going to show up in much threat intel. And so, his likelihood of throwing any sort of suspicion detectors on Alice is actually pretty low. Also, if Bob is operating from a legitimate computer in what we call an eyeball network, like a proper subscriber part of the internet, or maliciously through a botnet on the proper part of the internet, unless that computer has history of being invalid or being suspicious, it's going to be hard to do. 

And so, we actually have a demo on our site where we actually do this for real with push notification on a pretty popular SSO and a pretty popular push notification service. And evilginx2 is a GitHub repo which is really just a kit for doing this exact thing, and it works out of the box for a lot of services and requires this much modification for others. 

And so, what's the point of this, right? The point isn't to shame vendors, right? It's not that the vendors implemented the protocol incorrectly. The point is the protocol is itself as a class cannot solve the problem. What is the problem? Well, the problem actually is Alice needs to know she's talking to the bank. 

The bank needs to know that it's talking to Alice. That level of verification or proof has to happen at both the application layer and at the transport layer. And based on how most authentication protocols are defined, that's just not a problem that they solve. And so that's why we call it a class of vulnerability as opposed to an instance of vulnerability. 

And we'll get into more specifics about that a little bit later. But again, the whole point of this is just to show that most forms of possession and MFA are actually trivially weak. And then if they're not trivially weak, they're marginally weak and don't stand up to phishing, man-in-the-middle attacks.