How to disclose a vulnerability responsibly

Last March there were a couple of interesting vulnerability disclosures that merit a closer look from a disclosure point of view.

In early March, payment-processing software from the Finnish vendor Basware was discovered to have two vulnerabilities that can be used for e.g. creating fake transactions.

According to the finder of the vulnerabilities, security researcher Samuel Lavitt, the vendor has been informed of the gaps nearly 3 years ago. At the time the National Cyber Security Centre’s bulletin was published, one of the vulnerabilities had been patched while the other hadn't.

It did not take long for the next vulnerability discovery to hit the headlines. On Tuesday of the following week it was reported that the police had arrested three individuals, who had only a short time earlier informed Tekes (the Finnish Funding Agency for Innovation) about a vulnerability they had discovered. What makes the incident newsworthy is that the trio had exploited the vulnerability to download thousands of applications from the system.

In mid-March a political party's website contained a configuration file that included current admin credentials. The news reports included facts that indicate that the credentials had been used to access personal information and communication files. The vulnerability was patched within 24 hours. The security update that patched the WordPress WPML add-on had been published the week before.

Does testing admin credentials count as a hack?

Earlier in the spring another political party's website could be accessed using an easy password. The incident provoked discussion about the legality of verifying a vulnerability.

The author does not have legal training and does not wish to take a moral stand on this. However, it should be obvious that disclosing a vulnerability in the media without informing the vulnerable party can provoke exploitation of the vulnerability. Although it must be said that I find it difficult to understand why any party would need a bumper period that lasts several years. Whether or not the vulnerability is disclosed, the likelihood that another party discovers it grows all the time.

Our policy on disclosing vulnerabilities

Responsible disclosure of vulnerabilities is closely linked to keeping the information confidential until time of disclosure and helping customers and users of vulnerable systems to protect their systems. There is no universal agreement on how much time a software vendor should have to patch the vulnerability. A bumper period of a little over 40 days is often used.

For several years we have abided by the vulnerability disclosure policy approved by our company's directors. The policy was published on our website in the spring of 2012 and it has been updated today. As vulnerabilities are usually international in nature, our policy is published primarily in English. 

Nixu Corporation Vulnerability Disclosure Policy

If security vulnerabilities are identified on a customer project, Nixu will respect non-disclosure agreements and customer’s views on the matter. If security vulnerabilities are identified in 3rd party products, when allowed, Nixu will inform the vendor(s) either directly or via an appropriate vulnerability coordinator such as NCSC-FI, US-CERT or CERT/CC to ensure the vulnerability will be fixed.

NIXU’S MAIN GOALS ON VULNERABILITY DISCLOSURE ARE:

* To help our customers to protect their business by being able to patch vulnerable systems.
* To contribute to the industry in general so that software products are made more secure to all users by having vendors deliver generic patches.

Nixu may publish vulnerability information publicly in a responsible manner when the agreements with the customers and vendors allow that.

First release: April 2012
Last reviewed: March  2015
(CERT-FI -> NCSC-FI, Nixu Ltd -> Nixu Corporation)