SEGA’s Saga of Nearly Compromised Credentials

A look at VPNO’s recent findings of publicly accessible S3 buckets on SEGA’s infrastructure and what we can learn from it.

ICYMI - Last week, security firm VPN Overview (VPNO) published their findings of publicly accessible S3 buckets on SEGA’s infrastructure with extremely sensitive content in them. Thankfully, SEGA’s security team and external security researchers resolved the issue before any reported damage. Apparently, had this been detected by a malicious actor before being remediated — it could have led to the malicious actor being able to gain access to sensitive information of users and manipulate SEGA online content, causing serious damage to its reputation.

In addition to personally identifiable information (PII) records, the compromised buckets held very sensitive credentials including a MailChimp API key and AWS credentials. The AWS credentials which were found allowed the researchers to gain access to S3 Storage buckets, CloudFront distributions, EC2 servers and SNS topics.

Access to these specific resources would’ve allowed a malicious actor to:

• “Read and write access to SEGA Europe’s cloud storage”
• “Upload files, execute scripts, alter existing web pages and modify the configuration of … SEGA domains”
• “Upload files and modify content on domains” (on a total of 559 domains!)
• “Modify CloudFront distributions” (on a total of 436 domains including “sega.com”!)
• “Craft and send malicious SNS alerts to subscribers”

According to engadget, the MailChimp API key could’ve enabled malicious actors to abuse an 250,000-user email list — which is, of course, another serious finding.

Some might consider the main moral to this story the importance of separating public and private resources. This is a valuable lesson, as the main hazard of using public S3 buckets is precisely this: sensitive (or in this case — highly sensitive) information can find its way into buckets which can be read by anyone. For this reason, you should avoid using resources such as public S3 buckets; AWS provides you with controls on the bucket and the account levels to make it easier to avoid. Even if you do decide to use public S3 buckets — you should treat them and the type of content you place on them as you would a loaded gun — extremely carefully.

While this is a valuable lesson — there’s arguably a more important underlying (and somewhat less obvious) lesson AWS practitioners should pick up from this event — don’t use static AWS credentials. More than being an example of an instance when sensitive information found its way to a public S3 bucket, this is an example of how AWS access keys can find their way into the wrong hands. This could happen in a variety of ways — from a vulnerability such as the one reported in log4j, to malware designed specifically for this use, to developers placing it in code they post to GitHub, to a 3rd party with your access keys getting breached themselves.

Once these credentials are on the loose, they are very often outside of the AWS account admin’s control. As we discussed in our post on protecting your AWS environment beyond patching log4j there are great alternatives for using IAM Users’ access keys (and IAM users in general, but that’s another story). Having active access keys that allow the impersonation of identities in your AWS environment is something you should generally avoid, as you should with any kind of static, permanent credentials. And if you find yourself feeling obligated to use such credentials, just like with a public S3 bucket (and arguably much more importantly!) — you should treat them with extreme care — rotating them frequently, deactivating as soon as possible and securing them safely.

This is one lesson you don’t want to learn the hard way.