Data exfiltration from AWS and Azure PaaS

These days if you have to design a sensitive data bearing application in the public Cloud, you're in for long conversations which your compliance officer: GDPR, HIPAA, you name it.

You will explain that all services you plan to consume are private, and that they all run in private networks. All the assets are shielded from the Internet, you're at home in the Cloud so privacy is undisputably built-in... The officer will be relieved, but will you?

PaaS integration is the cornerstone of in-Cloud application composition. What used to take days of integration studies has now become so seamless and fast that we tend not to think about it. But hold on… In part 2 of Demystifying PaaS Security, I made the point that it opens large avenues for data exfiltration. I used the term "confines porosity" to put a name on this elusive risk.

Consuming purely private Cloud services does not make your data private

Confines porosity encompasses three patterns actually:

? Endpoints porosity: to be of any use, services that run in the Cloud Service Provider (CSP) managed network need to be called from the customer private network. Such endpoints are susceptible to data leakage.

? “Start points” porosity: this is the opposite pattern. Workloads that run in the CSP-managed network need to call a service in the customer private network. The customer endpoint is reputedly secure, but the workload itself (the start point) is susceptible to data leakage (via impersonation).

? Internet porosity: workloads and services that run within the customer private network may require egress Internet access to work properly. This access is susceptible to data leakage.

Other patterns affect data exfiltration from PaaS, notably IAM patterns, but for the sake of conciseness we must consider them out of scope for today's discussion. For a specific discussion on that topic you should take a look at my article covering the Capital One incident on AWS.

Since I first discussed PaaS integration leakage in 2018, the landscape has evolved quite a bit. An update is in order!

Porosity in Azure PaaS

Endpoints porosity

? So-called “management” endpoints for compute clusters have been privatized in AKS and Service Fabric. That’s a real, big, achievement. Now that next big chunk should be ASE: it is not on par yet.

? Service endpoints should be covered by endpoint policies, a recent addition to Azure security arsenal. Unfortunately endpoint policies are currently limited to storage only. What’s more, the routing machinery is a source of troublesome leakage vectors. By and large, Azure firewall is of great help reduce endpoints drastically, but it comes with limitations related to protocols inspection. Services tags are also possible, but unwise in my opinion.

Start points porosity

? Incoming Azure calls can now be hardened with conspicuous service tags (a welcome feature for Azure Load Balancers, for example).

? Ingress calls from another subscription can be hardened with peering + Vnet injection + Azure firewall + ACLs

Internet porosity

Azure firewall covers most of the data exfiltration scenarios for most services (some key components like AKS pods are still missing, unfortunately).

Porosity in AWS PaaS

Endpoints porosity

The canonical solution proposed by AWS is to use a combination of VPCE and resource-based policies (eg: bucket policies). This is very efficient and the service coverage is quite large, but, depending on your architecture, it might not scale well. Here the constraint is obviously not technical, but financial.

Start points porosity

? Incoming AWS calls have always relied on private NICs and/or security group integration.

? Ingress calls from another account rely on peering, security groups and ACLs.

Internet access

Fargate used to run in VPCs with a mandatory NAT gateway which kind of defeated this, but it now behaves like any other private AWS service.

So how do they behave? To put bluntly, it’s up to the customer to devise its own transparent proxy. The need for a customer proxy is a Cloud anti-pattern that has been lingering and that is not in AWS DNA. But let's be patient, these guys are wizards and I'm sure they'll come up with something.

Conclusion

Using PaaS privately does not grant an auto-magic immunity to data leakage. If you are a Cloud cosuming corporation, your Cloud security team has a critical share of responsibility: even if application composition is straightfoward in the Cloud, it's up to your team, not to your Cloud provider's, to identify potential exit channels in the design of your application and to have them monitored and fixed whenever possible.