Select Monthly Archives
- December 2017
- November 2017
- September 2017
- August 2017
- June 2017
- May 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- March 2016
- October 2015
- September 2015
- July 2015
- May 2015
- March 2015
- February 2015
- January 2015
- December 2014
- September 2014
- August 2014
- July 2014
- June 2014
- March 2014
- January 2014
- December 2013
- September 2012
Filed In: Security Testing, Application Security
Written By: Jayme Hancock August 22, 2017
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.
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, https://duo.com/docs/loginduo, 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!
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:
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.
Here’s what the login attempt looks like when the API host is reachable by the server, and the user accepts the 2FA push:
Here’s what the login attempts looks like when the API host is unreachable by the server:
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 *.duosecurity.com.
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:
*.duosecurity.com 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 [api-xxxxx.duosecurity.com] spoofed to [127.0.0.1]
With the default configuration, Duo can’t reach the API host address and fails open, logging you in with just the username and password.
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.
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.