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

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?

#1: Treat Secret Keys like they are passwords.

#2: Create a new application for everything.

#3. Change your secret keys periodically!

This button is your friend.

Here’s where things get harder.

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

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

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

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….

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

Thanks!

Data center/security/collab hack, CCIE #5026, focusing on automation, programmability, operational efficiency and getting rid of technical debt.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store