@thisismissem Difficult. If we spin this analogy further:...

@thisismissem Difficult. If we spin this analogy further: you gave me your key for a specific purpose (e.g. pizza delivery while you were out), after which I returned it to you. You didn’t allow me to make a copy of this key and use it later to rearrange the furniture for example.

Abusing hardcoded credentials can definitely constitute hacking and cause perfectly justified criminal charges. But intention and damage caused definitely need to go into the equation, not merely “circumvention of protection mechanisms.”

Like 18 January at 12:55 | Open on infosec.exchange

17 comments

Emelia 👸🏻

@WPalant in this case it just sounds like he used the key to open the front door, saw an absolute mess & notified the company of the issue

18 January at 12:58 | Open on hachyderm.io

Bartosz Rakowski

@thisismissem @WPalant this seems to omit the other side of the story. If I understand this correctly, vendor software was making undocumented calls to outside infrastructure and sharing potentially sensitive data. It should be in company's right to check the level of exposure to properly protect their and their customers' rights.

18 January at 13:47 | Open on hachyderm.io

Thomas Tempelmann

@RakowskiBartosz @thisismissem @WPalant Well, no. You can't demand the right to look into the internals of your partners - they have a right to privacy as well. You are instead "protected" by the law that requires the partner to protect your privacy interests, or by contracts. What that law is missing, however, is a way to universally verify that they do it correctly, e.g. by independent auditors. Which isn't often feasible, though. It's all a compromise, and it sucks.

18 January at 14:43 | Open on iosdev.space

Riley S. Faelan

@RakowskiBartosz

Surely you forgot to add a sarcasm tag.

The vendor is almost certainly out of GDPR compliance.

@thisismissem @WPalant

18 January at 23:19 | Open on toot.cat

Tamas K Lengyel

@WPalant @thisismissem Intent and damages should absolutely matter. But it's also common sense not to use the hardcoded credentials to login and dump the database. Or if you do, why report that you did? Perfectly sufficient to just say you found the hardcoded credentials and stop there.. Bad practice on both sides.

18 January at 13:22 | Open on discuss.systems

Yellow Flag

@tklengyel @thisismissem Where did you read that he dumped the database? My understanding is that he connected to the database in the assumption that it was specific to his client, then disconnected and reported the issue immediately after realizing that it contained data on other customers as well.

18 January at 13:31 | Open on infosec.exchange

Tamas K Lengyel

@WPalant @thisismissem Just connecting to the db won't show you what data is in it to determine it's not just your data. So he must have dumped it or at the least queried it sufficiently deeply to make that call.

18 January at 21:31 | Open on discuss.systems

Beady Belle Fanchannel

@tklengyel @WPalant @thisismissem Just connect to it with a GUI tool like dbeaver (like devs are likely to do), it will show you the schema of tables.
There will be columns like “clientName” or similar, and then doing a few very simple selects will tell you whether you have access to other people’s data.

19 January at 9:23 | Open on mastodon.xyz

Beady Belle Fanchannel

@tklengyel @WPalant @thisismissem Mixing customer data like that and giving full access to the database with the given user credentials is criminal neglect and should cost the company dearly. Not the person who figured it out.

19 January at 9:24 | Open on mastodon.xyz

Yellow Flag

@Profpatsch @tklengyel @thisismissem According to https://nitter.net/der_sofc/status/1747644600469127386 he connected with phpMyAdmin. While I haven’t used that tool in decades, that would presumably also expose the database schema immediately.

19 January at 9:34 | Open on infosec.exchange

DELETED

@tklengyel @WPalant @thisismissem I hate this thread. Also responsible disclosure is a thing and should be protected under law. Vendors doing something stupid than pressing charges is incompetence and should be audited by a gov agency.

This thread and this case is why people don't bother reporting anything they find without malicious intent and just watch the company shoot themselves in the foot.

18 January at 20:30 | Open on infosec.exchange

Tamas K Lengyel

@alex_02 @WPalant @thisismissem I agree, but the reality is that you are better off just ditching that vendor if they won't fix the issue. Then why not publish the issue anonymously? If you aren't going for a bug bounty what is there is to gain by attaching your name to it?

18 January at 21:35 | Open on discuss.systems

DELETED

@tklengyel @WPalant @thisismissem why does disclosing a security issue require to be a bug bounty or publishing it anonymously? Treating hackers and researchers like terrorists is just making things worse and why threats like ransomware gangs have such an easy walk in the park with breaking into networks.

18 January at 21:47 | Open on infosec.exchange

Clover :neocat_3c:

@tklengyel so your proposal is that when someone finds a severe security issue they should just stop using the service themselves then anonymously publish it publicly?

I suppose that is one way of doing things “fuck every company that won’t pay me for finding an issue”.

Though, overall, this would result in more vulnerabilities being exploited instead of fixed before they are exploited by bad actors

@alex_02 @WPalant @thisismissem

19 January at 6:11 | Open on akko.wtf

DELETED

@tklengyel @alex_02 @WPalant @thisismissem I'm trying to figure out if Tamas is just being disengenuous, or worse. If I were to find a bug in a product from your company (Intel?!), would y'all prefer that I
a) Blast it off into the aether and yolo off into the sunset while bad actors begin exploiting it?
b) Blast it off to what's likely a b0rked 'security@' e-mail address to be seen when the sun rises from the west?
c) Inform you of the problem in a way you can come back with questions?

19 January at 8:03 | Open on xvlt.net

Tamas K Lengyel

@frainfostudent @alex_02 @WPalant @thisismissem I'm just saying that if a vendor has no defined security reporting policy and/or an active bug bounty don't be surprised if they will be a bad actor in other ways as well. It's a risk at that point, why take it?

19 January at 11:41 | Open on discuss.systems

Alex Rock

@WPalant @thisismissem

Many judges in court don't know jack shit about programming, and "compiling" is the same as "encrypting" for them.

As many analogies said: if you give someone the key to your house, whether it's wrapped in tons of cardboard and tape, they still have the key.

The software provider must be condemned as a security flaw, endangering all users.

18 January at 14:46 | Open on mastodon.social

Go Up