Yesterday, an external researcher, Jérôme Nokin, posted a blog entry describing how he discovered one of the hashing algorithms our XTM products use when storing a certain kind of user credential. I wanted to point out his post for two reasons; first, to show off the researcher’s impressive reversing work, but also to clarify a few points for our XTM customers, so they understand whether or not this discovery poses them any risk. Let’s dive in.
Nokin’s discovery involves hashing functions, which are one-way cryptographic algorithms that map data sets (of any length) to a unique, fixed-length key. These one-way algorithms are designed so that the key should uniquely match one and only one data set, but also should not help you recreate the original data. Hashes are not intended as encryption, they’re intended to be unique “fingerprints” for specific data sets. However, they are often used as a secure way of storing passwords. Rather than store a clear text password, why not just store the “fingerprint” for that password. If a user enters the right one, the fingerprint should match.
In a nutshell, Nokin’s post outlines two things:
- He found that we store a certain type of user credential in the XTM appliance configuration file
- He found the specific hashing algorithm we use for storing passwords (NTLM + null)
Let’s look at each of these things.
What credentials are in the configuration file?
First, we do store a very specific type of user credential, including its hashed password, in the XTM configuration file, but it is not the XTM management credentials. In the original post, Nokin alluded that he was trying to recover management access to his appliance, and the reader might assume that “superuser” credential he demonstrated in the configuration file was this management user. That is not the case. Your XTM appliance’s status and administrator management credentials are not stored anywhere in the configuration file. They are only stored on the appliance itself, and not readily accessible.
The user credentials Nokin found are actually credentials associated with our optional FireboxDB authentication database. Our devices offer the ability for you to create policies by user, not just by IP address. To do this you have to set up authentication. In most cases, users choose to authenticate with their own internal Active Directory, LDAP, or Radius authentication server, in which case we don’t store any credentials. However, we also offer the local FireboxDB database, for small customers who don’t have their own authentication server. The users you set up in this database are just associated with policy creation; for instance, you might use them to create a policy allowing Bob to access the Internet but not Alice. They do not have any privileged access to manage the XTM appliance itself.
It is still important to protect the credentials of your FireboxDB users, if you are using that feature, but the key point is that the management credentials to your security appliance are not compromised in any way.
What’s the big deal about the hashing algorithm?
Nokin’s post also talks about discovering the hashing algorithm we use to store these FireboxDB credential. So what are the implications to this information?
There are two issues here, but the main one is if an attacker knows the hashing function a particular credential uses, he can attempt to use cracking tools to find the actual password. However, notice I said attempt. Password cracking tools can attempt to crack any hashing function (LM, NTLM, MD5, SHA-1, etc), but whether or not they succeed will depend on a few things, including password length and complexity. Simply put, if you use strong passwords, it still would take way to long too crack your password.
However, the second issue here is which hashing algorithm is used. Though you can attempt to brute-force any hashing function, some hashing algorithms take longer than others. Computers can generate NTLM hashes more quickly than newer hashing functions (like SHA2), so cracking NTLM hashes takes less time. That said, it still takes an exponentially longer time as your password length grows. Though an attacker might be able to crack an eight character password in hours, it would take years once the password grew to 11 or 12 characters.
In any case, Nokin is correct to point out that NTLM, even with a salt, is an older hash function, and worth updating.
So should I be worried about this as a major risk?
The short answer is, no.
Though Nokin has made a good point about our hashing algorithm, ultimately this issue poses you very little risk. Here’s why:
- The only hashed passwords we expose are for FireboxDB users, which are not your XTM appliances management credentials. Attackers cannot leverage this knowledge to gain management access to your XTM device. Furthermore, if you don’t use FireboxDB authentication, there are no credential at all in the configuration file.
- The password hashes Nokin found are stored in your XTM appliance’s configuration file. As you surely already know, this is a very sensitive configuration file that typically lives on the computer of your security administrator. It contains all the configuration information for your XTM device. By default, it is stored in a directory that is only accessible by the administrative user that installed our product software. Frankly, if an attacker already has enough access to the administrator machine you use to manage your network security appliance, you already have bigger problems
- Even if an attacker could obtain the hashes needed to attempt a password crack, there’s no guarantee he’d succeed in his attempt. If you use strong passwords (complex combinations of 12 characters or more), it would likely take too long for attackers to crack them.
So to summarize, Nokin’s reversing work is quite impressive, and his identification of our FireboxDB hashing algorithm is right on. However, this is not an issue XTM administrators should worry about, assuming you are following a few security best practices. Attackers can’t use it to gain management access to your XTM appliance, and if you protect your XTM configuration file, as you already are, there is really little risk.
That said, I agree with Nokin. The NTLM hash algorithm, even with a salt, is not as strong in this day and age. We have already started looking at updating it. — Corey Nachreiner, CISSP (@SecAdept)