Lucene search

K
attackerkbAttackerKBAKB:AF37CD6E-8730-4AEF-8679-0413B491A107
HistoryMar 12, 2020 - 12:00 a.m.

CVE-2020-0787 Windows BITS Privesc

2020-03-1200:00:00
attackerkb.com
396

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

7.2 High

CVSS2

Access Vector

LOCAL

Access 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

0.007 Low

EPSS

Percentile

78.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&gt;. 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/&gt; and the PoC at <https://github.com/itm4n/BitsArbitraryFileMove&gt;. 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/&gt; 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/&gt; 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&gt;. 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/&gt; and <https://itm4n.github.io/usodllloader-part2/&gt;. 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/&gt;, 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&gt;. 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/&gt; and the PoC at <https://github.com/itm4n/BitsArbitraryFileMove&gt;. 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/&gt; 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/&gt; 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&gt;. 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/&gt; and <https://itm4n.github.io/usodllloader-part2/&gt;. 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/&gt;, 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&gt;. 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/&gt; and the PoC at <https://github.com/itm4n/BitsArbitraryFileMove&gt;. 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/&gt; 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/&gt; 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&gt;. 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/&gt; and <https://itm4n.github.io/usodllloader-part2/&gt;. 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/&gt;, 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.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

7.2 High

CVSS2

Access Vector

LOCAL

Access 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

0.007 Low

EPSS

Percentile

78.4%

Related for AKB:AF37CD6E-8730-4AEF-8679-0413B491A107