Root Causes 214: New DUO MFA Flaw Explained

Episode Transcript

Lightly edited for flow and brevity.

• 

  Tim Callan

  We're going to talk about a recent news item. I'll direct you to the article. This is a March 15 article in Bleeping Computer and it's written by Sergiu Gatlan. The headline reads, FBI Warns of MFA Flaw Used by State Hackers for Lateral Movement. I would say there's an interesting takeaway here that's not captured in the headlines. What's the gist of what's going on here, Jay?

• 

  Jason Soroko

  Let's just get through some of the what are the facts that are written in the article is there was it seems to be a rash of issues of misconfigurations of multifactor authentication in some enterprises. In fact, it's an FBI warning. The FBI has done this through time, whenever they've come across a number of attacks that are common, they'll sometimes write an article about it and issue it out to the public as a type of warning saying, hey, guys, heads up, this kind of thing is becoming common, we're seeing it and what this is, it seems to be specifically DUO multifactor authentication. Very, very well-known vendor in this space. It's not your usual MFA bypass, Tim, which is sometimes what we might talk about in this podcast. What they're warning about here is a misconfiguration, which I can imagine would be common. That misconfiguration has to do with, obviously, there's going to be a digital identity tied to the credential that is being associated to the DUO account, that you're that you're logging into. That Active Directory Identity is not completely disabled within the enterprise. What's, what seems to be happening here is that the bad guys once they are able to - what seems to be part of the article is - able to brute force guess some of the passwords associated to those Active Directory accounts. Don't forget, these are just username and password accounts within Active Directory. When they're able to compromise the username and password, they are able to then renew the account. They're able to associate the account through DUO onto a different device. In other words, the attacker’s own device.

• 

  Tim Callan

  Then they are actually using DUO. They're using the real DUO functionality that exists to sign on to whatever DUO lets you sign on to?

• 

  Jason Soroko

  Exactly right, because most of these applications are now MFA enabled. So, you need more than just the username and password. Well, the username and password has been compromised. And then, of course, the very next step is you need to be able to utilize DUO to complete the authentication with the multifactor and because of the fact that these accounts are not fully disabled in Active Directory, the bad guys are able to use that stolen credential to then provision their own devices to utilize the DUO application and then, as you say, fully authenticate. So, there you go. That's the facts as we see it.

• 

  Tim Callan

  This is an unusual story in a couple of ways. It's an unusual story, one, in because it's about - and we could debate exactly where this falls - but to some degree, it's about exploiting a single sign-on service, which I don't think is typically the kind of story that we're reading.

• 

  Jason Soroko

  Exactly right. When we were talking about passwordless in the past, the recent past, we were talking about getting rid of passwords altogether and the benefits that that gives you. The reason why I think we decided to talk about this particular example today, it certainly is not to bang on to harsh on DUO or any vendor here.

  This is about the mistakes that can be made so easily and so commonly that the FBI has to issue a warning to enterprises about it. In other words, looking through the article here, there are some very good points. So, when you're configuring and you're reviewing your MFA setup, you really need to set up your configuration policies to protect against a fail open and reenrollment scenarios. In other words, you as an enterprise can very easily choose, great, I'm using MFA. I feel warm and fuzzy. I feel safe. It seems to be a real pain in the neck for people who happen to lose their password or maybe lose their phone, so reenrollment on a new device, let's just make that super dead easy and oh, what the heck, we're using MFA, so, we're all safe? Well, if you've configured it to be so easy to reenroll to a new device, and you're not fully disabling certain identities once they are disabled, then goodness. In fact, part of what the article said here is one of the reasons why people had become disabled was because they had not used their DUO account for a long time. And so therefore, part of the policy that was set was your length of inactivity had bumped you off, but then the bad guys were able to obtain your password somehow. Could be by any means. In the article, they were saying brute force guessing, but you can just imagine that something like keylogging would be just as easy, if not more so.

• 

  Tim Callan

  Password reuse.

• 

  Jason Soroko

  Therefore, think of that scenario, and realize how are you enabling reenrollment of your multifactor authentication in your enterprise? Because if there's passwords underneath, you have to still assume those passwords are going to be compromised. So then work backwards and think to yourself, if you're a bad guy, what is the art of the possible in order to be able to then get a hold of that account, be able to implement something like your, whatever MFA of choice you're using on a device and then use that to fully authenticate through? It turns out in many cases, it's not that difficult at all once the password has been compromised.

• 

  Tim Callan

  It's a tricky business to rely on every single end client to get the configuration correct. Could this be locked down? Like could the MFA vendor limit what it will allow its software to do to get rid of an attack like this or are there legitimate use cases where you need to leave that door open?

• 

  Jason Soroko

  What this comes down to, and people who are in the field could shoot me down for this. And if you do, please reach out to us.

  I would say, Tim, the centralized place that needs to be locked down further here is at the Active Directory level. It's not at the client level. It is at the Active Directory level and the choices you make about how that kind of, it's the same kind of issues you have to think through when you're first provisioning your users. What's the secure way of doing that? Well, I guess in this case, part of the issue is people have not fully thought through well, what is the reprovisioning process? Not just the initial provisioning process. What's the reprovisioning process? And that seems to be the configuration problem down at the Active Directory level that is problematic here. I mean, I guarantee the vendor is trying to say, look, you can set it up any way you like, we will play ball with you because every enterprise is going to have a different appetite for risk and a different way that they want to set up their help desk. And so, it's not really DUO who is going to dictate that to an enterprise. Unfortunately, I can see how enterprises, and especially Active Directory teams, kind of opt for the easy breezy method, because it saves them calls to the help desk. And unfortunately, it makes life easy for the bad guys.

• 

  Tim Callan

  Absolutely. We've talked about this in other episodes. You say, oh, happier users and fewer help desk calls, this all sounds really good to me. Let's do it. And you don't realize that you're not only making it easy for your own employees to navigate, but you're making it easy for that attacker to navigate as well.

  It was interesting. Interesting story on a few angles. So, I think it was good that you brought this up today and we talked about this.

• 

  Jason Soroko

  Tim, configuration problems. That seems to be configuration problems with Microsoft CA on-prem, configuration problems with even, very well-known, well-used multifactor authentication. It seems to be part of the theme.

• 

  Tim Callan

  Also, one other interesting thing just to touch here is that if a platform gets broadly enough used, it can be profitable to focus on an attack that is exclusive to that platform. There are an awful lot of people out there using DUO. And if you manage to find a way to exploit DUO, even if it's only that one, it can still be very rich ground for you. And that's another thing to think about as things become widespread and prevalent that that vendor platform itself becomes a legitimate environment for people to try to develop attacks.

• 

  Jason Soroko

  Monoculture in any sense is problematic because people learn it. Active Directory might be the most perfect example. Who doesn't have Active Directory and that's one of the most broken systems in history.

• 

  Tim Callan

  I mean we get to the point where we almost don't think about that. We think about these basics, like the Windows stack, as a sort of a given, but that's coming from a vendor too. But it's interesting to see people specializing to the next degree and say, well, this, provider on top of the Windows stack is now my playground and it's a big enough world that I can profitably do exploits just inside of that.

• 

  Jason Soroko

  The way that I want to wrap this up, because, again, we do not want to be hard on the vendors. It's a tough world out there.

  So the best way to think about what we're talking about in this podcast is, yes, you can do Active Directory correctly. Yes, you can. It's just, it's hard. And you need to learn a lot of things. You can absolutely implement DUO correctly. It's just, hey, follow what the FBI is telling you here, because they're giving you some good advice, saying you gotta lock down that config. And remember, folks, if the underlying credential is just a username and password, you really got to be careful.