Securing Cisco Duo Secret Keys is Really, Really Important. Really.

Photo by Matthew T Rader on Unsplash

Physical penetration testers have this really cool trick where they’ll swap out a lock’s key core with one that always opens, regardless of the key inserted. Unless you specifically test for this condition, you’d never know. To combat this, a security team needs a “red key” — one that will never open a lock.

What does this have to do with Duo? With the events of this week’s Solarwinds breach, one attack vector allowed the bad actor to access OWA that was protected with Duo two-factor authentication, but the 2FA credentials were never checked. I need to stress that this wasn’t a Duo issue — the machine was compromised in such a way that any security provider would have been bypassed.

I’m not going to go into the level of detail already in Volexity’s excellent writeup, but the organization was lulled into a false sense of security thinking that 2FA was protecting them. The attacker had changed the lock’s core so it always opened.

This got me thinking about Duo security and ensuring that people understand the critical importance of securing their secret keys. I’ll walk through an example, and give you a few tips for ensuring that your secrets are protected.

Setting up a Duo App

When you create an application in Duo, you get three parameters: an integration key, a secret key (the SKEY), and the API hostname. You can see all the parameters here. Don’t worry, none of these actually work.

A new application, created in Duo, provides an integration and secret key.

I’ve highlighted the secret key. If this secret key becomes compromised, your application security can be compromised. This secret key is used to validate authentication tokens from Duo. Duo (and all the other providers) tell you to protect your secret keys, but people don’t understand WHY this is important.

Duo tells you to protect the secret key, but I think they should make the text BOLD. This is REALLY IMPORTANT!

If you prep a workstation batch installation file, is your secret key in a location that’s accessible? If so, it could be compromised.

Even from a Cisco ASA, you can retrieve the secret key. In the configuration file, all you see is this:

‘show run’ output of a Cisco ASA Duo config

But, if you dump the actual configuration to a text file or remote server, there it is:

Ok, so what are my options to protect my organization?

There are a few things that you can do to protect your enterprise secret keys. I’m not saying that this would have helped in this particular situation, but these are the best practices that can reduce your risk vectors. In order from easiest to most difficult, here you go.

#1: Treat Secret Keys like they are passwords.

Make sure your installation scripts, configuration backups, and other places that the secret keys are stored have limited accessibility. Don’t store the SKEY in BAT files on shared folders. Keep them in your password vault.

#2: Create a new application for everything.

Protecting VDI and VPN? Make sure you create a new set of applications for every service. Don’t share integration and service keys between applications. Application integrations are free, so don’t be stingy!

#3. Change your secret keys periodically!

Resetting secrets is as easy as pressing the button on the application screen. Generally speaking, it’s more impactful to change secret keys on devices that service multiple users, versus distributed systems. If you want to automate this, reach out.

This button is your friend.

Here’s where things get harder.

#4: For distributed systems, create keys for each element.

Protecting your fleet of laptops with Duo? Create a separate integration for each device, so each IKEY and SKEY are unique. There’s absolutely no way that this can be done without automation and API integration, but you can make this part of your provisioning workflow. Duo has parity between the API and GUI, so if you can speak REST (or even Ansible), you can make this happen. Once again, if you want to automate this, reach out.

#5: Perform correlation audits between Duo and the on-premise systems.

There is a way — albeit not out of the box— to ensure that Duo is responding to requests and not being bypassed. All your Duo logs are accessible via API or able to be pipelined into your SIEM. Setup a correlation report to examine the authentication events on your protected device, then match them to the cloud authentication logs. Disabling the ability to trust a user device for a variable number of days ensures that all requests get cloud validated, however this comes at the expense of user convenience.

This is the only recommendation that might have uncovered the Solarwinds attack, but it’s the most complicated. As with all security, it’s a question of, “is the juice worth the squeeze”? This has a fairly high technical debt load. For some organizations, yes. Others, no.

#6: Enterprise credential vault

This is WAY more broad than this particular Duo use case, but if enterprise credential vault isn’t on your radar, it should be. This involves having an isolated vaulted credential vault store where secrets are checked in and out. I’m a massive fan of HashiCorp Vault, because for the low, low price of Absolutely Free, you can work towards eliminating static passwords.

Once again, this is a massive shift in thought processes, but I think that we need to do a better job of secret management enterprise-wide.

Let’s wrap this up….

It’s simple: protect those authentication secrets, regardless of vendor or application. Duo is one, but follow these same recommendations for RADIUS/TACACS keys, or other shared secrets that could potentially reveal protected credential information, or allow unfettered access to protected systems.

Any other recommendations? Please leave a comment here, reach out on Twitter, or send me a message on LinkedIn.

Thanks!