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)
I commend WG on addressing and commenting on this issue – some companies might not have. Here’s to stronger algorithms!
Thanks for saying so Tom. I believe more transparency tends to help lead to better security. And despite the fact that I don’t think this issue is a huge risk if you follow best practice, I am for updating our Hash alg.
Corey, I agree one has bigger issues if the network admins machine is compromised. However this may be accessible to more than one person as desktops and laptop machines in enterprise environments are frequently managed and accessible by a team of admins, so the internal threat remains very real. Secondly, what I don’t see in your discussion is the use of rainbow hash tables to crack passwords. These tables, though very large are often prepared in advanced exactly for this purpose, quickly cracking hashed passwords. Even long passwords can be cracked quickly if a matching rainbow has has been generated. Due to size and time constraints to generate such a table, your advice of using long passwords may go a long way towards defeating those with lesser resources.
You covered why I didn’t mention rainbow tables very well yourself. As it turns out, rainbow tables are great for significantly increasing the speed of cracking passwords from 1-8 or 9 characters, but they become relatively moot after that. In order to create a rainbow table, you need to go through the original time for the cracking process. It doesn’t take that long today to get through all the combinations of 8 character passwords, but after that, time increases exponentially. Look at the rainbow tables out there, many are not past 8 characters. The other issue is storage, you’ll notice rainbow tables for all the 7 or 8 character passwords for certain hash algs are around 5-15GB in size. Add a character and that grows exponentially, lets say hundreds of gigs, add another character and it becomes petabytes… The point is, after about 8 characters rainbow tables are no longer that useful to use, and since a computer can brute-force 8 characters relatively quickly already, the only point of rainbow tables is to speed up shorter password cracking.
So again. Use a long password, 12 characters or more, and make sure that it has enough complexity, and is not so common, that dictionaries don’t help, and you are relatively safe.
I still am spear-heading us changing our hash algorithm, but since the hashes only exist in your config file, I still think this poses minimal real-world risk. Simply put, it should encourage you to use best practice. Protect sensitive data, like your security appliances configuration file. Adopt the the least privilege paradigm. And always use strong passwords, regardless of hashing algorithm.
As an aside, Alan, this is a really good article on why rainbow tables are less useful:
http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html
I don’t think they are totally dead, in that a they still really help for speeding up cracking shorter random passwords, but they don’t really help for long passwords.
I’m concerned if the FireboxDB hash file is hacked then they may be able to gain VPN access into the LAN. I have 1 customer, very small, that I use the local accounts for VPN auth….
Do I have a valid concern?
Thank you!
Tim Jordan
North Tech Group, Inc.
http://www.northtechgroup.com
907-262-1455
That is a valid concern if an attacker gained access to your configuration file, and your client doesn’t use strong passwords. That is the case for anything. If an attacker gains access to the database file your web application stores hashes, attackers could also hack those passwords. The key here is make sure your customer employs best practice. The configuration file of any security appliance is a sensitive document. You should be sure to protect that document, and the computer it is on. And, make sure you clients use strong passwords always.
^_^
Impressive enough to see this sort of work done and I’m very happy knowing (hatted) external users focus on WG as well, as it’s necessary these days. I sleep better knowing there’s people chipping away at the WG products, which in turn (possibly) helps WG improve it and themselves; which is always a great thing!
I was curious though. It mentions only this standard config file which contains the wgdb. Made me wonder if the “support” file contains nothing “extra”. Nothing juicy in there at all, beyond additional logging?
In short I guess I’m asking: Does the support file contain any config-type of files other than ye olde regular config file which you (should) always get a backup of when saving to box?
//Ken
I agree. It’s a great thing when Whitehat, responsible researchers disclose issues to us. While I might argue that my engineers pay more attention to security, and secure coding practices than some… everyone mistakes. It’s great when well-meaning researchers help us find these issue and better our product.
Good question about the support file. I haven’t looked at all it contains recently, but I don’t think it has any more hashes. However, I will say their is file on the appliance itself that contains the management credentials (obviously the appliance would have to have this to accept logins). However, this file is not one we make readily accessible. There are no customer gui’s that give easy access to it. If you literally have physical access, and you dump firmware or whatever, than you could get it. But obviously most attackers wouldn’t have physical access to the appliance.
That said, I will take a pick at the support.TGZ file. Of course, you can’t dump that file without the admin credentials.
While it appears to be something that affects very few WG users, which is certainly a good thing, I think the difficulty in cracking passwords is easier than you describe. With new rigs with multiple video cards, performing GPU enhanced cracking is much faster than it was in the past, especially if you are attacking a weaker protocol like NTLM. Still, security best, or even security moderate practices would guarantee that this file would not be readily accessible. Like you said, if they have admin access to the machine that manages the appliance, it’s game over for your network anyway.
Websites using this content based strategy are always given top scores
by Google. Spill Under is when the people under you sponsor people
making your business grow. But this is the best option to sell your product and services.
He was a house painter a few years ago and began his internet marketing career as
an article writer. You have to start by thinking carefully about whatever it
is you are actually trying to do in your online marketing
project. This might not be a blatant sales pitch,
but the reader understands that the author also wants
to convey the superiority of a certain product.
If you desire to take a great deal from this paragraph then you have to apply such strategies to
your won weblog.
Excellent beat ! I would like to apprentice whilst
you amend your web site, how could i subscribe for a blog site?
The account aided me a acceptable deal. I have been tiny bit acquainted of this your broadcast offered brilliant clear idea
Hi Dear, are you truly visiting this web site
on a regular basis, if so afterward you will definitely get
good knowledge.
I’ve been browsing on-line more than 3 hours these days, yet I never found
any attention-grabbing article like yours. It is pretty worth sufficient for me.
Personally, if all website owners and bloggers made just right content material as you did, the internet
shall be a lot more helpful than ever before.
Do you have a spam issue on this blog; I also am a
blogger, and I was curious about your situation; we have developed some nice methods and we
are looking to swap strategies with others, please shoot me an e-mail if interested.
This post will help the internet visitors for creating new webpage or even a blog from start to end.
My spouse and I stumbled over here from a
different web page and thought I may as well check things out.
I like what I see so now i am following you.
Look forward to looking into your web page yet again.
Thanks for your personal marvelous posting! I certainly enjoyed reading it, youu could
bee a great author. I woll be sure to bookmark your blog and will come back later on. I
want to encourage you to ultimatepy continue your great writing, have a nice day!
Thhank youu foor every otther great post. The
place ekse may anybody get that kind of information in such a perfrect means
of writing? I ave a presentaztion next week, and I’m on the seearch ffor such information.
Wonderful site you have here butt I was wondering if you knew of any communty forums
that cover thee same topics talked about here?
I’d really like to be a part of online community where I can get
advice from other experienced pdople that share the same
interest. If you have any suggestions, please let me know.
Many thanks!
Hi there to all, it’s actually a good for me to visit this
web page, it includes valuable Information.
Hey there! Do you know if they make any plugins to safeguard
against hackers? I’m kinda paranoid about losing everything I’ve worked hard
on. Any tips?
Hello there! Do you use Twitter? I’d like to follow you
if that would be ok. I’m undoubtedly enjoying your blog and look forward to new posts.
Hey just wanted to give you a quick heads up
and let you know a few of the pictures aren’t
loading properly. I’m not sure why but I think its
a linking issue. I’ve tried it in two different
internet browsers and both show the same outcome.
Have you ever thought about writing an e-book or guest
authoring on other blogs? I have a blog based upon on the same ideas you discuss and
would love to have you share some stories/information. I know my viewers would value your work.
If you’re even remotely interested, feel free to shoot
me an email.