Hey foip, That’s an interesting find there. Good job reversing the hashing algorithm. However, I wanted to clarify a few things here that I didn’t think you really covered. First, let’s be clear. The hashes/users you found in the configuration file are NOT the credentials to manage the security appliance.

Sep 23, 2013 - Watchguard Firewall appliances offer the ability to manage policies per user. The function simply converts the password to UTF-16 (in this case. Next, in order for an attacker to even attempt to crack passwords, he'd have. CDW•G Software Solutions Free Cybersecurity Insight Report. WatchGuard develops multifunction security solutions that combine industry standard hardware, security features and policy-based management tools. It provides you with a suite of tools to identify key security issues and trends and helps you set up.

We do not store the management credentials for our appliance in the config file. The credentials you found are part of the optional local FireboxDB authentication feature, and I assume the user called “superuser” was one you made. Our devices offer the ability for users to create policies (firewall, IPS, and application control policies) by username, not just by IP. To do this you have to setup authentication.

In most installations, users choose to get our appliance to authenticate with their internal Active Directory, LDAP, or Radius server, in which case the login details are all stored on that authentication server (not in the config file). However, we also offer the local FireboxDB database, for small customers that don’t already have authentication servers. The users you manually setup in this local Firebox database are just users you can use in your policy creation. They do NOT have any privileged access to manage the security appliance itself.

So the “superuser” in your example is not a user with superuser privileges on the XTM appliance itself. Rather it’s some user you created that you can set specific access policies for through the XTM appliance. Next, in order for an attacker to even attempt to crack passwords, he’d have to get the hashes.

These are stored in the full configuration file for the XTM security appliance, which already contains all the security policies and IP addresses for your network. This is a sensitive file that you’d obviously want to protect, and would typically be found on an administrator machine in your network. If an attacker already had access to the administrative machine that has your security appliance configuration files, you already have big problems. Autocad draw polyline vba emulator. Finally, hashing algorithms (other than the salt) are often public. It’s not the algorithm that needs to be protected it’s the hashes. Sure knowing what hashing algorithm is used means you can attempt to bruteforce hashes, but that applies to any hashing algorithm, and they we designed to be public standards.

This is why you should protect hashes and also why you should apply password best practices. If you use long ( I recommend at least 12 characters), semi-random passwords, it would still take a long time to crack.