CVE-2020-8897 – aws-encryption-sdk

Package

Manager: pip
Name: aws-encryption-sdk
Vulnerable Version: >=0 <2.0.0

Severity

Level: High

CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

CVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

EPSS: 0.00078 pctl0.23962

Details

Security issues in AWS KMS and AWS Encryption SDKs: in-band protocol negotiation and robustness Authors: Thai "[thaidn](https://twitter.com/xorninja)" Duong # Summary The following security vulnerabilities was discovered and reported to Amazon, affecting AWS KMS and all versions of [AWS Encryption SDKs](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) prior to version 2.0.0: * **Information leakage**: an attacker can create ciphertexts that would leak the user’s AWS account ID, encryption context, user agent, and IP address upon decryption * **Ciphertext forgery**: an attacker can create ciphertexts that are accepted by other users * **Robustness**: an attacker can create ciphertexts that decrypt to different plaintexts for different users The first two bugs are somewhat surprising because they show that the ciphertext format can lead to vulnerabilities. These bugs (and the infamous [alg: "None"](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/) bugs in JWT) belong to a class of vulnerabilities called **in-band protocol negotiation**. This is the second time we’ve found in-band protocol negotiation vulnerabilities in AWS cryptography libraries; see this [bug](https://github.com/google/security-research/security/advisories/GHSA-7f33-f4f5-xwgw) in S3 Crypto SDK discovered by my colleague Sophie Schmieg. In JWT and S3 SDK the culprit is the algorithm field—here it is the key ID. Because the key ID is used to determine which decryption key to use, it can’t be meaningfully authenticated despite being under the attacker’s control. If the key ID is a URL indicating where to fetch the key, the attacker can replace it with their own URL, and learn side-channel information such as the timing and machines on which the decryption happens (this can also lead to [SSRF](https://portswigger.net/web-security/ssrf) issues, but that’s another topic for another day). In AWS, the key ID is a unique [Amazon Resource Name](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). If an attacker were to capture a ciphertext from a user and replace its key ID with their own, the victim’s AWS account ID, encryption context, user agent, and IP address would be logged to the attacker’s AWS account whenever the victim attempted to decrypt the modified ciphertext. The last bug shows that the non-committing property of AES-GCM (and other AEAD ciphers such as [AES-GCM-SIV](https://keymaterial.net/2020/09/07/invisible-salamanders-in-aes-gcm-siv/) or (X)ChaCha20Poly1305) is especially problematic in multi-recipient settings. These ciphers have a property that can cause nonidentical plaintexts when decrypting a single ciphertext with two different keys! For example, you can send a single encrypted email to Alice and Bob which, upon decryption, reads “attack” to Alice and “retreat” to Bob. The AWS Encryption SDKs are vulnerable to this attack because they allow a single ciphertext to be generated for multiple recipients, with each decrypting using a different key. I believe this kind of problem is prevalent. I briefly looked at [JWE](https://tools.ietf.org/html/rfc7516) and I think it is vulnerable. # Mitigations Amazon has fixed these bugs in release 2.0.0 of the SDKs. A new major version was required because, unfortunately, the fix for the last bug requires a breaking change from earlier versions. All users are recommended to upgrade. More details about Amazon’s mitigations can be found in [their announcement](https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment/). We’re collaborating with Shay Gueron on a paper regarding fast committing AEADs. # Vulnerabilities ## Information Leakage The [Encrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html) API in AWS KMS encrypts plaintext into ciphertext by using a customer master key (CMK). The ciphertext format is undocumented, but it contains metadata that specifies the CMK and the encryption algorithm. I reverse-engineered the format and found the location of the CMK. Externally the CMK is identified by its key ARN, but within a ciphertext it is represented by an internal ID, which remained stable during my testing. When I replaced the internal ID of a CMK in a ciphertext with the internal ID of another CMK, I found that AWS KMS attempted to decrypt the ciphertext with the new CMK. The encryption failed and the failure event—including the AWS Account ID, the user agent and the IP address of the caller—was logged to Cloud Trail in the account that owned the replacement CMK. This enables the following attack: * The attacker creates a CMK that has a key policy that allows access from everyone. This requires no prior knowledge about the victim. * The attacker intercepts a ciphertext from the victim, and replaces its CMK with their CMK. * Whenever the victim attempts to decrypt the modified ciphertext, the attacker learns the timing of such actions, the victim’s AWS Account ID, user agent, encryption context, and IP address. This attack requires the victim to have an IAM policy that allows them to access the attacker’s CMK. I found that this practice was allowed by the AWS Visual Policy Editor, but I don’t know whether it is common. The AWS Encryption SDKs also succumb to this attack. The SDKs implement envelope encryption: encrypting data with a data encryption key (DEK) and then wrapping the DEK with a CMK using the Encrypt API in AWS KMS. The wrapped DEK is stored as part of the final ciphertext (format is defined [here](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/message-format.html)). The attacker can mount this attack by replacing the CMK in the wrapped DEK with their own. ``` { "eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "<redacted this is the principal ID of the victim>", "accountId": "<redacted - this is the AWS account ID of the victim>" }, "eventTime": "2020-06-21T21:05:04Z", "eventSource": "kms.amazonaws.com", "eventName": "Decrypt", "awsRegion": "us-west-2", "sourceIPAddress": "<redacted - this is the IP address of the victim>", "userAgent": "<redacted - this is the user agent of the victim>", "errorCode": "InvalidCiphertextException", "requestParameters": { // The encryption context might include other data from the victim "encryptionContext": { "aws-crypto-public-key": "AzfNOGOnNYFmpHspKrAm1L6XtRybONkmkhmB/IriKSA7b2NsV4MEPMph9yX2KTPKWw==" }, "encryptionAlgorithm": "SYMMETRIC_DEFAULT" }, "responseElements": null, "requestID": "aeced8e8-75a2-42c3-96ac-d1fa2a1c5ee6", "eventID": "780a0a6e-4ad8-43d4-a426-75d05022f870", "readOnly": true, "resources": [ { "accountId": "<redacted - this is the account ID of the attacker>", "type": "AWS::KMS::Key", "ARN": <redacted - this is the key ARN of the attacker> } ], "eventType": "AwsApiCall", "recipientAccountId": "<redacted - this is the account ID of the attacker>", "sharedEventID": "033e147c-8a36-42f5-9d6c-9e071eb752b7" } ``` **Figure 1: A failure event logged to the attacker’s Cloud Trail when the victim attempted to decrypt a modified ciphertext containing the attacker’s CMK.** ## Ciphertext Forgery The [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) API in AWS KMS doesn’t require the caller to specify the CMK. This parameter is required

Metadata

Created: 2021-10-12T16:01:12Z
Modified: 2024-09-04T19:24:49Z
Source: https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2021/10/GHSA-wqgp-vphw-hphf/GHSA-wqgp-vphw-hphf.json
CWE IDs: ["CWE-327"]
Alternative ID: GHSA-wqgp-vphw-hphf
Finding: F052
Auto approve: 1