The topic of how to handle security vulnerabilities has been discussed for years. Wikipedia defines responsible disclosure as:
Responsible disclosure is a computer security term describing a vulnerability disclosure model. It is like full disclosure, with the addition that all stakeholders agree to allow a period of time for the vulnerability to be patched before publishing the details. Developers of hardware and software often require time and resources to repair their mistakes. Hackers and computer security scientists have the opinion that it is their social responsibility to make the public aware of vulnerabilities with a high impact. Hiding these problems could cause a feeling of false security. To avoid this, the involved parties join forces and agree on a period of time for repairing the vulnerability and preventing any future damage. Depending on the potential impact of the vulnerability, this period may vary between a few weeks and several months.
Facebook understands the value of responsible disclosure, noting:
If you give us a reasonable time to respond to your report before making any information public and make a good faith effort to avoid privacy violations, destruction of data and interruption or degradation of our service during your research, we will not bring any lawsuit against you or ask law enforcement to investigate you.
Microsoft has a similar scheme, which they call Coordinated Vulnerability Disclosure.
I believe in responsible disclosure, and have practiced it both when I was working as a vendor (at which point I worked with people who found vulnerabilities in my company’s products, ensuring that they got credit and that security problems were fixed promptly), and when I’ve found vulnerabilities in products.
So I was surprised by a recent interaction with Blackboard.com, a provider of services to schools and universities.
The problem started when I forgot my password for Fairfax County Public Schools, where my daughter is a student. Clicking the “I forgot my password” link sent me an email – but instead of an email with a link, it sent my actual password. This was common five or 10 years ago but has largely been eliminated in recent years.
So I wrote a letter to the FCPS technical support line, explaining the problem, and why it’s a bad idea to send passwords instead of a link. (In brief, because (1) if the site can send the password, that means they’re not storing it in a one-way hashed form as is best practice, (2) many people use the same password for multiple sites so any compromise of the site containing the password could compromise the user on multiple sites, and (3) email is insecure.) I got back a pleasant reply saying they would investigate, and after a few days was told that the problem was in Blackboard’s product, and they would follow up with Blackboard. It’s not the most critical security problem, but since site compromise causing password theft is a common source of identity theft, it’s an important problem to solve promptly.
Feeling that I, as a security professional, probably knew more about how to make this work than FCPS, I contacted Steve Feldman, the Vice President of Performance and Security Engineering at Blackboard (whom I found with LinkedIn. I explained to Feldman why storing and sending passwords is a problem, and asked him to investigate. Feldman responded promptly, understood the problem, and forwarded me to one of his lieutenants with the title “Director, Security, Blackboard Learn”, who also promised to investigate and respond promptly, and forwarded me to someone in technical support for Blackboard Connect, which I assume is a different product. And that’s where things went downhill.
The technical support person, after some investigation, informed me that “I have requested that my VP of Product Management generate a quote to perform this custom change.” I asked whether this was a problem in the Blackboard product or FCPS’s integration into their existing systems (which may have been performed by Blackboard, FCPS, or a third party), and what Blackboard is doing to solve this problem for all its customers – as well as questioning why a customer is being charged for a “custom change” to fix a security problem. (That’s a battle that Microsoft lost years ago, when they refused to give security patches to people with pirated copies of Windows.) At that point, the technical support person said that since I don’t work for FCPS, he can’t answer any more questions.
That’s fair enough, but when I popped the stack, I ran into the same problem – neither Feldman nor his director of security would tell me anything about whether this is a problem in their product or in the local integration, and how any resolution is being communicated to other Blackboard customers, if others are affected.
Which takes me back to my original point – responsible disclosure. It’s surprising that a vendor, in particular a company whose mission is to support education, is so uninterested in solving this problem. It’s now been almost two months since I notified them, which is not an unreasonable period of time – but since they’ve made it clear they have no intention of telling me anything, I think it’s long enough. I’m not a hacker by any stretch of the imagination – last time I did any amateur hacking was 15 years ago, and 30 years ago for any serious hacking – but I know the rules of the game.
Vendors, in general, justifiably complain when vulnerabilities are publicly disclosed without an opportunity to address the problem. This experience brought home to me that responsible disclosure isn’t the whole story – responsible handling of the disclosure by the vendor is also critical to the security ecosystem.