Hacker News new | ask | show | jobs
by laeri 641 days ago
I am confused, they didn't contact the company at all and just disclose this publicly? Very immature handling of a vulnerability finding.
7 comments

And to add that he tried out the exploit on unknowing participants. It would be better to try this with a friend in-the-know at a separate table. It makes me think he did it more as a practical joke than testing his exploit, especially because he mentioned they were "not-too-intimidating-looking guys".

I'll admit it is a bit funny and the damage caused is tiny(just the price of the food). However, things like this do harm the reputation of bug-bounty hunters.

He could have just tried it on his own table (order on the phone, and then on the laptop through the vulnerability) and avoid having to a) bother others, b) waste food. The result would have been the same.
The author says "I refuse to believe they’re unaware of this. This doesn’t feel like an oversight, it's either a deliberate design decision or they just don't care." Agree that this is an uncharitable way of looking at it.
Yep. It’s just working backwards from some pre existing very negative worldview.
Its a justifiable worldview. I'm an Indian dev and I've seen obvious backdoors like these added to the backlog as a low priority bug. If somebody spends time on this, that means features are being delayed and you are rewarded less.

I've worked in lambda web editor (not in Git) and my lead considered replacing sql injection with parameterised queries was a distraction/insubordination. Cant wait till audits, data breach insurance and imprisonment becomes the reality.

Could be as simple as no auth in debug builds and then deployed it by accident.
I don't mean to pick on your comment, but to respond to a prior comment, you are beginning with a very positive world view and interpreting the events from there.

Lazy API that did not vet a simple backdoor?

Good coders but accidentally pushed the debug version of the API?

I am going to have to say the second option feels less likely (yes, I have been called cynical).

Different confs in the same repo. Many CI/CD tools will pick debug/dev conf by default if nothing else is set.

It was just an example. Maybe they knew.

Is it a vulnerability when it is obvious the company do not care about security?
Yes. Because who at the "company" does even know about this? Maybe just some coder who wrote it. But the legally liable CEO? Maybe not.
> Because who at the "company" does even know about this?

Everyone who designed engineering requirements, technical requirements, test plan, everyone who wrote technical specifications, everyone who performed traceability. It was all approved by security engineers and management.

> The company was founded during the pandemic when contactless dining became popular.

There were tons of people intimately aware of the issue, yet for four years nobody cared.

That is his job to make sure he employs people who take care of this and that the services they sell are audited by an independent organization.
Who at the company gets to keep all the money?
If you discovered an incompetent healthcare provider was prescribing antibiotics for every condition would you "contact them privately" or contact the relevant authorities?

Private disclosure is for when you believe the company cares about security but made a genuine mistake. For the company in the OP it would be more like free education in fundamental privacy and ethics. They're not entitled to that. Name and shame.

Sure, but what you’re describing is not what is being suggested. Responsible disclosure typically involves disclosing publicly after a reasonable period of time.
Why? Why should they be the responsible ones, when the well-funded, well-connected service provider is acting like the fly-by-night startup (that they probably started as)?

There's little public benefit in responsible disclosure here; all it would lead to is the whole thing being swept under the rug with some trivial "fix". There's lots of public benefit in immediate, wide disclosure - the scramble to fix this under pressure from vendors before potential abuse, and any real or imagined attempt at abuse, and subsequent lawsuits, would go far towards educating people and the industry about privacy, security, and bad business practice. It's a nice low real damage, high publicity case.

It's not like this stuff is new. But without serious pressure, the businesses will never learn and never stop making or enrolling into such systems.

Anyway, if it happened over here in the EU, I'd do the responsible disclosure thing and give a full, detailed advance expose to the local Data Protection Authority.

(And if I sound adversarial, then consider that neither the vendor developing such systems, nor the venues using them, are doing it in the interest of the customers.)

There's a big difference between announcing "I found all this private data" and "I found all this private data and here's exactly how I did it and here are the URLs". What the author has done is detail exactly how anyone else can abuse this system from anywhere in the world and also given them ideas about what to do with that information that would cause a direct cost to the company. I think that's irresponsible and unnecessary. You public disclosure rationale has some merit but it didn't require publishing the user manual for the attack. Just saying you used the API, publishing the amounts plus some proof of private data from people who have given consent would be enough to get the business scrambling.
This seems less like a "manual for attack" and more like tweeting that your local storage unit rental never puts locks on their garages and gates and "anyone could just walk in and out".
To expand your analogy can you see the difference between: "A storage unit I know of never uses locks" and "The storage unit at 1234 Central Boulevard, San Andreas never uses locks, just wiggle the door a bit and it'll open."

I think most people would acknowledge there's a big difference.

> cause a direct cost to the company

Nothing wrong about that. Of course still doesn't justify publishing/providing access to client data who did nothing wrong.

Causing damage or cost to a company through fraudulent use would be the cornerstone of a civil or criminal prosecution. Cases where there is good disclosure and no cost incurred tend to get dismissed, cases where there is identifiable damages get stupidly big sentences and/or fines.
Right but would you afford the same opportunity to the healthcare provider? You'd contact them privately and expect them to go and learn why over prescription of antibiotics is a bad thing and change their ways? Of course you wouldn't. You'd go to someone who cares. In healthcare there are ways you can report it without naming and shaming publicly, but how could the author do that?
In the EU this would be illegal and (hopefully) lead to very high fines. So why would you try to help and conceal their criminal behaviour instead of reporting them?

Of course in other places, there aren't really any good options. So I guess the most "moral" approach would be to what you think would cause most financial damage to the business and discourage people from going there.

This is hardly a 0-day vuln exploit. This works as designed (and presumably design has been signed off etc)
is it really a vulnerability if the entire thing is open by design?
Who says it was? Why would they willingly give out their customers' and customers' customers data to any anonymous person or a bot? More likely a bad oversight
This is “the tire shop doesn't have a torque wrench” level shit. If it's an oversight, it's an oversight due to incompetency, not because a good team just happened to miss something in a crunch. Another possibility is that the issue was raised and management said to fix it later, and because software “engineering” isn't a real engineering field that holds its practitioners to any duty of care, those responsible (the engineers) just went along with it.
For 3 years? That would mean that no developer has ever raised these issues with management, to speak nothing of an actual pentest being conducted.

No, this is not some obscure security hole they forgot about. This is plain incompetence and/or deliberate design decisions.

I agree that full public disclosure like this is irresponsible, but exposing issues like this to the public is the only way for such companies to make a change or, preferably, lose business and shutdown.

No auth at all? For years? That’s a tremendous oversight. Nobody running a test having to authenticate?
Because they don't care, and their customers don't understand any of this shit?

It feels like the usual case of vendors buying service to better exploit the users, and themselves getting burned and/or exploited by that service too.

Yes! You as a user are not meant to knowingly access data that does not belong to you. Even something like changing the id from 1 to 2 is legally considered unauthorised access.

It would be different if for example the application was showing data for other customers through normal use of it, but even if there is no other barrier to access than changing an id that is considered bypassing access control and can result in jail time in most places. Now I'm not an expert in India's computer misuse laws but I am willing to wager they are not the most progressive when it comes to this kind of thing.

same thoughts, annual reports of larger companies have more dense figures than these too.
Doubt the company made it open by design. Doubt you will find an order from the CEO to make it open. It was probably a fuck up by a shitty coder.
Disagree.

Most likely the company will blame them for trying to help. Also, if the company is so incompetent that they allow this why bother. He's not getting paid to be their test engineer.