AnyDesk is a popular personal and enterprise software for remote administration distributed by AnyDesk Software GmbH. This post will dive into the vulnerability I found on AnyDesk mid of the year.
Last updated
The vulnerability is an Elevated Arbitrary File Read/Copy operation by the "AnyDesk" service as NT AUTHORITY\SYSTEM.
When initiating a new session, the AnyDesk service will copy the existing background image into C:\Windows\Temp\<targetimagefilename>. A session can be initiated to ourselves to trigger the bug on demand.
File Copy operation performed by the AnyDesk service as NT AUTHORITY\SYSTEM:
A few interesting notes we can write here:
A low privileged user on Windows can set its own background image, therefore we control the source of the file to be copied on demand.
The end file name in C:\Windows\Temp is the same as the initial background image file name.
Problem (not really, I'll explain just in a bit) - the source file is being copied to C:\Windows\Temp\, that means that the end file is going to be owned by NT AUTHORITY\SYSTEM, and since C:\Windows\Temp by default doesn't have read access for low-privileged users, the end file name will inherit the DACL and will be only allowed to be read by NT AUTHORITY\SYSTEM and the Administrators group.
So far we just almost have everything we need to copy an arbitrary file to C:\Windows\Temp and read it. We can control the source file name and location, and we know the target file name and location. We can't change the fact that it's going to be in C:\Windows\Temp. If that was the case it would have been a complete arbitrary file read/copy/write (which I have a few bugs of these waiting for public disclosure).
What if we change the file name, and pre-create an empty file with the same name in C:\Windows\Temp? Will it be overwritten and re-owned?
OK, setting the ground:
Now let's see what happens. Trigger bug (connect to your own ID):
Triggered! Looks like the file retains our ownership with the NEW data!
Seems like we got ourselves an Arbitrary File Read/Copy vulnerability!
By default, Windows systems are automatically creating a HarddiskVolumeShadowCopy (or in short - ShadowCopy), considering there's enough space on the device. This is called the Restore Point feature:
So now what we need to exploit this vulnerability for LPE is:
Pre-create the target file name in C:\Windows\Temp.
On trigger, set the directory of the background image as a junction (reparse mount point) to NT Object Manager Namespace (OMNS) \RPC Control or other writable OMNS directories such as \Sessions\<sessionID>\BaseNamedObjects, etc.
Create a DOS Device symlink from \RPC Control\<imagefilename> to \Device\HarddiskVolumeShadowCopy1\Windows\System32\CONFIG\SAM (/SYSTEM/SECURITY, respectively).
Copy target file from C:\Windows\Temp to a benign directory of choice to read it/preserve it.
After performing the above steps for the SAM, SYSTEM, SECURITY files, parse the files to retrieve local administrator/s credentials (SECURITY is essential for machine credentials, userKey, further more locally cached credentials, etc.).
Achieved administrative access.
DISCLOSURE TIMELINE
2024-07-24 - Vulnerability reported to vendor
2024-12-19 - Coordinated public release of advisory
2024-12-19 - Advisory Updated
CREDIT
Naor Hodorov
Vulnerability marked as CVE-2024-12754 && ZDI-24-1711
Special thanks for Trend Micro's Zero Day Initiative which encourages researchers to disclose vulnerabilities responsively.
Although there's no READ permissions for C:\Windows\Temp, a low-privileged user can WRITE to the directory.
We can query a ShadowCopy existence via WinAPIs as low-privileged users as well (a good public example here - using NtQueryDirectoryObject). It can also be manually viewed via WinObj:
Set an on the initial background image file name. The purpose is to trigger the CreateFile operation that leads to CopyFileW.
Disclosure URL:
