Correctly disclosing Private API security shortcomings

Question

I am hoping I can get some direction on the correct way to go about properly disclosing serious shortcomings with a private web service API (closed source).

Initially I assumed that the API would be relatively well implemented, so I set about sniffing the traffic with Wireshark, intending to reverse engineer it firstly for the the challenge and secondly to hopefully implement it into another product I am working on (open source).

What I discovered plainly horrified me, there are major implementation issues which leave username/password details in clear text on the wire (as an example of just one issue).

The program is not widely used, however the user demographic it appeals to would likely be one where a 'valuable' password would often be used, and as such I feel this should be addressed by the author in some manner.

Naturally, and even though this will hamper my own efforts to integrate with the API if the author resolves the issues, I wish to disclose this to the author initially and then to the public, in the interest of having the problems resolved. To achieve these ends I would assume that I should follow Responsible Disclosure procedures.

This product does have some paying customers, however I am not one of these, and I only use the free version.

To the best of my understanding I should proceed as follows:

1. Contact the Author(s) privately, outlining the issues discovered with risks and mitigation options for each.
2. Determine a suitable time frame for patching the issues and releasing fixes with the program author.
3. Once the time frame expires, I release details of the problems and proof of concept code.

Some worries I have however are:

1. What is the best way to convey the message that I am not after any kind of financial gain, and that this is not personal and is not intended to harm the product or the company?
2. What if, despite best efforts, the author of the product decides to get 'legal' to try and hide the issues? (Of course you're probably not lawyers, advice will be general guidance only).
3. What is a valid release mechanism for the release of the details? I see announcements of this nature on the Full Disclosure mailing list often; is this generally regarded a suitable place for these?
4. Would this require applying for a CVE number for the problems found?
5. As I potentially would like to enter the information security field full time in the future, should I use a personal name on the disclosure? Or does this expose me to potential legal issues?

Answer 1

1) Just report the issue. Don't even mention "I'm not trying to extort you".

2) One way to completely avoid legal problems is to report anonymously. Create a webmail account using ToR, and do all communication through that. It's sad that we have to consider this, but legal issues can cause you great problems, even if you've not broken the law.

3) The most official disclosure route is bugtraq@securityfocus.com. Organisations like CERTs and Secunia will pick it up from there. The vendor will usually release their own advisory; your advisory is like a blog post that you'd promote: Twitter, Reddit, etc.

4) Apply for a CVE number at some point before you release the advisory. It's easy to get one and you only need to reveal outline details of the vulnerability.

5) If the issue gets fixed and the vendor is constructive, you could lift your anonymity. Pointing to advisories you've published is very helpful for technical infosec employment.

One other thing: I suggest you don't bring up time lines initially. Only do this if they seem to be excessively slow.

Answer 2

Based solely on how you've written question here, it seems obvious that you have the best intentions in doing this, and that you are quite capable of making these intentions clear in written form. Just state your motive in a plain and respectful manner, as you've done here, and any publisher seriously committed to his product should take your message seriously too.

A few general points to keep in mind for this sort of thing:

Ask for the right person to talk to before mentioning any details.
You will want to convey your information to a relevant architect or developer, or perhaps a manager who has enough technical knowledge to understand the issue properly, and who will also understand the need for keeping a lid on the issue until it is resolved. It may take some time (?) to get access to the person you need to talk to, but I'm sure that person will appreciate the effort.

Be respectful
Not everyone responds equally well to what may be interpreted both as criticism and possibly as a threat (of public disclosure). Remember that there is likely to be a certain amount of pride involved. It's also entirely possible that the developers are fully aware of the issue, but that priorities are not high enough, or that they simply consider abuse unlikely, and have ignored it thus far. In either case, it is more likely that you'll succeed if you come across as a nice and genuinely helpful person (which, as I already noted above, you do). Hopefully, this will help you avoid question 2 altogether (I can't imagine a developer ever wanting to involve any lawyer in an issue such as this unless they felt they absolutely had to).

That said however, make sure they understand that you are serious and that you do want to see the issue resolved.

Requesting a CVE Identifier
I'm not familiar with the requirements for obtaining a CVE Id, or how relevant this would be in your specific case. Perhaps you can find some useful info in the mitre.org FAQ? You can find info about the application process itself from the same site. I'd be careful when mentioning this though, so as not to appear to be too aggressive or threatening towards the publisher.

Answer 3

Whilst attempting to implement some functionality relating to your product {product name}, I noticed something that might potentially have a security vulnerability. Would it be possible to speak to someone regarding this issue, which relates to {sensitive information disclosure/potential denial of service/accidental alien invasions}. Due to the nature of this issue, I'd prefer to reveal full details to a member of technical staff.

Thank you,

{finder}

• A reasonable disclosure time should be agreed with them, not enforced on them - some companies have published disclosure times (e.g. 90 days), but others might have fixed release cycles or dependencies on third parties (e.g. Apple takes a while to get things through app store submission process, so they might be able to fix it tomorrow, but it not be published until next month)
• Provide PoC upon request, or once speaking to correct person. This should avoid coming across as after a reward.
• If they go "legal", ensure you can demonstrate that you've not done anything illegal. For example, you have every right to look at traffic on your own network, even if it was generated by an application you did not write. Attempting to hide issues tends to suggest that the developers don't actually care about the security of their users - sooner or later, someone less scrupulous will exploit the issue. Nothing much you can do if they are unwilling to sort it, other than warn (factually) other potential users through means such as disclosure lists.