As part of a risk assessment conducted for one of our clients, our technical team performed an external penetration test on the organization’s digital assets. The objective of the test was to evaluate the security posture of the organization and its assets across the external attack surface and to identify potential vulnerabilities that could pose a threat to the organization. What we discovered is an excellent example of the risks associated with misconfigured AWS S3 Buckets.
The Beginning: Discovering Vulnerabilities in AWS S3 Storage Services
At the start of the assessment, we identified that the website we were testing uses an S3 Bucket to store HTML and JS files related to the application. This service allows for files to be stored and accessed rapidly over the internet globally. While the service itself is secure, we discovered that due to a misconfiguration, sensitive files stored in S3 could be accessed, potentially leading to the exposure of sensitive information and even a complete takeover of the organization’s website.
Using S3 Buckets – Pros and Cons
The S3 service is a critical tool for external file storage, offering flexibility and convenience for application developers. When configured correctly, the service can mitigate risks and provide clear isolation between application servers and stored files. For example, instead of allowing a user to upload image files or documents directly to the application server—which could enable malware uploads and even Remote Code Execution (RCE) in some cases—all files are uploaded to an S3 Bucket. This separates them from the server, ensuring they cannot execute within the context of server-side code.
Conversely, when the service is misconfigured, it can become a significant security weakness. For instance, in cases where files containing sensitive information are uploaded—such as candidate resumes containing phone numbers and sometimes ID numbers (information defined as sensitive under the Privacy Protection Law)—a misconfiguration in the S3 service can allow external parties to view and list all files uploaded to the system.
In theory, S3 is designed to ensure secure file storage with restricted access. In practice, improper settings can expose stored data to anyone without the need for special permissions. Incorrect read permissions can allow any user to access all files stored in the bucket, while incorrect write permissions can allow attackers to upload malicious files into the application.
Client Case Study: S3 Misconfiguration Resulted in User Account Takeover
During the penetration test, an IPV Security expert discovered that one of the organization’s websites loaded HTML, CSS, and JavaScript files from an S3 Bucket belonging to the organization. Direct access to the bucket revealed it was open to public access. By running the following command:
`aws s3 ls s3://[name_of_bucket] –no-sign-request`
it was discovered that read access existed for the objects in the bucket and their contents.
While the bucket’s content did not initially contain sensitive information, we did not stop there. We examined the Access Control List (ACL) permissions and noticed a critical security flaw: the `WRITE_ACP` (edit) permission was granted to the “Authenticated users group.” Despite its confusing name, this group grants permission to edit the bucket’s access settings (ACL) not just to accounts associated with the organization, but to anyone with an AWS account!
By exploiting this setting, it was possible to modify the ACL settings responsible for bucket permissions, allowing an anonymous user to edit and upload files to that bucket. Using the permissions the tester assigned to himself, he edited one of the JavaScript files loaded by the organization’s website and injected an XSS (Cross-Site Scripting) payload. This ultimately led to the hijacking of user session cookies within the system.
Insights from Senior Cyber Experts at IPV Security:
To prevent similar scenarios within your organization’s networks, we recommend the following actions:
1. Define Precise Bucket Permissions: Correctly configure read and write permissions for buckets based on necessity, and allow public access only when absolutely essential.
2. Use Pre-signed URLs: Implement the use of Pre-signed URLs to provide temporary and limited access to files stored in S3, rather than granting direct read/write permissions to the bucket. This allows for better control over access to sensitive files and reduces the risk of unauthorized data exposure.
3. Use Automated Tools for Misconfiguration Detection: Utilize tools such as AWS Config and IAM Access Analyzer to identify and alert on overly permissive settings.
4. Monitor Suspicious Activity: Enable monitoring and auditing tools like CloudTrail to detect anomalous activities, such as bulk file uploads or access to sensitive data.
5. Sensitive Data Segregation: Ensure that sensitive information is stored in separate buckets with highly restrictive permissions.
6. Periodic Security Assessments: Conduct regular penetration tests and security audits to identify and remediate vulnerabilities in the organization’s websites and cloud assets.
Summary
The findings from this penetration test demonstrate the dangers of improper S3 Bucket usage and the critical need for implementing robust and secure access control. By taking proactive steps and implementing appropriate security measures, organizations can reduce the risk of data exposure and ensure the safety of corporate information. Adherence to strict information security processes and performing periodic assessments are key to maintaining organizational security and protecting against severe breaches.