Hello loyal blog readers. Over the last few weeks I have been busy working on a network assessment for one of our fantastic customers. One of the areas we look at when assessing a customer’s network is how they are protecting/restricting access to the management plane of their network infrastructure.
Ideally, we want our customers to be leveraging a centralized AAA model, with individual members of the support team all having their own unique accounts, while granting them the minimum permissions required to fulfill their job functions. All sessions should be centrally logged and performed over a secure encrypted connection (SSH not telnet right!), and that unused management protocols are disabled (HTTP/HTTPS). Finally, we want to ensure that these management sessions are only permitted from trusted networks/subnets or from a fortified bastion host.
With that being said, there are occasions when local authentication can be advantages, such as for console connections or in the event of our centralized AAA servers not being accessible. I generally recommend that customers keep local accounts to a minimum and that their credentials are kept locked away, only do be used when absolutely necessary.
So if we do have local accounts and passwords stored in our configurations then there are some best practices we should be following to protect these credentials.
In this blog I’ll take a trip back in time and look at how IOS/IOS-XE has improved its method of credential storage over the years.
CLEAR TEXT and Type 7
In the screenshot below, I have created my enable password “TOPSECRET” and two user accounts “USER1” and “USER2” with the password “HAPPYDAYS”. As we can see from the “show running-config” command these passwords are stored in plain text (Type 0) in our configurations. This is the ultimate ‘no-no’ when it comes to protecting our management plane. Anyone who has access to the configuration now has the keys to the kingdom. Even a person that is casually shoulder surfing an unexpecting network admin while he/she sips on their coffee at Starbucks, would be able to see and record these credentials. I have worked in environments where the admin credentials were stored like this and they used those same credentials across multiple platforms (Domain, Backup, SaaS, VPN).
Lesson Learned: Do not store credentials in clear text and have alternating local passwords per device.
The next step in our credential storage evolution was to enable the “service password-encryption” feature.
As shown below once this command is entered all our Type 0 (Clear text) passwords have been obfuscated to Type 7 by running them through a Vigenère cipher. You can read more about the math behind the cipher here, but in short it’s a substitution cipher which is trivial to decrypt once you have the input key and table. If you search your favorite search engine for “Cisco type 7 decrypt” you will receive a whole host of sites that are only too willing to reverse your cipher text back to plain text.
In fact, we don’t even need an internet connection as we can decrypt our type 7 cipher text right on any Cisco IOS/IOS-XE device. Below I decrypt USER2 password by creating a key chain with the same type 7 input.
Lesson Learned: Service Password Encryption does not help us. It only thwarts the casual shoulder surfer. To all intents and purposes our passwords are still stored in plain text for anyone with access to our configs.
Type 5 Salted MD5 Hash
Then came Type 5 passwords. This was a big improvement over our previous two options. Passwords are combined with a random salt value and have a one-way MD5 hash function run over them. The salt value ensures that two identical passwords will have different hash outputs (see USER3 & 4 screenshot below), the salt also acts as a protection against attackers using simple precomputed hash table (known as rainbow tables) cracking.
We use the “secret” keyword when creating our accounts to denote that we want to store our passwords in a hash format. Since hashes are one-way functions you can not reverse them to reveal a password. Authentication is performed by taking the user provided password and combining it with our known salt value. The router then feeds it through an MD5 hash and if the results match the hash we have in our configuration then the user is authenticated.
Below I have highlighted the salt value in red with the resulting hash for USER4 highlighted green.
username USER4 secret 5 $1$Cw5j$nPnEH3Pj70KhJjjhzQCJa1
Supplying the same salt value and clear text password into an OpenSSL, MD5 function you can see that we get the identical hash output.
Up until recently that is where the story would end. Enable Secrets with it's salted MD5 hashes was the preferred way to store local credentials in our Cisco devices. But time waits for no man or woman, and advances in chipsets and processing power continue to advance which results in our old algorithms becoming increasingly susceptible to compromise. And that is where we are with MD5 today. We needed something new to protect our passwords and that is where Type 8 and 9 come into the picture.
Lesson Learned: Type 5 is ok, but we need to upgrade.
Type 8 and Type 9 Password Protection
Algorithms are just like buses. You wait ages for one to come along and then two come along together!
Type 8 passwords are pretty much a direct upgrade from type 5 but instead of using MD5 we are now hashing with SHA256.
Type 9 on the other hand takes a whole new approach and utilizes the purpose-built password protection algorithm “scrypt”. Scrypt is designed to be extremely CPU and memory intensive (not that you would notice it when encrypting a single password). This resource intensity is what makes it so difficult to brute force crack.
The screenshot below shows how to upgrade your enable secret to use scrypt, and how to create USERS5 and 6 with type 8 and 9 encryptions respectively.
These new kids on the block were introduced in IOS 15.3(3)M which came out way back in July 2013. Although they have been available for a long time I very rarely see customers utilizing these algorithms in their configurations. This might have something to do with another password encryption method (Type 4) which was touted by Cisco back in the day to be the successor to Type 5. Things did not go to plan, and Cisco ended up with a little egg on their faces and had to pull code that supported type 4 encryption. But that might have to be a story for another day.
Lesson Learned: Type 9 is how all your local account passwords should be secured. Remember a stronger algorithm is no substitute for implementing a strong password policy, so keep those passwords random and rotated often.
Hopefully you have found this blog useful. As always comments and friendly mocking are always welcome.
Written By: Chris Marshall, LookingPoint Senior Solutions Architect - CCIE #29940