December 5, 2019

Cloud Encryption Part Two: Client Side Encryption for Azure Storage

Azure Storage is one of the most widely used services in the Microsoft Azure cloud, and is the Azure equivalent of the AWS S3 service. Most users of the service know that it is wise to encrypt sensitive data before storing it in the cloud. In this post, we will look at how that can be done using the Azure Java SDK, and will use the Cryptosense Analyzer Platform to gain insight into how the Azure SDK encrypts your data.

Note that in this post we are only talking about client-side encryption, where the sensitive data is encrypted locally, before being sent to the server. Server-side encryption is also available, but this is only applied to the data at rest, so the data is decrypted (briefly) on Azure servers each time it is accessed. When using Azure Storage, as the API documentation explains, client side encryption can be enforced by changing a setting in your application, causing anyy unencrypted upload to be rejected.

Client side Encryption in the Azure Java SDK

The Azure Java SDK uses the envelope encryption technique to protect data. When the client sends data to the server, it encrypts the data with a unique data key. The data key is itself wrapped (encrypted) using a ‘master key’. The encrypted data key is sent and stored on the server as metadata for the encrypted file. When the client wants to download the data from the server, it gets the encrypted data along with the encrypted data key. The client unwraps the data key using the master key and decrypts the data using the data key.

However, we still have to manage the master key: the Azure SDK can use master keys stored locally or stored in the Azure Key Vault (or a mixture of both). The main difference between using local or Key Vault master keys is the location where the data key wrapping happens (the encryption of the file contents always happens on the client):

  • If the master key is stored in the Azure Key Vault, the content key is wrapped/unwrapped inside the Key Vault: therefore the master key never leaves the Key Vault
  • If the master key is stored locally, the wrapping/unwrapping happens locally

Under the Hood

The Azure SDK documentation gives some information on what encryption modes are used for client-side encryption, but find out what algorithms are actually being used we can use the Cryptosense Analyzer Platform.

We have 3 use cases to test:

  • Encryption using a local symmetric master key.
  • Encryption using a local asymmetric master key.
  • Encryption using a master key stored in the Azure Key Vault.

After running all three tests, the first thing we can see is that in all three cases the file contents is encrypted using AES-CBC mode with PKCS5 padding. This is a worry, because these modes don’t guarantee that the ciphertext has not been tampered with, and can often lead to padding oracle attacks on the underlying plaintext if the application is not extremely careful about treating decryption errors.

Analyzer output showing encryption of the file contents

There are a couple of ways to mitigate this problem. Generally, AES_CBC should be replaced by an authenticated mode (such as AES-CCM or AES-GCM). However, the Azure documentation specifies that AES-CBC is used in order to allow ranged download of the content, so this is not an option for the SDK. In this case, authentication using HMAC over the ciphertext can provide the same security.

Looking at the rest of the results, we can see that HMAC authentication is performed over the HTTP request. However, the SDK does not perform HMAC authentication over the ciphertext. Using dynamic analysis allows us to see what really happens in the application, and this is an example of where that is useful.

By looking at the stack trace, we can see that HMAC is performed on a HTTP request

The next thing we can check is the wrapping and unwrapping of the data key. If we store the master key in the Key Vault, we do not see any key wrapping, which shows that the data key is correctly wrapped inside the Key Vault rather than the master key being made available to the local code.

When we use a local key, we can see the wrapping being performed. The algorithm used depends on the key: if the key is symmetric, AES KW is used;  if the key is asymmetric, RSA/ECB/OAEPWithSHA1AndMGF1Padding is used. Both of these methods are considered secure.

The call arguments show us that AES Wrap is for an AES master key

The call arguments show us that RSA/ECB/OAEPWithSHA1AndMGF1Padding is used for an RSA master key

Control your crypto

In this post we investigated how client side encryption actually works when using Azure Storage.
You can use Cryptosense Analyzer to check that all cryptography in our applications – including cloud SDKs – is secure and compliant. For a demo get in touch here.

November 12, 2019

The Capital One Breach and Cloud Encryption

On 29th July 2019 CapitalOne Financial Corp announced a data breach affecting 140 000 of their customer’s social security numbers and 80 000 bank account numbers. CapitalOne is a major user of AWS cloud, and in this case the stolen data was stored in AWS S3 buckets. Since the perpetrator was arrested and left quite a long trail on social media, much more detail about this breach has become public than usual, allowing in-depth analysis of what went wrong.

Why didn’t encryption save us?

Configuring firewalls, IAM roles, VPCs and so on is complicated. It’s not surprising that this occasionally leaves a hole. To protect against such eventualities most corporations require that all sensitive data stored in the cloud is encrypted.

In the CapitalOne statement, they assert:

We encrypt our data as a standard. Due to the particular circumstances of this incident, the unauthorized access also enabled the decrypting of data.

So what is this encryption that doesn’t protect you from a breach?

Tick the box to comply

One possible explanation is that, in this case, server-side encryption was used. This is the easiest way to comply with a requirement that cloud-stored data be encrypted: you just have to select an option in the AWS dashboard and AWS will generate a key, encrypt your data, and store the key for you. When you request the data back, AWS will transparently fetch the key, decrypt the data, and send it to you. This is not just an AWS feature, all major CSPs offer this functionality (in GCP it happens automatically).

This might protect you from some hypothetical insider at AWS who gets access to the raw data of your S3 bucket, but it doesn’t protect you from the far more likely attack that happened to CapitalOne: a server-side request forgery or SSRF, where the attacker persuades the application to make a request under his own control.

AWS (and other CSPs) offer an extra level of control on server-side encryption, where you can specify a particular key in their key-management service (KMS) that will wrap the data key for the S3 bucket. To decrypt, you will need IAM permission to access the KMS as well as access the bucket. In the CapitalOne case, if this extra feature was in use, it seems like the same credentials allowed access to both.

To address the shortcomings of server-side encryption you need to use what’s called client side encryption, where the encryption key is managed by your own application, setting the bar far higher for a successful SSRF attack.

The trouble is, client-side encryption is more complicated, imposing key-management responsibilities, requiring parameter choices that may have unintended consequences (see our recent article on AWS S3 Client-side encryption), and requiring a control at the application level to be sure its being used correctly.

Making client-side encryption easy

In the next few blog posts, to complete the series we started with AWS S3, we’ll be looking at how client-side encryption works in the other two of the big 3 CSP’s block storage services (Azure and GCP). We’ll also discuss how you can control at scale that all your cloud applications are following your client-side encryption policy using Cryptosense Analyzer Platform. To make sure you don’t miss anything, subscribe to this blog or follow us on twitter.

August 26, 2019

What is Cryptographic Inventory?

Companies that handle sensitive data are frequently required to demonstrate to internal or external auditors that they use cryptography appropriately as part of their data protection strategy. This requires them to use a definition of acceptable cryptography (that often comes directly from a standards body like NIST/FIPS or PCI-DSS), and evidence that this policy is enforced throughout their infrastructure.

An automated, up-to-date Cryptographic Inventory provides this evidence. It can also be leveraged to develop “crypto agility” (the ability to change cryptographic libraries and algorithms rapidly when required). But what exactly should you put in a “crypto inventory”, and how do you make one efficiently?

Continue reading →

April 23, 2019

How common is insecure cryptography?

Application security teams have limited resources for improving security. Deciding where to deploy them is not easy, and the right answer will vary for different organisations. However, one question we’re often asked by teams considering our Analyzer software is, how common are the kind of “rubber hits the road” deployment of crypto flaws that it detects?

Continue reading →

December 17, 2018

Why IAST should mean Instrumented Application Security Testing

Interactive Application Security testing (IAST) first emerged as a concept in the early 2010s as application security companies looked to improve on static (SAST) and dynamic (DAST) testing by either combining results together, or looking for some kind of best-of-both-worlds approach.

Since that time, IAST has grown to about 20% of the AST market and is predicted to gain a larger share of this rapidly growing market in the coming years. However, in my opinion, the way IAST is understood and deployed today means that the acronym needs a tweak.

Continue reading →
December 7, 2018

Auditing AWS S3 Crypto Use

Amazon Simple Storage Service (S3) is one of the most widely-used cloud services. Most users of the service know it’s wise to encrypt sensitive data before storing it in S3. In this post we’ll look at how to do that securely using the AWS Java SDK, and how Cryptosense Analyzer will help you spot if you’ve done it wrong.

Note that in this post we’re talking about client-side encryption where the sensitive data must be encrypted locally before it’s sent to AWS S3 servers. There are also options for server-side encryption managed via the S3 console. These only treat the data while at rest, it will still be in clear inside AWS servers (at least briefly) each time it’s accessed.

There are several different client-side encryption modes for S3 offered by the Java S3 SDK. First you need to decide whether you want to manage your master keys yourself, or have AWS manage your master keys in their key management service (KMS).

Continue reading →

November 13, 2018

Why Cryptosense is an IAST Tool

There are several kinds of tool for testing applications for security vulnerabilities: Static Analysis Security Testing (SAST) looks at source code or compiled binaries and searches for patterns that suggest an issue. Dynamic Application Security Testing (DAST) tools test running code by sending inputs (typically to endpoints in a web application) and observing evidence of vulnerabilities.

At Cryptosense, we wanted to build a tool that would effectively identify and help fix vulnerabilities related to cryptography – something no other tool makes a good job of. We quickly realised that we would have to be able to test both code written by our users (to check the way it calls cryptographic libraries), the cryptographic libraries themselves (to look for known issues), framework components and dependencies (that are often using cryptography in insecure ways) and some kinds of behaviour that can only be observed at run-time (like key values loaded from keystores, passwords in configuration files, random number generators..).

Neither SAST nor DAST allow you to do all this – SAST does not see run-time aspects and DAST only sees the cryptography from the exterior of the application.

That’s why we built an IAST (Interactive Application Security Testing) tool, i.e. we instrument an application while it’s running to see all the cryptographic operations, and analyse these to detect crypto vulnerabilities.

Continue reading →

October 17, 2018

Cryptosense Analyzer finds Crypto Flaw in Java EE

Yesterday’s Oracle Critical Patch Update contains a credit to Cryptosense for CVE-2018-3210, a flaw found by one of our users while they were testing a Java application with our Analyzer software.

The bug involves a repeating IV in AES-CTR mode, a crypto mistake that can be hard to spot in code review. Our run-time testing approach detects it more easily. It’s also rather easy to exploit (see e.g. the Many-time Pad tool).

Continue reading →

October 3, 2018

Post-Quantum Crypto: How to Start Preparing

post quantum crypto

UPDATE: Graham recently contributed to this article in The Economist on Post-Quantum Cryptography.

Computers that exploit quantum mechanical properties offer the promise of (supposedly) unbreakable cryptography and other exciting applications, but they will also cause a huge, immediate problem: the day a large, practical quantum computer is developed, all existing widely-used asymmetric cryptography will be broken.

This will have serious consequences: massive amounts of secret information exchanged over the internet under public-key or hybrid cryptography could be revealed. Computers will no longer be able to ensure the updates they are downloading and installing are legitimate, since code signing will be broken. The owner of the first powerful quantum computer (which will probably be a large state organisation, who will keep it a secret) could have the power to take over almost every computer and mobile phone connected to the Internet. Even though nobody knows when this will occur, it makes sense to start preparing.

Continue reading →