3 ms·
Ask HN: Should working exploits be released with full disclosure of a 0day?
The vulnerabilities aren'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.
Should I include the exploits with the disclosure or leave them off so it is slightly harder to attack?
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).
- jlgaddis 9y agoThat'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!
- badrabbit 9y agoMight 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 9y agoTo 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.