7.2 High
CVSS2
Attack Vector
LOCAL
Attack Complexity
LOW
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:L/AC:L/Au:N/C:C/I:C/A:C
7.8 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
0.011 Low
EPSS
Percentile
84.4%
An elevation of privilege vulnerability exists when the Windows Background Intelligent Transfer Service (BITS) improperly handles symbolic links, aka ‘Windows Background Intelligent Transfer Service Elevation of Privilege Vulnerability’.
Recent assessments:
gwillcox-r7 at June 10, 2020 2:20am UTC reported:
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):
Set up a temporary directory that will be our staging area and create two folders: Bait and MountPoint inside of it.
Upload the payload DLL within this temporary directory.
Create a symbolic link between MountPoint and Bait.
Create a new job using the IBackgroundCopyJob
interface, whose handle is obtained by calling the QueryJobInterface()
method of the IBackgroundCopyGroup
interface,
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.
Resume the BITS job
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.
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).
bwatters-r7 at March 20, 2020 4:00pm UTC reported:
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):
Set up a temporary directory that will be our staging area and create two folders: Bait and MountPoint inside of it.
Upload the payload DLL within this temporary directory.
Create a symbolic link between MountPoint and Bait.
Create a new job using the IBackgroundCopyJob
interface, whose handle is obtained by calling the QueryJobInterface()
method of the IBackgroundCopyGroup
interface,
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.
Resume the BITS job
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.
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).
xFreed0m at March 12, 2020 5:28pm UTC reported:
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):
Set up a temporary directory that will be our staging area and create two folders: Bait and MountPoint inside of it.
Upload the payload DLL within this temporary directory.
Create a symbolic link between MountPoint and Bait.
Create a new job using the IBackgroundCopyJob
interface, whose handle is obtained by calling the QueryJobInterface()
method of the IBackgroundCopyGroup
interface,
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.
Resume the BITS job
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.
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).
Assessed Attacker Value: 3
Assessed Attacker Value: 3Assessed Attacker Value: 3
7.2 High
CVSS2
Attack Vector
LOCAL
Attack Complexity
LOW
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:L/AC:L/Au:N/C:C/I:C/A:C
7.8 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
0.011 Low
EPSS
Percentile
84.4%