Hello readers,
this is my first article in a series about vulnerabilities in Watchguard products. Watchguard is a self-proclaimed NextGen Security vendor building security appliances for complete network protection. As I am working with Watchguard products for around 2 years now, I have to say that their firewall products are useable – especially if you’re looking for a fast-to-implement and low-priced network security solution, but if you’re looking for more, I would rather implement a comprehensive Juniper solution.
The vulnerability “Watchguard Server Center v11.7.4 wgpr.dll Insecure Library Loading Local Privilege Escalation Vulnerability” is filed under CVE-2013-5701 and is a potential 0-Day threat to all customers who are using the Watchguard Server Center.
The CVE describes a classic privileges escalation vulnerability due to an insecure library loading issue in two different modules of the Server Center:
- Watchguard Log Collector
- Watchguard WebBlocker Server
What’s the problem ?
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 privileges of the program or user executing the program.
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.
What happens if an attacker is able to exploit this vulnerability?
This basically means running calc.exe as SYSTEM 😉 :
How can the vulnerability be exploited ?
The wlcollector.exe (same for the wbserver.exe) tries to load the file “wgpr.dll” from the application directory where both files can usually be found. The real wgpr.dll is located directly in the “wsm11” directory. This means the application stops searching for the original if it finds a same-looking in the application “bin” directory.
To make the exploit library look like the real library, it’s important to spoof the entry – point or at least one export. So when following the application flow, the string “wgpr_library_get” is PUSH’ed onto the stack and then used in a kernel32.GetProcAddress call. That’s it.
Now that we know the name of at least one function from the wgpr.dll, we are able to create our own arbitrary library:
#include
#define DLL_EXPORT __declspec(dllexport)
#ifdef __cplusplus
extern "C"
{
#endif
void DLL_EXPORT wgpr_library_get()
{
WinExec("calc",0);
}
#ifdef __cplusplus
}
#endif
This code snippet simply creates the “wgpr_library_get” export and its only task is to launch calc.exe – as SYSTEM :-). Copying this library to the bin directory allows executing of everything you may imagine – and can be semi-automated using Metasploit.
Any limitations and/or mitigations?
Not all installations of the Server Center are vulnerable – this highly depends on the directory where the administrator installed the software:
- 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
The logical conclusion: To make sure this vulnerability isn’t used in a privileges escalation scenario, you only need to harden the directory permissions to make it impossible for low-privileged users to write own files into the bin/ directory.
Some last words (criticism) about the disclosure – process.
The disclosure process started like with every other advisory, I’ve coordinated: You’re looking for some way of contacting the vendor. But what if the vendor does not provide a useful address ? Contacting using some info@ or POST-forms is most of the time useless, because they are (but ony if they are) read by the wrong people.
Watchguard in this case did not provide a dedicated address to report security vulnerabilities. No support@, no security@ addresses were available, which results in missing RFC2142, although they assure that they are closely working with 3rd party security researchers.
Fine, but how did those “security researchers” report their issues ? Well – thanks to myself – they have a security mail address including a gpg key from now on 🙂
Finally…now just think about the fact that we’re talking about a security vendor here.