Live data from Hacker News

Sega Europe suffers major security breach

vpnoverview.com

71–80 of 108 posts

Re: Sega Europe suffers major security breach

#71

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.

Why they used users in the first place I don't know, but for IAM credentials - I've seen people using Terraform to generate the users and access keys, and storing the access keys in the terraform state (you can't access secret keys after they are generated), and the entire state of Terraform is typically stored in something like an S3 bucket.

It's definitely not a great practice, but still it's done.

Re: Sega Europe suffers major security breach

#72

Earlier quoted context omitted.

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!

In this case SEGA, due to their incompetence lost a bunch of car keys owned by other people despite claiming that they’ll keep them safe (and having a legal obligation to do so under GDPR). So I don’t see any problem with publicly exposing them.

Re: Sega Europe suffers major security breach

#73
post #8

Earlier quoted context omitted.

Yes, if PII is involved it's common to run an audit like this. In addition to the access keys on the server image, Sega also accidentally published a database export containing PII. In order to write a comprehensive disclosure I have to investigate thoroughly. And yeah, there's no branding or information on HackerOne. Even if this had been in scope, I would have thought twice about submitting anything. Our publishing…

Did Sega agree to this public disclosure? Referring to the HackerOne standards, it appears your team violated a couple: > Respect privacy. Make a good faith effort not to access or destroy another user's data. > Do no harm. Act for the common good through the prompt reporting of all found vulnerabilities. Never willfully exploit others without their permission.

Public disclosing it seems to clearly fall under the ‘ Act for the common good through the prompt’ since SEGA’s user are the real victims in this situation and have the right to known that SEGA us incapable of keeping their data safe.

Re: Sega Europe suffers major security breach

#74

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.

If the third party has their own IAM users, you can create a cross-account trust relationship where you allow their IAM entity to assume a (scoped-down) role in your account. Then they are able to retrieve temporary credentials to assume this role.

One reason people don't like doing this is that by assuming this role you lose all the privileges in your own account. It's not something you can't overcome (e.g. by using separate credential chains in different parts of the app), but people are lazy.

Re: Sega Europe suffers major security breach

#75

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.

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

If you need to access 3rd party services from your AWS account you can at the very least put those credentials into Secret Manager or SSM Parameter Store, so that your application retrieves them at runtime when it needs to - no need to store them with the app.

Re: Sega Europe suffers major security breach

#76

Earlier quoted context omitted.

mullvad, the company mozilla recently partnered with. not much else... I am biased because I do my own VPN so all of them seem shady to me.

Tangential to the thread, but I've never understood what people mean when they say this. Do you run all your personal traffic through a VPS or something? That's not really offering the same thing as most VPN's. It hides your traffic from your ISP so they can't sell your data and snoop on you, but doesn't accomplish some of the anonymizing that an actual multi-user VPN can provide by adding additional traffic under th…

One of the VMs that I have on a system in colocation is my own customized OpenVPN setup, where I also run the openssl CA for it. My phone, laptop, etc all have their own keys.

It's set up for my own needs when I want to use a VPN from a weird place. Or simply to bypass artificial restrictions on traffic if I'm on amenity wifi in somebody's office, airport, hotel, etc. Since I can arbitrarily reconfigure it at will, and run multiple openvpn daemons from differnt .conf files listening on different ports with unique configurations (all relying on the same CA), I can do things like have one VPN that pushes a default route for my spouse's need to do internet things on restricted amenity wifi.

Another part of it pushes only routes to a few /24 that are my personal project servers, and the routing table on vpn clients remains otherwise unmodified. Sometimes known as a split horizon VPN.

>95% of the time I am not using it to run all my traffic through there.

It's also the gateway and pushes routing table entries to things that exist for my personal test/project/development VMs that are in private IP space, so I need to be connected to the VPN in order to talk to those.

Re: Sega Europe suffers major security breach

#77
post #58

Earlier quoted context omitted.

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

You don't need to break security to spray the side of a store. You do need to break security to deface a website. Analogies are analogies, they're unnecessary in this case (nowadays). Because we got law to punish people who deface a website, and the law stands on its own. Its akin to people who call 'copyright infringement' 'theft'. Its not the same, its a different mechanic, damages are different, and... different l…

No post body was provided.

Re: Sega Europe suffers major security breach

#78
post #62

Earlier quoted context omitted.

Do you understand that, from the perspective of the person suffering an attack, there is absolutely zero difference between a good guy that breaks in without a contract, permission, or other sort approval and an actual bad guy? The act of committing a crime actively destroys trust. Come to me with a list of potential vulnerabilities that I can detect and investigate with an open source scanner, and we can talk. Come…

The "person suffering the attack" is not the only party who suffers from an attack — the individuals whose information gets leaked also suffer when a company hoards toxic data and it inevitably spills. From the perspective of those individuals, there is a dramatic difference between black hats who exploit their data and grey hats who humiliate the toxic data hoarders.

Do you think those individuals will see the difference?

Also, I would argue there is no gray. A white that breaks the law cannot be trusted, because they become indistinguishable from a black hat that is pretending to be a white hat.

This all comes down a matter of trust, and breaking the law does not build trust in anyone except other criminals. If anything, it erodes trust by demonstrating the willingness to skirt the rules when it suits you.

In this case and context, I see the use of "gray hat" as an attempt whitewash black hat activities. Once you behave like a black hat, you always need to be treated like a black hat. Trust is like that, particularly when talking about security.

Re: Sega Europe suffers major security breach

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

I think "deserves" is a better word than "deserved".

The punishment for grossly negligent handling of PII should not be a childish website defacement, and should not be from enforced by vigilantes. Obviously.

The punishment for mishandling PII like this should be a painful fine, a rigorous externally imposed technical audit, and possibly civil/criminal implications for senior leadership.

(If the last one sounds unreasonable, consider Equifax. Many executives in charge of security orgs do not have technical degrees and, more importantly, have not booked any time in the trenches. Being self-taught and having non-engineering degrees can be okay, but combining that with no in-the-trenches experience is inexcusable. Assignment security to corporate politicians who don't understand the work that they are managing should be criminally negligent.)

Re: Sega Europe suffers major security breach

#80
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…

Strong disagree (not about the law claims, I'll leave that to the law-knowers), but the moral implications of 'crossing a line'. It reads like they revealed security vulnerabilities that had the possibility to harm others. I think they can be allowed some leeway in their methods.

Nope. That can come after responsible disclosure. Did they try the responsible path first? Looks like they notified and then kept going for another 10 days
Post reply on HN