Severity: Low
Summary:
- This vulnerability affects: WatchGuard System Manager (WSM) Server Software.
- How an attacker exploits it: By placing a specially crafted DLL into a specific WatchGuard path
- Impact: When you install WSM into a non-hardened, non-default directory, local users can execute code on your Windows computer with SYSTEM privileges (see mitigating factors below)
- What to do: If you install WSM in a non-default location, or use XP, change the directory permissions of the WatchGuard folder
Exposure:
This week, Julien Ahrens of RCE Security disclosed a local elevation of privilege vulnerability that affects the Server Software portion of WatchGuard System Manager (WSM) 11.7.4 and below. Ahrens responsibly informed us of the flaw a month before his disclosure, and had our blessing to post his findings.
Specifically, the flaw is an insecure library loading vulnerability involving two services installed as part of our Server Software package; our Log Collector and WebBlocker services. These services run with SYSTEM privileges, and load certain libraries and DLLs found in WSM’s default install directory (typically %program files%/WatchGuard/wsm11). By placing a specially crafted version of a DLL file our services look for into one of WSM’s directories, a local, authenticated attacker could exploit this flaw to execute arbitrary code with SYSTEM privileges.
However, there are many mitigating factors that significantly lessen the severity of this vulnerability.
First, in order to exploit this flaw the attacking user must have the permissions necessary to access WatchGuard’s WSM directories. By default, our installer sets restrictive permissions to these folders, but the permissions differ depending on your version of Windows:
- If you install WSM in the default location on Windows Vista, 7, 8, Server 2008 and 2012 computers, only users with administrative privileges can access the WSM directories, making this issue moot.
- However, if you install WSM on Windows XP, Server 2000 and 2003 computers, we also allow the Windows Power User group to access the WatchGuard folders. That said, the Power User is already a fairly privileged user. Though still a vulnerability, a Power User => SYSTEM elevation of privilege is less severe.
- Finally, there is one case of most concern. If you install WSM on Windows Vista, 7, 8, Server 2008 and 2012 computers in a non-default location, we do not change the permissions of the folder you choose. So if you install into a folder a guest could access, this becomes a guest => SYSTEM elevation of privilege.
In other words, if you install in default locations on Windows Vista and above, you are not vulnerable to this flaw. If you use older versions of Windows, this is only a slight elevation of privilege flaw. Only when you purposely decide to install the product into a non-hardened directory does this become a more significant issue.
Also, don’t forget the normal mitigating factors associated with local vulnerabilities. In order to exploit this issue, an attacker would already need local access to the Windows computer you use for management, and he’d need credentials to log into the machine. Normal security best practices suggest that you are already protecting the machine you use to manage your security appliance, and restricting access to it in many ways. If an attacker already has local access to your management computer, you already have a big problem.
Finally, remember that this flaw only allows the attacker to elevate his privilege on your Windows computer. It does not give him access to your WatchGuard management console, nor your XTM security appliance, both of which require separate authentication.
In short, though we take all vulnerabilities in our product seriously, and do plan on fixing this one, we think it poses a very low risk in the real world. Furthermore, the simple workaround below will totally alleviate the issue.
We’d like to thank Julien Ahrens and RCE Security for bringing this matter to our attention, and following a responsible disclosure path. If you’d like to learn more detail about this flaw, including Ahrens’ technical discussion, see this Full Disclosure post or his blog post.
Solution Path:
Though we have not patched this flaw yet, a simple workaround can protect you from this issue. If you are concerned with this issue, simply hardening the directory permissions of your WatchGuard WSM folders will protect you. Here’s how:
- If you’re using a modern version of Windows, like Vista and above, and you’ve installed WSM in the default location, you’re already safe
- If you’re using an older version of Windows, like XP, change the folder permissions of the %program files%/WatchGuard folder to reflect the users and groups you trust. To do so, right-click on the folder and choose Properties=>Security tab and remove the write permissions for any users or groups you don’t want to have access, such as the Power User group. We recommend you limit write access to administrator users.
- Finally, if you are using a modern version of Windows, like Vista and above, and you’ve installed WSM in the non-default location, you should also change the folder permissions of the %install dir%/WatchGuard folder to reflect the users and groups you trust, using the same directions mentioned above.
We plan on releasing a fix for the flaw in the version of WSM that immediately follows the one coming out shortly (the next release is currently in QA “code lock” status, so is not a candidate for the fix).
FAQ:
Are any of WatchGuard’s other products affected?
No. This only affects the Server Software that ships with WSM 11.7.4 and below.
What exactly is the vulnerability?
This is a local elevation of privilege vulnerability. If an attacker can gain physical (or remote desktop) access to your WatchGuard management computer, she may be able to exploit this flaw to execute code on the computer with SYSTEM privileges. However, whether or not the attacker can leverage the flaw depends on how you installed WSM, and what version of Windows you use. If you install using our defaults, you’re either not vulnerable to the issue, or the elevation is only from Power User to SYSTEM.
Does this give attackers access to my XTM security appliance?
No. This flaw only potentially allows a local user to elevate their Windows privileges. It does not give attackers any access to your management console or security appliance. That requires separate credentials.
How serious is the vulnerability?
In our opinion, this is a minor vulnerability, especially if you install WSM using our defaults. We believe most of our customers follow security best practices, and significantly restrict access to their WatchGuard management station.
Other than the workaround, when will you release an update to fix this?
We plan on fixing this issue in the release immediately following the next one. We are due to ship our latest version of WSM shortly, and it’s currently in a code lock status for QA, so we haven’t been able to work the fix into that release. Regardless, the simple workaround above—hardening your WatchGuard folder—will completely alleviate the issue.
How was this vulnerability discovered?
This flaw was discovered by Julien Ahrens of RCE Security, and confidentially reported to WatchGuard through a very responsible disclosure process. We thank Mr. Ahrens for working with us to keep our customers secure.
Do you have any indication that this vulnerability is being exploited in the wild?
No, at this time we have no indication that these vulnerabilities are being exploited in the wild, nor do we believe them likely to be in the future. In fact, we believe this flaw poses a very limited risk in the real world, due to its many mitigating factors.
Who can I contact at WatchGuard if I have more questions?
If you have further questions about this issue, or any other security concerns with WatchGuard products, please contact:
Corey Nachreiner, CISSP.
Director of Security Strategy and Research
WatchGuard Technologies, Inc.
http://www.watchguard.com
corey.nachreiner@watchguard.com