I found a Vulnerability. They found a Lawyer

Posted by toomuchtodo 3 hours ago

I found a Vulnerability. They found a Lawyer(dixken.de)

182 points | 89 comments

janalsncm 1 hour ago|

Three thoughts from someone with no expertise.

1) If you make legal disclosure too hard, the only way you will find out is via criminals.

2) If other industries worked like this, you could sue an architect who discovered a flaw in a skyscraper. The difference is that knowledge of a bad foundation doesn’t inherently make a building more likely to collapse, while knowledge of a cyber vulnerability is an inherent risk.

3) Random audits by passers-by is way too haphazard. If a website can require my real PII, I should be able to require that PII is secure. I’m not sure what the full list of industries would be, but insurance companies should be categorically required to have an cyber audit, and laws those same laws should protect white hats from lawyers and allow class actions from all users. That would change the incentives so that the most basic vulnerabilities are gone, and software engineers become more economical than lawyers.

stevage 1 hour ago||

Since the author is apparently afraid to name the organisation in question, it seems the legal threats have worked perfectly.

pavel_lishin 1 hour ago||

Or maybe in the diving community, "Maltese insurance company for divers" is about as subtle as "Bird-themed social network with blue checkmarks".

frederikvs 1 hour ago|||

I'm a diver, DAN is the only company I can name that specialises in diving insurance.

Huh, apparently they're registered in Malta, what a coincidence...

bpavuk 43 minutes ago||

checks out with both Perplexity[0] and top Google results

[0]: https://www.perplexity.ai/search/maltese-scuba-diving-insura...

saxelsen 1 hour ago||||

There's pretty much only one global insurer affiliated with dive schools, so this is spot on

bpavuk 45 minutes ago|||

well, it is. quick search revealed a name of a certain big player, although there are some other local companies whose policies can be extended to "extreme sports"

https://www.reddit.com/r/scuba/comments/1r9fn7u/apparently_a...

tuhgdetzhh 1 hour ago|||

If you follow the jurisdictional trail in the post, the field narrows quickly. The author describes a major international diving insurer, an instructor driven student registration workflow, GDPR applicability, and explicit involvement of CSIRT Malta under the Maltese National Coordinated Vulnerability Disclosure Policy. That combination is highly specific.

There are only a few globally relevant diving insurers. DAN America is US based. DiveAssure is not Maltese. AquaMed is German. The one large diving insurer that is actually headquartered and registered in Malta is DAN Europe. Given that the organization is described as being registered in Malta and subject to Maltese supervisory processes, DAN Europe becomes the most plausible candidate based on structure and jurisdiction alone.

wildzzz 49 minutes ago|||

[flagged]

MrQuincle 2 minutes ago||

There should exist a vulnerability disclosure intermediary. They can function as a barrier to protect the scientist/researcher/enthousiast and do everything by the book for the different countries.

esafak 1 minute ago|

Who compensates them for the risk?

general1465 3 minutes ago||

One way how to improve cybersecurity is let cyber criminals loose like predators hunting prey. Companies needs to feel fear that any vulnerability in their systems is going to be weaponized against them. Only then they will appreciate an email telling them about security issue which has not been exploited yet.

Hnrobert42 8 minutes ago||

I use a different email address for every service. About 15 years ago, I began getting spam at my diversalertnetwork email address. I emailed DAN to tell them they'd been breached. They responded with an email telling me how to change my password.

I guess I should feel lucky they didn't try to have me criminally prosecuted.

vaylian 2 hours ago||

> Instead, I offered to sign a modified declaration confirming data deletion. I had no interest in retaining anyone’s personal data, but I was not going to agree to silence about the disclosure process itself.

Why sign anything at all? The company was obviously not interested in cooperation, but in domination.

dwedge 2 hours ago|

[flagged]

gchamonlive 2 hours ago|||

Because you are highjacking a thread. Wanna trash the site's design, you should open a top level thread instead.

magicalhippo 2 hours ago|||

> Wanna trash the site's design, you should open a top level thread instead.

Or better, don't[1]:

Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.

[1]: https://news.ycombinator.com/newsguidelines.html

gchamonlive 1 hour ago|||

Exactly, thanks

dwedge 1 hour ago|||

Being impossible to read is not common

magicalhippo 1 hour ago||

Get a better browser I'd say. Firefox Reader mode makes short work of such sites, including the submission. I use it very often, so I can enjoy the content rather than get frustrated over styling issues.

dwedge 1 hour ago|||

Ah then I deserve it. I didn't notice from the app I was using that it wasn't all the way to the left

MBCook 2 hours ago||||

Your response didn’t have anything to do with the parent comment. And I’m on a phone (iOS) and had no issue reading it, for the record.

capitainenemo 2 hours ago||

As well as contrast issues, could also be that there was a javascript error on their end (or they don't whitelist sites for JS by default). This is unfortunately one of those sites that renders a completely blank page unless you use reader mode, enable JS, or disable CSS.

If it was a random JS error, well, that reminds me of: https://www.kryogenix.org/code/browser/everyonehasjs.html

0sdi 2 hours ago||

Is this Divers Alert Network (DAN) Europe, and it's insurance subsidiary, IDA Insurance Limited?

locusofself 1 hour ago|

Another commenter basically deduced this

paxys 1 hour ago||

When you are acting in good faith and the person/organization on the other end isn't, you aren't having a productive discussion or negotiation, just wasting your own time.

The only sensible approach here would have been to cease all correspondence after their very first email/threat. The nation of Malta would survive just fine without you looking out for them and their online security.

czbond 1 hour ago||

Agree - yet, security researchers and our wider community also needs to recognize that vulnerabilities are foreign to most non-technical users.

Cold approach vulnerability reports to non-technical organizations quite frankly scare them. It might be like someone you've never met telling you the door on your back bedroom balcony can be opened with a dummy key, and they know because they tried it.

Such organizations don't kmow what to do. They're scared, thinking maybe someone also took financial information, etc. Internal strife and lots of discussions usually occur with lots of wild specualation (as the norm) before any communication back occurs.

It just isn't the same as what security forward organizations do, so it often becomes as a surprise to engineers when "good deed" seems to be taken as malice.

bpavuk 52 minutes ago||

cynical. worst part? best one can do in this situation. can't imagine how I could continue any further interaction with such organization.

undebuggable 1 hour ago|

> the portal used incrementing numeric user IDs

> every account was provisioned with a static default password

Hehehe. I failed countless job interviews for mistakes much less serious than that. Yet someone gets the job while making worse mistakes, and there are plenty of such systems on production handling real people's data.

tracker1 9 minutes ago||

Literally found the same issue in a password system, on top of passwords being clear text in the database... cleared all passwords, expanded the db field to hold a longer hash (pw field was like 12 chars), setup "recover password" feature and emailed all users before End of Day.

My own suggestion to anyone reading this... version your password hashing mechanics so you can upgrade hashing methods as needed in the future. I usually use "v{version}.{salt}.{hash}" where salt and the resulting hash are a base64 string of the salt and result. I could use multiple db fields for the same, but would rather not... I could also use JSON or some other wrapper, but feel the dot-separated base64 is good enough.

I have had instances where hashing was indeed upgraded later, and a password was (re)hashed at login with the new encoding if the version changed... after a given time-frame, will notify users and wipe old passwords to require recovery process.

FWIW, I really wish there were better guides for moderately good implementations of login/auth systems out there. Too many applications for things like SSO, etc just become a morass of complexity that isn't always necesssary. I did write a nice system for a former employer that is somewhat widely deployed... I tried to get permission to open-source it, but couldn't get buy in over "security concerns" (the irony). Maybe someday I'll make another one.

makr17 49 seconds ago||

Years ago I worked for a company that bought another company. Our QA folks were asked to give their site a once-over. What they found is still the butt of jokes in my circle of friends/former coworkers.

* account ids are numeric, and incrementing

* included in the URL after login, e.g. ?account=123456

* no authentication on requests after login

So anybody moderately curious can just increment to account_id=123457 to access another account. And then try 123458. And then enumerate the space to see if there is anything interesting... :face-palm: :cold-sweat:

More comments...