{"id":271,"date":"2021-03-16T06:42:49","date_gmt":"2021-03-16T06:42:49","guid":{"rendered":"https:\/\/certitude.consulting\/blog\/?p=271"},"modified":"2021-05-18T14:48:30","modified_gmt":"2021-05-18T12:48:30","slug":"windows-docker-dp-api-vulnerability-cve-2021-1645","status":"publish","type":"post","link":"https:\/\/certitude.consulting\/blog\/en\/windows-docker-dp-api-vulnerability-cve-2021-1645\/","title":{"rendered":"DP API encryption ineffective in Windows containers: Publicly Available Cryptographic Keys (CVE-2021-1645)"},"content":{"rendered":"\n
\"\"<\/figure><\/div>\n\n\n\n

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.<\/p>\n\n\n\n

This vulnerability was discovered in close cooperation with SignPath [2].<\/p>\n\n\n\n

Introduction<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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).<\/p>\n\n\n\n

The vulnerability<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Normally, a machine key is tied to a (virtual-)machine. Therefore, machine B<\/em> is not able to decrypt data encrypted by an application on machine A<\/em>. 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!<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Proof of concept<\/h2>\n\n\n\n

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<\/em>, VM2<\/em>) generated from the Azure VM template \u201cWindows Server 2019 Datacenter with Containers- Gen2\u201d.<\/p>\n\n\n\n

Note<\/em>: Microsoft patched images in their Dockerhub repository. To reproduce this scenario, an old image version is required.<\/p>\n\n\n\n

First, start a docker container called Alice <\/em>on VM1<\/em>:<\/p>\n\n\n\n

docker run --name Alice -it mcr.microsoft.com\/dotnet\/framework\/runtime:4.8-windowsservercore-ltsc2019 cmd.exe<\/code><\/pre>\n\n\n\n
Then, encrypt a file in the Alice <\/em>container using the powershell script vault.ps [5]:<\/p>\n\n\n\n
C:>powershell.exe -File vault.ps1 -StoreSecret \"This is my secret text\" secret.txt\n\nC:>type secret.txt\nAQAAANCMnd8BFdERjHoAwE\/Cl+sBAAAAm+1a2TNbiEahEIB4y\/C3vQAAAAACAAAAAAAQZgAAAAEAACAAAAAdbJ9ZanY929j39ZLgabsaE5hRS4TLkCaaaRqb\n+n3ZXAAAAAAOgAAAAAIAACAAAAC7fHbsKHCTaMhsWIVMYwUZezbLozItcqExHdg9EJcfDiAAAABFv2EHA5TTqb8I9I+BZrfQS5ViD93KZlL4FoYIBldGY0AA\nAABdx7adlANRnw1shJTOtE6cYTAeqmb1yTe9adcSY1nBvtqlqSWQ\/zwGaqfIfumuUm+o+ySwZXH\/Su5GovJ8aUP9<\/code><\/pre>\n\n\n\n
Start a docker container Bob <\/em>on VM2<\/em>:<\/p>\n\n\n\n
docker run --name Bob -it mcr.microsoft.com\/dotnet\/framework\/runtime:4.8-windowsservercore-ltsc2019 cmd.exe<\/code><\/pre>\n\n\n\n
The following command shows that the file encrypted by Alice <\/em>on VM1 <\/em>can be decrypted in the Bob <\/em>container on VM2<\/em>:<\/p>\n\n\n\n
C:>powershell.exe -File vault.ps1 secret.txt\nThis is my secret text<\/code><\/pre>\n\n\n\n
The fix<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Appendix<\/h2>\n\n\n\n
References<\/h3>\n\n\n\n
[1] https:\/\/msrc.microsoft.com\/update-guide\/vulnerability\/CVE-2021-1645<\/a>
[2] https:\/\/www.signpath.io\/<\/a>
[3] https:\/\/www.passcape.com\/index.php?id=28&section=docsys&cmd=details<\/a>
[4] https:\/\/docs.microsoft.com\/en-us\/previous-versions\/ms995355(v=msdn.10)?redirectedfrom=MSDN<\/a>
[5] https:\/\/blag.nullteilerfrei.de\/2018\/01\/05\/powershell-dpapi-script\/<\/a>
[6] https:\/\/certitude.consulting\/advisories\/CSA_2021_002_Windows_Docker_DP_API_Design_Vulnerability.md.txt<\/a>
<\/p>\n\n\n\n
vault.ps1<\/h3>\n\n\n\n
Script from [5]:<\/p>\n\n\n\n
Param(\n  [string] $StoreSecret,\n  [Parameter(Mandatory=$True,Position=0)]\n  [string] $filename )\n[void] [Reflection.Assembly]::LoadWithPartialName(\"System.Security\")\n$scope = [System.Security.Cryptography.DataProtectionScope]::CurrentUser\nif ($StoreSecret -eq \"\") {\n  $data = Get-Content $filename\n  $ciphertext = [System.Convert]::FromBase64String($data)\n  $plaintext = [System.Security.Cryptography.ProtectedData]::Unprotect(\n    $ciphertext, $null, $scope )\n  [System.Text.UTF8Encoding]::UTF8.GetString($plaintext)\n} else {\n  $plaintext = [System.Text.UTF8Encoding]::UTF8.GetBytes($StoreSecret)\n  $ciphertext = [System.Security.Cryptography.ProtectedData]::Protect(\n    $plaintext, $null, $scope )  \n  [System.Convert]::ToBase64String($ciphertext) > $filename\n}<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":2,"featured_media":303,"comment_status":"closed","ping_status":"open","sticky":true,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,103],"tags":[120,76,83,116,80,86,84,85],"class_list":["post-271","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technical-analysis","category-vulnerability-research-en","tag-container","tag-cve-2021-1645","tag-docker","tag-dpapi","tag-microsoft","tag-research","tag-vulnerability","tag-windows"],"_links":{"self":[{"href":"https:\/\/certitude.consulting\/blog\/wp-json\/wp\/v2\/posts\/271","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/certitude.consulting\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/certitude.consulting\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/certitude.consulting\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/certitude.consulting\/blog\/wp-json\/wp\/v2\/comments?post=271"}],"version-history":[{"count":33,"href":"https:\/\/certitude.consulting\/blog\/wp-json\/wp\/v2\/posts\/271\/revisions"}],"predecessor-version":[{"id":334,"href":"https:\/\/certitude.consulting\/blog\/wp-json\/wp\/v2\/posts\/271\/revisions\/334"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/certitude.consulting\/blog\/wp-json\/wp\/v2\/media\/303"}],"wp:attachment":[{"href":"https:\/\/certitude.consulting\/blog\/wp-json\/wp\/v2\/media?parent=271"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/certitude.consulting\/blog\/wp-json\/wp\/v2\/categories?post=271"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/certitude.consulting\/blog\/wp-json\/wp\/v2\/tags?post=271"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}