AWS Ends SSE-C Encryption, and a Ransomware Vector

You probably weren’t using it anyway, so might as well cut the cruft and end a lesser-known attack vector.

I’m a bit late to the party, but this morning I learned that AWS is ending support for a feature called “SSE-C” for encrypting data in S3 in April. Normally in security when we hear a cloud provider is getting rid of a capability, we get annoyed, but in this case I think it’s a great decision. In this post I’ll quickly cover what SSE-C encryption is, how it was starting to be used for nefarious purposes, and your alternative options. Which you’re probably already using anyway since I can’t remember the last time I found an organization using this feature for anything built in the last 10 years.

SSE-C was always a bit of a weird feature. And even though it isn’t widely used, as it comes to an end I think it’s interesting enough, especially with its role in ransomware, to spend a few minutes saying goodbye.

 

What is SSE-C?

SSE-C stands (well, stood) for “Server Side Encryption- Customer-provided keys”. It allowed you to provide an encryption key when you put an object into S3. That key was used by S3 to encrypt the data for you, and was then wiped from memory. The key was never stored, and the customer was totally responsible for their own key management.

Why did this exist? Well, it was launched before we had any other ability to encrypt on the AWS side with a key a customer could control. SSE-C allowed you to encrypt your data using keys you controlled, that AWS couldn’t ever recover or abuse (without sniffing in-memory, which would break all their contracts and would likely be an existential event).

Using SSE-C was a pain since it was required in all API calls and you, the customer, needed to self-manage the key. This wasn’t built into key management solutions and required custom code in your application accessing S3. I honestly never once encountered someone using it in the wild. Maybe we would have seen it more if KMS hadn’t appeared so soon. If you were going through the trouble of your own key management, from both an operational and security perspective, the odds are client-side encryption was a better option than SSE-C (encrypting your data before putting it in S3, which I used to see not infrequently).

Here’s an example of a script using SSE-C in the AWS command line. Yeah, not super painful but not super fun:

# First, generate a 256-bit (32 byte) AES key

openssl rand -out sse-c-key.bin 32

# Convert to base64 for use in the API

SSE_C_KEY=$(base64 sse-c-key.bin)

# Calculate MD5 of the key for validation

SSE_C_KEY_MD5=$(openssl dgst -md5 -binary sse-c-key.bin | base64)

# Upload file with SSE-C encryption

aws s3api put-object \

    --bucket my-bucket \

    --key sensitive-data.pdf \

    --body /path/to/local/file.pdf \

    --sse-customer-algorithm AES256 \

    --sse-customer-key $SSE_C_KEY \

     --sse-customer-key-md5 $SSE_C_KEY_MD5

 

SSE-C in Ransomware

SSE-C is something I think we included in one iteration of the CCSK training class, then promptly ignored. It was there, but not widely used, and was more of interest as a conceptual demonstration than a tool I would actively recommend. Between KMS, CloudHSM, and client-side encryption there really wasn’t a place for it.

Which is why I was kind of impressed when I found out there was a ransomware campaign leveraging SSE-C. This was pretty devious. Here’s how it worked:

• The attacker compromises/finds AWS credentials with permission to get and put AWS objects (read and write).
• They copy down the object (file) and re-upload it with SSE encryption enabled.
• They delete any old, non-encrypted versions of the object (likely using a lifecycle policy).
• The attacker uploads a ransom note.
• Profit!

While slow, this attack was interesting for a few reasons:

• The attacker only needed limited S3 permissions to read/write. They did not need any KMS permissions.
• Until this attack was promoted, unless you had volume-based triggers it was unlikely to trigger a threat detector.
• KMS has a minimum of 7 day key retention, even if you go to delete a key, and key deletion is very noisy. SSE-C allowed for in-place encryption with a key that AWS never held and could not recover.

This was not a widespread or common attack technique! But SSE-C is a feature that isn’t really recommended anymore, and there are many better alternatives. I’m not sad in the slightest that AWS is deprecating it.

 

Your SSE-C Alternatives

Look, for a moment let’s pretend one of two of you are using SSE-C. I mean, we all know you aren’t, but I feel like I need to leave some recommendations here.

For the vast majority of S3 encryption, just use KMS. If compliance is an issue, use it with a Customer Managed Key (CMK). If you want the ability to cut off AWS, you can use a CMK with your own key material.

If you have data that absolutely needs to be isolated from AWS and you still want to use S3, use client-side encryption. This is how I long managed my personal backups; I used a backup tool that put my files into S3 with a key that never left my system. (I still do this, just not with an S3-based service anymore).

SSE-C never really took off. It was an odd duck approach released before we could manage our own keys in AWS, and when local encryption was performance limited. It’s impressive some adversaries got creative with using it in ransomware, and thus provided AWS to end a feature that should have crossed the rainbow bridge years ago.