Sega Europe suffers major security breach
vpnoverview.com
vpnoverview.com
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.
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 cool.
from the perspective of a colocation-specialist ISP or medium sized generalist ISP that offers colo, they get lots of weird requests for colo and dedicated server services from VPN companies they've never heard of before. often with something like a corporate entity that exists in cyprus, panama or even weirder places.
looking at this in terms of the risk that a VPN provider presents to an ISP's reputation, IP space, attracting unusual volumes and numbers of DDoS, etc... there is a certain amount of "KYC" (exact same idea as finance industry KYC) that needs to go into a potential vpn service provider as a colocation client before quoting them a price or accepting them as a customer. fail to do that at your own risk.
it's very much in the weird/shady/grey market end of the ISP market.
the level of technical acumen and professionalism varies greatly between VPN providers.
not much else...
I am biased because I do my own VPN so all of them seem shady to me.
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 the same IP.
So, what do YOU mean when you say you "do your own VPN"?
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.
> OpenVPN
No email needed for sign up either.
Wait? How is Cyprus supposed to be a weird place to incorporate?
I suppose Delaware is weird too? It’s not like anyone is actually based there.
>looking at this in terms of the risk that a VPN provider presents to an ISP's reputation, IP space
None, because you obviously make the VPN provider bring their own IPs. And even if you don’t? Just block email and the IP reputation issue is solved.
>attracting unusual volumes and numbers of DDoS, etc..
This has calmed down so so much over the past years.
> fail to do that at your own risk.
Not much risk at all as long as you make them prepay their bills. Nobody is getting depeered because they offered colo to a sketchy VPN provider.
Literally nothing can happen, the big ISPs do not give a single fuck about this.
(I don’t have any involvement with VPN nonsense, but do have extensive experience with “bulletproof” hosting)
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.
I think the rest of the sentence makes it clear the author didn't intend to support defacement as punishment.
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.
How would you prevent such negligence
The ones who are damaged by the negligence sues for negligence.
Similarly: those people who act recklessly can get sued for more, or even criminally prosecuted. Finally, someone who acts out with malicious intent can be sued / criminally charged with the highest crimes.
-----------
So in this "Sega" case: Sega can sue their security for the negligence.
Then, the hackers can be sued for something between recklessness and malicious intent.
Yeah, the law is flexible. "Justice" as a concept in the Western world revolves around both actions + intent. (With intent / state of mind in roughly 3 states: negligence, recklessness, and malice in that order).
Its a flexible system, albeit sometimes imperfect... but just applying it in a textbook manner to this case results in acceptable results IMO.
they should be punished by legal means (legal proceedings or lawsuits) and by reputational damage
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 laws apply. That doesn't mean one's right or wrong or anything like it; like I said: the laws stand on their own, respectively.
I can construct any sort of scenario such that victim blaming is always possible, when the reality is they shouldn't have to worry about their property being messed with.
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.)
This is the problem I have. They kept going without permission. Leaving your key in the door doesn't give someone the moral authority to go through your house and look for other issues.
This seems like the wrong time to bring in analogies, given that we all understand whats being done well enough to talk about it directly. Given that there were obvious problems that implied a clear and present danger to people it seems reasonable to take more immediate, more effective measures.
All the keys and services are secure and the breach is closed.
I guess that if they leave them lying around that it is likely there are more.
Also, the HackerOne page doesn't appear to be claimed by SEGA Sammy, so notices might dead-end there as well.
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 standards match HackerOne ethical disclosure standards.
Sorry, I don't understand. Why would you be hesitant to responsibly disclose it to HackerOne?
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.
Is there any limit to the vast, systemic negligence and enabled criminality which can be excused away into nothingness because the circumstances under which they were made public were problematic?
This isn't a criminal prosecution of the company who was irresponsible with user data. If the people who exposed the negligence screwed up, that doesn't mean we have to act as though that the negligence ever happened.
Demonizing the messenger while remaining silent about the message is a choice.
The point I am trying to make is the ends don't absolve the hacker from consequences. Ransomware operators often blame their victims for poor security and frame their actions as security-as-a-service.
I agree on this point. I see it as analogous to holding your allies to a standard that your adversaries are unwilling to uphold.
In this case I categorize both black hats and toxic data hoarding companies (including their techie apologist employees) as "adversaries" (though I don't assert you agree with my assessment).
> Ransomware operators often blame their victims for poor security and frame their actions as security-as-a-service.
Despicable victim blaming by the very party doing the victimizing.
I understand why advertising a VPN service can be seen as analogous, even if the scale of profiteering is not comparable.
The argument against toxic data hoarding is easier to make when untainted by exploitative profit motive.
Historically: yes.
Now: no.
> possibly criminal
Sans some sort of formal agreement (which platforms like HackerOne might facilitate), it's definitely criminal. (IMO at least not unethical, to be clear.)
Again, sans some sort of contract either one-off or platform based. If SEGA wanted a prosecution, they would almost certainly be able to convince a prosecutor to press charges. The prosecutor would certainly get a guilty verdict. (Or, much more likely, a guilty plea with a bit of prison time and stiff probation.)
This still happens from time to time in much more ambiguous situations. E.g., https://www.nytimes.com/2021/10/15/us/missouri-st-louis-post...
Fortunately, there's a bit of a gentleman's detente among reasonable white hats and reasonable companies. But if you venture much outside of the small set of companies who rely on and have technologists in senior leadership, the story changes fast.
- Don't make humiliating changes to their content
- Don't mess with their userbase
- Don't leave undocumented backdoors
- Don't damage production
If you do your best to comply with those principles, then you can make a strong argument to a judge/jury that your behavior was without malice, which will notably improve your chances of survival if someone decides the usual detente isn't palatable.
It's a dangerous game to play now, though. You're basically betting the company you tested your PoC on would rather avoid the negative PR of filing charges against you, vs. a bunch of non-technical suits who just want to see you do 150 years in Sing Sing.
You want a bounty? Talk to me before you break into my systems. Because once you do that without my permission, you have proven yourself completely unworthy of being trusted. Why should I believe that you have not installed a rootkit or other tech that you did not subsequently disclose?
You will need to be treated the same as any other criminal. If my insurance gets involved, that also probably means directly assisting with an attempt at criminal prosecution.
So, yeah, brilliant strategy. /s
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 dropped their keys.
This is the most accurate analogy I've seen in months, thank you for sharing it!
> 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?
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.
The whole world sucks: the companies who are slovenly with our data, the criminals who exploit that data when it is inevitably leaked, the grey hat hackers who "joyride to prove they found your keys" to use the memorable metaphor from elsethread, the circumstances which make probing for vulnerabilities incredibly risky because one misstep gets you a prison sentence. the resulting feast of vulnerabilities ripe for criminal exploitation....
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 to me after you've already broken in, and you will never be grated the trust required to work on security systems.
I think this whole scenario effectively is perjury. Once someone has been proven to lie, everything associated with that lie needs to be vetted (or simply thrown out), because you have demonstrated that this person cannot be trusted to tell the truth. Does anyone here think that perjury is moral or ethical? Is the scenario presented here really that different?
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.
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.
No more or less than an individual whose home was not robbed because a crime was prevented unbeknownst to them.
However, I believe that the toxic data hoarding companies collectively don't see any difference, and so they don't care if individuals suffer. The suffering of individuals when data is leaked is an externality, and it is only when forced to pay for that externality that companies would start to care.
In this regard, the black hats and the toxic data hoarders both contribute towards undermining the common good. Companies don't care if money disappears mysteriously from the bank accounts of individuals who happen to be their customers — companies just don't want to be embarrassed, as it isn't their money being stolen.
But the grey hats disrupt this state of affairs. They are truly antagonistic to the toxic data hoarders, because they humiliate them, rather than merely use them to steal from somebody else.
This status quo of companies operating unsafely, creating massive but dispersed and plausibly deniable harm, is perfectly legal. But should the public trust these companies? Should the public trust individuals who work hard at these companies to build toxic data stockpiles and cover up intrusions, rather than those who expose the harms these practices bring? Who are the "good guys"?
This isn't how a white hat should behave. At the first issue, they should have stopped, reported, and waited. At the very least, a responsible disclosure, followed by a reasonable time, then maybe public disclosure-- or just move on. Continuing to dig and steal information because someone didn't reply is unacceptable.
That's unethical and likely criminal without explicit testing authorization (which it appears you didn't have).
I wonder if there are any examples of "researchers" being sued/prosecuted for stunts like this.
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.
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.
> 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.
I listened to a vendor pitch for a product that would need access to my cloud assets. They wanted me to export auth keys as strings and hand them over, with super high access rights. I laughed and pointed out OIDC, Workload Identity Federation, cross account user identities... etc as more secure methods that didn't require handing over any secrets.
Multi-billion dollar vendor; their engineer just gave me a blank stare as if the notion was completely novel. It's not. None of the products/integrations I build require a customer to share their cloud creds to work w/ their cloud assets.
2020 is calling...
There's also SAML/OAuth2/OIDC proxies you can use along with role-specific service accounts, so even legacy app access can be audited and controlled with temporary sessions. One OAuth2 reverse proxy can authenticate entire subdomains worth of web apps. (https://oauth2-proxy.github.io/oauth2-proxy/)
If some proprietary app says they only support static IAM keys, they can easily enable the AWS SDK to transparently handle AWS STS temporary credentials. You just authenticate with some other app (say, saml2aws) and the tokens are cached locally, and the AWS SDK takes care of the rest. (You can also configure the AWS SDK's credential_process feature to make that seamless)
Cross-account AWS access can be granted to specific roles to be assumed with specific IAM policies. No keys or users at all.
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.
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.
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.
A publicly accessible S3 bucket suggests that someone mistakenly thought it was private, even by obscurity.
It's definitely not a great practice, but still it's done.
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.
> 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.