Open Mobile Menu


Few things are more frustrating as an attacker than running up against widely implemented two-factor authentication (2FA). Even with valid credentials, without a valid two-factor authentication code or push acknowledgement, logging in to a protected service and abusing its capabilities or harvesting information isn’t possible. But what if instead of attacking the application, we first attacked how the two-factor authentication was implemented? In this blog post, we’ll discuss how one particular 2FA solution – by Duo Security – can have its default configuration leveraged to allow a log in without 2FA and how to mitigate against this tactic.


The Setup

In this example we’ll be using the following setup:

  • An Ubuntu 14.04LTS server
  • The Duo Security Unix “login_duo” module
  • A Kali Linux “attacker” system

We will configure our test Ubuntu system to use Duo 2FA for SSH logins. Detailed installation instructions can be found on the following Duo Security page,, but the high-level process goes something like this:

  • Register a Duo account and select “Applications > Protect an Application > Configure a Unix Application”
  • Install the Duo software on the server
  • Add the integration key, secret key, and API hostname to the login_duo.conf file
  • Enroll a device

At this point, each inbound SSH connection will require Duo 2FA. Easy!


The Problem

I want to stress that the problem does not lie with Duo’s software. The problem lies with the default configuration. After installing Duo for Unix, the login_duo.conf file looks like this:

  ; Duo integration key
  ikey =
  ; Duo secret key
  skey =
  ; Duo API host
  host =
  ; Send command for Duo Push authentication
  ;pushinfo = yes

What this default configuration lacks, is what to do when the Duo API Host address is unreachable. By default, Duo fails “safe.”  That means that if the API Host address cannot be reached, Duo will let you log in without 2FA. This is great from a usability perspective, but not so great from a security perspective.


Figure 1 - The “failmode” parameter is optional, and by default a fail allows access.


Here’s what the login attempt looks like when the API host is reachable by the server, and the user accepts the 2FA push:

Figure 2 – The login process with a 2FA push.


Here’s what the login attempts looks like when the API host is unreachable by the server:

Figure 3 – The login process when the API host address is unreachable.


The Attack

What this default behavior tells us is that if we can control the DNS response for Duo API hosts or somehow disrupt the communication between the server and the Duo API hosts, we can cause the 2FA to fail open. There could be multiple ways to do this depending on the level of access you have and your network position, but for this example, we’re going utilize a Man-In-The-Middle attack, with Ettercap, on the Kali host to intercept DNS requests for *

The first step we’ll take is editing the etter.dns file, located at /etc/ettercap/etter.dns. You can comment out or delete all of the default lines; the only one we need to make this work is the following:

  *   A   <Your Kali IP Address>

With this line in place, start Ettercap with the following command:

  root@kali:~# ettercap -i eth0 -M ARP:remote -P dns_spoof //<Victim IP>// -T -q

You can now try to SSH into the host once again. On the Kali host, you’ll see Ettercap give the following output:

  dns_spoof: A [] spoofed to []

With the default configuration, Duo can’t reach the API host address and fails open, logging you in with just the username and password.


The Mitigation

Preventing this is easy. Only a single line needs to be added to login_duo.conf:

  failmode = secure

With this line in place, the SSH connection simply fails if Duo is unable to reach the API host address and closes the SSH connection. However, it is important to keep in mind the potential usability impact that this could cause if, for whatever reason, your servers are not able to contact the Duo API hosts.

Figure 4 – An unsuccessful login attempt with the “failmode = secure” line present.

In Conclusion

This tactic demonstrates the importance of both fully understanding the software you’re implementing, the default configuration, and all of the available options. While hardening against this attack is easy, it does take some level of understanding of how the software works and what an attacker may look for when trying to get around your defenses. Two-factor authentication has been a huge win for defensive security and should be implemented where appropriate – but it should be done with care to ensure that it reduces your attack surface, rather than just alter it.

Please note that we contacted Duo Security about this issue and were informed that they are aware of the issue and it will not be fixed, as it was a deliberate design decision.

Jayme Hancock

Jayme Hancock is a Penetration Tester with AppSec Consulting with 14 years of experience in the Information Technology field as a systems administrator and security professional. He holds the Offensive Security Certified Professional (OSCP) certification, the Certified Information Systems Security Professional (CISSP) certification, the Certified Ethical Hacker (CEH) certification, and the GIAC Certified Enterprise Defender (GCED) certification. He has helped secure and implement network systems for small and medium businesses, as well as Fortune 500 companies. Over the past five years, he has implemented and managed the HIPAA compliance program for an insurance brokerage from the ground up, including creating and enforcing security policies and performing compliance audits and penetration tests. He served on the board of directors for a local ISSA chapter from 2013-2014 and is active in the information security community.

read more articles by Jayme Hancock