DP API encryption ineffective in Windows containers: Publicly Available Cryptographic Keys (CVE-2021-1645)

We recently discovered a vulnerability in the DP API key management of Windows containers. This vulnerability was assigned CVE-2021-1645 by Microsoft [1] and allowed attackers to decrypt any data that was encrypted with DP API keys in Windows containers.

This vulnerability was discovered in close cooperation with SignPath [2].

Introduction

Windows containers is a feature that extends the container concept well-known from Linux environments to Windows. Just like containers on Linux, Windows containers utilize a shared kernel but container processes are somewhat isolated from one another.

The Windows Data Protection API (DP API) allows applications to encrypt arbitrary data. An application does not have to manage keys, but instead, any data can be passed to the API, which then returns an encrypted blob. Similarly, an application can pass a previously encrypted blob to DP API to retrieve the plain text. The cryptographic key used for these encryption operations is either tied to the user context or is unique to a machine (please refer to [3] or [4] for more details).

The vulnerability

CVE-2021-1645 applies to both, user and machine key DP API encryption within Windows Docker containers. In our explanation and PoC, we will use machine key encryption, but the same issue exists if data is encrypted with the user-key.

Normally, a machine key is tied to a (virtual-)machine. Therefore, machine B is not able to decrypt data encrypted by an application on machine A. However, Microsoft apparently did not sufficiently consider this behavior when designing Windows containers. As a result, DP API machine keys used in containers came from the container images. Since Windows docker images usually share the same base images, the DP API keys of containers were identical. As the base images are public, the DP API keys were public too!

Therefore, DP API operations performed by any Windows container application were ineffective, as the encryption key that was used is public. Organizations that used the DP API in Windows Docker containers and relied on it to store encrypted data in a potentially insecure location, should consider this data as compromised.

Proof of concept

The following section demonstrates that any data encrypted by a container application can be decrypted in any other container. The test setup utilized two virtual machines (VM1, VM2) generated from the Azure VM template “Windows Server 2019 Datacenter with Containers- Gen2”.

Note: Microsoft patched images in their Dockerhub repository. To reproduce this scenario, an old image version is required.

First, start a docker container called Alice on VM1:

docker run --name Alice -it mcr.microsoft.com/dotnet/framework/runtime:4.8-windowsservercore-ltsc2019 cmd.exe

Then, encrypt a file in the Alice container using the powershell script vault.ps [5]:

C:>powershell.exe -File vault.ps1 -StoreSecret "This is my secret text" secret.txt

C:>type secret.txt
AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAm+1a2TNbiEahEIB4y/C3vQAAAAACAAAAAAAQZgAAAAEAACAAAAAdbJ9ZanY929j39ZLgabsaE5hRS4TLkCaaaRqb
+n3ZXAAAAAAOgAAAAAIAACAAAAC7fHbsKHCTaMhsWIVMYwUZezbLozItcqExHdg9EJcfDiAAAABFv2EHA5TTqb8I9I+BZrfQS5ViD93KZlL4FoYIBldGY0AA
AABdx7adlANRnw1shJTOtE6cYTAeqmb1yTe9adcSY1nBvtqlqSWQ/zwGaqfIfumuUm+o+ySwZXH/Su5GovJ8aUP9

Start a docker container Bob on VM2:

docker run --name Bob -it mcr.microsoft.com/dotnet/framework/runtime:4.8-windowsservercore-ltsc2019 cmd.exe

The following command shows that the file encrypted by Alice on VM1 can be decrypted in the Bob container on VM2:

C:>powershell.exe -File vault.ps1 secret.txt
This is my secret text

The fix

Microsoft fixed this vulnerability with a patch [1] for Windows Server and Windows 10 operating systems and in their docker base-images. Users should apply both, OS updates and base-image updates, to address this issue.

However, the patch comes with a caveat: As the issue is a design problem, it could not be fixed in a straightforward way. Windows containers now generate a DP API key when the container is first started. This also means that all containers use different keys. There is currently no supported way to share keys between containers or transfer a key from one container to another. This is impractical, because containers are often relatively short-lived. Moreover, when a container is scaled up, new containers will not be able to work with previously encrypted blobs. As a result, DP API is currently of limited use in containers.

Appendix

References

[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1645
[2] https://www.signpath.io/
[3] https://www.passcape.com/index.php?id=28&section=docsys&cmd=details
[4] https://docs.microsoft.com/en-us/previous-versions/ms995355(v=msdn.10)?redirectedfrom=MSDN
[5] https://blag.nullteilerfrei.de/2018/01/05/powershell-dpapi-script/
[6] https://certitude.consulting/advisories/CSA_2021_002_Windows_Docker_DP_API_Design_Vulnerability.md.txt

vault.ps1

Script from [5]:

Param(
  [string] $StoreSecret,
  [Parameter(Mandatory=$True,Position=0)]
  [string] $filename )
[void] [Reflection.Assembly]::LoadWithPartialName("System.Security")
$scope = [System.Security.Cryptography.DataProtectionScope]::CurrentUser
if ($StoreSecret -eq "") {
  $data = Get-Content $filename
  $ciphertext = [System.Convert]::FromBase64String($data)
  $plaintext = [System.Security.Cryptography.ProtectedData]::Unprotect(
    $ciphertext, $null, $scope )
  [System.Text.UTF8Encoding]::UTF8.GetString($plaintext)
} else {
  $plaintext = [System.Text.UTF8Encoding]::UTF8.GetBytes($StoreSecret)
  $ciphertext = [System.Security.Cryptography.ProtectedData]::Protect(
    $plaintext, $null, $scope )  
  [System.Convert]::ToBase64String($ciphertext) > $filename
}