It’s been a fun week. About six months ago, a coworker and I found a session stealing race condition in Duo Security’s multifactor authentication product. Wednesday, they published the fix, so now I can talk about it openly. The vendor response was really great – as we worked with them on different ideas on how to fix it, I wasn’t sure how they’d end up deciding. The solution they chose is really taking the high road, and I’m excited about the strength of the Duo MFA design with this update.

Some of the discussion we had, though, was very interesting. The vendor has a certain objective, and in their view this race condition is hard to exploit and they felt (and I think express pretty clearly in their post about it) that it’s really the fault of the customer in failing to adequately protect their end-user workstations. From my perspective, as a pen-tester, I don’t think this line of argument is completely sound. Hence this post – presenting my thoughts on why the Duo race condition is a genuine concern, and how it fits in the broad threat scenario landscape.

First, let’s talk about how the race condition works, and can be exploited. Duo MFA is unique in its support for mobile device push notifications. The user logs into a system with their username and password, but before the authentication is complete, Duo sends a notification to the user’s mobile device. The login completes only if the user authorizes the request on his phone. It’s a very cool design, and it has some real merit when compared with other MFA schemes.

Duo Push Notification Scree

The vulnerability occurs when there are multiple requests to authenticate at the same time. The mobile application “compresses” the notifications, so that at any given time there is only one visible to authorize. If you asked, “Which one gets authorized?” You’re half way to the vulnerability yourself. The answer is that it’s the last one (see footnote 1). So if an attacker can generate a push notification slightly after a legitimate one, the user will authorize a malicious connection rather than the one that is expected. Impact to the user is light – a login failure, at which point most users will just try again. MFA can be finicky sometimes anyway, and we’ve found that users are more likely to report a network problem than that they’re being hacked.

The point of the discussion is this: is it reasonable to think that MFA should protect you when your workstation is compromised? Second, should Duo consider it a problem for them to fix if compromising the end-user’s workstation can undermine MFA?

Let’s imagine a fictitious network where users authenticate to RDP jump boxes to access a PCI cardholder data environment (CDE). We’re going to do an internal penetration test (or, if we’re evil, we’re going to breach the CDE!). How should we go about it? Here’s my best guess:

  1. Find some low-hanging fruit
  2. Exploit it
  3. Use initial access to escalate
  4. Get domain admin
  5. Monitor privileged user workstations
  6. Steal credentials
  7. Log in to RDP jump boxes
  8. Profit.

I do that every other week somewhere. It works all the time – I think I’ve had three internal pen-tests since 2009 where I didn’t get domain admin. The real truth is that no one can protect an internal network of significant size or complexity. If you don’t believe this – maybe you have magic defensive controls – ask a decent pen-tester how he would get around in your environment. This isn’t the time for ostritch-head-in-the-sand thinking.

OK, now let’s throw effective MFA into the mix. We’ll protect those RDP jump boxes that protect the CDE. What does our process look like now?

  1. Find some low-hanging fruit
  2. Exploit it
  3. Use initial access to escalate
  4. Get domain admin
  5. Monitor privileged user workstations
  6. Steal credentials
  7. ???
  8. Profit.

That “???” becomes incredibly important. If there isn’t a way to undermine the MFA, then the intruder isn’t getting anywhere. Maybe he can keylog the users for months and get some credit card numbers or something. An effective MFA solution, where there isn’t an easy way to undermine it, prevents the intruder from getting to the goal.

Effective MFA can mean the difference between “possible” and “impossible.”

OK, so maybe that’s not completely right. Duo even suggested at one point, “If you’re local admin, can’t you just ride along on the RDP session?” Well, the answer is sort of yes. In a way. But it’s pretty delicate. Are you going to steal the keyboard from the user? What’s the detection profile of that move? You might be able to find an abandoned session somewhere and use it. But that’s preventable with some end-user hygiene and hardening of the jump box. There are some cool ways to tunnel traffic through RDP (I’ll talk a bit about that in this week’s presentation at Nolacon!), but most of those require setup on the jump box itself, so they’re a no-go from the ride-along perspective.

Unless you’ve got an 0-day that gives you remote code execution through RDP in an undetectable manner, it’s a pretty hard problem. A lot harder than triggering a race condition and getting your own perfectly good RDP desktop somewhere.

So back to our two questions. Is it reasonable to expect MFA to protect against a workstation compromise? I can see the vendor choosing to do nothing here. Their goals and motivations are different from mine, and they could just as easily say, “Not a problem with our technology.” But for someone who is relying on MFA to be a strong protection against an internal threat, it’s critical. For the customer, it is reasonable, and I’m really glad that Duo took it seriously and issued a fix.

Second question, should Duo consider it something that they have to fix? They didn’t have to, I suppose, but fixing it gives their customers a stronger control. It becomes an MFA solution that can be recommended for segmentation boundaries without having to say, “But be aware that there’s this one thing…” Thanks Duo!

With the bypass, #7 above (the “???” step) becomes “steal a session” Without the bypass, it’s still question marks. And with Duo’s mobile push, it’s a fantastic design, and I love it. Even if it makes my pen-tests harder.