Both application services use a fixed path to look for specific files or
libraries. This path includes directories that may not be trusted or under
user control.

By placing a custom version of a library in the application path, the
program will load it before the legitimate version. This allows an attacker
to inject custom code that will be run with the privilege of the program or
user executing the program. The following libraries could be hijacked on
this way:

wgpr.dll

Since both services are running using the SYSTEM account, this may allow a
less privileged user to gain access to SYSTEM privileges. A local attacker
or compromised process is able to put a malicious application library into
the directory which will be executed after a service restart.

On a default installation (%programfiles%\Watchguard) of the Watchguard
Server Center on Windows Vista and above the directory permissions disallow
an low-privileged attacker to mount the attack.

On a default installation (%programfiles%\Watchguard) of the Watchguard
Server Center on Windows XP, the attacker needs to have at least Power User
rights to successfully mount the attack.

On a non-default installation of the Watchguard Server Center to a
directory, which is writeable by a low-privileged user, the attack can be
mounted successfully without any restrictions.

5. DEBUG INFORMATION
--------------------
The vulnerable code part of wlcollector.exe:

6. PROOF-OF-CONCEPT (CODE / EXPLOIT)
------------------------------------
Use the following code to exploit the vulnerability:

#include <windows.h>

#define DLL_EXPORT __declspec(dllexport)

#ifdef __cplusplus
extern "C"
{
#endif

void DLL_EXPORT wgpr_library_get()
{
WinExec("calc",0);
}

#ifdef __cplusplus
}
#endif

6. SOLUTION
-----------
Administrators who installed the Watchguard Server Center on WinXP or
outside the default installation folder, should harden the directories
permissions (administrative write permissions only) on the mentioned
folders to lower the attack risk.

7. REPORT TIMELINE
------------------
2013-07-29: Discovery of the vulnerability
2013-07-30: RCE Security sends first notification to Customer Care via mail
with disclosure date set to 13. August 2013
2013-08-05: RCE Security sends second notification using Twitter
2013-08-05: Response from vendor
2013-08-05: RCE Security sends vulnerability details to vendor
2013-08-05: Vendor ACKs the issue and asks for an extension of 30 days
2013-08-06: New disclosure date set to 13. September 2013
2013-08-06: Vendor assigns bug id #75251
2013-08-19: No further status updates received according to disclosure
policy, asking for status update
2013-08-19: Vendor estimates the risk of the issue as "extremely limited",
and therefor ACKs the public disclosure
2013-08-28: Vendor plans to release the fix with the next major release in
around Q4
2013-09-05: MITRE assigns CVE-2013-5701 for this issue
2013-09-08: Full Disclosure