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.
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.
In this instance, a simple inspection of the resources loaded by the web page was required. Many of these resources were JavaScript files, which unnecessarily disclosed locations of application files. My first intuition was to try and browse these locations. Instead of accessing an unauthorised resource, this led to a “Not Found” error. However, the application was still configured for a development environment, so instead of a standard error page, a Symfony debug dashboard was presented.
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.
So here we are, having trivially obtained programmatic AWS access without even logging into the application! In fairness, after running weirdAAL (a wonderful tool for auditing the access for an AWS account) the account had strict permissions set for access to AWS resources.
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!
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!
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.
Given the serious fallouts of data breaches, safeguarding yourself with effective protective measures is not a luxury but a real necessity. At Triskele Labs, we provide you with the support and expertise you need - including AWS security measures - so you’re free to get down to business.