Menu
Three AWS S3 Buckets, owned by data management company Attunity, have exposed customer data of some major global companies.
This data was found on publicly accessibly Amazon S3 Buckets which were not password protected and includes email correspondence, system passwords, sales and marketing contact information, project specifications and employee personal data. The total size of the leak is still unclear.
Amongst the customers affected are Netflix, Ford, TD Bank and even Attunity themselves.
Attunity claim on their website to have more than 2,000 global customers, including 44 of the Fortune 100 so it’s easy to see how serious this exposure could be.
This isn’t the first time Amazon S3 Buckets have been breached and probably won’t be the last. Below we talk about some recent major attacks, what an AWS bucket is, how these can be exploited and how AppCheck can help identify your exposed data.
This is by no means the first time there has been a data breach from Amazon S3 Buckets.
Companies previously affected include Fed Ex, Adidas, GoDaddy, Shopify, WWE, Uber, Verizon and Top defence contractor Booz Allen Hamilton.
Previous problems occurred with S3 Buckets being publicly writeable with one study suggesting 7% of all S3 Buckets had unrestricted public access at the time.
Even though Amazon have now introduced functionality to block public access to S3 Buckets and are now actively working with vendors to try avoid breaches caused by misconfiguration, problems can still occur.
An example from recent years is when hackers accessed personal data from around 198 million American voters through Amazon servers, believed to be one of the largest exposures of voting data at the time of the attack.
In 2017, 111GB of financial information was left exposed by the National Credit Federation on a publicly available S3 Bucket. Included in this data was credit card information, bank account details, full credit reports and personally identifiable data for around 47,000 people which could have been used for identity theft.
Earlier that year personal information was found on an S3 server owned by the WWE, unprotected by any kind of authentication. The leaked information included address details, dates of birth, ethnicity and children’s age ranges for around 3 million wrestling fans.
These are just a few of many major breaches over the years from AWS servers and highlights the importance of keeping your data secure.
Amazon Web Services provides a cloud-based file storage solution named Simple Storage Service or “S3” for short. A ‘Bucket’ is the name given to each configured instance, although technically different, a Bucket can be thought of as being similar to a folder on a file system.
Under the hood, a Bucket is an object-based file store where the key is the logical file or folder name and the value contains the file content and other metadata for the entry. As with many other services provided by AWS, S3 includes an array of advanced features such as replication to different geographical regions, backup and encryption.
S3 Buckets are used for a myriad of reasons such as hosting static webserver content, storing user uploaded files, backup and big data analysis.
One of the crucial properties of a Bucket is its name. Each Bucket name is unique, once a Bucket is configured, the name given is then taken and no other user can create a Bucket with the same name. Should the Bucket then be deleted, the name becomes available again and someone else can claim it.
There are several problems that can occur with S3 Buckets that can lead to a security flaw. The following are some of the more common issues:
Perhaps the most common security flaw affecting Amazon S3 is incorrectly configured permissions. Although this has improved recently (when using the web console), S3 Bucket permissions are named in a way that has confused many administrators. One of the most notable vulnerabilities occurs due to the use of either the “Authenticated Users” or “All Users” user groups. Based on the name of each group, many administrators assumed that these groups only applied to users they had configured within a given AWS tenant. However, this assumption is incorrect and instead means any user who has an AWS account for any tenant across the world,
AppCheck frequently encounters S3 Buckets that are used to store files uploaded from one or more web applications, either to support a user upload feature or for backup purposes. The web application typically accesses the Bucket using the AWS API and is granted permission to upload files, with the intention that only a trusted application is permitted to do so. If the “Authenticated Users” group was used to grant permissions, any user including the attacker can authenticate to AWS and assume the same permission as the trusted application. There have been several high-profile cases where attackers have exploited this assumption to gain access to sensitive data and overwrite sensitive files to attack web applications.
Another common flaw occurs when the “list objects” permission has been granted to the public. This permission usually allows any user to list the contents of a Bucket and then download files contained within it. In some cases where the Bucket contains only public data, assigning this permission doesn’t pose a threat. However, its not uncommon to find the same configuration assigned to Buckets hosting sensitive data, as was recently demonstrated in the case of the Attunity data breach.
The name assigned to a Bucket is unique, once configured the Bucket name can be thought of in the same was as a domain name, in that it can be considered unique to the organisation who owns it and others are unable to use the same name. In the same way a domain can expire and then be claimed by someone else, S3 Bucket names can also be claimed should they be deleted.
Consider a scenario where your web application implements an analytics service that imports a JavaScript file from a bucket named “websitetracker” (https://websitetracker.s3.eu-west-2.amazonaws.com/). The company running the service decides to remove the bucket for some reason, either accidentally, as part of a rebranding exercise or another reason. The websitetracker bucket then becomes available and can be registered by an attacker. By creating a bucket with the same name, the JavaScript file imported by your website can then be replaced with a malicious file designed to intercept credit card numbers, deface the site or propagate malware.
In many real-world cases encountered by AppCheck, the affected organisation was unaware that their application had a dependency on Amazon S3 and didn’t notice an immediate effect of the Buckets deletion.
AppCheck includes a Cloud Assessment module that is enabled within the Standard and Penetration testing profiles by default. For each URL referenced by your application, a check is performed to determine if the resource is hosted on Amazon S3 and is audited for security flaws. Since the check can be conducted passively, we are able to check buckets hosted by third-parties as well as your own S3 Buckets.
The following checks are performed
As well as the above specifically for Buckets, AppCheck will also check for other AWS security flaws such as missing security patches (EC2), injection flaws in the application code, vulnerabilities that could allow sensitive data to be disclosed, exposed AWS credentials and can deploy AWS specific exploits to demonstrate the impact in a cloud hosted environment.
If you would like a free demonstration of the AppCheck system or if you would like more information on how AppCheck can help secure your networks then please feel free to get in contact at: info@appcheck-ng.com
For all the latest news and updates make sure to follow us on LinkedIn and Twitter and keep an eye on the blog.
References
https://threatpost.com/leaky-amazon-s3-Buckets-expose-data-of-netflix-td-bank/146084/
https://businessinsights.bitdefender.com/worst-amazon-breaches
No software to download or install.
Contact us or call us 0113 887 8380
