I pwned half of America's fast food chains simultaneously
mrbruh.com
mrbruh.com
In my eyes people should be free to pentest whatever as long as there is no intent to cause harm and any findings are reported. Sadly, many companies will freak out and get the law involved, even if you are a 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 time
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.
As a tool for oppression however, yes it's quite effective.
This is backed by studies.
"Using three different emotion inductions and two different dependent measures, we repeatedly found that endogenous shame motivates prosocial behavior. After imagining shame with a scenario, proself participants acted more prosocially toward the audience in a social dilemma game (Experiment 1). This finding was replicated when participants recalled a shame event (Experiment 2). Moreover, when experiencing shame after a failure on performance tasks, proself participants also acted prosocially toward the audience in the lab (Experiment 3). Finally, Experiment 4 showed that this effect could be generalized beyond social dilemmas to helping tendencies in everyday situations. Therefore, it seems safe to conclude that shame can be seen as a moral emotion motivating prosocial behavior." [1]
You can also contrast 'humiliation' shame with 'moral shame', with moral shame being prosocial. This is also backed by studies.
"Our data show that the common conception of shame as a universally maladaptive emotion does not capture fully the diversity of motivations with which it is connected. Shame that arises from a tarnished social image is indeed associated with avoidance, anger, cover-up, and victim blame, and is likely to have negative effects on intergroup relations. However, shame that arises in response to violations of the ingroup’s valued moral essence is strongly associated with a positive pattern of responses and is likely to have positive effects on intergroup relations."[2]
[1] de Hooge, I. E., Breugelmans, S. M., & Zeelenberg, M. (2008). Not so ugly after all: When shame acts as a commitment device.Journal of Personality and Social Psychology, 95(4), 933–943.
[2] Allpress, J. A., Brown, R., Giner-Sorolla, R., Deonna, J. A., & Teroni, F. (2014). Two Faces of Group-Based Shame: Moral Shame and Image Shame Differentially Predict Positive and Negative Orientations to Ingroup Wrongdoing. Personality and Social Psychology Bulletin, 40(10), 1270-1284.
A 2021 meta-analysis showed that, “shame correlates negatively with self-esteem and is large effect size.” [0] So unless the goal of your shame is to actively harm the people involved, then no, shame is not an effective tool at behavior change, given the damage it causes.
You may be thinking of “guilt” rather than shame:
> In sum, shame and guilt refer to related but distinct negative “self-conscious” emotions. Although both are unpleasant, shame is the more painful self-focused emotion linked to hiding or escaping. Guilt, in contrast, focuses on the behavior and is linked to making amends. [1]
One has to do with self-esteem, which has nothing to do with whether it is pro-social or beneficial, just that some types of shame harm self-esteem, which was never contested.
The second study is about criminal populations, and I specifically mentioned that shame is about self-policing, and that obviously didn't work if someone is incarcerated for a crime.
And criminals aren't some ungovernable animals...
Yes, your self esteem will likely be harmed if you do something bad and it gets found out.
> And criminals aren't some ungovernable animals...
?
Shame makes people feel bad, so we must do all we can do avoid making anyone feel that.
What's next? Is "disappointment" next? Having someone disappointed in you feels bad, therefore no one can ever show disappointment to others?
As you are demonstrating, shame is more about causing pain than changing behavior. You seem to want to hurt people, and that’s one reason why shame is not effective. You don’t care that equally or more effective means exist for improving behavior.
> So you admit that shame can be bad? Then you’re close. Next you need to realize that shame’s effectiveness is dependent on a person feeling shame the way you want them to. But that’s not how it actually works, is it? Instead, shame is sourced from the judgements of others, so one way of effectively mitigating shame is to hide the behavior from others, rather than stopping it. So shame is ineffective.
I never claimed that shame couldn't be bad -- I said it is essential for society to function properly. I cited two studies which demonstrated that shame can be prosocial and beneficial depending on circumstances.
> And I’m not being silly. You tried to dismiss the legitimacy of my citation by dismissing an entire category of people. That was inconsiderate.
I dismissed your studies because they were both irrelevant to my point and did not contradict anything I cited. If you feel that I am othering prisoners because I said that the situation of the people in the study made it useless to make your point, then I object to that and say that you are grasping at straws since you have no reasonable argument otherwise.
Look, you have every right to be absolutely wrong in this case, so don't bother changing your mind or looking at my actual standing on the issue and instead imagine I am some kind of meany pants who wants people to feel bad if you want, but I am done with this conversation.
And one of the clearest indicators to me that a person knows their argument is weak is when they declare themselves correct (or me wrong). Of course I’m free to be wrong, the problem you have is you’ve done a terrible job demonstrating that fact.
(See how your attempt at shame failed? That's why shame is not a useful tool.)
Even if you think I am an asshole, self-reflection can only be beneficial. One thing that may be helpful is to take a look at your actions over the thread and think about it from the other perspective, and seeing how you may appear from someone else's point of view. I do that often and though it isn't always pleasant, it does give a reality check in some key areas.
Refusing to acknowledge that other people have valid arguments and continuing to repeat the same thing over an over again is indeed 'unbeatable'.
People then ceasing to continue to argue with you because you aren't listening to them is them recognizing they are wasting their time.
And you made a value judgement about the people who end up in jail/prison, which was completely uncalled for.
> And you made a value judgement about the people who end up in jail/prison, which was completely uncalled for.
You are being silly.
And I’m not being silly. You tried to dismiss the legitimacy of my citation by dismissing an entire category of people. That was inconsiderate.
shame as a tool of change does not work on the person being shamed at the time, it works on that person for the future hopefully as they will be afraid to be shamed again and it works on changing the behavior of other peoples because they don't want to get shamed either.
Thus as a tool of oppression, as you pointed out, it works great. But also as a tool for enforcing otherwise non-enforced social rules - until of course you meet someone shameless or who feels at least that they can effectively argue against the shaming.
You are correct that I didn't provide supporting reasons myself. Fair point. I suppose I didn't think your comment warranted it. Saying that might come across as harsh, which isn't my goal. I'd rather shift into a constructive and specific discussion instead. In that spirit, I'll elaborate on my criticism. Let's start with your leading sentence:
> Nope, shame is ineffective as a tool for change.
There are lots of ways to improve this sentence; here is one suggestion: consider a phrasing like "In comparison to _X_, shame tends to be less effective for _particular purpose_."
I'd suggest avoiding empirical claims about likelihoods you aren't able to defend. Take this sentence fragment:
> More often people shut down or ignore you if you attempt to shame them...
If done forcefully, this _might_ lead to "shutting down" or "ignoring"; however, on what basis can one say this happens "more often"? More often than what? The writing here overreaches -- this is why I called it "overconfident".
There are many situations where one person points out a shameful behavior in another, who recognizes it, feels bad, and i.e. apologizes and modifies their behavior. My point: it would be faulty to dismiss the idea of shame as useless in social contexts.
Finally, the next sentence also struck me as an overreach:
> As a tool for oppression however, yes it's quite effective.
Care to elaborate your thinking on that one? What do you mean by oppression?
By oppression I think of a power dynamic where the weak are kept in a lower position by the more powerful. Is this what you mean? Why do you think shaming is particularly effective way to oppress? In my mind, military, physical, legal, and economic mechanisms tend to be more effective, historically speaking.
I could speculate. Perhaps you are referring to the practice by certain religious systems to make people feel ashamed for merely doing things that all humans do (make mistakes) and thus deserve punishment (e.g. by the religious elites, or worse, by yourself, thus making yourself feel weak and unworthy).
In short, I'm sufficiently enough in these ideas to be rather unsatisfied with writing that doesn't unpack the ideas at all. No offense intended. I look forward to learning what you mean.
If you were trying to show some of the worst faith engagement possible on HN, you did it.
> According to cultural anthropologist Ruth Benedict, shame arises from a violation of cultural or social values while guilt feelings arise from violations of one's internal values.
> In sum, shame and guilt refer to related but distinct negative “self-conscious” emotions. Although both are unpleasant, shame is the more painful self-focused emotion linked to hiding or escaping. Guilt, in contrast, focuses on the behavior and is linked to making amends. [0]
Sure, but large businesses entities (as opposed to individuals) often cannot afford such luxury.
Try being a bank in a western country and ignoring a public security blog post, outlining exactly how one can exploit your online banking auth flow to gain unauthorized access to customer accounts.
Risk of what? Risk of losing credibility and revenue due to… people shaming them, perchance?
Prejudice is rooted in lack of knowledge and unfamiliarity. Racism is familiar and has it's own body of knowledge; all wrong, but vehemently defended. Racists try to build their own narrative.
"Never believe that anti-Semites are completely unaware of the absurdity of their replies. They know that their remarks are frivolous, open to challenge. But they are amusing themselves, for it is their adversary who is obliged to use words responsibly, since he believes in words. The anti-Semites have the right to play. They even like to play with discourse for, by giving ridiculous reasons, they discredit the seriousness of their interlocutors. They delight in acting in bad faith, since they seek not to persuade by sound argument but to intimidate and disconcert. If you press them too closely, they will abruptly fall silent, loftily indicating by some phrase that the time for argument is past." Jean-Paul Sartre
Shame is so effective when it actually lands that you can never fully deprogram it -- I will live with my Catholic guilt for the rest of my life.
This is why words have meanings. Companies aren't people and hence "shaming a company" can't possibly mean "shaming the legal entity" because that's nonsense but instead shaming the humans that make up that legal entity. Saying such a thing is impossible actually treats the company as an autonomous metamind.
I interpreted what you said as nonsensical and I'm making that your problem isn't really an argument.
> Running to the press never helps.
Except of course, in reality we know that it ABSOLUTELY DOES. In fact, it has been often times the ONLY thing that has helped.
Ask Troy Hunt: https://www.troyhunt.com/the-effectiveness-of-publicly-shami...
Says some pests
---
Shaming for businesses and politicians should be encouraged, not just warranted.
Product Recalls are a form of corporate shaming, but public discourse about companies or politicians should be encouraged, and shaming them should always be warranted.
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.
Those who are tasked - and are being paid(!) - to "[do] a cybersecurity assessment" will typically be given a brief.
For those who aren't tasked - or being paid(!) - to do this stuff, things are much less clear. There's no defined target, no defined finish line, no flag you have been requested to capture.
(I don't work in cybersecurity now, but <cough> I did get root on the school network way back when, and man, that took some explaining..)
When we begin any assessment on a production system we have a very clear discussion about the rules of engagement. But we are often authorized to access data someone that is not authorized can't legally access with their unauthorized bug hunting. Once you have some experience and understand the relevant laws it is pretty clear when you should stop without violating the law. The general threshold when you are authorized is that you stop if it would risk the stability of the system. If you aren't being paid the general rule is once you have accessed others' PII you need to stop. If you broke an authorization control or accessed any functionality a regular user can't, you need to stop.
Gaining root to any network you don't own or have authorization to operate is clearly crossing the line. You went from finding issues to actively exploiting them. If you have to actively exploit to find an issue and you don't own the system and you don't have permission you don't do it.
Q: As an attacker - whatever colour your hat - how are you supposed to know if any particular action may gain you root unless/until you try it?
I agree with everything you wrote except this sentence. There is no ethical obligation not to waste a company's time.
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.
It really is though. People just don't understand the ethics of white hat hacking.
> Suppose you suspect the company could be using a default admin password
Putting in that password on a system you don't own without any sort of permission to do so is very clearly against the law. You are accessing the system without permission. You just walk away if you want to be ethical about it.
The only ethical path is to let them know you have some reason to believe they are not using secure passwords or whatever. Accessing their system illegally is not the move. It just isn't the white hats problem.
People just think they understand ethics, even if they don't.
"Don't break the law" is an incredibly poor foundation. Many laws are ill-conceived, ambiguous, overly broad and widely ignored or manifestly unjust. Using this as the basis for ethical behavior would require you to be unreasonably conservative and pedantic while regarding complicity in an injustice as ethical behavior. (It also implies that you could never use ethics to inform what the law should be, since it would just tautologically be whatever you make it.)
"Don't knowingly cause net harm" is at least as valid, but then admits the possibility of curiosity-based shenanigans that could lead to the revelation of a vulnerability that saves innocent people from the consequences of it being later exploited by someone nefarious.
> Putting in that password on a system you don't own without any sort of permission to do so is very clearly against the law.
Driving 1 MPH over the speed limit is very clearly against the law, even if the orphanage is relying on you to have the funding letter postmarked by end of day.
Walking your date home while you're intoxicated is very clearly against the law (public intoxication), even if the alternative is that they drive themselves home while intoxicated.
Ethics is something else.
> The only ethical path is to let them know you have some reason to believe they are not using secure passwords or whatever.
But you don't, really. Your belief may even be purely statistical -- suppose you expect that if you try the default on many servers at different companies, there will be at least one where it works, and you'd like to report it to them, but you have no idea which ones unless you try.
> It just isn't the white hats problem.
If you have the capacity to prevent likely harm and instead do nothing, what color is your hat?
The web is insecure enough as it is, I just want to do my part to make it that little bit safer :)
The bad guys don't play by the rules so the rules only hinder the good guys from helping. I think Internet security would be in a better position if we had legislation to protect good samaritan pentesters. Even moreso if they were appropriately rewarded.
or care even less about shipping secure code?
Pass.
It's quite the thing.
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 any findings to the company (keeping government body in the loop)
5. Company patches systems and may reward white hat at their discretion
6. Government body determines if fines should be applied and may also reward white hat at their discretion
https://www.ftc.gov/news-events/news/press-releases/2023/11/...
What matters is if the thing they're doing to test your security is similar to what criminals would do to breach your security.
In the case of a physical location, that bar is low. It's things like seeing if your garage door is open, or your car doors are locked, etc.
In the case of computer resources, that bar is high. Probing your database for permissions holes is absolutely something that a normal "cyber criminal" would do. It's the equivalent of a carjacker looking to see if your doors are unlocked.
So an "online neighbor" alerting you that your database is unprotected doesn't feel weird at all. It's not the equivalent of that weird laser pointer thing you talked about, it's the equivalent of looking to see if your car doors are unlocked while you're away on vacation.
As someone else mentioned this would be more akin to a security officer of some sort waking me up and letting me know I left my front door open. I'd sure as hell be shaken but they were doing their job and I'd be thankful for that.
If i leave that filing cabinet in the middle of Times Square in Manhattan (which has an insane amount of foot traffic every day), then yes, I would expect plenty of people to give it a little wiggle to check if it’s locked. And I would be rightfully given a lot of questionable looks for complaining that passerbys stop to check it out or give it a wiggle.
Having your service on the internet is not the same as having a filing a cabinet in your house. I think that the Times Square analogy is even underplaying it, given that on the internet, your audience is many many magnitudes larger and more remote/anonymous.
On the other hand, if I had a private VLAN (that wasn’t exposed to the internet) on my home network, then I would be definitely annoyed if my houseguests would try and pentest it without asking.
There is a big difference between the digital world and the physical one. Many actions e.g stealing are very different in these 2 worlds and have very different implications.
If a neighbor came to me and said, "Hey, your mailbox that's located at the end of your long dirt driveway is protected by a wafer lock that can be opened by simply slapping the side of the mailbox in a funny way," I would maybe wonder why they were slapping my mailbox but I would be grateful that they told me and I would want them to continue doing whatever weird shit they were doing (so long as it wasn't causing damage).
When you put property in a public (or practically public) space, there's an expectation that it will not be treated as though it is on private property. There's a big difference between someone jiggling the door to your home (where you physically reside) and jiggling the lock on a mall gumball machine or the handle on a commercial fire exit.
The internet is like the former not the latter and taking a moral high ground stance that it just should be otherwise is just screaming underwater while doing nothing to actually protect yourself from an actual real threat.
I'd be very thankful if I moved to some place I'm unfamiliar with where people lockpicking is just a cultural norm and someone warned me I should get a better door.
I wouldn't even consider this "hacking" really. If prosecuted a defense attorney familiar with both the technology and the admitted niche area of computer crime law can readily conduct some very effective cross-examination against whoever the state is bringing out as a witness. The government does frequently rely on the lack of tech-competent and accessible counsel as a way to exert coercion (and usually resulting in a plea), and it doesn't help that the layperson has a very difficult time figuring out what qualities constitute competency when looking for attorneys (hence the enduring popularity of jingles since being memorable is frequently mistaken for being competent), but they are out there.
Make a tool which will look at the list of all the franchises within radius of person, and have it auto submit applications to all of them simultaneously...
I’m curious what the limits are
I don't see how this "p0wns" the companies themselves
If you can't view the images then it means you are likely using an outdated browser, all current versions of browsers support it (afaik) except Internet Explorer.[0]
...And if you are using Internet Explorer, then god help you.
I had a moment of total freakout when I realized the person across from me at lunch had an iPhone on the table. Actually he had an Android, and we continued talking like no big deal.
To be clear, we were talking about a 10-100M dollar problem, this wasnt small potatoes.
Too many exploits, I can't imagine having anything of value on an iphone.
Why?
> 06/01 - Vulnerability Discovered
> 09/01 - Write-up completed & Emailed to them
> 10/01 - Vulnerability patched
Note those dates are DAY-MONTH. At least they patched it within a single day.
I find it funny that the author found a massive vulnerability but chose to wait a couple days to report it so they could finish a nice write-up.
Reminds me of my experience with HackerOne: We had some participants who would find a small vulnerability, but then sit on it for months while they tried to find a way to turn it into a larger vulnerability to claim a higher prize.
Then when they finally gave up on further escalation and submitted it, they'd get angry when we informed them that we had already patched it (and therefore would not pay them). The incentives in infosec are weird.
They couldn't even be bothered to send a proper thank you.
The only email listed on their site was for the sales team which would not be checked on a weekend.
* They were just trolling Firebase accounts for anything left open, and the first hit was a company that works with a bunch of American fast food chains. That doesn't require OP to live in the US.
* They specified "America's fast food chains"; someone living in the US probably wouldn't qualify it with "America's".
* They used a $DAY/$MONTH date format, which is uncommon in the US.
I call that US-centrism. Quite annoying to non-Americans living in the States.
From a bug hunters perspective, certain issues are often underpaid or marked as non-issues (and then subsequently fixed without paying out) so it’s in their interest to find a chain of issues or explore to show real impact.
Then from the programmes perspective you have to content with gpt generated reports for complete non issues so I can also understand why the might be quick to dismiss without hard impact evidence rather than a “potentially could be used to”
I am not against bug hunting by any means, but if you want to me act like I care about your product and not about my money, pay me monthly.
The reason most people have converged on a preference for salaried work is that most jobs don't actually need consistency to be useful, but most people do need consistent pay to focus on a job
I have never found out if this is a side gig, a full-time job, or a hobby for people.
You don’t make HackerOne your primary source of security testing. It’s a fun thing you do in addition to your formal security work internally.
The reason people do it is because so many people expect or even demand payment and public recognition for submitting security issues they found. Just look at how many comments in this thread are insisting that they pay the author various amounts of money. The blog post even has a line about how they have not provided recognition (despite being posted exactly on the day it was fixed, giving the company almost no time to actually do so).
HackerOne style programs provide a way to formalize this, publicize the rules (e.g we pay $25K for privilege escalation or something) and give recognition to people finding the bugs.
Pentesters like it not only because they get paid, but now they can point to their record on a public website.
This isn’t a “gig economy bad” situation.
The incentives in infosec are weird.
Much smarter folks than me have been saying it for decades.
Do you even know what Full Disclosure is?
Yes, I know what full disclosure is. Companies don't do full disclosure about anything. Full disclosure is better than not disclosing publicly. But monetizing the vulnerability is akin to what companies do.
I find it utterly bizarre that it's totally OK and even lauded that companies are selfish profit maximizing machines that DGAF, but individuals should pamper them like babies.
I think you clearly do not understand what full disclosure is.
I admittedly used disclosure in a bit different sense for companies in that companies typically don't give out any (truthful) information they have if they aren't required by law. And they lie when profitable.
The symmetric action from a researcher is to sell the exploit to the highest bidder. Of course if the researcher wants to do other disclosures, that's fine too. But what I don't like is the double standard that researchers are scolded for being "unethical" but companies, by design, not caring about ethics at all is just fine and the way it should be.
Considering that there is “more than one way to skin a cat”, it is not a given that vulnerabilities further along the chain will be resolved by closing the initial vector.
When a chain of vulnerabilities is reported it might become clear that not only does the initial attack vector need to be closed, but additional work needs to be done in other areas because there are other ways to reach that code which was called further along the attack chain.
Nope! The two vulnerabilities are usually one and the same. The person is just trying to find a clever way to access additional data to make their payout larger.
From the customer perspective, getting the initial vulnerability fixed ASAP is the best outcome.
When they start delaying things to explore creative ways to make their payout larger, everything goes unfixed longer.
Maybe it's because the write-up was well written that they could patch in a day?
That's what you'd expect: finding != understanding, and you need some understanding before you can submit a sensible, actionable report to the vulnerable party. And then you need to write it up in a way that will be understood by the recipient. Going from initial finding to submitting a detailed report in a few days is excellent turn-around time.
Well - only the amateur infosec world where you try and force someone to be your client after you do the work, and then get butthurt when they don't become your client.
In the professional infosec world the clients choose to hire you first.
Forget the pwn how do I do this
Also, HN used to think this was cool now there are 20 posts blaming the hacker…
sudo apt install pulseaudio-utils
./some_script ; paplay /usr/share/sounds/freedesktop/stereo/complete.ogaFun fact: the `bell` control character is part of the ascii standard (and before that the baudot telegraph encoding!) and was originally there to ring a literal bell on a recipient's telegraph or teletype machine, presumably to get their attention that they had an incoming message.
To keep backwards compatibility today's terminal emulators trigger the system alert sound instead.
\u0007
#!/usr/bin/env zsh
(mpg123 /path/to/processing3.mp3 > /dev/null 2>&1)
then it's just `./foobar.sh && boc` or `./foobar.sh; boc` as appropriate.
beep() {
if [ $? -eq 0 ]
then
file=/usr/share/sounds/purple/receive.wav
ret='true'
else
file=/usr/share/sounds/purple/alert.wav
ret='false'
fi
(aplay $file 2>/dev/null >/dev/null &);
$ret
}
$ command ; beep
This depends on the libpurple sounds to be where they are (works in ubuntu at least)
I'm not sure whether it's HN thinking this is uncool (it is cool!) or it's HN taking the unfortunate realistic position that this type of stuff only gets the reporters into trouble, after seeing it happening time and time ago. People doing cool stuff get in trouble, and it's sad to watch.
./myscript.sh; curl -d "Script done" \
ntfy.sh/mytopic
[1] https://ntfy.sh/ + https://github.com/binwiederhier/ntfy
This guy just grabbed publicly available information, and by 'public' I mean put out onto the web un-protected, just put out there. If you can just basically browse to something, is it really his fault for finding it.
It's like if I have a front door on my house, and just in the front hallway I have a huge naked picture of my wife. If I leave the door open, can I get mad at pedestrians walking by, for seeing the picture. Maybe they walkup to ring the door bell just to get closer look, walking up to the door, but not going in, is allowed.
I think the law is pretty wrong.
It means I can break law by just accidentally browsing to something. Can be breaking the law just by seeing it, before knowing I'm doing something wrong.
Basically, just see something and be guilty before being able to look away.
Fish config: https://github.com/qznc/dot/blob/master/config/fish/config.f...
Notification script: https://github.com/qznc/dot/blob/master/bin/notify_long_runn...
I stole it from some zsh solution originally.
It is meant to be used after a command or a chain of commands to give feedback about success or failure. The alias by itself doesn't issue a ping, but can easily be amended to do so.
What worked for me is to add an invocation of `paplay`. Actually it is two different invocations, one sound for success and another one for failure.
In addition to that I also send an ASCII 0x07. I have both `tput bel` and `echo -e "\a"` in my alias, but don't remember why. Probably one of them is enough. I do this because I have my terminal emulator set to visual bell an that causes the tab to change color when the command is finished and I can immediately see it even if I am in another tab.
For anyone who's never used Firebase before this is as simple as a single piece of logic that appears basically as:
if authUserID is UserDirectoryID
That simple.
That seems like an insane design...
It sounds like the rule that they wrote only checked that the request _is logged in_, because they assumed that visitors can't create their own accounts.
Correct. :/
The fact that the company/CEO/cto seems to just get away with this is depressing, because why should anyone else? it's not good business sense to invest in security if there's no serious repercussions
> When the user requesting access isn't signed in, the auth variable is null. You can leverage this in your rules if, for example, you want to limit read access to authenticated users — auth != null. However, we generally recommend limiting write access further.
Title is misleading.
The right people will read it (Chattr.ai’s customers) and respond . Right now everyone looks at it and some CISO will overreact and make everyone go check their Firebase configurations which may likely be a non-value add.
Personally I feel the title is justified but I understand and respect your viewpoint.
Also keep in mind that trying to clarify the such would also make the title much longer than I desired.
That’s what you should call it. It explains to readers what’s going on without over sensationalism.
That isn’t too long either.
By this argument, getting access by phishing a company employee also wouldn't count as an attack on the company.
These companies are responsible for their employees behavior and data but they are not responsible for nor legally liable for (in most cases, some exceptions apply) the actions of a third party that they have retained to help with hiring.
In fact the contract they have with said third party likely absolves them of any liability.
The title should be: I owned an AI startup via Firebase misconfiguration.
You can even name the startup if you want. That’s not flashy though and this person wants marketing.
Naming and shaming does work.
Firebase.database().ref('/').set('All your data is gone').
Better yet, download the whole DB and then:
Firebase.database().ref('/').set('I have all your data, pay me to get it back').
Or is there some weird loophole of "We didn't take action because of your message. We just happened to patch the same vulnerability after you mentioned it. We are not aware of any penetrations, because we didn't notice your message"?
Nobody knows.
But between taking an unknown legal risk, vs being seen as ungrateful, the choice for legal is quite clear.
I totally understand how you feel though.
Seems well funded companies are immune from data liability or responsiblity.
also wikipedai as a list of major data breaches https://en.wikipedia.org/wiki/List_of_data_breaches.
Are those the documents, often dozens of pages of barely understandable legalese word salad, that we've conditioned nearly everyone to click past?
While I certainly agree that people share way too much data, I personally think hiding behind "it's in the terms of service agreement" is getting quite tired when they are designed in such a way that you are encouraged to skip past it, and they are worded in such a way that a lay-person doesn't have a chance of understanding what the ramifications of agreeing to the agreement is.
Not to mention that, quite often, you don't really have a choice in the matter if you want to have a relatively normal life (e.g. being forced to agree to the terms of service of some random service to submit an application to a job, and not having a job isn't an option).
Where does your entitlement come from? I bet working in tech too long.
It's related in the same way that I can say "nothing matters at all" in reply to literally anything. Which is to say, very loosely, and entirely lacking substance.
"Hi, we have fixed the issue you reported to us. Thank you so much. We are willing to offer a reward of <x> dollars to you, because you have protected our customers. Please reach out with a payment address or any other questions you might have. Thanks again, Tim from <Large corporation>"
and... stop timer. 11:27:38
was that so hard?
NOTE: I am not a legal professional, just making my guess.
Forcing function would be cyberinsurance policies that typically want to see audit results if you have multi-million dollar policy limits.
It will just be FTC knocking on your door…
It’s very basic. There’s no best practices clauses it’s all “reasonable” clauses. Also no requirement for an external audit.
That redirects to https://www.careersatsafeway.com/desktop/home -- which is very much not about jobs at safeway -- appears to be an Indonesian gambling/gaming site.
Safeway.com has zero email contacts published and expects communication to be via phone call or chatbot. I found their domain admin email and sent them info with no response, and no change to their site behavior.
This makes me think that they might be ripe for more monkey business but that's not my thing. Oh well.
I was tempted to find their CTO on linked in and post a message there, along with the fact that there was no reply to my outreach nor a proper channel to do so.
I think the only think in their defense is that they must get a lot of angry customer messages and they just don't want to deal with that.
But as noted elsewhere, it's still not fixed.
And the link you shared is a good thing but is that going to be easy to find to someone who sees an issue with your websites? I'd recommend putting a link here: https://www.safeway.com/help/contactus
I've done enough here but ffs, if that form requires an account to be created beforehand then don't let the submitter go to the trouble of filling it out and then discard it.
Other than this security vuln, the issues vs. just using postgres are:
* It is more work! Despite being a backend as a service it is much less code to just write a simple API backend for your thing both in time to do it and time to learn how to do it. Think of Firebase as being on the abstraction level of Sinatra or express and you may as well just use those. Things like Firebase and Parse etc. are more complicated. For the same reason it is more complicate to walk to work with just your arms and no legs (even though there are fewer limbs to deal with and no backend!).
* Relational is king. Not being able to do joins really sucks. Yes you need to make async calls in a loop. NoSQL is premature optimisation.
* Lots of Googlization. This means lots of weird, hard to find out clickops configuration steps to get anything working. Probably why this security flaw existed(?).
* Emulator is flakey, so for local dev you need another cloud DB, and yes all that Googlized setup RSI inducing clickops.
* I reckon it is slower than postgres at the scale of starting a project. Traditional architecture are blitz fast on modern hardware and internet. Like playing a 90s game on your laptop.
* Apparently as you scale it gets pretty pricey.
The main thing is: it actually slows you down! The whole premise is this should speed you up.
EDIT:
loud buzzer
Careful, Icarus: "permissions can be setup to allow global read-writes" is a "vuln" of every system.
p.s. Any comment on why her blog has you guys "remembering Chattr" then getting a seedy Firebase pwner GUI, and yours has you diligently looking through .ai TLDs?
Sorry, but supabase has a similar issue.
Another blog going over that has or will be made by Eva (referenced on the site)
If you take this approach, it's "pay now or pay later".
-- Fellow millenial
One particular thing that annoys me with SB is that by default, or when you create a table with SQL, they're publicly accessible, which is very bad! (Firebase defaults to no access in production mode.)
It's front-and-center constantly, and has _all_ access disabled by default on tables every time I use it.
I guess my main concern is that it's hard to setup RLS correctly using SQL. Because it's two separate statements, if your `CREATE TABLE` succeeds, but the `CREATE POLICY` does not, you're also exposed. And it is more annoying than it should've been to test the rules (Firebase has a dedicated tool for that).
I now just use Supabase to host a normal Postgres that only my backend connects to. That works well.
I did find it a footgun that creating a table through SQL was not private by default. (Why doesn't Supabase apply RLS by default to tables created through SQL?)
Serverless also turned out to be more trouble than it was worth. In particular:
* Doing DB business logic in JS is gross.
* It's tricky to secure a table to be semi-public. e.g. you have a bookmark site and you don't want users to browse all URLs, just the ones they have bookmarked. The best solution appears to be disabling foreign-keys until transactions are done and then having a complicated policy.
* It's a pain to set up a CLI client that interacts with the DB. I think you have to copy-paste the access AND refresh tokens to it. I couldn't figure out a way to create my own API tokens.
A backend is nice, because it is private by default.
Your confusion probably stems from how you can have RLS disabled, or RLS enabled with no policies. If you have RLS enabled with no policies, the access is restricted. But if RLS is disabled (or never enabled!), then your table is blasted to the entire internet.
This confusion kind of proves my point; if DB access from untrusted clients were baked into SQL since birth, RLS would probably be enabled by default.
The comment chain went long enough that I got confused and thought I was missing something, I started a brand new account, brand new project, brand new table, RLS is enabled by default, has a big recommended next to it highlighted, it is checked, the entire section is highlighted, and has documentation right below it. Source: https://imgur.com/a/X9oJ2i9
It's enabled by default, quite forcefully so
but I'm not a Postgres admin, maybe there's a stronger way you know of to enforce it, so you can prevent the footgun of CREATE TABLE?
Whether it's a "vulnerability" or by design is another question, but it's definitely a footgun (particularly for new Supabase users that use an ORM like Prisma, which has its own UI and creates tables by itself).
The solution might just be to not let untrusted clients access your DB.
I’m using supabase as “just Postgres” at the moment and the only access to the data comes from a server I control.
Could you explain how my data is being “blasted to the internet”?
Genuinely concerned if I’m grossly overlooking something.
Yes and no ;)
The original release of the Realtime Database didn't have security rules (though they were thought of at the time), and they were added in late 2013/early 2014 (IIRC). At that point, in the name of "easier getting started experience (don't force users to learn a custom DSL)", the default rules were `read: true, write: true`. As you might expect, it resulted in a high potential for this type of thing, and sophisticated customers cared _a lot_ about this.
This changed at some point post acquisition (probably 2016?) when the tradeoff between developer experience and customer security switched over to `false/false` (or picking something slightly more secure than `true/true`.
Firebase Security Rules were upgraded and added to Firebase (Cloud) Storage and Firestore, with both integrations being first class integrations, as _the whole point_ of those products was secure client-side access directly to the database from day 1.
The tricky part of all of any system in this space was designing a system that's simple enough to learn, highly performant, and also sufficiently flexible so as to answer the question "allow authentication based on $PHASE_OF_THE_MOON == WAXING_GIBBOUS" or some other sufficiently arbitrary enterprise parameter. Most BaaS products at the time optimized for the former, then the latter, and mostly not the flexibility; however, over time, it turns out that sufficiently large customers really only care about the last one! Looks like Firebase solved this recently with auth "blocking functions" (https://firebase.google.com/docs/auth/extend-with-blocking-f...) which is sort of similar to Lambda Authorizers (https://docs.aws.amazon.com/apigateway/latest/developerguide...), which I believe is a pretty good way of solving this problem.
Disclosure: Firebase PM from long ago
Question is how much effort that is. It's scarily easy on Firebase, idk about Supabase.
What I found is you are right and FB is easier for the Millennial, Gen Z, Boomer or whatever IF everything you need can be done by rules and schema.
As soon as you need to write functions (because rules are not sophisticated enough or too slow/expensive, or you want to know why the thing got denied) then you are writing backend code.
It is actually easier to write the same code in a NextJS template - like there is less to learn, less docs to read. And then chuck it on Vercel which will deploy and devops it for you. So you have all the devops done for you like Firebase would and you have spent less time. Now if you are talking to postgres instead of firebase from the backend, it is actually easier IMO. A line to connect to pg. A line to issue a query.
Guess this is just my opinion, but it is less code to do so, less environment variable farting around, downloading a weird .json with all the credentials. If I were inclined I would write a blog post showing how much less lines of code are needed, how much less understanding is needed, and with the managed infra/DB offered by Vercel etc. you are still serverless, etc.
Firebase is not an alternative to Postgres alone. You need an actual API server. The value of Firebase is you don’t need that, nor do you need to worry about ops, authentication, queues or other things.
The issue the OP found could have been easily fixed by simply reading the docs, but that seems to be a rare activity these days.
The hard work of using Firebase’s apis, libraries, reading it’s docs (which are detailed but badly organized) is more than the delta between not needing a backend. And for a non trivial app you will end up using functions: infact if you want a guarantee that your user has a name then you will need to write a function. And that is… a backend, like writing an app.route statement.
There's still nothing that holds your hand through a proper client-server interface, good relational schema design, and all the glue in between. Partially because nobody agrees on what those are.
And yes, there is such a thing as relational data. If you do not believe this then you really shouldn’t use Firebase (or dynamodb for that matter).
Putting aside the problem between chair & keyboard.
Another difference is more if you make a mistake in your relational schema, you can SQL your way out of it - add an extra join or group by. And you can also fairly easily migrate you way out of it to a new schema that is the right structure.
This requires actual code with firebase, and a lot of patience, and probably a lot more downtime. So you need more of a waterfall approach, I would suggest, to design a schema ahead of time, and know all of your requirements. NoSQL document-oriented schemas just aren't flexible (unless the DB supports something like materialized views to help you get out of it)
Regarding Postgres, that is where tools like PowerSync (disclosure: co-founder) and ElectricSQL are useful, which are both sync layers for Postgres for offline-first architecture.
On top of the Googlized clickops, there's the whole Firebase vs Google cloud situation, where you end up having to drop down to "real" google cloud for certain specific features. The docs appear to be detailed but you often end up with more questions than answers.
If you are ever thinking about using firebase, give Supabase a try. The emulator works well, the dashboard is there for prototyping but you can just write SQL to clearly define your database and migrations. Since it's just postgres you have a clear route to leave Supabase if you should ever want to.
I’m not at Google anymore but I was a core contributor to the Firebase emulators project when I was. I can think of many flaws with the emulators but flakey is a new one to me
Something like DynamoDB can be great for simple data. I liked the idea of Graphql (technically the API query and not the database). Both of them turn into hot garbage once you get into complex data, especially if it's being aggregated from multiple sources. Or maybe the systems I work with just implemented them poorly.
Key words right there. The relational model is a timeless mathematical model for data that gains both logical consistency and adaptability as a result. It has and will continue to stand the test of time.
Can you give an example of a query that cannot be expressed well in relational algebra, but can be in SQL because it deviates from that?
But what was in question is why SQL is the standard. Did it take that position because of its deviation? If so, that would suggest the theory doesn't just work. Without actually profiling, I suspect that the deviation allows some real-world optimizations to take place, enabling SQL databases to be faster than something with strict adherence to the theory. That would be a good reason why you might have to choose SQL over a strict alternative.
> Can you give an example of a query that cannot be expressed well in relational algebra
Seems not. CloudFlare blocked the submission, complaining that I was submitting a SQL query, which it thinks is a security concern for some reason...
In lieu, just think about what a relation is and how SQL is not relational. Even some of the simplest select queries you can imagine can demonstrate your request.
The simplest SQL queries map perfectly to relational algebra, so I'm still unclear as to what you had in mind. The two major deviations that SQL has over strict relational algebra are non-uniqueness of rows in a table, and NULL. The first one rarely comes up in practice, and any bag of non-unique rows can be trivially mapped to a bag of unique tuples simply by adding synthetic IDs to them. And SQL NULL semantics is widely considered to be a mess even by many users of SQL itself. With respect to performance, NULLs can be implemented very cheaply while optimizing their relational equivalent (1:0-or-1 relation) requires a little bit more effort on the DB side, but it's still such a simple pattern that I don't see a problem here.
Then wouldn't we be using LINUS today rather than SQL? "Viable" is quite hand wavy, so maybe you don't consider MRDS to have been viable enough for some reason. But even once relational databases were moving into the mainstream, there was no clear winner between SQL and QUEL for quite a long time. Even what is arguably the most beloved DBMS of all time, Postgres, picked the QUEL horse originally.
But SQL was generally considered easier to understand for the layman, perhaps in large part because it was less strict with respect to the theory. This may be another reason why it won.
> Similar to how JavaScript became the standard PL for browsers.
I don't know how similar that is. I'm not sure there was ever another realistic alternative you could have ever chosen. The only real attempt to change that, VBScript, was likely to not work half the time due to not having the right dependencies on the host system, making it impractical for real-world use.
Maybe not anymore, but for a time there were practical alternatives to SQL.
> The first one rarely comes up in practice
The first one is the most common source of SQL bugs I see out in the wild. Complex joins can become quite unintuitive because of it. Nothing you can't learn around, and of course work around, but something you have to always be mindful of. As such, I'm not sure I agree that it rarely comes up in practice.
Not to mention I see a lot of people making use of that fact. It is a useful quality in practical applications. It also comes up quite a bit in practice because, frankly, often you don't want rows to be unique.
I think it would be more helpful if you could give a specific example of a simple SQL query that does not map nicely to a relational expression, since it's kind of hard to discuss the specifics in these vague terms.
The discussion is about why SQL became the standard. Being first is not it. It wasn't first. It was second, but QUEL came along hot on its heels before SQL established itself. It was approximately another decade after that before SQL solidified dominance.
- Was there a specific technical reason to choose SQL over QUEL/LINUS?
- Was there a specific human reason to choose SQL over QUEL/LINUS?
- Was it just random chance and if we were to do it all over again we are just as likely to see QUEL/LINUS become the standard instead?
I remember having some issue, and thought: well, it's JS, let me just check the source like I normally would! Only to find out that you couldn't browse the full client source code anywhere. At that point my only option was to reverse engineer the minified source which just seemed silly and like a waste of time.
Firebase moat has nothing to do with their frontend library, which anyone could reverse engineer with a little bit of time. And yet they still kept it closed source. I don't know if anything has changed since then, but that was the primary reason why I lost interest in the service.
When mobile apps started out, most had little to no online features.
As the mobile apps market grew, more and more of these apps started requiring account persistence, sharing content with other users, real-time online interactions, etc.
That's when Backend as a Service became a thing (eg Parse), targeting developers with little to no server-side experience. And that's when Firebase popped up.
Guess I'm a little lucky in that I can spin up personal backend services just for kicks, and even though DayJob is pretty corporate and locked down, I can still spin up a new backend on my own with not much oversight as long as it doesn't touch certain sensitive things.
Thanks for a brief and clear description - it's surprising how few people can't seem to write one, and how many official corporate sites bury what their service actually does behind 10 pages of marketing fluff and stock photos.
I thought there was a US law now where breaches like this have to be reported?
Yes.
> Will they report it?
Probably not (unless forced imo).
[1] https://www.burr.com/cyber-security-law-blog/ALPHV-extort-Me...
Chattr is a private company - https://www.crunchbase.com/organization/chatrr
Being "good" and giving companies free work is a HORRIBLE idea. They're never gonna pay, or even than you. If they're not willing to treat security researchers properly, I see no reason to return the favor.
Remember security groups: if your company wont pay, there are others that will.
Chances are some blackhat already discovered this data and sold it.
Actually downloading the data from a hack and selling it is expressly illegal.
Now if the person/group you're selling to expresses illegal actions as a result, you have a duty not to sell. So, don't ask, and dont tell!
The real solution: companies all should allow for bug bounties and good-faith reporting and proper compensation for reported issues. But as long as they don't another group WILL pay.
It's... way too successful internally, lol, because we have a lot of permissions and privileges to manage now. And now we have to figure out good ways to assign these permissions to people more efficiently.
But that's a better problem than a GDPR relevant data breach, to be honest.
Is this because doing so might be seen as an admission of liability, and could be used in any legal cases that are brought?
Thanks for the clarification
I'm not clear on this. Splice a new entry into what? The list of admin users? And then do what with it?
'splice" means to join two things as if by weaving them together. If used as "splice into" or "splice in" there is a sense of breaking something apart, inserting something into the gap, and joining it back together.
This all makes a bit more sense if you look up the etymology which was about ropes (despite splicing being about uniting, it's closely related to the word 'split').
Nice to see someone doing good.
Before, one collaborator had them in a chat sneering about chattr, checking their Javascript, then getting a GUI pwn tool for firebase.
i.e targeted attack with malice, followed up a blog post wildly exaggerating what happened, with a disclosure policy of 'we emailed them once and they fixed and didn't email us back so we'll just publish'
Only spelling this out because it's important to point out the significant gaps between white hat culture and these actions, not only for the authors, but for people who are inspired and want to practice it
"Wow this thing looks crappy"
> checking their Javascript
"I wonder if it is crappy"
> then getting a GUI pwn tool for firebase.
"Huh, it seems crappy. Let's just check to be sure"
> with a disclosure policy of 'we emailed them once and they fixed ...'
"Well, this thing is really crappy. we don't want to harm people. Let's tell them about how crappy it is to avoid harm"
> and didn't email us back so we'll just publish'
"They fixed the thing, nobody will be harmed. We still think it's crappy so let's talk about it"
Why wouldn't they go public at this point? They've gotten nothing else out of it, and since the issue has been fixed there is zero harm to customers. Do you propose they go like
"Hey company, we found this really embarrassing thing you did. I see you fixed it now, so can we talk about it"
silence
"Oh well the company didn't say anything so we won't talk about it. So sad"
In what world do we not hold companies accountable? In what world do we blame the people who find these issues for free?
They did do the most significant signifiers to a layman: hack, write a blog post, wait until fix before talking about it.
I'd have a better explanation for picking a target, avoid having competing versions of the story out there, avoid having one version having you targeting a company while another claims it was a general sweep, get the collaborators together and at least credit them in all versions of you can't get people to agree to write one post, avoid exaggerating, avoid claiming you hacked other companies, and add a contact or two before releasing the vulnerability.
Comparing a Project Zero blog post to this is a good idea, I went off of memory.
As it stands it sure sounds like some people were hanging out in Discord, scrolled through some JS in dev tools and / or ran some automated script against a site, then got puzzled and downloaded a pwner GUI to do the hard part, saw a fix, then rushed to write blog posts and stepped on each other's toes, one wildly exaggerating who was hacked while covering up details, another being honest but had ~0 idea of what they were supposed to say
I found it a little tricky to start with while getting familiar with the rules, but it worked really well after I got the hang of it.
> we didnt know much about firebase at the time so we simply tried to find a tool to see if it was vulnerable to something obvious and we found firepwn, which seemed nice for a GUI tool, so we simply entered the details of chattr's firebase
Genuinely curious (I’ve no infosec experience), wouldn’t there be a risk that a tool like this could phone home and log everything you find while doing research?
Littlesnitch iirc is macos only, but it sounds lovely for this sort of thing.
It's available for Windows and Linux
If anyone wants to get to know us, our next Live Q&A is tomorrow at 15:00 CET: https://m.youtube.com/watch?v=S6P8ajLECXg
Plus as part of the pentesting I watch the network stack in Firefox sometimes so I would tell if it was trying to exfiltrate date
Lots of crimes are not "worth it". And yet criminals do it anyway. Because criminals (nor most humans) are not perfectly rational.
There's routinely reports where people try to rob a gas station with a loaded gun - a $200 haul if everything goes perfect. It doesn't and now they have 10 years in jail...
If you’re a felon and unskilled you’re as desperate as it gets in America.
I would strongly argue that almost all crime is irrationally - take it to the game theory strategies of tit-for-tat and such.
No wonder PII keeps getting leaked and sold all the time...
For example, my school's laundry app. Takes 8s to load because it continually refreshes the screen while it is trying to make a connection to their portal. Even now I just checked, it logged me out, took 5 seconds to let me touch the login, I placed in my email, grabbed my password form my password manager, it clearerd my email, retyped, and now the login is grayed out. Looks like I'm currently locked out. Looking at the laundry rooms, it takes 45s to load (literally, I timed it), and then the rooms aren't in order. It'll be like A4, A6, A7, A3, A11, A9, and so on. I'm not sure it's even manually filled in because they seem to change. Plus I have to unplug and replugin the machines constantly because they disconnect from the server. The dryer is a pain. This happens enough that the cords are worn down and it is a fire issue.
Yesterday I ordered from Jersey Mikes. They have a field where you can specify instructions. They do keyword filtering so you can't place a word like "cheese" in it, because they want you to click the box, but the box doesn't let you specify what kind of cheese. You also can't use words like "extra." Employees have always understood my shorthand or leet speak.
My housing processes applications via LIFO instead of FIFO. So all the students who renew their applications a month after the deadline get approved for their housing before anyone who does it within a reasonable time.
Electric bikes are known to light on fire when charging them. Teslas doesn't cover warranty for water damage. Google Maps routinely tells me to be in the wrong lane or miscalculates the number of lanes that exist. Google drive's solution to scrolling through music too fast is to lock you out, which just results in the user picking up the phone. Mine also likes to frequently disconnect itself and there's no low data mode so sometimes it just overloads my car's infotainment computer. Classic halt and catch fire situation.
I can go on about this stuff and it astounds me. Something is fundamentally broken when we can have computers that can talk to us in natural language but we are unable to design a system where employees understand the concept of a sorted list. Not to mention that I won't be surprised when that building catches fire.
Edit: I got logged in. My username was pasting into my password because their password field is labeled as a username field... but it is also hidden... They also double charged me in the past, said they didn't, and their solution was for me to issue a clawback with my bank. These people just don't care.
I really believe a lot of people are building things that they never test and never use. Even at big companies.
WTF.
Recently I reported an issue to a company valued at >$10bil issues were quietly fixed, not a single response back, not even a "thank you"
One could speculate that these companies want to pretend that infosec isn't a problem for them, and if they ignore the "problem", it will go away.
Also, what marketing value - if you're just pwning random web sites rather than getting hired to test a site's security you aren't in any market.
That's modern society for ya.
Most people who are doing this type of things offer consulting services to help make sure your site / app are secure.
> The best approach is not to do it.
Don't do what? Don't tell them there is a security problem?
> Demanding money from someone that didn't hire you is never ethical - just childish.
Lets say my front door is open. Someone takes a picture of it and sends it to me so I can close and lock it. Once it is closed, they explain that they offer a service where they will help homeowners make sure that they keep their doors closed. They plan to use the picture they took to illustrate how they help identify open doors to show why people might want to be their client. However, if I want to pay them for the service the provided, then I get to decide if and how any information about my door being open is used.
I'm not making any moral judgments, but purely from a legal perspective this sounds dangerously like blackmail. If anyone decides to take this path, be sure you understand the risks involved.
So... you're suggesting blackmail?
Don’t expose your database / api / blob storage bucket / etc to the public! It’s not that hard to do it right, or at least “right enough” that you can’t get owned by someone scanning a whole TLD.
What is additionally sad, is that your comment - in 2024 - is being downvoted.
Having slightly tried Firebase, I can also say that the Google cloud tool environment was really confusing the last time I tried using it. Just this enormous maze of switches, and dials, and widgets, like a lot of the popular IDEs.
If the defaults are not set on something sane, and I, a personally evaluated competent tech user with some background in security (fed work) can barely find the settings, then most normal humans with limited grasp of those issues probably won't even know to look.
You pwned them? What are you twelve? All you did was commit a felony and post it online.
Why? They shouldn't be allowed to sweep it under the rug
If security is mostly an afterthought, maybe naming and shaming might help them take it seriously.
I do not understand your stance at all. Why are you defending corps that were negligent?
Read this please https://news.ycombinator.com/newsguidelines.html
If they steer you to one of these third party services, send your resume by snail mail directly to the HR director with a cover letter highlighting all the data breaches such as this one, LinkedIn, Indeed, etc. You'll stand out as someone who pays attention.
And for that matter, how that kind of initiative would be received by your potential future manager at the drive-thru.
I feel like I sound a little patronizing, but my broader point is it’s not other people’s job to be responsible for this kind of data security, especially in a relationship so imbalanced as that between a job seeker and the potential employer who offers only one pathway to gainful employment.
As to the remedy you propose, I’m reminded of the inimitable @patio’s Seeing Like A Bank [0], where he points out that banks (like other firms) use techniques like the paper letter that you described as subtle shibboleths to distinguish people who are likely sophisticated customers from the rank and file.
[0] https://www.bitsaboutmoney.com/archive/seeing-like-a-bank/
If there was a pentester agreement, safe harbor, or other protection that's different. Be careful out there.
Knowing that they store passwords in plaintext is a security issue on top of the R/W credential
I'd argue that it was absolutely necessary to gauge the severity of this misconfiguration and furthermore, that Chattr.ai must contact every affected user, not MrBruh.
Their configuration allowed anyone to create an account and access plaintext passwords. There is no telling whether and how many outside of this disclosure have previously accessed this information and may intend to use it. This was negligence of the highest order, and it shouldn't be on the one finding and reporting this issue to rectify it.
Keep in mind, a good first step to improving security is to hire a pentester. So pentesters have a unique view into companies that are trying to improve. Often the starting place is quite poor. When I leave those contracts, to my knowledge, they are all on track to fix these sorts of defects.
Possibly. But what's the legal basis that allows random external parties to make that determination? Report the leaked credential, and let the company assess impact.
The problem is that pivoting to accessing user passwords may cause the companies to spend money notifying customers and harm their reputation. If they want to pursue legal action, those are clear damages.
> Chattr.ai must contact every affected user, not MrBruh.
Agreed, a pentester directly contacting impacted users would increase the risk legal gets involved.
> There is no telling whether and how many outside of this disclosure have previously accessed this information
Typically the company would review logs to determine that.
I'm sorry, but I don't quite understand. Are you saying that you feel a company should not notify customers when exposing passwords in plaintext and furthermore, that this fact alone isn't harmful to their reputation? Not notifying customers, in my eyes, would destroy any semblance of reputation further.
> Typically the company would review logs to determine that.
Again, do you believe in the competence of someone storing passwords in plaintext? Logs may be incomplete; even a more competent organization that stores credentials following proper procedures and lost a db due to specific phishing rather than such a major screw-up would be expected to contact every customer and advise them to change their credentials, for very good reasons.
Legally, bypassing security controls, using credentials that are not yours, and accessing data without authorization is a crime[1]. I see no indication that this blog post was authorized. Others should not consider this blog post as a good approach.
Look instead to bug bounty programs and stay in-scope. Often that means creating your own account and avoiding other customer's data.
While it doesn't make a good blog post, I still emphasize that the author should have reported the leaked credentials and stopped.
[1] varies by jurisdiction, I'm not a lawyer, etc.
But, and this can be a significant differentiator from a legal standpoint in multiple jurisdictions[0], they did not use leaked credentials, nor did they circumvent any barriers. They used a publicly accessible endpoint to create their own, completely new user that just had access rights from the get-go.
[0] Sticking solely with US examples, most notably United States v. Auernheimer which was in part overturned on jurisdictional issues, in part due to the following: "We also note that in order to be guilty of accessing “without authorization, or in excess of authorization” under New Jersey law, the Government needed to prove that Auernheimer or Spitler circumvented a code-or password-based barrier to access. See State v. Riley, 412 N.J.Super. 162, 988 A.2d 1252, 1267 (N.J.Super.Ct.Law Div.2009). Although we need not resolve whether Auernheimer's conduct involved such a breach, no evidence was advanced at trial that the account slurper ever breached any password gate or other code-based barrier. The account slurper simply accessed the publicly facing portion of the login screen and scraped information that AT & T unintentionally published."