
Ask HN: Should working exploits be released with full disclosure of a 0day? - ta_up2bx7ve
The vulnerabilities aren&#x27;t patched and can be exploited in a couple of minutes by anyone with curl or similar installed. The full disclosure already includes curl commands, only a few lines of glue code is needed for a working exploit.<p>Should I include the exploits with the disclosure or leave them off so it is slightly harder to attack?<p>PS: The full disclosure comes after months of trying to get even a support ticket in. Data protection bodies seem to be busy with GDPR and have given an extremely unreasonable timeline for even deciding whether to investigate the issue. The vulns are also easy to find as they are simple HTTP requests with malformed data, although they expose one PII data record each time (up to millions).
======
badrabbit
Might get downvotes for this but my stance is against publication of a PoC
until most users are confirmed to have patched it.

Hear me out though, I don't think it should be legally prohibited but I still
do consider it unethical to publish a working PoC.

Before I present my reason let me give you a real life example I experienced
first hand: A certain rce exploit against a webapp was published along with a
PoC exploit on github. Within 24 hours there was a large volume of attacks
against servers running that software,compromising them and installing
cryptominers. Worst part? Turns out the patch wasn't even done right by the
vendor.

My point is this: yes researchers have every legal right to publish a PoC and
I support that. Ethically speaking, there very real consequences to businesses
and individuals when these PoC are made public.

Sure, even if there was no PoC the attackers can reverse the patch. In my
experience, most of the attacks for an exploit with a working PoC use the
researcher's PoC script line for line with only the needed modifications.

The difference here is the likelihood of an attack and the size of the threat.

Without a working PoC, the amount of attackers reverse engineering a patch
would be dramatically smaller than with a working PoC. Not only that, the
amount of users that should anticipate a high likelihood of an attack
leveraging a vulnerability with an unpublished PoC is low.

Objectively speaking (at least for a short while after the patch) releasing a
PoC reduces security for the users of the software. That being said I
understand the educational merit of a PoC and a lot of vendors won't respond
without some arm twisting,so there are exceptions. It certainly isn't a black
vs white clear cut issue.

But yeah,generally speaking I am against publication.

~~~
ta_up2bx7ve
To add some context, the affected software is a company's proprietary, closed-
source website.

In this case, there is no way of doing a full disclosure without making it
somewhat easy to attack. Even if I only warned the media about this (without
even mentioning the "how"), it would make someone else find the flaws in a
matter of hours (attack surface is limited) and likely start exploiting them
anyway.

I really don't want to publish anything; even my data would be exposed and
there's nothing I can do about it.

------
jlgaddis
That's your call to make.

While I'm generally in favor of (100%) full disclosure -- _especially_ when
the upstream is unhelpful or even completely unresponsive -- there's a whole
spectrum between "coordinated disclosure" and "full disclosure".

If full disclosure means that PII would be exposed, I'd probably try one more
time to reach the {company|developer|vendor} before going public... but maybe
you already have. I'd also be hesitant to release actual "exploits" (perhaps
just a PoC) but if you publish enough details to identify the vulnerability,
it will also be enough for _someone_ to develop an exploit on their own.

There's also options like US-CERT (or similar in your country) and/or going to
the media, if you think that would help.

Good luck!

