In the past couple of weeks we heard about two interesting incidents of data leakage from Azure blobs. The Azure blob is a storage service, equivalent to AWS S3 bucket. Since the world is currently busy with much bigger events like the SolarWinds massive incident, the blob leakage didn’t get a lot of coverage. The absurd thing about leaky storage services is that they are very simple to avoid, yet they still happen:
The first event was published by The Register about a blob that contained data of a Cayman Islands-based investment fund. Data containing shareholders name, value of holdings, term sheets, passports and other documents was publicly available.
The second event was brought to us by Techradar about a Canadian app-developer that left a blob open. Not only did it contain more than half a million documents, the company did not create separation between its different clients’ data, which is a basic data management principle. The data contained things like occupational health assessments, insurance claims and other sensitive medical data (HIPAA anyone?).
We don’t hear about many publicly available Azure blob incidents, but that doesn’t mean they are uncommon, and that absolutely doesn’t mean the blob is more secure than the bucket. At the end of the day, the storage service is publicly available because someone made it so.
When initially provisioned, access is enabled from all networks and you might want to choose a specific virtual network, your office IP range or include other limitations.
One detail often missed is the access to storage accounts. You should disallow public access at the account level, and only give access to specific blobs, instead of allowing access at the account level and then disallowing it per each blob.
Another thing to remember is that the name of the blob is unique (just like the S3 bucket name), and that creates somewhat guess-able URLs. There are plenty of open-source tools out there for dictionary attacks, so think about it next time you name your blobs. In the image below you can see the blob I just created for this blog, it might still be up and running but it only contains some images of my dog. I will alert you that I activated logging for the storage account so don’t make me go all Liam Neeson on you. And this is a great opportunity to remind you to activate the monitoring options for your blob.
To sum up, misconfigurations are not a force majeure. They happen because of us, the users. Because we just wanted to provision one thing real quick, or assume someone else will update the configuration down the CI/CD process.
Overly permissive IAM policies is one of the most popular cloud-native attack vectors. From a survey we recently ran, we learned that up to 92% of the policies contain excessive permission, often allowing access to sensitive or private data, remote code execution and wallet attacks. Solvo helps to prevent all of that, simply by integrating early in your CI process, helping the developers to deliver a secured cloud infrastructure, automatically.
Last week, vpnMentor’s research team published their findings around Pray.com’s data leakage. The leakage contained private data belonging to millions of users, including privately identifiable information like names, phone numbers, home addresses, email addresses and more. Some users of Pray.com chose to allow the app access to their phonebook, and so the buckets contained these contacts as well.
The vpnMonitor team assumes 10M users were affected and had their data leaked. According to the research, the Pray.com application was running on AWS infrastructure, using the S3 bucket for storage behind CloudFront, but unfortunately, had those misconfigured.
S3 Bucket and CloudFront Configurations
Image:vpnMonitor
S3 bucket is a very popular storage service provided by AWS. Among its many applications, it can be used to access static content. Connecting the bucket to Amazon CloudFront enables a secure and scalable connection, as the data is cached in various locations worldwide and users can access it easily and quickly.
Image:vpnMonitor
Due to many misconfiguration mistakes in the past, AWS made major improvements to the S3 bucket service, making it close to the internet by default. Should a user want to open it, they will be notified and asked to approve this step. In addition, the bucket will be marked.
So if you need to create an application that uses an S3 bucket and CloudFront, what would be the best way to protect it and provide access?
OAI (Origin Access Identity) – to make sure users access files stored in the S3 by using CloudFront URLs and not the bucket URL. This mechanism can be used for Get and Put actions altogether, but prevents unauthorized access directly to the bucket. The bucket policy would look like this:
If we look at the bucket protected by OAI we’ll see that AWS points out that the bucket is not public, but with the appropriate permissions, access can be granted. In this case, using the bucket URL will not allow access to the bucket and anyone who wants to access it will need the URL to CloudFront from the OAI.
Another popular and unsecured method, is using AWS managed policies. Many choose this route as they believe AWS is creating least-privileged policies. Unfortunately they often contain excessive permissions that are unnecessary for the use-case and in fact permit the executing of excessive actions that can lead to data leakage or disruption of business. In the Pray.com incident we can tell if any of these were used, but using policies like CloudFrontFullAccess or AmazonS3FullAccess can be exploited for such actions.
To sum up, storing data in the cloud makes it accessible easily and quickly from anywhere in the world. But with great power comes great responsibility, and we need to insist we only grant the relevant and least-privileged security policies, to make sure we protect our users, our data and our business. Solvo is here to create least-privileged security configuration for your cloud application, automatically and at scale. To check your cloud security configuration, visit our website and make sure you request a demo,
Nowadays there is a very thin line between Application Security (AppSec) and cloud security. The day when cloud security will be an integral part of AppSec is not far (it’s practically tomorrow).
The cloud is not only “someone else’s computer (or server)”, when we use managed services in the cloud, we’re using pieces of applications we did not create as a part of our cloud infrastructure.
This means that your cloud vendor is in charge of the security of the cloud, and you, the users, are also in charge of the security in the cloud. You get to decide what kind of asset or service to run, who will get access to it, and how exactly it will be configured.
But still, users skip this part, or at least don’t give it a deep dive. According to Gartner, by 2023 99% of cloud security failures will be the customer’s fault. That’s you again.
To make your life a little easier, here are a few steps I suggest, in order to improve your cloud security posture and avoid misconfiguration:
The network layer: in AWS’s default settings, the outbound traffic is open and unrestricted. As a best practice, you should switch to enable access only where it’s necessary. Similarly, don’t allow all traffic just because it’s using known ports. Exfiltrated data can be wrapped with legitimate packets like ICMP or DNS requests.
The secrets management: API keys, usernames and passwords, access tokens and other types of credentials are secrets you want to keep to yourself and perhaps use a mechanism to create temporary credentials. That’s what secret managers are for! And no matter which one you choose, never ever write secrets in plain text in your code, variables or comments. You’re going to put that in Git and we all know how that ends.
The IAM (identity and access management): a great way to give granular access and action permissions to users and resources. There’s really no need to use a root user. Users and resources should be able to do only what they need. This is also known as the least privilege principle. And take advantage of native tools like the AWS Access Analyzer, to see if you have some unused permissions that you can delete. The biggest mistake with IAM is to go the lazy route and use excessive roles. Don’t get tempted to use the ‘*’ or the pre-configured roles that allow your assets to do too much.
Logging and monitoring: this is the way to know about bad stuff that happens in (near) real time, and the only way for you to run a forensic analysis in case of a real incident. As mentioned, in the cloud an incident usually begins (99% of the time) with a user’s mistake. Logging and monitoring would allow you to detect that mistake before it is exploited. Log everything. In AWS for example, the Flow Logs default logging is only the ‘accept’ logs, leaving out the ‘reject’ logs. The rejected traffic can teach us a lot about failed attempts, brute forcing, scanning etc.
Encryption: encrypt data at rest and in transit. Use your own keys (don’t forget to rotate), or use a native service. Enabling these is easier than you think and could prevent you from massive damage. If you ‘forgot’ your S3 bucket open to the world, at least the data will be encrypted.
Subscribe to the Solvo blog. Get the most recent articles about cloud security to stay up-to-date with industry trends and best practices.
Picture this. One day, you’re working at your desk in the office as usual (remember offices? :-O ). Your boss, Monica, walks up excitedly and breathlessly says, “Guess what? We’re gonna move our flagship app to… THE CLOUD!” (Cue ominous thunderclaps. Or celebratory violins. Or both.)
You quickly grab a cup of coffee (a big one), and join your boss and the rest of the team in the meeting room, where you are treated to a long litany of benefits supposedly achieved by moving directly to the cloud: Automatic scaling. Easier management. Continuous uptime. Lower costs. Someone else responsible for infrastructure and security. “And the best thing,” she wraps up, “it’s so easy to just deploy our code to cloud platforms, and the whole thing is transparent!”
Do you want to guess what happened next?
Well, I’m sure some of you don’t have to guess, you can remember. Vividly.
Anyway, since this blog is about cloud security, we will skip over the weeks of frustration, planning, retro-fitting, and finally arriving at a solution that is technically IN the cloud, but barely achieves the listed benefits… But let’s talk about The Incident. You know the one I mean, the one that’s only mentioned in hushed tones, often with nervous giggles. The one that is brought up every time anyone attempts a new migration plan to modern platforms, and why no one is allowed to mention the newspaper clippings stuck to Monica’s wall…
Many organizations have a similar story, and each one has different specifics for The Incident. While there are many possible flaws, with varying impacts, the common thread for all of them is not adapting the system architecture to the completely different environment. Cloud-based applications have a different threat model from “classic”, on-premises systems, with different trust boundaries, unexpected entry points, and implicit dependencies.
Your systems now share the same hardware as any number of nameless companies, and while there are no real stories of substantial breaches of tenant isolation, nor do you really know who is next door, and what they are doing. For that matter, you must have taken a real leap of faith to be able to trust every employee of the cloud provider! And even if we could rely on them, we’re still throwing all of our corporate jewels up on to the public internet – even if we tried to encrypt them, the keys are all right there for all to see, right?
While there definitely are plenty of benefits to be achieved by moving to a cloud platform, it is not at all, as your fictional boss Monica claimed, transparent.
There are several aspects you really should consider when designing a cloud-native application, to account for the different architecture. At the very least, the infrastructure stack and operational model is completely transformed. Hopefully, you’ll be taking advantage of the particular services available with your provider. But even if you don’t, your application’s risk profile is significantly altered – and it’s never going back.
So, what are the specific considerations for a starter level of security for a basic application heading to the cloud?
First thing worth discussing is the mutual responsibilities you now share with the cloud provider. Just because you no longer need to update your operating system and install patches, doesn’t mean it’s not being done. But this is now your platform provider’s concern, as well as with any other underlying software. Likewise, the provider is also responsible for the infrastructure security, such as networking and DNS. They will usually also be responsible for availability, backups, migrations, and physical security, to name just a few. However, you may still have some platform configuration in that area as well.
In particular, pay special attention to access controls on the cloud services themselves. I’m sure you’ve heard plenty of horror stories of organizations that were surprised by sensitive data being stolen from open S3 buckets, so I’d rather not add to your anxiety – but do make sure your buckets are locked down! And not just your buckets, you should ensure every cloud service and cloud resource in your account is similarly restricted, according to the “Least Privilege” principle. Typically, there are quite a few active services in use, even if your application isn’t using them directly.
This is especially relevant for management console access. Platforms such as AWS do give you very fine grained control over who has access to each part of the management interface, including network access control – for example, limiting the configuration interface to specific IP addresses only, and requiring two factor authentication (2FA). But you need to go through and configure what each user can do – and review that, periodically. You’ll want to leverage your platform’s IAM (Identity and Access Management) service as much as possible, there will be a lot of functionality and flexibility there, with hundreds (or thousands) of possible permissions, roles, and various policies for identity lifetimes and what each can do.
It is a bit trickier to granularly control which component can use which resources with what service, but nonetheless it is very important to do so as much as possible.
This will help mitigate most potential vulnerabilities that might be discovered in your code in the future, by constraining the “blast zone” of a vulnerability – once again, by following the principle of least privilege, not just which resources a component should access but also what they can do with it. You will also need to ensure your application and components are properly configured for strong authentication.
And this brings us to data security… Of course all the network traffic between your components, services, and users would be secured and encrypted, and there’s no reason not to use TLS all around. You’ll need to set up PKI certificates to be able to enforce HTTPS, though you might be able to get that done with just a flip of an administrative switch.
But you’ll probably also have a bunch of sensitive data that you’ll feel like keeping protected even in storage. Easy enough to use standard encryption, but how could you protect the encryption keys while running on shared infrastructure? Lucky enough, most platforms provide a dedicated service just for this – for example, Azure’s Key Vault, or KMS (Key Management Service) on AWS. These hosted services will provide, unsurprisingly, key management APIs, and provision access to them as needed. This will allow you to dump responsibility for protecting encryption keys and other secrets on to the cloud provider – and they do a really good job of it. You can even use this to protect configuration secrets, such as database credentials and API keys, using services such as AWS’ Secrets Manager.
Now, at this point you’re probably realizing how many different services you can leverage to support your application – and how many of those you really have no choice about. Not only do you need to manage the configuration for each of these, you’ll probably also want to track and monitor the actions of each one. Since your application should also be generating some form of user activity tracking, wouldn’t it be great if there was some kind of audit trail cloud service? Yes it would! And there is! Make sure to set up and configure audit logging, and protect these as well. Pay attention to the particulars, as some services will log the cloud service activity, and some are designed for user activity logging. Either way, you’ll want some kind of monitoring, and configure alerts on specific events – for example, if your services are running far above typical costs, you may be undergoing a FinDoS (financial denial of service) attack, which could wind up costing you much more than the whole system is even worth.
Of course, none of the security requirements from the “old” architecture went away either! You will still need secure coding, authentication and authorization controls, data validation, protection against injections, a process to secure and update all application dependencies, and everything else that we still haven’t even got a full handle on. Implementing a WAF (Web Application Firewall) over cloud services can be especially tricky… But one area in particular deserves special mention. If you are deploying code to FaaS (Function as a Service), such as AWS Lambda or Azure Functions (or even GCP Functions, we’re not judging), there is a tendency to treat it as back-end code. Call into it, it does its’ job, end of story. Except that in reality, it is as much an entry point as your user-facing APIs, and must be treated as such. That includes authentication and authorization of course, but also input validation inside the function.
Lastly, you’ll still want to include all of this in your regular SDLC (Software Development Life Cycle) process, including running scans on all your code and components. Just make sure you get official authorization from the service provider, before scanning their services or running penetration tests on live systems! You wouldn’t want to end up as a headline, just because you tried doing your job.
So, to sum up: moving your application to a cloud platform will likely provide substantial benefits, but you’ll be much happier if you spend some time designing your system to take advantage of the new architecture, and not just suffer through it. Almost all of the traditional risks still exist, and you’ll still need to build your application securely. However, there are also some new risks to consider, and plenty of increasingly powerful services are provided to you by the platform to empower greater control over your security controls. Automate everything, definitely.
Action items:
Configure all open services, and shutdown unneeded services
