A couple of months ago, I found a DACL permissions overwrite vulnerability in the Check Point Endpoint Security VPN client. This vulnerability allows any user on a Windows system to set permissions for any file to Full Control for the Authenticated Users security group (the only limitation being that the SYSTEM user needs to have access to edit permissions on the file, so some system files owned by TrustedInstaller can not be overwritten).
The VPN client has two counterparts, a Windows service running as SYSTEM and a userland client running as current user. For this vulnerability, we don’t really need to interact with the serivce, other than restarting it. However, I did look at the communication between the user client and the service, and it’s an interesting type of custom-looking RPC protocol that is probably interesting to look at.
While I did find this vulnerability individually, I was not the first to report it to Check Point. The fixed version was released 16. april 2019.
Vulnerability Description
Upon the startup of the “Check Point Endpoint Security VPN” service it performs a reset on the permissions of all files under C:\Windows\Internet Logs. The permissions it sets are Full Control for Authenticated Users which means any user on the system has permission to write, read and modify those files. It also gives Full Control to the Internet Logs folder itself. This reset of permissions is performed regardless of the contents of Internet Logs and on all files in the folder, regardless of source.
Windows has the ability to create hard links. Briefly (and far from actually correct) explained, a hard link is a copy of another file where any performed on the copy is propagated to the original and vice versa. This means that if we have a hard link to a file, and we set permissions on the hard link, those permissions will also be the same on the original one. However, the built-in command line tool for this, mklink, requires that the user creating the hard link has write-access to the “original” file. James Forshaw from Google’s Project Zero actually found out that this is not a hard requirement. mklink uses the CreateHardlinkW API in Windows which enforces the write-check and then calls NtSetInformationFile if the user has write-access. But if we just use NtSetInformationFile directly, we can bypass this write-access enforcement. James Forshaw details in his post about this bypass that it is intended functionality in Windows, unless the running application is sandboxed.
This means that creating a hard link from C:\Windows\Internet Logs to any files that SYSTEM has permission to edit will reset those permissions to a state where any user on the system can overwrite it. This can lead to elevation of privileges from a standard user account.
Proof of Concept
First off, we need a file to overwrite that might give us elevated privileges. Looking through the task scheduler to see tasks running as SYSTEM is a good start.
The Google Update scheduled task is a great target, it runs as SYSTEM, runs at a predictable time (at any user log on) and the executable is modifiable and writable by SYSTEM.
Next we need to create a hard link from C:\Windows\Internet Logs to the Google Update executable. FuzzySecurity’s PowerShell-Suite has a handy PowerShell script for creating hard links using NtSetInformationFile directly; Native-HardLink. We import that script and create a hard link to the Google Update executable.
We’ll see the executable mirrored in both directories now.
Next, because standard user accounts cannot restart the Check Point services, we reboot the computer to induce a restart of the services. When booted up, we’ll see that the file permissions for GoogleUpdate.exe has updated and we can now overwrite its contents as a standard user.
I opted to replace the executable with a reverse shell, so we do that, log out and in again and we’ll get a shell with SYSTEM access.
