Wrote the Metasploit module for this vulnerability which is currently sitting as a PR at https://github.com/rapid7/metasploit-framework/pull/13554. Let me start with an overview of this vulnerability and then explain why I believe this vulnerability is more valuable than it may initially appear to be.

First off, as mentioned in other reviews of this bug, you can find the original writeup at https://itm4n.github.io/cve-2020-0787-windows-bits-eop/ and the PoC at https://github.com/itm4n/BitsArbitraryFileMove. As described in the blog, the BITS service exposes the Legacy Control Class over COM. An attacker can use this to obtain a pointer to the IBackgroundCopyGroup interface, which contains two undocumented methods, QueryJobInterface() and SetNotificationPointer(). By calling the QueryJobInterface() method of the IBackgroundCopyGroup method, the attacker will get a handle to the new IBackgroundCopyJob interface.

The problem here is that the handle to the IBackgroundCopyJob group is done without proper impersonation. Normally this would not be an issue since the other methods implement impersonation properly. However there is a catch. When adding a new job using the IBackgroundCopyJob interface that was returned via the method described earlier, the temporary file that BITS creates when creating a new job will be renamed via a call to MoveFileEx() with the permissions of the IBackgroundCopyJob interface. Well since BITS runs as SYSTEM and the IBackgroundCopyJob interface didn’t implement impersonation, guess what? Its going to copy the file as the SYSTEM user.

Exploitation of this vulnerability is not the most difficult in the world but it basically relies on the following process (described in https://itm4n.github.io/cve-2020-0787-windows-bits-eop/ way better than I can explain it here, but heck I’ll give it a shot):

1. Set up a temporary directory that will be our staging area and create two folders: Bait and MountPoint inside of it.
   
2. Upload the payload DLL within this temporary directory.
   
3. Create a symbolic link between MountPoint and Bait.
   
4. Create a new job using the IBackgroundCopyJob interface, whose handle is obtained by calling the QueryJobInterface() method of the IBackgroundCopyGroup interface,
   
5. Since the BITS job will be created in a suspended state, locate the temporary BITS job file, and set a file oplock on it so that our function will be called whenever someone tries to move the file.
   
6. Resume the BITS job
   
7. Our oplock gets hit. Delete the previous symbolic link, and create a symbolic link between the MountPoint directory and \RPC Control\. Create two more symbolic links to link the temporary BITS file within the MountPoint directory to the DLL we want to copy, and the sample test.txt file we were going to the file to so that it instead points to the protected location we would like the file to be copied to.
   
8. Release the oplock, and profit!
   

Again its probably better you look at the How to Exploit this Vulnerability? section of https://itm4n.github.io/cve-2020-0787-windows-bits-eop/ for a better explanation of this, he words it much better than I do.

With this aside though the next important thing to note is that BITS was introduced with Windows 7, which is reflected in the affected systems listed at https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0787. Looking over this list we can see that every single version of Windows, be it Server or Workstation, is affected by this vulnerability, regardless of architecture.

In fact further examination of this bug revealed that with the PoC provided, one can very reliably obtain SYSTEM level file copies on nearly any affected machine with no interruption to its service at all. The only downside though is that SYSTEM level file copies alone are not enough to get LPE. To do this an attacker needs to combine this vulnerability with a DLL hijacking vulnerability or some other vulnerability where the placement of an arbitrary file into a protected location would grant the attacker additional privileges.

In the case of the PoC and the Metasploit module, this is achieved by taking advantage of a bug in the Windows Update Session Orchestrator service, which is well documented at https://itm4n.github.io/usodllloader-part1/ and https://itm4n.github.io/usodllloader-part2/. In a nutshell, an attacker can gain SYSTEM level code execution if they can create the file C:\Windows\System32\WindowsCoreDeviceInfo.dll and then run the undocumented command usoclient StartScan or usoclient StartInteractiveScan. Note that since the Update Session Orchestrator service only exists on Windows 10 and later, it is only possible to use this technique on those computers. With this being said though other techniques could be used to gain LPE on other Windows systems, it is just a matter of creativity.

This means that in essence, any Windows system that has not applied the March 2020 updates has a pretty universally accessible arbitrary file copy vulnerability provided that an attacker already has local access to the system. The only other limitation is the aforementioned DLL hijacking issue; however should an attacker account for this via vulnerabilities such as the NetMan DLL hijacking issue described at https://itm4n.github.io/windows-server-netman-dll-hijacking/, which affects all Windows Server editions from Windows Server 2008 R2 to Windows Server 2019, they could easily adjust this vulnerability to escalate privileges on a wide variety of systems.

In summary this is one to look out for and I can see this being weaponized in the future, however attackers will need a little bit of work to get a DLL hijacking bug working for each target they want to compromise (not that hard given that Microsoft doesn’t consider DLL hijacking issues a bug and tends not to patch them), and the fact that they need local access (the main limiting factor here).

This is another of the recent junction-dependent local privilege exploits that rely on tricking a trusted process to move a payload to a trusted location to be executed by a (possibly other) trusted process. These particular exploits work because many of the trusted binaries fail to evaluate symlinks prior to file moves. This particular exploit is slightly more difficult, as the timing for it is trickier than some of the other exploits in this style.
This particular exploit relies on the Background intelligent Transfer Service (BITS), a trusted service used for uploading and downloading files. BITS is a powerful service that downloads files and can pause, or adjust download speeds based on network state. To do so, it first downloads files to a temporary location and then moves them to the final location when the download is complete. In this case, the service impersonates the user who called it when creating the temporary file, but not on the final move.
To trigger this vulnerability, an attacker must call the BITS service to download a file to a location that represents a symlink to another area of the filesystem. While BITS is downloading to the temporary location, the attacker must insert a mountpoint and symlink to redirect future file queries for the temporary destination to a malicious file (typically a DLL) and for the final location to redirect to a trusted location (for example C:\windows\system32). BITS will then continue to write tot he original file, but when it completes the task, it performs the final copy not as the user who called it, but as SYSTEM. That means when the move is called, the attacker has changed the symlink to the temporary file to now point to the malicious file, and the destination directory now redirects to a trusted directory. When the final move is called, the malicious file is moved to the trusted location as SYSTEM. It the remains the attacker’s task to find something to execute the malicious file. There are several was to achieve that goal, as multiple trusted processes will blindly load dll files from the system32 directory. In the PoC I’m looking at now (https://itm4n.github.io/cve-2020-0787-windows-bits-eop/), the overwrite targets WindowsCoreDeviceInfo.dll, which is loaded by the Windows Session Orchestrator service into a system-privileged process, but other options exist.
Given the race conditions and junctions required, this is not a particularly easy exploit to develop, but PoCs exist, so defenders should be aware of the technique.
Basic mitigations might start with something as simple as checking for any strings shared with James Foreshaw’s symbolic link testing tools (https://github.com/googleprojectzero/symboliclink-testing-tools); the advantage being that it would trigger on many of the basic PoCs for this class of vulnerability as they import these libraries during compilation, and leave in the diagnostic strings. Further mitigations might be to monitor filesystems for the creation of junctions or symlinks to trusted locations.

An elevation of privilege vulnerability exists when the Windows Background Intelligent Transfer Service (BITS) improperly handles symbolic links. An attacker who successfully exploited this vulnerability could overwrite a targeted file leading to an elevated status.

To exploit this vulnerability, an attacker would first have to log on to the system. An attacker could then run a specially crafted application that could exploit the vulnerability and take control of an affected system.

The security update addresses the vulnerability by correcting how Windows BITS handles symbolic links.

Technical details can be found: https://itm4n.github.io/cve-2020-0787-windows-bits-eop/