Amazon has fixed five vulnerabilities in its S3 Encryption Client, which is embedded in its AWS SDK, one of which could have allowed an attacker with access to a given S3 bucket to figure out the contents of an encrypted file.
The vulnerabilities are specific to the Encryption Client and don’t affect the S3 server side encryption. The most serious of the bugs affects older versions of the S3 Encryption Client and is related to the fact that the client would include an unencrypted MD5 hash of a file’s plaintext as part of the metadata for the encrypted object. In some cases, an attacker could use that hash to find the plaintext of the object.
“For well-known objects, or for extremely small objects that may be subject to a brute-force attack, this hash may allow an attacker to reveal the contents of the encrypted object. Only a user with read-access to the S3 object could have had access to the hash,” Colm MacCarthaigh of Amazon wrote in a post.
“This issue owes its history to the S3 ‘ETag,’ which is a content fingerprint used by HTTP servers and caches to determine if some content has changed. Maintaining a hash of the plaintext allowed synchronization tools to confirm that the content had not changed as it was encrypted.”
Amazon has removed that capability in the S3 Encryption Client to address the issue. One of the other vulnerabilities the company fixed is similar to a problem that has plagued many encryption systems, including SSL and TLS. The issue stems from the fact that the S3 Encryption Client supported cipher-block chaining (CBC) mode encryption but did not use a message authentication code to verify the ciphertext before decrypting it.
“This exposes a padding oracle vulnerability: If the attacker has write access to the S3 bucket and can observe whether or not an endpoint with access to the key can decrypt a file (without observing the file contents that the endpoint learns in the process), they can reconstruct the plaintext with (on average) 128*length(plaintext) queries to the endpoint, by exploiting CBC's ability to manipulate the bytes of the next block and PKCS5 padding errors," Sophie Schmieg of Google, who discovered this vulnerability and two of the others, wrote in an advisory.
“To use this issue as part of a security attack, an attacker would need the ability to upload or modify objects, and also to observe whether or not a target has successfully decrypted an object. By observing those attempts, an attacker could gradually learn the value of encrypted content, one byte at a time and at a cost of 128 attempts per byte,” MacCarthaigh said.
The company’s own cryptography team discovered two of the flaws, while the other three were discovered by Schmieg. The two vulnerabilities that Amazon’s team discovered and fixed in its update are less serious and more difficult for an attacker to exploit. One of those issues derived from the way that the AWS C++ SDK implemented the AES-GCM encryption algorithm.
“We’ve updated the AWS C++ SDK’s implementation of the AES-GCM encryption algorithm to correctly validate the GCM tag. Prior to this update, someone with sufficient access to modify the encrypted data could corrupt or alter the plaintext data, and that the change would survive decryption. This would succeed if the C++ SDK is being used to decrypt data; our other SDKs would detect the alteration,” McCarthaigh said.
The last weakness fixed in the update is an incorrect check on the length of the initialization vector for AES-CBC in the C++ SDK.