7 ms·

Sega Europe suffers major security breach

185 points by aaronwp 5y ago

isbvhodnvemrwvn 5y ago
If you're running on AWS, why would you even have long-lived credentials in your images?
- whoknew1122 5y ago
  There's a few reasons, none of them good. Likely the answer is gross incompetence. If I were to give them the benefit of the doubt and provide the most defensible reason to have an image that contains AWS credentials, you could theoretically use long-term (i.e. user) AWS credentials on an on-premises VM and then export the server image to AWS. When you rehost the server in EC2, you would switch to an instance role per best practices. And then you forget to delete the image stored in S3. Still doesn't explain why the S3 bucket is publicly available. But that's one reason a server image with long-term credentials could end up stored in an S3 bucket. Unlikely that the image was an EBS snapshot or AMI. While those are technically housed in S3, you can't access them from the S3 console. And they didn't brag about accessing the EC2 console.
batch12 5y ago
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.
- thr0wawayf00 5y ago
  "Breach" is a legal term, and although IANAL, it seems semantically correct here. When anyone outside of your organization gains access to sensitive information in your systems, regardless of their intent, that is a breach and these guys accomplished that. PCI and all of those other security protocols and programs don't draw the line at white-hat access vs black-hat access.
  - batch12 5y ago
    I agree mostly. I don't think an unsanctioned assessment that goes this deep is pure white hat. It seems firmly gray to me. > PCI and all of those other security protocols and programs don't draw the line at white-hat access vs black-hat access. PCI mandates penetration tests. A white hat finding as a pentest isn't reportable as a breach. This one may be unless some gymnastics are used to call it an authorized test.
0xbadcafebee 5y ago
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 thing to set up, that's what everyone does. And that leads to compromises. If, on the other hand, IAM Users were more difficult 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. 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.
- watermelon0 5y ago
  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.
  - drjasonharrison 5y ago
    This also occurs when your AWS resources need to access 3rd party services. Some services don't have temporary key support.
    - isbvhodnvemrwvn 5y ago
      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.
  - banana_giraffe 5y ago
ff7c11 5y ago
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.
- kiklion 5y ago
  > By temporarily defacing the Sega website I may have missed it but what did they deface? I see a proof of script execution in what appears to be an uploaded file of a random string of letters and numbers .htm address. So if don’t correctly there is a near zero chance of any public user stumbling into the site.
  - whoknew1122 5y ago
    They clearly said they modified careers.sega.co.uk and posted a screenshot of the careers site displaying vpnoverview's logo (https://vpnoverview.com/wp-content/uploads/screenshot-about-sega-page-defaced-image.png https://vpnoverview.com/wp-content/uploads/screenshot-about-...)
    - vlunkr 5y ago
      They say it "briefly" showed that logo. Who knows how long that is.
      - whoknew1122 5y ago
        The question was whether a site was defaced, not how long it was defaced for.
    - christophetd 5y ago
      It's been taken down, but still available through https://web.archive.org/web/20211230160444/https://vpnoverview.com/wp-content/uploads/screenshot-about-sega-page-defaced-image.png https://web.archive.org/web/20211230160444/https://vpnovervi...
rosndo 5y ago
It’s hilarious to see people generating content like this to push their VPN affiliate marketing schemes.
- walrus01 5y ago
  If there's one thing that I can absolutely rely upon, it's for VPN service providers to use any and every form of shady grey marketing sales technique that exists.
politelemon 5y ago
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.
- drjasonharrison 5y ago
  Rather than use a password manager, or credential store, or some other secure way to keep these credentials safe while providing access to internal developers for development purposes, they put them on S3. Here's an example I have seen: - env file is needed for development to run a service on development machine and to access the staging deployment - the credentials in the env file aren't per-developer because that requires work to setup accounts for every developer with the staging hosting service - so make a copy of the credentials, put them in an env file on the NAS - NAS isn't available from home or from other network locations - so make a copy of the env file in the cloud If the S3 bucket hadn't been public they probably would have been fine.
- grogenaut 5y ago
  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.
ipaddr 5y ago
Another grow marketing hack successful. Double if their is a lawsuit.
swdev281634 5y ago
Was not the best idea to do that. Sega is very traditional Japanese company. Consequences are likely to follow, but not the legal ones.
aaronwp 5y ago
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. All the keys and services are secure and the breach is closed.
- robtaylor 5y ago
  Assertive: Show me something else.
  - aaronwp 5y ago
    stay tuned
- duxup 5y ago
  > dig out more keys I guess that if they leave them lying around that it is likely there are more.
- imwillofficial 5y ago
  This would be awesome as a blog post if you ever want to go into detail on how you executed each step.
  - deleted 5y ago
    [deleted]
- phnofive 5y ago
  Is it common, now or historically, to follow up a notification of compromise with self-directed PoC and privilege escalation exercises on the resources of a company with which you're not under contract? My naïve take is that this was a series of well-intentioned but possibly criminal actions used to illustrate a lesson we could all be reminded of from time to time. Also, the HackerOne page doesn't appear to be claimed by SEGA Sammy, so notices might dead-end there as well.
  - 5y ago

185 points by aaronwp 5y ago

isbvhodnvemrwvn 5y ago

If you're running on AWS, why would you even have long-lived credentials in your images?

whoknew1122 5y ago
There's a few reasons, none of them good. Likely the answer is gross incompetence. If I were to give them the benefit of the doubt and provide the most defensible reason to have an image that contains AWS credentials, you could theoretically use long-term (i.e. user) AWS credentials on an on-premises VM and then export the server image to AWS. When you rehost the server in EC2, you would switch to an instance role per best practices. And then you forget to delete the image stored in S3. Still doesn't explain why the S3 bucket is publicly available. But that's one reason a server image with long-term credentials could end up stored in an S3 bucket. Unlikely that the image was an EBS snapshot or AMI. While those are technically housed in S3, you can't access them from the S3 console. And they didn't brag about accessing the EC2 console.

batch12 5y ago

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.

thr0wawayf00 5y ago
"Breach" is a legal term, and although IANAL, it seems semantically correct here. When anyone outside of your organization gains access to sensitive information in your systems, regardless of their intent, that is a breach and these guys accomplished that. PCI and all of those other security protocols and programs don't draw the line at white-hat access vs black-hat access.
- batch12 5y ago
  I agree mostly. I don't think an unsanctioned assessment that goes this deep is pure white hat. It seems firmly gray to me. > PCI and all of those other security protocols and programs don't draw the line at white-hat access vs black-hat access. PCI mandates penetration tests. A white hat finding as a pentest isn't reportable as a breach. This one may be unless some gymnastics are used to call it an authorized test.

0xbadcafebee 5y ago

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 thing to set up, that's what everyone does. And that leads to compromises. If, on the other hand, IAM Users were more difficult 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. 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.

watermelon0 5y ago
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.
- drjasonharrison 5y ago
  This also occurs when your AWS resources need to access 3rd party services. Some services don't have temporary key support.
  - isbvhodnvemrwvn 5y ago
    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.
- banana_giraffe 5y ago

ff7c11 5y ago

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.

kiklion 5y ago
> By temporarily defacing the Sega website I may have missed it but what did they deface? I see a proof of script execution in what appears to be an uploaded file of a random string of letters and numbers .htm address. So if don’t correctly there is a near zero chance of any public user stumbling into the site.
- whoknew1122 5y ago
  They clearly said they modified careers.sega.co.uk and posted a screenshot of the careers site displaying vpnoverview's logo (https://vpnoverview.com/wp-content/uploads/screenshot-about-sega-page-defaced-image.png https://vpnoverview.com/wp-content/uploads/screenshot-about-...)
  - vlunkr 5y ago
    They say it "briefly" showed that logo. Who knows how long that is.
    - whoknew1122 5y ago
      The question was whether a site was defaced, not how long it was defaced for.
  - christophetd 5y ago
    It's been taken down, but still available through https://web.archive.org/web/20211230160444/https://vpnoverview.com/wp-content/uploads/screenshot-about-sega-page-defaced-image.png https://web.archive.org/web/20211230160444/https://vpnovervi...

rosndo 5y ago

It’s hilarious to see people generating content like this to push their VPN affiliate marketing schemes.

walrus01 5y ago
If there's one thing that I can absolutely rely upon, it's for VPN service providers to use any and every form of shady grey marketing sales technique that exists.

politelemon 5y ago

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.

drjasonharrison 5y ago
Rather than use a password manager, or credential store, or some other secure way to keep these credentials safe while providing access to internal developers for development purposes, they put them on S3. Here's an example I have seen: - env file is needed for development to run a service on development machine and to access the staging deployment - the credentials in the env file aren't per-developer because that requires work to setup accounts for every developer with the staging hosting service - so make a copy of the credentials, put them in an env file on the NAS - NAS isn't available from home or from other network locations - so make a copy of the env file in the cloud If the S3 bucket hadn't been public they probably would have been fine.
grogenaut 5y ago
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.

ipaddr 5y ago

Another grow marketing hack successful. Double if their is a lawsuit.

swdev281634 5y ago

Was not the best idea to do that. Sega is very traditional Japanese company. Consequences are likely to follow, but not the legal ones.

aaronwp 5y ago

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. All the keys and services are secure and the breach is closed.

robtaylor 5y ago
Assertive: Show me something else.
- aaronwp 5y ago
  stay tuned
duxup 5y ago
> dig out more keys I guess that if they leave them lying around that it is likely there are more.
imwillofficial 5y ago
This would be awesome as a blog post if you ever want to go into detail on how you executed each step.
- deleted 5y ago
  [deleted]
phnofive 5y ago
Is it common, now or historically, to follow up a notification of compromise with self-directed PoC and privilege escalation exercises on the resources of a company with which you're not under contract? My naïve take is that this was a series of well-intentioned but possibly criminal actions used to illustrate a lesson we could all be reminded of from time to time. Also, the HackerOne page doesn't appear to be claimed by SEGA Sammy, so notices might dead-end there as well.
- 5y ago