AWS security and S3 buckets: How to maintain data security if you’re an AWS user
There have been several instances of AWS security incidents in the news recently, including the Capital One and Lion Air breaches, which compromised the data of millions of everyday individuals.
This is, perhaps, a good opportunity to share a personal experience of an insecure AWS configuration we discovered "in the wild”.
AWS, which stands for Amazon Web Services, is described by the e-commerce giant as “the world’s most comprehensive and broadly adopted cloud platform.” A truly global data centre, Amazon leverages more than 150 features that its customers can make use of, some of whom include government agencies, large corporates, and fast-paced startups.
Given our work in the cybersecurity field here in Australia, AWS security breaches come our way from time to time; just another day at the Triskele Labs office. Continue reading for a look at how we recently averted a potential data breach.
AWS AND DATA SECURITY - A DANGEROUS MATCH IF YOU DON’T TAKE THE RIGHT PRECAUTIONS
In this particular instance, the client we worked with used a misconfigured AWS Simple Storage Service (S3) bucket, which led to a compromise of sensitive production data from an engagement scoped for a development environment. This was all achieved without even logging into the application, highlighting the importance of protecting development instances, not just production instances.
When commencing the engagement of an application that requires a login, I always prefer to test several issues prior to authentication, as this is often the perspective from which the most critical issues can be discovered.
Symfony is a set of reusable PHP components and a PHP framework to build web applications. This software comes with a hugely verbose exception message dashboard, which is useful for debugging issues but tends to disclose a great deal of sensitive information about the application, including software versions, library information, database credentials, file paths and disk, and in this case, an AWS Access Key and AWS Secret Key.
I was, however, able to access S3 resources. An enumeration of available S3 buckets quickly showed that although I was testing a development instance, this particular account had access to several buckets labelled “production”, from which files could be enumerated including web application resources, CloudWatch logs, configuration logs and more!
WHAT DOES THIS EXPERIENCE TELL US?
The kicker to this story is that this particular development site was open to arbitrary IP addresses on the internet, as no AWS security groups had been set!
This means that anyone could access this development login page, send a request to the page that generates an error, gain access to the AWS tenancy, then pivot to access sensitive production resources.
There are several takeaways here – first, is to ensure that development instances are afforded the same, if not higher, protections as production instances.
Second, is to always consider the fact that AWS Security Groups could be used to lock down access to a resource.
Third, be careful when you’re using dashboards such as Symfony that expose sensitive information. Finally, always audit AWS Configurations through a full AWS security review before deploying an AWS resource to the public!
LEVERAGE COMPREHENSIVE AWS SECURITY EXPERTISE FOR COMPLETE DATA SECURITY
If you’re one of the thousands of companies that leverage AWS for your business applications, data security must be - or should be - at the forefront of your mind.