By temporarily defacing the Sega website and modifying files I think they have crossed the line. Enumerating what access they have, rooting through S3 and reporting it is OK, but by messing around like script kiddies they can no longer claim good faith. Publicising that you've illegally defaced the website is a little silly. Of course, Sega should not have got themselves so completely owned. Sega deserved to be punished, but these VPN twits have clearly committed a crime and Sega should maybe sue their company.
Sega Europe left AWS S3 creds laying around in a server image on downloads.sega.com. I was able to use them to enumerate a bunch of storage, dig out more keys, and mock up a spear phishing attack against the Football Manager forums.<p>All the keys and services are secure and the breach is closed.
A good example of how the <i>usability</i> of your product directly affects security.<p>AWS has multiple forms of credentials. IAM Users (static keys tied to a specific user identity) are one form. But you can also authenticate via SAML or OIDC. If you use SAML/OIDC, you can enforce temporary IAM credentials, audit who authenticated, expire credentials, enforce password rules & MFA, etc.<p>Because IAM Users are the <i>easiest thing</i> to set up, that's what everyone does. And that leads to compromises. If, on the other hand, IAM Users were <i>more difficult</i> to set up than SAML/OIDC, then everyone would use SAML/OIDC and temporary credentials. And that would mean giant compromises like these would be much rarer, because it would eliminate the easiest form of compromise: people putting static, non-expiring keys where they shouldn't be.<p>So when you develop a thing, think about the consequences of it, and design it so that users are more inclined to use it in a way that leads to good outcomes. That might even mean making parts of it intentionally hard to use.
If I'm understanding correctly, a whole bunch of credentials, like IAMs, DB passwords, Steam keys, and MailChimp keys were lying around in S3 buckets.<p>But I don't understand the use case, what would be the purpose of uploading those details into S3 buckets? Or I suppose I'm trying to reverse engineer the situation where the dev/ops team decided to do this.
So the breach referenced was a breach by the researchers, not a malicious third party (that we know of)? I would have called it exposure or a vulnerability since breach has a specific meaning that I am not sure this fits. Maybe I am being pedantic.