Abusing Duo 2FA

On a recent client engagement, our customer asked us to look at their use of Duo Security multifactor authentication that protected Windows workstation logins. It was configured to send a push notification to users’ phones whenever they logged in or unlocked, either physically at the console or over remote desktop.

Through other mechanisms during the test we’d already obtained local administrative credentials to the target systems, but any attempts to logon interactively was met with the Duo prompt. Sometimes it’s necessary to gain an interactive session either to run remote desktop applications, obtain a Kerberos token to re-use, or because meterpreter is picked up by AV. It’s also fun to try and bypass security controls :)

Now, we could have simply uninstalled Duo, but that’s potentially noisy. Here’s a much more stealthy way of sidestepping Duo.

If you find yourself on a test, and are challenged to gain access to your client’s desktops that are protected by Duo, here’s what you need:

How-to

1. Obtain an account with administrative network access to the target box (domain or local account), but is not enrolled in Duo.

2. Obtain a shell on the target machine (either with psexec \\target cmd.exe or meterpreter).

3. Attempt to logon to target, either via RDP or interactively. This will cause Duo to issue the message “the username you have entered is not enrolled with Duo Security”:

4. Using your shell from step 2 run ipconfig /displaydns which should reveal a recent DNS lookup to the Duo API server of the form api-1234567.duosecurity.com.
This server is used by the local Duo agent to communicate with the cloud service and is unique to each customer installation (the server name should be the same across all the workstations at your client).

5. Edit c:\windows\system32\drivers\etc\hosts to add 127.0.0.1 for api-1234567.duosecurity.com (the specific DNS name from step 4)

6. Logon to target via RDP/console again, Duo authentication is bypassed.

The ability to bypass Duo in this way requires that you already have an account with local administrator rights on your target (for example, through LLMNR poisoning) and that Duo is setup to “fail open” when it loses contact with its cloud servers, although this is the default option.

You don’t even need local admin to cause issues

Whilst in this single-target example, a local administrator account was required, the same effect could be accomplished by an attacker that has privileged access to the network but not local admin rights, either by setting network ACLs at the border to block outbound connectivity to Duo or by compromising or poisoning recursive DNS servers to sinkhole DNS lookups.

If Duo is set to “fail open” then an attacker can now login to systems with a valid credential (even if they’re not local admins) without triggering Duo to send a push notification, or if Duo is set to “fail closed” then this likely causes a significant denial of service condition as users will no longer be able to log in to, or unlock, their workstations.

Of course, if you already have local admin rights on a machine there are various other options you could take, like just uninstalling Duo itself, but this is quite a “noisy” action for an attacker to take. Sinkholing DNS lookups is less likely to be noticed, and is certainly easier to justify to a client!

We knew that this was intended functionality – if the Duo API is unavailable for any reason, then one can’t remotely authenticate to the workstation. Hence, the service is set to ‘fail open’. The alternative is to ‘fail closed’ which mitigates our sidestepping technique, but also causes access issues in the event of network outages.

We spoke to Duo prior to publishing, and to their credit, they were amazingly responsive:

Resolution

This isn’t is a security vulnerability per-se though we think it’s important that Duo users think carefully about choosing which option of ‘fail open’ and ‘fail closed’ they select. One allows the above sidestepping technique or simple uninstall of Duo. The other means that you can’t authenticate if access to the cloud service is lost.

Of course, ensuring that your local admin creds can’t be pinched would be an even better idea!