Ask HN: How do I go about responsibly disclosing security vulnerabilities?
11 comments
So I took everyone's advice and have done the following.
1) I mailed the company again saying that they have not yet addressed the issue. And that the vulnerability is now critical given how much info they are adding per day. Expressed that I would like to know if a patch is in the works.
2) Contacted several people in the IT security and audit business and asked what the standard procedure was. The response from our CERT was that for a vulnerability of this nature they need to respond with intention and details of fixing within 24 hours else I'm free to send one more email expressing intention to disclose vulnerability to public. Disclosure of vulnerability will not include how to exploit, proof of concepts, or any personally identifiable information.
3) if they say they need some time, and they say how much ( or I have to ask) I have to allow them that.
4) if things get ugly, CERT will take over upon my request
Yey. Thanks to all for the advice
1) I mailed the company again saying that they have not yet addressed the issue. And that the vulnerability is now critical given how much info they are adding per day. Expressed that I would like to know if a patch is in the works.
2) Contacted several people in the IT security and audit business and asked what the standard procedure was. The response from our CERT was that for a vulnerability of this nature they need to respond with intention and details of fixing within 24 hours else I'm free to send one more email expressing intention to disclose vulnerability to public. Disclosure of vulnerability will not include how to exploit, proof of concepts, or any personally identifiable information.
3) if they say they need some time, and they say how much ( or I have to ask) I have to allow them that.
4) if things get ugly, CERT will take over upon my request
Yey. Thanks to all for the advice
Google blackmailing MSFT on a regular basis to fix their holes within 90 days. Or else.
http://www.geekwire.com/2015/microsoft-chastises-google-disc...
But Google certainly has more legal resources to support it's efforts.
http://www.geekwire.com/2015/microsoft-chastises-google-disc...
But Google certainly has more legal resources to support it's efforts.
Don't bother doing it responsibly - it's easier, worth more and safer to sell onto to other interested parties.
Fly to China, give the info to wikileaks.
What, why the down-votes, isn't that the accepted model for this situation?
Edit: Really, I'm curious. the last guy that did it is considered a hero.
Edit: Really, I'm curious. the last guy that did it is considered a hero.
These comments were most likely downvoted because glib throwaway comments are off-topic here (https://news.ycombinator.com/newsguidelines.html). If you didn't intend your comment that way, you probably needed to express it more substantively.
Sincerely, the thread originator asked how to responsibly disclose sensitive information. This has been done ~recently, and the person in question has been lauded for their efforts in responsible information disclosure. I am curious why the same model shouldn't be followed.
Yes, the first comment was glib. I was hoping to spark a debate. The edit on my second comment was probably superfluous.
Yes, the first comment was glib. I was hoping to spark a debate. The edit on my second comment was probably superfluous.
I would start by assuming it will naturally take them more than one week to completely fix this problem, and ask if the fault is so severe that it would be better to take the service down until it's fixed, both from the company's viewpoint, and that of an external entity able to force it being taken down even if it kills the company.
If the answer is no to both, it's not that dire and they can be given 3 more weeks, precipitate action would not seem to be required.
As for deadlines, experience shows they are so frequently required that you will need to set one; there's a lot that's been written about this so I'd look for that.
If the answer is no to both, it's not that dire and they can be given 3 more weeks, precipitate action would not seem to be required.
As for deadlines, experience shows they are so frequently required that you will need to set one; there's a lot that's been written about this so I'd look for that.
TLDR: Talk to a lawyer.
Also: https://www.eff.org/issues/coders/vulnerability-reporting-fa...
--
It depends on whether they already know who you are. If you've managed to remain completely anonymous, you can pressure them much easier since they can't retaliate with legal repercussions.
If they know who you are especially, but generally as well, i recommend talking to a lawyer.
Edit: Removed bit about phone/email. Good point.
vvvv
Also: https://www.eff.org/issues/coders/vulnerability-reporting-fa...
--
It depends on whether they already know who you are. If you've managed to remain completely anonymous, you can pressure them much easier since they can't retaliate with legal repercussions.
If they know who you are especially, but generally as well, i recommend talking to a lawyer.
Edit: Removed bit about phone/email. Good point.
vvvv
First thing is you need to be aware that anyway you do go with this could end up with legal action against you from the company. This can happen even to people with the best intentions or who try to be responsible. Just make sure you are aware and understand the risk.
You've already talked to the company, so anonymously releasing the information is out of question, they could probably track it to you.
Do they not have any sort of policy on this? Maybe try to talk to their team again but make sure you get it in writing and signed first that you're not going to be held liable, and just make sure you're safe. Maybe even ask a tech-orientated lawyer first?
My advice would to just try to be nice and open to the company, but stay firm that this is a major issue. Maybe write up some documents with exactly how you found everything, what it could mean to their company if it got out, and what they could do to fix it.
Just really be aware of your safety/risk. If you try to help and they don't want to fix it, don't feel bad or unethical, you've done what you can.
You've already talked to the company, so anonymously releasing the information is out of question, they could probably track it to you.
Do they not have any sort of policy on this? Maybe try to talk to their team again but make sure you get it in writing and signed first that you're not going to be held liable, and just make sure you're safe. Maybe even ask a tech-orientated lawyer first?
My advice would to just try to be nice and open to the company, but stay firm that this is a major issue. Maybe write up some documents with exactly how you found everything, what it could mean to their company if it got out, and what they could do to fix it.
Just really be aware of your safety/risk. If you try to help and they don't want to fix it, don't feel bad or unethical, you've done what you can.
In the future, submit it anonymously to https://hackerone.com/ and let them handle it. You open yourself up to a substantial amount of risk (e.g. massive fines or going to prison) with the upside being a tiny reward or perhaps a "thank you". It's absolutely not worth it to try and be the good guy here.
Horrible idea. If they know who he is, and they find it on there, they're likely to try and hit him with legal bullshit if they're a dumb company.
Right. This is more of advice to anyone else that submitting security vulnerabilities to a company who didn't ask for it is an extremely risky decision to make.
The Security Researchers that I work with, and myself included, usually follow the RFPolicy:
http://www.wiretrip.net/p/rfpolicy.html
This responsible disclosure policy was first put together by rain.forest.puppy. (One of the first people to discover SQL injection, and one of the founders of the OSVDB.) We have had good results with it, and nearly all the people that we have disclosed vulnerabilities to have found it to be more than fair, and motivating. The researchers have found that it also gets results quickly.
By default it requires you to disclose that you are following this policy, disclose the vulnerability, as directed in the document, then give them 5 days to respond. If you have done everything you could to contact them, and they will not respond, then disclose.
However, as others here have been saying, it may take a while to fix this problem. If they do respond, they may want to "negotiate" more than 5 days to fix the issue. That's great. Get some details, set up a reasonable timeline with them, and get a contact's information. Then it's up to you to hold them accountable. Sometimes this means disclosing on the agreed upon deadline, other times it means following up and seeing if more time should be given before disclosing.
The main issue, as you point out, is keeping users/data safe. If the company is unwilling to work with you, not disclosing could put other people at risk, because you didn't stop unsuspecting users from signing up for the service. On the other hand, disclosing without working with the company can unnecessarily put the current users/data at risk.
It's good to have a balance. The RFPolicy has helped me to have that balance when doing responsible disclosure. Give it a look over. It's not too late to use the RFPolicy now.
http://www.wiretrip.net/p/rfpolicy.html
This responsible disclosure policy was first put together by rain.forest.puppy. (One of the first people to discover SQL injection, and one of the founders of the OSVDB.) We have had good results with it, and nearly all the people that we have disclosed vulnerabilities to have found it to be more than fair, and motivating. The researchers have found that it also gets results quickly.
By default it requires you to disclose that you are following this policy, disclose the vulnerability, as directed in the document, then give them 5 days to respond. If you have done everything you could to contact them, and they will not respond, then disclose.
However, as others here have been saying, it may take a while to fix this problem. If they do respond, they may want to "negotiate" more than 5 days to fix the issue. That's great. Get some details, set up a reasonable timeline with them, and get a contact's information. Then it's up to you to hold them accountable. Sometimes this means disclosing on the agreed upon deadline, other times it means following up and seeing if more time should be given before disclosing.
The main issue, as you point out, is keeping users/data safe. If the company is unwilling to work with you, not disclosing could put other people at risk, because you didn't stop unsuspecting users from signing up for the service. On the other hand, disclosing without working with the company can unnecessarily put the current users/data at risk.
It's good to have a balance. The RFPolicy has helped me to have that balance when doing responsible disclosure. Give it a look over. It's not too late to use the RFPolicy now.
Thank you for the link of the policy, it seems to be a fair one.
I just read it and it looks like you are misinterpreting it.
> then give them 5 days to respond > they may want to "negotiate" more than 5 days to fix the issue
"5 working days" is not the same at all than "5 days", think of public holidays and week ends ...
I just read it and it looks like you are misinterpreting it.
> then give them 5 days to respond > they may want to "negotiate" more than 5 days to fix the issue
"5 working days" is not the same at all than "5 days", think of public holidays and week ends ...
You are absolutely right. Big difference. I did not mean to imply that it was 5 days, regardless of holidays/weekends.
In fact, because we are online more often during holidays, it is during holidays that we most often find vulnerabilities that we need to disclose.
Especially during December, we are much more lenient.
In fact, because we are online more often during holidays, it is during holidays that we most often find vulnerabilities that we need to disclose.
Especially during December, we are much more lenient.
> I did not mean to imply that it was 5 days
My comment was supposed to be an addendum but I failed by nitpicking and questioning your interpretation. I'm sorry.
As a security researcher, may I ask you these questions:
Which channel are you using as a first contact ? Would it be enough for me as a saas supplier to monitor [email protected] ? I must admit I'm bit afraid by a cleartext channel for this kind of disclosure. Would you have some recommandations for the receiving part of the vulnerability ?
My comment was supposed to be an addendum but I failed by nitpicking and questioning your interpretation. I'm sorry.
As a security researcher, may I ask you these questions:
Which channel are you using as a first contact ? Would it be enough for me as a saas supplier to monitor [email protected] ? I must admit I'm bit afraid by a cleartext channel for this kind of disclosure. Would you have some recommandations for the receiving part of the vulnerability ?
security@ is common, but it's unlikely that I'm going to blindly send an email to an address without knowing it is monitored, except as a last resort.
Having a web page on your website that is easily identifiable via google is probably one of the best. You can put a PGP key there if you like. You will find that security researchers have a wide range of caring about how secure the communications are, so don't be surprised if lots do not bother to use it, since it's still your data that is at risk and not theirs. Alternatively, there are bug bounty programs for incentivizing researchers (both to find bugs, but also to play nice), and those generally work over HTTPS, so it's encrypted to that extent.
HackerOne recently launched a Directory service for security contacts: https://hackerone.com/blog/wheres-that-security-at I don't think that is the most common way by far, but if you particularly care, you might want to use that.
Having a web page on your website that is easily identifiable via google is probably one of the best. You can put a PGP key there if you like. You will find that security researchers have a wide range of caring about how secure the communications are, so don't be surprised if lots do not bother to use it, since it's still your data that is at risk and not theirs. Alternatively, there are bug bounty programs for incentivizing researchers (both to find bugs, but also to play nice), and those generally work over HTTPS, so it's encrypted to that extent.
HackerOne recently launched a Directory service for security contacts: https://hackerone.com/blog/wheres-that-security-at I don't think that is the most common way by far, but if you particularly care, you might want to use that.
> My comment was supposed to be an addendum but I failed by nitpicking and questioning your interpretation. I'm sorry.
Well, I appreciate you pointing out where I was vague. You provided, and brought about, some important clarification.
> Which channel are you using as a first contact ?
It takes quite a bit of effort to make a nice writeup for an identified vulnerability, and hunt down where to send it. Generally, someone willing to take the time to be nice and send in a detailed report, is willing to look for the best channel to send information through.
I start by looking through the "About" and "Contact" pages of the web application or service that I found the vulnerability on. If they have a reference to a bug tracking system, a system administrator, or a security contact, I send it there. If they are all emails, I usually send a message to all of them, to make sure that someone receives it.(If I don't know who is going to get the message, I am initially vague on the vulnerability, and ask for a technical contact to forward the technical information to.) Otherwise, I look at whois information to see if there is a good technical contact. If I still haven't found a good contact, I send a message to all of the emails listed in the RFPolicy. If all of those messages bounce, I send a message to any email address I can find for the domain. And once, I even called in to a sales line after all of this, and explained the situation. They got me in contact with "Bob the website guy", to take care of the issue.
I have never received a bounty for any of these. I just want to do my best to make sure it gets taken care of.
> Would it be enough for me as a saas supplier to monitor [email protected] ?
I think this would be a good backup plan. Probably safe to add forwards for all the RFPolicy emails.
> I must admit I'm bit afraid by a cleartext channel for this kind of disclosure. Would you have some recommandations for the receiving part of the vulnerability ?
My recommendation would be to make it easy and clear to find how you would prefer to receive notices. If you include your PGP key on your contact page with a message that all security reports should be encrypted, most I know are willing to do so. If you prefer them to send it via an HTTPS "Contact" page, say so, and most will see that and send it via that channel. Just like your saas, if you make it intuitive and useful, they will be happy to use it.
Well, I appreciate you pointing out where I was vague. You provided, and brought about, some important clarification.
> Which channel are you using as a first contact ?
It takes quite a bit of effort to make a nice writeup for an identified vulnerability, and hunt down where to send it. Generally, someone willing to take the time to be nice and send in a detailed report, is willing to look for the best channel to send information through.
I start by looking through the "About" and "Contact" pages of the web application or service that I found the vulnerability on. If they have a reference to a bug tracking system, a system administrator, or a security contact, I send it there. If they are all emails, I usually send a message to all of them, to make sure that someone receives it.(If I don't know who is going to get the message, I am initially vague on the vulnerability, and ask for a technical contact to forward the technical information to.) Otherwise, I look at whois information to see if there is a good technical contact. If I still haven't found a good contact, I send a message to all of the emails listed in the RFPolicy. If all of those messages bounce, I send a message to any email address I can find for the domain. And once, I even called in to a sales line after all of this, and explained the situation. They got me in contact with "Bob the website guy", to take care of the issue.
I have never received a bounty for any of these. I just want to do my best to make sure it gets taken care of.
> Would it be enough for me as a saas supplier to monitor [email protected] ?
I think this would be a good backup plan. Probably safe to add forwards for all the RFPolicy emails.
> I must admit I'm bit afraid by a cleartext channel for this kind of disclosure. Would you have some recommandations for the receiving part of the vulnerability ?
My recommendation would be to make it easy and clear to find how you would prefer to receive notices. If you include your PGP key on your contact page with a message that all security reports should be encrypted, most I know are willing to do so. If you prefer them to send it via an HTTPS "Contact" page, say so, and most will see that and send it via that channel. Just like your saas, if you make it intuitive and useful, they will be happy to use it.
A week is no time whatsoever.
Lots of people routinely publish vulnerabilities; anecdotally, if you do it the same way everyone else does, I think your risk is probably minimal.
Some thoughts:
* Have a calendar and stick to it. If it's 90 days from acknowledged contact, don't publish anything for 90 days.
* Be careful about upselling services (my advice: simply don't do it). If you're effectively breaking someone's terms of services by testing (spoiler: you probably are) and you "ask" for a service contract in return for doing something favorable (ie, not doing something unfavorable) with the results of that testing, you're being coercive. Doing something unlawful to coerce someone into giving you something of value is extortion. Don't extort people.
* Be extremely careful testing other people's sites. The short answer to "is it lawful to test someone's site" is, "probably not". If they've posted a bug bounty or a list of thank-yous to researchers, you can reasonably infer that they're allowing remote testing --- but if your testing crashes their site or compromises user data, all bets are off.
* Do not under any circumstances post actual user information, sanitized or otherwise.
* Do not post exploit code, or information that makes exploitation trivial. If the world doesn't believe you about the severity of your finding, get better at gauging severity, or become a better writer.
If it were me, I'd probably sketch out a policy as follows:
* A calendar and set of escalations for confirmation of a finding --- first contact in order to find a safe way to relay the finding, escalating to public (Twitter) requests for someone to relay the finding to (maybe 2-3 business days later), escalating to simply sending the finding to public support addresses (maybe a week later). With no acknowledgement of a finding after, like, a month, I might escalate to posting the name of the company and a SHA2 hash of the finding, repeatedly confirming the finding every other week or so, and then maybe a month later more details on what the finding enables (the "Phone numbers. Names. Location." thing you wrote here, I would not write for a long time.)
* Once the finding is confirmed, a simple schedule for public announcement. Maybe 30-90 days, depending, on generating a patch, and then N days after than for an announcement on my blog or whatever. If we're doing a coordinated announcement where you send a bulletin that credits me and agrees with my assessment of the finding, maybe I'll give you an extra 30 days after the patch if you want it. If I'm the only one who announces, maybe I'm announcing 5 days after the patch. Things like that.
The important things are:
1. Write a policy and stick to it.
2. Get the vulnerability confirmed before you announce it.
3. Negotiate with the vendor to minimize harm.
Again: be especially careful when you're testing someone's servers. The law is generally pretty supportive of testing software you personally install, but not at all supportive of you testing software on other people's machines.
Lots of people routinely publish vulnerabilities; anecdotally, if you do it the same way everyone else does, I think your risk is probably minimal.
Some thoughts:
* Have a calendar and stick to it. If it's 90 days from acknowledged contact, don't publish anything for 90 days.
* Be careful about upselling services (my advice: simply don't do it). If you're effectively breaking someone's terms of services by testing (spoiler: you probably are) and you "ask" for a service contract in return for doing something favorable (ie, not doing something unfavorable) with the results of that testing, you're being coercive. Doing something unlawful to coerce someone into giving you something of value is extortion. Don't extort people.
* Be extremely careful testing other people's sites. The short answer to "is it lawful to test someone's site" is, "probably not". If they've posted a bug bounty or a list of thank-yous to researchers, you can reasonably infer that they're allowing remote testing --- but if your testing crashes their site or compromises user data, all bets are off.
* Do not under any circumstances post actual user information, sanitized or otherwise.
* Do not post exploit code, or information that makes exploitation trivial. If the world doesn't believe you about the severity of your finding, get better at gauging severity, or become a better writer.
If it were me, I'd probably sketch out a policy as follows:
* A calendar and set of escalations for confirmation of a finding --- first contact in order to find a safe way to relay the finding, escalating to public (Twitter) requests for someone to relay the finding to (maybe 2-3 business days later), escalating to simply sending the finding to public support addresses (maybe a week later). With no acknowledgement of a finding after, like, a month, I might escalate to posting the name of the company and a SHA2 hash of the finding, repeatedly confirming the finding every other week or so, and then maybe a month later more details on what the finding enables (the "Phone numbers. Names. Location." thing you wrote here, I would not write for a long time.)
* Once the finding is confirmed, a simple schedule for public announcement. Maybe 30-90 days, depending, on generating a patch, and then N days after than for an announcement on my blog or whatever. If we're doing a coordinated announcement where you send a bulletin that credits me and agrees with my assessment of the finding, maybe I'll give you an extra 30 days after the patch if you want it. If I'm the only one who announces, maybe I'm announcing 5 days after the patch. Things like that.
The important things are:
1. Write a policy and stick to it.
2. Get the vulnerability confirmed before you announce it.
3. Negotiate with the vendor to minimize harm.
Again: be especially careful when you're testing someone's servers. The law is generally pretty supportive of testing software you personally install, but not at all supportive of you testing software on other people's machines.
This post is the best answer you can ask for.
I spend a lot of time poking at software I can install on my own device (i.e. open source) because I've made the mistake of testing someone else's server (CFAA violation) then going public about it (which gave them incentive to prosecute). Don't make my mistake.
I spend a lot of time poking at software I can install on my own device (i.e. open source) because I've made the mistake of testing someone else's server (CFAA violation) then going public about it (which gave them incentive to prosecute). Don't make my mistake.
I wish this was the top level post. OP, this is exactly what you should be doing.
If I could add my own top level post - just don't do any penetration testing on applications you have not received explicit permission to test on.
Would you like it if someone did you a favor by breaking into your house, explaining to you that your security is crap, and then justifying it by saying that they should be thanked because they didn't steal anything and they're doing you a favor?
No. You'd be annoyed. Don't look for security vulnerabilities when you haven't been explicitly tasked with doing so (unless there is a bug bounty or explicit responsible disclosure policy).
Also, seriously, don't offer your services after you find a vulnerability. Even if you don't think it's extortion, a jury would probably disagree with you. Imagine how it would feel to receive an email explaining you have a serious security flaw, and "oh by the way hire me because I'm great at this."
If I could add my own top level post - just don't do any penetration testing on applications you have not received explicit permission to test on.
Would you like it if someone did you a favor by breaking into your house, explaining to you that your security is crap, and then justifying it by saying that they should be thanked because they didn't steal anything and they're doing you a favor?
No. You'd be annoyed. Don't look for security vulnerabilities when you haven't been explicitly tasked with doing so (unless there is a bug bounty or explicit responsible disclosure policy).
Also, seriously, don't offer your services after you find a vulnerability. Even if you don't think it's extortion, a jury would probably disagree with you. Imagine how it would feel to receive an email explaining you have a serious security flaw, and "oh by the way hire me because I'm great at this."
So here's a question on a metaphor that seems closer to the current scenario. Imagine a bank that's promising to deliver a secure service but leaving the safes unlocked and account holders' files lying around. The current issue I discovered actually falls under that with user data being publicly exposed with no extra steps required to get it. No hacks over here. Going back to the metaphor, assume everyone else believes their money is safely locked away and their account information secure. At this point, you tell the bank that they have this problem. Don't you also have a moral obligation to tell the public they are not as safe as they thought they were? Doesn't that moral obligation increase the longer the problem remains unresolved?
I'm really not looking for any thank yous here (and not suggesting that that was insinuated). I just want to help people and I would like to do my part to ensure society is safe. This information being pulled by a more malicious source could be incredibly damaging.
As for the services offering. Wouldn't dream of it. Totally onboard with everyone on that :).
I'm really not looking for any thank yous here (and not suggesting that that was insinuated). I just want to help people and I would like to do my part to ensure society is safe. This information being pulled by a more malicious source could be incredibly damaging.
As for the services offering. Wouldn't dream of it. Totally onboard with everyone on that :).
This is an absolutely fantastic post. Not just legally, but morally as well. It doesn't just outline the legally correct thing to do, but the morally right thing to do as well.
It's what separates a responsible researcher who improves security for all, from a petty cyber criminal. +1 on the above advice.
It's what separates a responsible researcher who improves security for all, from a petty cyber criminal. +1 on the above advice.
When I started reading this, I assumed this was going to be a typical "I've emailed them a dozen times over the course of two months, and nothing has changed!" story...
In this case, you've sent them one email, and it sounds like they rolled out a partial fix in less than a week.
Why don't you wait and see how they respond to your second email?
In this case, you've sent them one email, and it sounds like they rolled out a partial fix in less than a week.
Why don't you wait and see how they respond to your second email?
It feels like threatening, and I'm not sure what the legal implications are. Overall it feels unethical to be sitting with this knowledge and not disclosing it if the company doesn't get it done.
That said, I informed them only a week ago. Which really puts me at crossroads. Usually the time given is one month. But with the data being this critical, I don't know if one month is acceptable.
What should I do?