Informal security chat with Beyond Identity's CTO Jasson Casey, Founding Engineer Nelson Melo, and VP of Global Sales Engineering Husnain Bajwa and our host Marketing Empress Reece Guida about how most MFA can be hacked. 

Transcription

Reece

Hello, and welcome to Hot Takes with me, Reece, the marketing person. Nelson, our founding engineer and global sales engineering guru, and Jasson Casey, our CTO. Today's Hot Take is a sizzling one. And, it's that most MFA sucks. It's not fun to use and it doesn't even protect you that well. Like, I'm sure we've all heard that myth. "Oh, MFA stops 99% of attacks." Does it guys, what do you think?

Jasson

Well, the stats suggests that two out of three of you haven't deployed any MFA at all. But most of you that have deployed MFA have probably deployed either a push-based system, a TOTP-based system, right? Where you have a rotating code or...not a rotating code, but a jumping code that you put in or perhaps you're using SMS magic links, or email magic links, or codes being sent to your email or whatnot. And, I think what we're really kind of getting out there is all of these things are fairly trivial to phish and man-in-the-middle exploit. And, you know, we've got a demo showing how exactly that works with a couple of the common setups.

But the U.S. Government has given out guidance to federal agencies, specifically moving away from phishable factors. And they basically have two years to get things done, right? Which is kinda light speed in government-speak. So when we say these things are trivially phishable and man-in-the-middle wall, what we basically mean is you can download tools, open-source tools, right off of GitHub, and with a minimal amount of setup, start having fun phishing. And, you know, these aren't vulnerabilities in the products that we're demonstrating, they're vulnerabilities in the design itself of that style of MFA.

Reece

What are some of those open-source phishing tools that you're talking about?

Jasson

I never feel like I actually know how to pronounce it, but it's Evilginx2. So everybody's familiar with Nginx. So there's an Evilginx2 which is...from what I could tell it's a project that some pen tester pulled together just to kinda help in some of his engagements when he is actually working with customers pen testing their organization and, you know, it makes easy what most pen testers usually will just script up on their own, but he turned it into a little open-source. You almost think of it as a little product. It's got nice little phishlets that you can kind of make emails look enticing, and it sets itself up as a full-fledged proxy so you don't really have to worry about setting up lookalike pages and whatnot. And, you know, it's really just down at the end of the day to how well are your users trained? How well do you have things on the endpoint that are looking for things like new domains, new certificates, like, it immediately... It's a really useful tool. And with anyone who knows how to use it or knows how to go about doing what it intends to do, it's easy to show how to bypass those techniques, those mechanisms of defense.

Nelson

Jasson, you did a demo using that. How long did it take us to set that up?

Jasson

Probably took us a couple hours. And it wasn't just me, it was also George. One of our AppSec engineers. But it was just a couple hours to get set up. The initial couple trial runs, you know, they'd work for a little bit, then they'd stop working because we would burn a domain. Google's pretty good at picking up some of these things pretty quickly. And then we started to realize what some of the detection techniques were likely being employed. And so we started...you know, we set up proxy and a VPN, so that the egress off the tool wasn't necessarily the same as where we were directing the victim. We started becoming a little bit more clever with the URLs we were choosing and whatnot. But again, we were just trying to demonstrate feasibility in that demo. We weren't trying to, you know, go after anyone.

Reece

I bet you that most people would say, "I'm using a password manager and I have MFA, like, is there really that much for me to be worried about?" Like, Jasson, earlier you mentioned phishable versus unphishable factors. Maybe we could talk more about that and what that means and why people might think that they're protected, but in reality they're not.

Jasson

Sure. So, the password in your password manager is still a symmetric secret. And what that basically means is, it's known by you, by your password manager, and it has to be known by the service you're trying to log into. Otherwise how could it authenticate you as you? What makes it phishable is if someone is able to insert themselves in between you and the target site. If they're able to pretend that they're the target site as far as you're concerned, and if they're able to pretend they're you, right?

Facing the target site, so it's kinda like, as far as the victim's concerned, they look like a legit service, and as far as legit service is concerned, they look like the victim. If they can engineer that scenario, then they're gonna get access to those credentials. Now, the interesting thing here, isn't really getting access to the credentials. Chances are those credentials have already been leaked. And you can find them through various password dumps. What's more interesting is because you've man-in-the-middle of the authentication, at the end of the authentication you typically get an access token or a cookie, which is how the legitimate service kind of tracks you and knows to...you know, when you wanna update your preference for shipping, it's how it knows that's you and no one else.

Most of those access token cookies, they don't really have any protection against movement. So it's fairly trivial to take that token and drop it into another browser somewhere else, and basically hijack the session. That's what people typically reference when they talk about cookie stealing. It's a pretty common technique. It was used in SolarWinds. It's used pretty often.

Nelson

So those access tokens, some of them are short-lived, but depending on what the SSO or the server system sets that up, they can be pretty long-lived, couple days to a couple weeks. Aren't there marketplaces where you can even go buy some of those access tokens already? Somebody stole them and tried to sell them?

Reece

Yeah.

Jasson

Yeah. Everything is available for purchase. But, you know, one thing I would like to call out, even on a short-lived access token, it doesn't take the adversary long to use that access token and reset the primary credentials. It doesn't take long for that adversary to use that access token and set up an alternative shipping address and execute a purchaser too, right? It doesn't take long for that adversary to dot dot dot.

Reece

Well, how do you stop the access token from moving?

Jasson

There's a couple different techniques, but, you know, the biggest and most obvious one is you can integrity seal the apparent IP address of the access token. There's some other things you can do too. There's also schemes, like, more future schemes where you can have an access token itself that changes over time but in a kind of a predictable cryptographic way. The biggest protection to start with here is remove the phishable nature of the problem to begin with, right? Force session binding. Force the victim and the legitimate service to verify that the session that they're both running is in fact talking to each other. Without session binding, you're always going to have a phishable/man-in-the-middle vulnerability regardless of what you do.

Nelson

I think what falls out a lot too is if your authentication factors are of the more frictionless kind, you can also afford to ask the user to authenticate more. So, you reduce the session length, whatever that is, because you can prompt the user more often.

Jasson

And I think you see that in Finserve or FinTech, right? Like, when you're on a bank, when you're on a brokerage, when you're in... I don't actually trade Bitcoin, but I would assume when you're trying to do anything of high value, the service providers will basically... It's not re-authenticating the session, it's almost like they're wanting you to authenticate the transaction, right? So, traditionally we authenticate sessions and then transactions within sessions are just deemed good because we've already done our work.

A lot of these services that have higher risk around transactions will actually do individual transaction authentication. So the cookie is not necessarily good enough. You wanna move $10,000? You wanna sell $10,000 worth of stuff? You wanna buy $10,000 worth of stuff? In this moment I need you to prove that you can authenticate successfully as Nelson or as Reece, right? So yeah, we've definitely seen that as a trend in FinTech. And we've also seen that start to get generalized in standards protocols.

Nelson

It's actually kinda tragic that that's no more of a trend in security architecture. Just actually prompting for higher factors whenever somebody's trying to do something risky, rather than trying to get everything at the beginning of the session. Only I can't name many...maybe only financial and high security applications that actually do that.

Jasson

I don't think I could tell you... It was a wallet-based company. It was like a blockchainy wallet style company I was talking to, but they had this concept of progressive authentication. Actually no, it was strong authentication with progressive identity proofing. And so what that basically meant is they don't really have any identity proofing requirements on the end user, until the end user starts doing things that surpass certain financial thresholds. So, someone could create an account with almost no identity proofing, right? And if they're staying under a certain amount, like, again, no identity proofing necessary. Once certain thresholds are reached, right? Then it's going back out and saying, "Hey, I need you to identity proof to a stronger degree or to a stronger level." I thought that was pretty interesting, and it made a lot of sense, but yeah, I've only ever seen it in financial related applications.

I do think you get into this battle between, you know, security and product, right? At the end of the day, let's say we're a pizza company, right? Like, our job is to deliver pizzas and deliver pizzas fast. It may be okay if we deliver a few pizzas to the wrong address, because the pizza costs us what? 10 cents. Probably costs more for the driver to deliver the pizza than the ingredients to make the pizza. So, I think they don't look at these problems in the same way. I think they look at these problems more along the lines of, let's say somebody wants to order a pizza fast, and they get to the end of the checkout and they forgot their password, right? How many people just stop and walk across the street and buy a sandwich? Or let's say they really want a pizza, right? Pizza sounds really good right now, it really does. And they're like, you know, "I'll go through a password reset process." So they do the password reset process. And then something comes in their email and they click it and for whatever reason, it drops them in and they have to start doing a...set up a new password. It's like, "Oh man, I gotta do this again. You're telling me I'm reusing a password I used before." So the friction's kind of coming up, right?

And the likelihood of me giving up and walking across the street and just buying a sandwich at The Deli is increasing. So the product folks, I think they think about this more along those lines, right? Like, what is the percentage increase by moving to less friction authentication techniques that they might be able to improve like shopping cart completion or... They have various phrases depending on the industry, but essentially, to increase the level of someone likely to finish the payment, the transaction. And that's when they start becoming interested in these, like, frictionless authentication techniques. Oh, I know that little puppy.

Reece

What is your prediction for how...the way cybersecurity professionals and most people who look at MFA, how is that gonna change? Because this OMB Memo is definitely setting off some ripples, right? People are hearing the word phishing resistant MFA for the first time. And they're like, "What does that mean?" How do you think that...? What do you think it's gonna look like three years from now compared to today when people think about MFA?

Jasson

You wanna start on this one?

Reece

Yeah.

Nelson

So, definitely most people should be thinking about the types of factors they're using and if they use anything that's push-based or SMS or easily phishable. Probably the most opportunistically phishable factor you can find out there is the LTP tokens. They're fine products that actually give you better solutions around that.

Jasson

Yeah. And I would say from a technical perspective it's...all authentication solutions are gonna require session binding. Without session binding, without the legit service and the victim being able to verify that they're in fact actually talking to each other, and there is no man-in-the-middle in between, coming along with the fact that there's kind of strong authentication and at least a couple factors present when things of risk are actually being transacted. Like, I feel like that's gonna be the baseline of all authentication in the next couple of years. If you don't do that first thing, you just have a flaw by design, right? If you don't do session binding, you have a flaw by design. You're always gonna be able to be phished. But, having that is also not enough, right? You need session binding and you need some sort of authentication that's based on asymmetric crypto, right? If you don't do that, then you're still susceptible to breaches, right?

Reece

Yeah. We'll see how it pans out, right guys? Well, thanks for your takes today. I'll see you next week. And if you're liking these episodes, please subscribe. We're gonna be putting them out every week. Hope you enjoy them. Thanks everybody.