Original reporting credited to ZDNet and UpGuard Research. Source reference: dqindia.com (July 2019).
What Happened
In May 2019, security researchers at UpGuard discovered that Attunity — an Israeli data management, warehousing, and replication company — had left three AWS S3 buckets publicly accessible without authentication. The buckets were discovered on May 13, 2019, and were secured approximately three days later.
Attunity counts many of the world’s largest enterprises among its customers. The exposed buckets contained not only Attunity’s own internal data but also sensitive information belonging to prominent Fortune 100 clients, including Ford, Netflix, and TD Bank.
What Data Was Exposed
According to the UpGuard research team, the exposed S3 buckets contained a wide range of highly sensitive data. The categories of leaked information included:
- Backups of employee OneDrive accounts
- Internal email correspondence
- System passwords and private keys for production systems
- Sales and marketing contact information
- Project specifications and technical documentation
- Employee personal data
- Credentials for internal applications belonging to Attunity and at least one named client, Netflix
- Job account passwords and credentials related to manufacturing systems at unnamed client companies
UpGuard researchers noted that the 1 TB sample they downloaded was likely only a fraction of the total data stored in the exposed buckets. The actual volume of exposed data was almost certainly larger.
Why This Incident Was Especially Serious
Beyond the sheer volume and sensitivity of the exposed records, the incident carried significant lateral risk. Because the leaked data included private keys, system passwords, and credentials for internal applications, a malicious actor who found these buckets before researchers did could potentially have used them as a launchpad to access Attunity’s own internal network — and from there, potentially pivot into the networks of its enterprise clients.
This is a textbook example of supply-chain risk: a third-party vendor’s misconfiguration creating a potential entry point into the systems of the world’s largest companies.
Root Cause: Misconfigured S3 Bucket Permissions
The underlying cause was a misconfigured AWS S3 bucket access policy. By default, S3 buckets created today are private, but historically it was straightforward to accidentally set a bucket’s ACL (Access Control List) or bucket policy to allow public reads. Organizations that store sensitive data in S3 must explicitly audit bucket permissions to ensure no buckets are inadvertently world-readable.
Common reasons S3 buckets end up publicly exposed include:
- Developers setting permissive ACLs for testing and never reverting them
- Misconfigured bucket policies that grant
s3:GetObjectto*(all principals) - Lack of automated scanning and alerting on bucket permission changes
- No enforcement of an AWS Organizations Service Control Policy (SCP) that blocks public bucket access account-wide
How to Prevent S3 Data Exposure: Practical Steps for DevOps Teams
The Attunity incident is far from unique — misconfigured S3 buckets have been responsible for numerous high-profile breaches. The following controls are considered baseline hygiene for any AWS environment that stores sensitive data.
1. Enable S3 Block Public Access at the Account Level
AWS provides a Block Public Access setting that can be enforced at both the individual bucket level and the AWS account level. Enabling all four Block Public Access options at the account level prevents any bucket in the account from being made public, regardless of bucket policy or ACL settings. This is the single most effective safeguard against accidental public exposure.
2. Apply Least-Privilege Bucket Policies
Every S3 bucket policy should grant only the minimum permissions required. Avoid wildcard principals ("Principal": "*") in bucket policies unless you specifically intend public access. Scope policies to specific IAM roles or AWS account IDs.
3. Use AWS Config Rules or Security Hub to Detect Drift
AWS Config includes managed rules such as s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited that continuously evaluate your buckets and alert you when a bucket becomes publicly accessible. AWS Security Hub aggregates these findings for centralized visibility.
4. Enable Server-Side Encryption and Enforce It via Policy
Encryption at rest does not prevent public exposure, but it does protect data if physical storage media is compromised. Use a bucket policy Condition that denies any PutObject request that does not include server-side encryption headers (aws:SecureTransport and s3:x-amz-server-side-encryption).
5. Enable S3 Access Logging and CloudTrail Data Events
S3 server access logs and CloudTrail data events record every request made to a bucket. This provides an audit trail that can reveal whether a bucket was accessed by unauthorized parties before a misconfiguration was corrected.
6. Audit Third-Party Vendor Cloud Posture
The Attunity breach underscores that your security posture is only as strong as the vendors who handle your data. Include cloud security configuration requirements in vendor contracts and assess vendor posture as part of third-party risk management programs.
Key Takeaways
- Three misconfigured, unauthenticated AWS S3 buckets exposed Attunity’s internal data and data belonging to major Fortune 100 clients including Ford, Netflix, and TD Bank.
- The exposure included passwords, private keys, and credentials that could have enabled further network intrusion.
- UpGuard researchers found the buckets on May 13, 2019; they were secured within three days.
- Enabling AWS S3 Block Public Access at the account level is the most effective single control to prevent this class of incident.
- Continuous compliance monitoring (AWS Config, Security Hub) and robust third-party vendor assessments are essential components of a mature cloud security program.
DevOps and cloud engineering teams should treat S3 bucket permission audits as a recurring operational task, not a one-time setup step. Permission drift is a real and well-documented risk.