Microsoft Windows Containers DP API Cryptography Flaw

Risk: Medium
Local: No
Remote: Yes

CVSS Base Score: 4.3/10
Impact Subscore: 2.9/10
Exploitability Subscore: 8.6/10
Exploit range: Remote
Attack complexity: Medium
Authentication: No required
Confidentiality impact: Partial
Integrity impact: None
Availability impact: None

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Certitude Security Advisory - CSA-2021-002 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ PRODUCT : Windows Containers VENDOR : Microsoft SEVERITY : High AFFECTED VERSION : Windows 10, Windows Server IDENTIFIERS : CVE-2021-1645 PATCH VERSION : KB4598229, KB4598230, KB4598242, KB4598243 FOUND BY : Marc Nimmerrichter, Certitude Lab ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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. There was a design issue with DP API in containers which resulted in DP API using the same key in all containers. Additionally, these keys were public in base-image layers published by Microsoft. Organizations using DP API inside containers should apply patches to Windows and use the latest base images. However, the fix causes a design change, which might render the use of DP API difficult for many use-cases. Vulnerability Overview ---------------------- The vulnerability described applies to both, user- and machine-key DP API encryption within Windows Docker containers. In our description 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, a machine is not able to decrypt data encrypted by an application on another machine. However, due to a design issue, DP API machine keys used in containers came from the container images. Since Windows docker images are based on the same base images, the DP API keys of containers were identical. As the base image is 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 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 ---------------- First, start a docker container called Alice on VM1: \$ docker run --name Alice -it cmd.exe Then, encrypt a file in the Alice container using the powershell script vault.ps1: 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 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 vault.ps1 PowerShell script from used in this PoC: ``` {.powershell```} 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 } ``` Resolution ---------- Microsoft fixed this vulnerability with a patch 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. Please also refer to 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. This reduces the potential use-cases of DP API with containers. References ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (c) 2021 Certitude Consulting GmbH ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2021,


Back to Top