2023-11-20

Security Disclosure of Vulnerabilities: CVE-2023-45252 and CVE-2023-45253

This article provides technical descriptions of two vulnerabilities that allowed for local privilege escalation in HuddlyCameraService. During a previous assessment, these vulnerabilities helped to escalate privileges from regular user to SYSTEM, establish command and control (C2), evade the installed EDR by DLL sideloading a non-Microsoft binary, and install persistence on the host since the service started on system boot.

The first vulnerability, CVE-2023-45252, enabled privilege escalation due to the service being installed in a directory that grants write privileges to regular users. The second vulnerability, which was identified as CVE-2023-45253, enabled local privilege escalation through a privileged file operation executed by the service under the SYSTEM user context.

The vulnerabilities were reported on August 10, 2023, and Huddly promptly addressed them by releasing a fix on September 21, 2023. The solution to resolve these vulnerabilities involves upgrading to version 8.0.7 of the program, officially released on September 21, 2023. Our team has thoroughly tested this patch, and it has effectively rectified the issues.

Official release notes and security advisory can be found at this Huddly support page.

Privilege Escalation via Insecure Installation Directory (CVE-2023-45252)

The first vulnerability, identified as CVE-2023-45252, enabled privilege escalation due to the service being installed in a directory that grants write privileges to regular users, affecting version <8.0.7 of Huddly’s Camera Windows software.

Identification and Exploitation

By using Microsoft's Process Monitor (ProcMon), which can be used to analyze and monitor file operations on a Windows system, it was found that the HuddlyCameraService.exe file was executed as NT AUTHORITY\SYSTEM from the C:\Windows\Temp\.net\HuddlyCameraService folder, as highlighted in Figure 1. Additionally, the process attempted to load missing dynamic-link library (DLL) files from the same folder.

Figure 1 - Process attempting to load missing DLLs

Figure 1 - Process attempting to load missing DLLs.

Due to regular users having write permissions in C:\Windows\Temp\.net\HuddlyCameraService, which contains permissions inherited from C:\Windows\Temp, the service was susceptible to a local privilege escalation attack that could be exploited through a DLL hijacking attack. The permission inheritance is demonstrated in Figure 2 and Figure 3.

Figure 2 - Permissions

Figure 2 - Permissions for C:\Windows\Temp.

Figure 3 - Permissions for C:\Windows\Temp\.net\HuddlyCameraService.

To exploit the vulnerability, an adversary could drop a payload as one of the missing DLLs into C:\Windows\Temp\.net\HuddlyCameraService\IQQF1G9DDW8qNL0XgxzvxAVCQLDvvYE=, and then reboot the machine. This often works because Windows uses a pre-defined search path to find DLL, which searches in a specific order.

Arbitrary File Write Leading to Privilege Escalation (CVE-2023-45253)

The second vulnerability, identified as CVE-2023-45253, enabled local privilege escalation through a privileged file operation executed by the service under the SYSTEM user context

This vulnerability affects version <8.0.7 of Huddly’s Camera Windows software.

Identification

When the log4net library performs a rollover via the RollingFileAppender class (an Appender that rolls log files based on size or date or both), and if the maximum number of size backups is reached (set with maxSizeRollBackups), then the oldest file is deleted, as can be seen in Figure 4.

RollOverRenameFiles

Figure 4 - DeleteFile when maxSizeRollBackups is reached.

The DeleteFile method will delete a file if it exists. Figure 5 shows that a new filename is generated, containing a tick count, which is the number of milliseconds elapsed since the system started. Then, the file is first moved to a new filename and then deleted. This allows the file to be removed even when it cannot be deleted, but it still can be moved.

DeleteFile

Figure 5 - DeleteFile generates a new name and moves/renames the file.

By following the call chain for System.IO.File.Move, it ends up calling Kernel32$MoveFileEx. This is where the flaw is - the service does never attempt to impersonate the user but performs all actions in the context of NT AUTHORITY\SYSTEM. Therefore, the file move operation is done on a file that unprivileged users can manipulate in the context of NT AUTHORITY\SYSTEM. If files are moved from C:\ProgramData\Huddly\Logs\ to, for example, C:\Program Files\Huddly, then the file moved to the new location will have access rights inherited from the old location, as demonstrated in Figure 6.

Figure 6 - Inherited access rights on FakeDll.dll after successful exploitation.

By using Microsoft's Process Monitor (ProcMon), the file operations performed by the HuddlyCameraService can be seen, as shown in Figure 7.

Figure 7 - ProcMon shows the file operations performed by the Huddly service.

The SetRenameInformationFile call originates from the Win32 MoveFileEx() function. Further inspecting the operation showed that it did not impersonate the user but was executed as NT AUTHORITY\SYSTEM, as demonstrated in Figure 8. If the application did impersonate the user, it would have included Impersonating: <domain>\<username> in the Event Properties.

Figure 8 - No impersonation is being performed by the service.

The arbitrary file move as SYSTEM results in a Local Privilege Escalation. To exploit the vulnerability, an adversary could drop a payload as one of the missing DLLs into C:\Windows\Temp\.net\HuddlyCameraService\IQQF1G9DDW8qNL0XgxzvxAVCQLDvvYE=, as shown in Figure 9. After rebooting the machine, the malicious code would be executed as SYSTEM. There are also multiple other ways to escalate privileges with the ability to move files as SYSTEM.

Figure 9 - Paths that resulted in NAME NOT FOUND.

Exploitation

When the service creates test.5.log, the service will soon open the file again to be moved/renamed. There is a short time between the file creation and the file move operation, where the attacker can modify the behavior of the file move. The exploit code will place an Opportunistic Lock (Oplock) on the test.5.log after the service creates it because this will allow the attacker to block file operations on a given file for as long as they choose to hold the lock, making it easier to win the race. The attacker cannot perform any operations on the file while the Oplock is there. However, the attacker can achieve what they want by creating Object Manager symbolic links.

Therefore, the strategy to exploit this flaw is configuring the logging with a maximum file size of 0 and setting the log folder to a folder initially used as a junction point to another "physical" directory. Then, when the service is started, it will write the logs into the junction and store them inside the other physical folder. When this is done, we can continue to phase 2 of the exploit.

Phase 2 of the exploit will attempt to open test.log.5. When it successfully opens the file, it will place an Oplock on the file. When the Oplock is triggered, the exploit code generates a new filename with the tick count, switches the mountpoint to an Object Directory, and creates two symbolic links. The test.log.5 file will point to a file owned by the attacker, and the test.log.5.TickCount.DeletePending file will point to where the attacker wants to write, for example, C:\Program Files\Huddly\FakeDll.dll. After releasing the Oplock, the service will perform the final move operation through the two symbolic links. These steps are described in more detail below.

Prepare the workspace and log4net configuration

Create the workspace directory with the following structure:

C:\ProgramData\Huddly\Logs\workspace

|__ <DIR> bait

|__ <DIR> mountpoint

|__ FakeDll.dll

The mountpoint directory will first be a junction to the bait directory, then switched to a junction to the RPC Control Object Directory. The DLL file is the file to be moved to a secure location such as C:\Program Files\Huddly\.

Additionally, as shown in Figure 10, the log4net configuration file will be updated to write into the mountpoint directory, and the maximumFileSize will be set to 0. The maxSizeRollBackups decide how many backup files there will be. The default was five, which is why we will be looking for test.log.5.

Figure 10 - log4net configured for exploitation.

Create the mountpoint from mountpoint to bait

C:\ProgramData\Huddly\Logs\workspace\mountpoint -> C:\ProgramData\Huddly\Logs\workspace\bait

Start the service / reboot the machine

The logs will be written to C:\ProgramData\Huddly\Logs\workspace\bait\test.log because of the junction created.

Start phase 2 – Find the test.log.5 file and set an Oplock

This phase will attempt to race the log4net rollover function. The exploit code enters a loop that will attempt to open the test.log.5 file. When the file open is successful, an Oplock will be placed on it, which helps win the race by allowing us to pause the operation.

Wait for the Oplock

The Oplock will be triggered when log4net in the service opens the test.log.5. When the Oplock is triggered, the exploit generates the new file name, switches the mountpoint, and creates two symbolic links.

Before the switch:

C:\ProgramData\Huddly\Logs\workspace\mountpoint -> bait

test.5.log = C:\ProgramData\Huddly\Logs\workspace\mountpoint\test.5.log -> C:\ProgramData\Huddly\Logs\workspace\bait\test.5.log

After the switch:

C:\ProgramData\Huddly\Logs\workspace\mountpoint -> \RPC Control

test.5.log = C:\ProgramData\Huddly\Logs\workspace\mountpoint\test.5.log -> C:\ProgramData\Huddly\Logs\workspace\FakeDll.dll

C:\ProgramData\Huddly\Logs\workspace\test.5.log.<TickCount>.DeletePending = C:\Program Files\Huddly\FakeDll.dll

Release the Oplock

Upon Oplock release, the final MoveFileEx() call redirection will occur due to the symbolic links. Consequently, the DLL will be moved to the C:\Program Files\Huddly folder.

Figure 11 shows the important parts of the Proof of Concept code used to exploit the vulnerability.

exploit_code-2

Figure 11 - Proof of concept code to exploit the vulnerability.

After a short time, the race is won, and the FakeDll.dll was placed inside C:\Program Files\Huddly with inherited access rights from C:\ProgramData\Huddly\Logs, as was demonstrated in Figure 6 earlier.

Disclosure Timeline

2023-08-07 – Identified the vulnerabilities
2023-08-10 – Vulnerabilities reported to Huddly
2023-08-28 – Huddly verified vulnerabilities
2023-09-21 –Patch available
2023-10-23 - Verified the effectiveness of the patch
2023-11-20 - Released the full disclosure of the vulnerabilities

Acknowledgment

I want to thank Huddly and everyone involved with the patch for these vulnerabilities. They were kind and demonstrated a collaborative spirit, making them easy to work with.

Article written by: Henrik Pedersen, XLENT Cyber Security Norway