Live data from Hacker News

Sega Europe suffers major security breach

vpnoverview.com

41–50 of 108 posts

Re: Sega Europe suffers major security breach

#41

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. 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.

S3 keeps secrets out of source code, so you at least don't have to purge git history and can lock access down to "internal developers", and can relatively easily rotate the creds, just find everything in the creds bucket (instead of searching all your code).

Handling of secrets has gone through many rapid iterations in the cloud lately since around 2013.

For AWS: In Source. In a magic file that lives on build machine. In S3 with crypto at rest that you can pull when you boot your machine, or dynamo, or DB, just one boot password or IAM role to get you access to the rest. Then in Envvars for the service. Then Secrets manager / SSM Parameter store, more recently.

Various organizations and pieces of software are somewhere along this curve. And the less cared for this software is (or even known about, people forget software), the further back on the curve it likely is.

Beyond the above methods that is a more constant rotation behavior similar to Hashi Vault using SSM/Secrets manager. And a drive to require all systems to use constantly rotating credentials (no static creds). I'm not sure what comes after that.

However what system you use is highly dependent on your organizational maturity and internal threat model.

Re: Sega Europe suffers major security breach

#42

A good example of how the usability of your product directly affects security. 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. Because IAM Users are the easiest thin…

When allowing 3rd parties to access your AWS resources, IAM keys are in most cases the only way to achieve this. For example, most CI/CD systems don't support OIDC yet, so you have to add IAM keys to them. GitHub Actions is a notable exception here.

This also occurs when your AWS resources need to access 3rd party services. Some services don't have temporary key support.

Re: Sega Europe suffers major security breach

#43
post #14

Earlier quoted context omitted.

How do you know there’s a breach without seeing it?

How would Sega know there are AWS API keys in a public S3 bucket without vpnoverview defacing their careers site? Sega could probably, y'know, look in the S3 bucket at the identified file which contained the keys. All of the things found could have been investigated by Sega and replicated if vpnoverview just documented how they got access to the info. You don't have to joyride in a car to show the owner that they dro…

> You don't have to joyride in a car to show the owner that they dropped their keys.

This is the most accurate analogy I've seen in months, thank you for sharing it!

Re: Sega Europe suffers major security breach

#44
post #31
post #19

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 punis…

>Sega deserved to be punished I don't understand this way of thinking. They made a serious security oversight, but that doesn't mean that they deserve to have their website defaced.

> Sega deserved to be punished, but these VPN twits have clearly committed a crime

I think the rest of the sentence makes it clear the author didn't intend to support defacement as punishment.

Re: Sega Europe suffers major security breach

#45

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. 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.

One can only speculate but I can't imagine how many companies will avoid investing in security here, because they think that the secrets in their git repos and S3 buckets are perfectly safe, and they allow some people to skip 2FA because it's too inconvenient for them, and some people have root access on AWS because it's easier, etc. Maybe even giving the job to people who don't have much experience in the field and are still learning how to set up things in the cloud.

A publicly accessible S3 bucket suggests that someone mistakenly thought it was private, even by obscurity.

Re: Sega Europe suffers major security breach

#46
post #27

Earlier quoted context omitted.

Not sure why my comment got downvoted, but it very much feels like HN is defending this kind of behavior. This is why we can’t have nice things.

You can't have nice things because you aggressively criminalized the white hats, thus were never warned by them before a black hat took your nice things away. > Why should I believe that you have not installed a rootkit or other tech that you did not subsequently disclose? Because doing that and also disclosing your identity would be incredibly stupid?

> You can't have nice things because you aggressively criminalized the white hats

voakbasda even proposed giving a bounty. Is defacing a website and spearfishing the users (as is claimed higher up in the thread) needed for white hats to do their thing? I'm surprised that we aren't all in agreement that this isn't at least grey hat behavior.

Re: Sega Europe suffers major security breach

#47
post #19

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 punis…

> Sega deserved to be punished The store owner was gone on vacation, and thus the side of his store was riddled with graffiti. He deserved to get graffiti because he didn't take basic security precautions.

So the store owner can just leave all his customers’ credit card information lying around and ignore PCI compliance etc. because anyone who would possibly use it for nefarious purposes is a criminal?

How would you prevent such negligence

Re: Sega Europe suffers major security breach

#48

A good example of how the usability of your product directly affects security. 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. Because IAM Users are the easiest thin…

When allowing 3rd parties to access your AWS resources, IAM keys are in most cases the only way to achieve this. For example, most CI/CD systems don't support OIDC yet, so you have to add IAM keys to them. GitHub Actions is a notable exception here.

Reminds me of this I stumbled across for ngrok:

> Can I run my own ngrok server? > Yes, kind of. You may license a dedicated installation of the ngrok server cluster for commercial use. You provide us with keys to an AWS account and we will install the server cluster software into that account

I have no idea how common this pattern is, but personally, the idea of giving someone else AWS creds that aren't _very_ locked down scares me.

Re: Sega Europe suffers major security breach

#49

Earlier quoted context omitted.

When allowing 3rd parties to access your AWS resources, IAM keys are in most cases the only way to achieve this. For example, most CI/CD systems don't support OIDC yet, so you have to add IAM keys to them. GitHub Actions is a notable exception here.

Reminds me of this I stumbled across for ngrok: > Can I run my own ngrok server? > Yes, kind of. You may license a dedicated installation of the ngrok server cluster for commercial use. You provide us with keys to an AWS account and we will install the server cluster software into that account I have no idea how common this pattern is, but personally, the idea of giving someone else AWS creds that aren't _very_ locke…

I never understood the point of self-hosting ngrok. Isn't its entire value proposition that it lets you borrow a stable public IP to host something with when you don't have one of your own?

Re: Sega Europe suffers major security breach

#50
post #19

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 punis…

it seems like there's a couple of hundred consumer-facing VPN service providers, all with slick looking marketing websites to sell you a $5/mo service. lots of them are nothing more than 1 or 2 people and some rented 1U servers or dedicated servers somewhere on whatever ISP that can find with cheap IP transit / DIA rates. maybe a part time website design/graphic arts person they found via fiverr to make things look c…

Who are reputable in the space?
Post reply on HN