You've found a nasty vulnerability and want to do the right thing.


Now what?



A guide for anyone new to vulnerability reporting

Risks

People don't take bad news too well. Companies are no different.

Legal threats

Dear sir/madam

Sorry to start on such a negative note, but it is important that you understand the mess you might be getting yourself into.

There have been a number of cases where security researchers have received threatening legal letters and even visits from the police, all for just trying to do the right thing. Telling a company that their software is broken can upset them. Rather than take responsibility for the problem, they might try to blame you. They might claim you were attempting to "hack" them or that you were trying to extort money from them. They might get lawyers involved. Getting caught up in this sort of mess can be very stressful, disruptive and time consuming.

Attrition.org maintains a list of legal threats against security researchers.

Police Involvement

Knock Knock

If you're really unlucky, you might not just get an angry letter from a lawyer. You could get a visit from the police. A classic example happened a couple of years ago when security professional Patrick Webster was questioned by police after notifying First State Superannuation about a direct object reference vulnerability in their online service. Think seriously about your intentions, and always act in a way that is defensible.

Options

Doing the right thing basically means telling those responsible for the service or product that it is vulnerable and putting users at risk.

Non-disclosure

Don't tell

As the title suggests, with this approach you don't actually report the vulnerability to the vendor. You might keep it to yourself and develop your own zero-day exploit. You could also pass on or sell the vulnerability to a third party which doesn't disclose the issue to the vendor. This might be a legitimate approach if you work for a security research company that needs to develop exploits as part of the service it provides its customers.

Limited disclosure

Let them know, then sit back, relax and forget about it

The idea here is that you don't disclose the vulnerability to the public. Instead, you notify the owner, provide them with the relevant details then let them get on with it. Unfortunately, a lot of vendors and services do not take responsibility for their security problems and could simply ignore your notification without ever fixing the problem. This means users remain at risk.

Coordinated disclosure

Let them know, but give them a time frame in which to fix the issue. Then go public

Instead of just notifying them and forgetting about it, you can give them a time frame in which they need to fix the issue before you go public with the vulnerability. You might want to give them the benefit of the doubt first, and not specify a time frame in your notification. Give them the chance to fix it within a reasonable amount time. If nothing happens, then you could chase them. If nothing happens still, then you could give them the time frame and state that you will go public. Remember, always be polite, professional and non-threatening. Explain that your actions are in the interest of the users and that vulnerabilities are rarely discovered by a single person, so they can't assume you're the only one to have found it. It's just that you decided to help the vendor.

Limited public disclosure

Going public but without the details

This might be done alongside limited or coordinated disclosure. Certain details are made public, such as what software is affected and the severity of the issue, but the exact details about the vulnerability are withheld. This could put the required pressure on the vendor but without exposing users unnecessarily. Proof of an exploit, such as a video showing code execution, can help add pressure.

Full public disclosure

No warning. Go public

Here the details are published in full without a warning to the vendor or service. This immediately exposes users to risk but could result in a swift response by the vendor.

You'll probably want to go with coordinated disclosure.

Approach

Be polite and non-threatening.

Stay anonymous

Temporary email, TOR and Wi-Fi

If you want to protect yourself from potential legal hassle, you could consider using TOR to access a temporary email service such as 10 Minute Mail. Do be aware though that there have been recent problems with TOR's security. As an alternative to TOR, you could use public Wi-Fi which you might find at a coffee shop or hotel. You could also use a VPN or proxy service. Or a combination.

Be yourself

They might say thank you

If you accept the risks outlined above, you might consider notifying them without hiding your identity. This would allow them to get back to you to request further details, to tell you it's fixed, or perhaps to say thank you. They might also give you credit. Remember to always be polite and non-threatening.

Content

What to include

The Open Security Foundation has produced an excellent document titled Researcher Security Advisory Writing Guidelines. It contains a full description of what you should include in an advisory. In brief: Title, Credit, CVE, Dates, Vendor, Product, Versions Affected, Risk / Severity Rating, Vulnerability Description and Impact, Caveats / Prerequisites, Proof of Concept, Solution, References, Creditee, Legal Disclaimer and Greetz & Shout-outs. It also has a section on the disclosure process.

Bug bounty

Cash Swag Credit

If you're lucky, you may have found a vulnerability in a product or service owned by a company that runs a bug bounty program. Some offer cash, some give you swag (aka t-shirts), others add you to their hall of fame. Bugcrowd has an excellent list of vendors that offer bounties, as does bugsheet. Make sure you follow the bounty's terms and conditions, otherwise they might decide not to pay you.

Third parties

CERTs etc

If the vendor doesn't have a bug bounty program, and if you're not comfortable contacting them directly, then another option is to go through a third party. Again, the bugcrowd list includes brokers and security companies that might be willing to handle your vulnerability for you. You could also try upSploit who offer an advisory management service. Finally, many Computer Emergency Response Teams (CERTs) are willing to contact a vendor on your behalf. For example, the US CERT provides a form for you to submit vulnerability reports. The Wikipedia CERT page has a list of CERTs on it. ICS/SCADA vulnerabilities can be reported to the ICS-CERT.

Who to contact

Contacting the vendor

Vulnerability Policy

Read it

If the vendor or service has a security vulnerability policy, it should contain details on how to notify them of vulnerabilities. This would probably be your best bet, as it should get you straight through to those who understand the vulnerability and can take appropriate action.

Contact page

Be careful

You could try to notifying them through their usual support channel. Most companies have a "contact us" link somewhere on their website. This might take you to a contact form or provide details of a technical support email address. The danger here is that you don't know who will have access to your notification and it could get into the wrong hands. Ideally you would contact a security team directly, but this is generally not an option for most support channels. Simply state that you have found a serious vulnerability that is putting users at risk and that you would like to be contacted by a member of their security team.

Email

whois $domain | grep @

If their website doesn't explicitly mention how to notify them of security issues and if the standard contact channel isn't getting you anyway, then you might want to try sending them an email. RFC 2142 suggests the use of security@domain but if that doesn't work you can also try hostmaster@domain and webmaster@domain.

As a last resort or as an alternative to trying an RFC 2142 email address, you could do a WHOIS lookup on the domain and look for appropriate admin contact details.

Contact lists

SELECT * FROM VENDORS;

Webantix maintains a searchable database of security contact for organisations and services, and OSVDB maintains a list of software vendor security contacts.

Going public

The time has come...

FD mailing list

Lightly moderated

The first option for going public is the resurrected Full Disclosure mailing list. The original list created and run by John Cartwright was terminated in March 2014. However, Gordon Fyodor Lyon has created a replacement which will be lightly moderated by a team of volunteers.

Bugtraq

Moderated

Bugtraq is another security mailing list that tends to be moderated more than Full Disclosure, so it should have a better signal-to-noise ratio.

Vulnerability databases

Verified

Instead of posting to a mailing list, you could send your vulnerability to a vulnerability database and let them publish it anonymously. VDBs include OSVDB, NVD, Exploit DB and Secunia. Some VDBs will verify the vulnerability before publishing.

Open source

Free as in beer, free as in speech

If you've found a vulnerability in open source software, you can post it to the Open Source Security mailing list. Members of the list include open source projects as well as researchers and developers. As open source software is community-driven, getting a CVE identifier and having others on the list verify your research puts the focus on addressing the technical issues, rather than on the politics of the disclosure. A quick fix benefits everyone in the community.

Finally

The fine print.

Disclaimer

You use the advice on this site at your own risk

This web site and its creator is not responsible for, and expressly disclaims all liability for, damages of any kind arising out of use, reference to, or reliance on any information contained within the site. While the information contained within the site is periodically updated, no guarantee is given that the information provided in this web site is correct, complete, and up-to-date.

Although this site may include links providing direct access to other Internet resources, including web sites, I am not responsible for the accuracy or content of information contained in these sites.

Thanks

^_^

Special thanks go to Jericho for his excellent blog post which provided tons of valuable feedback.

Feedback

Have something to say?

If you think this site needs improvement or if you've found a technical inaccuracy, please let me know. Any constructive feedback is welcome, positive or negative. You can leave a comment on this blog post or on this reddit post. You can also contact me directly on twitter at @zeroXten.

Further reading

The following sites might help you

Wikipedia Full Disclosure page | The responsibility of public disclosure | Ethics of full disclosure concerning security vulnerabilities | OSVDB Everything is vulnerable