Another S3 Bucket Permissions Breach That Could Have Been Prevented

The private information of nearly 2 million voters in Chicago has been exposed, thanks to a misconfigured S3 Bucket by a data provider. If this sounds familiar, it has happened several times before, and it will unfortunately happen again. At least until every Amazon Web Services (AWS) user adds the security a cloud management platform like CloudCheckr provides.
Amazon S3 Buckets are a great way to store an unlimited amount of data, making them useful for backups and log files. The good news is the AWS restricts access to S3 Buckets by default. However, in this case and in the case of the other high profile breaches, a cloud administrator chose to expose the bucket to the public, and they subsequently stored proprietary data on it.  Security for Amazon Web Services, like most cloud platforms, is achieved through a “Shared Security Model,” where AWS provides secure hardware, software, and data centers and users are expected to follow best practices. This is a lot like a contractor that builds a door with a strong lock, but the homeowner is expected to use the key.
In the most recent example, voter names, addresses and birthdates were publicly available, as well as partial social security numbers and in some cases, drivers’ licenses. The data hosting firm, Election Systems & Software (ES&S) did not follow best practices and protect that data using even a simple password, let alone encryption, as Amazon offers and recommends. This is the kind of rookie mistake that could have easily been caught by CloudCheckr’s Best Practice Checks. Instead, they relied on “Security through Obscurity,” assuming that if hackers didn’t have the web address of the data, it was safe. This is like leaving your door closed but unlocked.
 

 
That didn’t stop cybersecurity experts from simply leveraging Google or “brute force” techniques to access the proprietary information. Estimates are that during the first two weeks of June, data was exposed from 198 million U.S. citizens. The security researchers acted swiftly to alert Deep Root, but hackers could have accessed it just as easily.
ES&S acknowledged the breach and launched an investigation. They did state that “The backup files on the AWS server did not include any ballot information or vote totals and were not in any way connected to Chicago’s voting or tabulation systems. These back-up files had no impact on any voters’ registration records and had no impact on the results of any election.”
This incident demonstrates that even data experts can get it wrong, and how important it is to have an automated, self-healing, security checking platform in place to prevent such events from happening.
While the S3 buckets were exposed to the public, locking them down to just Authenticated Users could be dangerous as well, causing a false sense of security because a hacker could get in through a back door. CloudCheckr’s Best Practice Checks also cover List, Update, and Delete Permissions, which could have let hackers corrupt data as well as read it.
Fortunately, CloudCheckr has developed a free tool, S3Checkr.com, that anyone can use to check the status of their AWS S3 buckets. Visit CloudCheckr S3 Breach Check and type or paste in the URL of your bucket. The tool will tell you if your S3 bucket is publicly accessible or not. This critical insight is free and open to anyone, giving you just a glimpse of the value of using CloudCheckr.
 

 
“This time it was S3 buckets” CloudCheckr founder Aaron Newman notes. “Next time it could be a different misconfiguration or a different cloud platform. CloudCheckr incorporates over 450 Best Practice Checks to keep your business secure and out of the headlines, at least for the wrong reasons.” Get started with a free 14-day trial to experience CloudCheckr’s full suite of Best Practice Checks and more.