Ask HN: Found security flaws but vendor seems not to care. What should I do?
I've found some web app vulnerabilities to some high profile services in my country, but the vendor doesn't seem interested in fixing them as 6 months have passed and they claim to have other things to do, which, judging by the announcements on the main page, is finishing missing features.
The fixes to the flaws that allow for iterative exfiltriation of PII are trivial to implement as well. The others are simple reflected XSS's.
What is the most appropriate course of action here?
40 comments
[ 5.7 ms ] story [ 114 ms ] thread[1] http://seclists.org/fulldisclosure/
Responsible disclosure isn’t codified in law, even bug bounties do not somehow exempt you from criminal prosecution they just make it less likely as long as you follow their guidelines at least.
The only difference is that companies elect not to file complaints which lead to charges being filed when this is done properly.
I've handled bug bounty payouts on both sides, I've sat on a advisory board for a national CERT (my employer held the seat not by name), and I've seen quite a few cases of bug bounty and reported submissions go wrong really fast for as something as silly as poorly constructed language or someone being overly pushy.
The OP here found a vulnerability that discloses PII of other users, if this is actual PII as defined by law in their jurisdiction well then they again just potentially commited a crime. By the nature of the vulnerability "iterative exfiltriation of PII" I'm assuming they found some direct access to a resource like a profile page, invoices, or something similar which means that they've found a vulnerability, exploited it during a proof of concept and retrieved PII data, all of this falls under unauthorized and criminal access if not handled correctly.
Usually when you have a vulnerability which requires actionable exploitation to prove and you access any type of information especially one that is regulated by law you want to document everything you've accessed and provide those details in the disclosure as they would have to notify the people whose information has been exposed in the least if not their entire customer base.
No, it's a descriptor. In the debate about the best way to handle knowledge of vulnerabilities, there arose a vaguely-bounded subset practices that got this name.
Yes, it's also great marketing. Whatever has the name implies that it's the best of all possible alternatives, fait accompli.
On the other hand, if we’re speaking just about doing it anyway, it’s basically trivial to do this as the commenter described without ever being caught. Publicly claiming the PGP signature later will obviously not be trivial, but you can easily send one anonymous email without ever being caught.
If someone wants to do this out of a sense of personal ethics, and doesn’t mind restrictions on legally claiming it later on, I’d say go for it. An anonymous email is not a high operational security bar to pass for someone technically competent enough to find a security issue, especially if it’s only once.
The correct way to handle it is to contact the relevant CERT team in your country usually on a national or state level.
And if it's regulated industry or information (PII is) you can also contact the relevant regulator.
Publishing a functional exploit that can be used to gain access to PII on an open mailing list isn't just illegal it's also unethical.
This advice is quite indicative of anyone who never handled disclosures from either side of the aisle.
You need to understand there could be good reasons why you might not get a reply to a reported vulnerability, including the fact that the legal team and or the authorities put a gag on it. You don't know what language was used in the initial report and what information they've accessed. In many jurisdictions especially in the EU you are actually required to report the incident even if it's under a "bug bounty" program to the authorities if regulated information has been exposed. They may allow you to handle it through your BB program (but they also remind you that you'll be liable for any mishaps in the handling of the incident) they may elect to tell you to stop all contact and hand it over, your own legal department might say they don't like the language used or some other things raised a red flag like "I've downloaded your entire DB as a PoC"....
I really don't understand why people on HN elect to give such poor advice on a subject that while unlikely but can go south really bad on a whim.
No it isn’t. Make a new key-pair for the signature. This key-pair will also be anonymous. Best of both worlds: still anonymous, but you keep the option to positively claim it later.
The fact that they’ve spoken about it on HN somewhat deanonymizes them, sure, but perhaps not meaningfully so yet. The OP needs to secure against a private company’s security and legal teams, not a theoretically omniscient naion state. If he used an alternate IP address for this throwaway, he’s still basically fine.
> I really don't understand why people on HN elect to give such poor advice on a subject that while unlikely but can go south really bad on a whim.
This isn’t poor advice. Speaking for myself, I choose to give this advice as a security professional and someone who has had to make various disclosures, both “responsible” and “full”, and of the latter, with and without the cooperation of the company.
Generating PGP keys for future claim would require you to keep a copy of the private key, this copy can be seized if a criminal investigation does happen.
>This isn’t poor advice. Speaking for myself, I choose to give this advice as a security professional and someone who has had to make various disclosures, both “responsible” and “full”, and of the latter, with and without the cooperation of the company.
So have I and this is a poor advice, especially these days with some of the regulation that is popping up. The line which differentiates between a paid bounty or a PR piece on your website and criminal prosecution is how you handle the situation the law applies identically to both there are no legal provisions for doing unsolicited penetration testing because you say you're a good guy, heck in the UK for example the exemption form that companies sign do not actually exempt the individual tester from being prosecuted by the crown it can only be used as a legal defense, in Germany the possession of "hacking tools" is illegal without a cause, and there are tons of other nuances for each and other country and jurisdiction in the world.
Telling people to just post stuff on seclists especially after already being in contact with the company is a terrible idea, so while I do appreciate you might have had different experience it doesn't mean you handled it correctly nor does it mean you are giving a sage advice.
My solution is not the politically correct way of doing it but I think that people who don't care about security should be punished
If you do not get a response, then go ahead and make a blog post about it. Be sure to mention that you failed to get a response from the org in the post.
I would email a security list since email is not retractable once sent.
If the service is not publicly available or is some kind of internal, enterprise tool, then it would be a different matter.
Does this mean PII can be extracted by an attacker one user at a time?
If you make a public disclosure, you are at risk of being bullied by lawyers at the very least. Handing the issue over to the regulators might be more or less effective than making a public disclosure, but it should offer you some protection against liability and legal threats. As I understand it, most EU member states have some form of legislation to protect whistleblowers against defamation suits.
http://ec.europa.eu/justice/data-protection/article-29/struc...
In a legacy codebase, even the smallest change can introduce all sorts of problems; and a small change to output or business logic can require disproportionately large changes to code. They may simply have determined that finishing the feature changes they think they need for their business to survive is more important than protecting against exploits that they consider either unlikely or low-value.
And how acceptable this is may depend in large part on what the service in question is and how broadly it's used. The lack of concern you describe would be totally unacceptable from a bank or even Twitter, but perhaps excusable (at this stage) from an early stage company trying to build the next Twitter.
Your course of action should be:
1) Understanding the legal framework in your country supporting the disclosure of vulnerabilities.
2) Contacting your country’s CERT team or EUCert if you are in the EU.
Well, if you're in the EU then GDPR [1] will be enforceable from 25 May 2018, so it is my noob understanding that the vendor you're dealing with will, sooner or later, be the subject of regular periodic data protection audits and will be forced to have a Data Protection Officer. Not sure if necessary, but you may contact ENISA [2] to be advised on how to proceed.
[1] https://en.m.wikipedia.org/wiki/General_Data_Protection_Regu...
[2] https://en.m.wikipedia.org/wiki/European_Union_Agency_for_Ne...
Your first option is simply to let it go. It might not be worth your time, energy and risk to pursue this. Certainly if the vulnerabilities are not high risk. You already did the right thing by notifying them. It's the company choice to accept the risk of not fixing the vulnerabilities.
You can file the finding with your local CERT, they might be able/helpful to coordinate.
You can go full disclosure with it, if you accept the risk the company might sue you. Even if you're in the right, it might cost you a lot of time, money and anxiety before the court says you are. See option 1.
Notification to the authority responsible for enforcing GDPR or local privacy authority might be worthwhile, it depends.
Also, what kind of PII are we talking about?