431–440 of 513 posts
Earlier quoted context omitted.
How so?
Because everyone makes mistakes, if you antagonize someone they are less likely to care about you and feel more obligation to protect their own.
But that's different than shaming. That's over-saturating the system with false positives. To combat this I'd encourage you to not respond, in __any__ way to bullshit fake controversy and to also give positive reinforcement for when companies do something good.
I'll give an example, you've probably seen companies like Meta occasionally do something good. For example, they released the source of LLaMA. But people tend to use those opportunities to not congratulate Meta for doing the good thing but rather complain about other bad things they do. Then yes, it fits your model, because you've reached bad steady state and you can no longer turn good because nothing you do that is good will get any signal to continue in that direction.
Us humans are weird and routinely shoot ourselves in the foot only to ask who fired the bullet, smoking gun in hand.
> If you grab the list of admin users from /orgs/0/users, you can splice a new entry into it giving you full access to their Administrator dashboard. I'm not clear on this. Splice a new entry into what? The list of admin users? And then do what with it?
I read this as worse - splice being a client side JavaScript function to add items to arrays. My concern here is whether the “is admin user” perms checks were done solely on the client side and not enforced on the API endpoint!
Earlier quoted context omitted.
[flagged]
> "remembered chattr.ai" They didn't say that, you just made that up. This is what they said: "when we remembered the existence of a scanner we made for firebase and found https://chattr.ai " And in MrBruh's post, the way they found it was scanning .ai domains, using the same scanner that Eva remembered they had made.
Earlier quoted context omitted.
The issue is it is often impossible to distinguish from a white hat or a black hat hacking your live systems. It can trigger expensive incident response and be disruptive to the business. Ethically, I think it crosses a line when you are wasting resources like this, live hacking systems. There is usually a pretty clear and obvious point where you can stop, not trigger IR, and notify the companies. Not saying that was…
> Ethically, I think it crosses a line when you are wasting resources like this, live hacking systems. I agree with everything you wrote except this sentence. There is no ethical obligation not to waste a company's time.
Earlier quoted context omitted.
The issue is it is often impossible to distinguish from a white hat or a black hat hacking your live systems. It can trigger expensive incident response and be disruptive to the business. Ethically, I think it crosses a line when you are wasting resources like this, live hacking systems. There is usually a pretty clear and obvious point where you can stop, not trigger IR, and notify the companies. Not saying that was…
The potential downside of stopping once you find a critical defect is that the company may not take it seriously unless you go just a bit further and show what you can do with the defect. In this case, showing that it gives you access to the admin dashboard.
I do agree, some of the time you need fireworks to get the right people's attention. You could argue there is some moral imperative there, but ethically you are in the wrong if you keep going. Just have to decide of the moral imperative outweighs clearly breaking the law in situations where you don't have permission.
Earlier quoted context omitted.
It’s an ineffective tool if your goal is change.
Shame is absolutely a valuable tool for change. Without it society would not function since many of our 'rules' are self-enforced.
Earlier quoted context omitted.
Full disclosure isn't something for _companies_ to do. It's what _researchers_ do. Full disclosure isn't compatible with the monetization incentives offered by companies. You're publishing in public and immediately. I think you clearly do not understand what full disclosure is.
My understanding of Full Disclosure is that researchers publish the vulnerability (and potentially exploit) publicly without coordinating with the software vendor. This contrasts with Coordinated Disclosure (sometimes "Responsible disclosure" in corporate propaganda) or No Disclosure (and potentially e.g. selling the exploit). I admittedly used disclosure in a bit different sense for companies in that companies typic…
Earlier quoted context omitted.
> It's not clear if the author was hired to do this pentest or is a guerilla/good samaritan Pretty clear to me, "it was searching for exposed Firebase credentials on any of the hundreds of recent AI startups.", running a script to scan hundreds of startups > Sadly, many companies will freak out and get the law involved, even if you are a good samaritan. Yeah, but that also ends with that company being shamed a lot of…
The issue is it is often impossible to distinguish from a white hat or a black hat hacking your live systems. It can trigger expensive incident response and be disruptive to the business. Ethically, I think it crosses a line when you are wasting resources like this, live hacking systems. There is usually a pretty clear and obvious point where you can stop, not trigger IR, and notify the companies. Not saying that was…
If your servers are connected to the internet, you can expect that people from countries that won't prosecute them will try to break in. This will happen, almost immediately, as soon as they're connected to the internet.
If your servers have been properly secured, this doesn't matter. If they have not, you are paying for that incident response regardless and the only question is if the context is today because of some innocuous kid or a month from now because of some black hats from Eastern Europe and your company's internal database of everything is now public information.
You want it to be the innocuous kid.
> There is usually a pretty clear and obvious point where you can stop, not trigger IR, and notify the companies.
This is obviously not the case.
Suppose you suspect the company could be using a default admin password. Contacting them without confirming this a pointless waste of everybody's time. Checking it takes two seconds, and if you're wrong you just won't get in and will be one of ten billion failed login attempts against a public-facing server. If you're right, the successful login to an admin account from a novel external IP address could very reasonably trigger some kind of alert, which could very reasonably trigger an incident response when the staff knows that nothing should be logging into that account from there. Or it might not, because the kind of company that uses default passwords may not have thorough monitoring systems either, but you have no way to know that.
There is no point at which it would be reasonable to contact them prior to doing the thing that could trigger an incident response.
Earlier quoted context omitted.
How do you propose such a law would work?
1. White hat submits a "Notice of Vulnerability Testing" document to target company (copy also sent to government body) including their information, what systems will be tested, and in what time window 2. Company is required to acknowledge the notice within X hours and grant permission or respond with a reason that the test cannot take place 3. White hat performs testing according to the plan 4. White hat discloses a…