The Worst S3 Bucket Breach - So Far
Various news reports claim that a completely unsecured S3 bucket containing hundreds of thousands of US birth certificate applications has been discovered.
In this briefing, we will take a look at what happened, who is at fault and why these kinds of incidents keep being an issue.
UK based penetration testing company Fidus Infosec found the bucket at an unspecified point in time and reached out to TechCrunch to share the findings. According to reports by TechCrunch, the two companies together then attempted to contact the owner company of said bucket several times to no avail.
While the name of the company owning the bucket has not been disclosed, we know that it is a business that helps its customers apply to receive a copy of their birth certificate from their state. Such applications naturally contain highly sensitive information that is a treasure trove for anyone interested in committing identity theft.
The records reach back as far as 2017 and appear to be actively updated.
Who is at fault?
Any time an incident like this occurs, it cannot be stressed enough that Amazon is not at fault in this breach. While they provide the infrastructure that was poorly used, blaming Amazon for poorly used S3 buckets is like blaming a toll road operator for drunk drivers.
The company operating the service and owning the S3 bucket is wholly and solely to blame for this incident.
Why does this keep happening?
Not a month goes by without at least one significant breach caused by sensitive data being stored in S3 buckets that are open to the world. And while Amazon has added more and more safeguards - from making all buckets private by default to displaying prominent warnings when users try to make buckets public - the chain of incidents does not seem to abate.
The underlying issue is poor staff upskilling and human nature. Anyone with a reasonable understanding of information security and cloud infrastructure will immediately be able to tell that placing confidential information into a public storage location is a terrible idea. However, as the world continues to become more and more digitalized, the supply of adequately skilled developers struggles to meet the demand in the marketplace.
The highest-skilled workers are usually hired by either highly technical companies (which provide exciting work) or large corporations (which provide job security). This leaves SMEs without a tech focus out in the cold. For many companies whose core business is not technical, development and security considerations are still an afterthought.
This is exactly what appears to have happened here. The forms found in the S3 bucket are all printed or handwritten. They were likely uploaded by customers through a very simple web-interface. While the company handles a significant amount of critical data, they likely have a relatively small development team. Even a scenario where all development is outsourced isn’t unlikely.
As such, no one was likely versed enough in security topics to spot the glaring flaw in their infrastructure. And since the system “worked” - i.e. allowed them to do business - nothing seemed out of place.
A bucket that can be read and written by anyone is always easier to set up than one that requires proper authentication. Poorly trained or under-qualified developers will thus continue to place confidential data into public buckets while trying to solve development tasks that they are not qualified to handle.
Solutions like stringent reporting requirements, government regulation, and fines can only go so far to curb this issue since the majority of affected businesses lack even the technical talent that would allow them to grasp the severity of their problems.
Subsequently, many non-tech SMEs believe themselves to be secure. However, in reality, they may be completely oblivious to the ticking information security time-bomb on which they sit.