When vulnerability disclosure goes sour: New GitHub repo details legal threats and risks faced by ethical hackers

Public timeline of incidents aims to further conversation surrounding security research and vulnerability disclosure

UPDATED A new GitHub repository has been created to document and track the times when vulnerability disclosure has gone sour.

The Research Threats project details historical legal battles between researchers and the target organizations whose software was found to have security flaws.

It was built on top of data collected in an already-established list by security researcher and “vulnerability historian” Jericho, who launched the original project as a section called Legal Threats on website Errata in 2009.

Jericho told The Daily Swig: “Since then we’ve seen all the points made, and re-made, about how trying to stifle research is a losing battle and the wrong approach.

“The goal was to have a clear list of companies that used that tactic, so researchers could avoid them. Or if they chose to disclose vulnerabilities in that vendor’s products, consider doing it anonymously or with some other protection in place.”

Speaking to The Daily Swig, researcher Sick Codes, who alongside Jericho and Casey John Ellis maintains the repo, said the move to GitHub was made to give both researchers and organizations the opportunity to both upload and change information, something that “wouldn’t have happened” on the original website.

Research Threats is a ‘collection of over-reactions, demands, and cease and desist letters’

Judge or jury?

Research Threats offers a timeline of notable vulnerability disclosure incidents from 2006 up to the present day, including descriptions of the legal threat and how it was resolved, if at all.

It also has a ‘goodies’ folder, in which researchers can upload copies of correspondence they have received from companies or lawyers acting on their behalf.

Anyone can make pull requests to change the information in this growing database, creating a level playing field for all parties involved.

Making the timeline open source also improves its accuracy, reducing the risk of misreporting cases, according to Sick Codes.

The security researcher told The Daily Swig: “I’m not the judge and jury on any of these situations because, you know, people could lie and say they got a letter, but they were actually doing something bad… and that’s one of the issues we considered when we were thinking about like, should we put a time limit [on how long information can be changed] of like a month or something?

“And then we were like, that’s not really appropriate either because things could happen fast or slow.

“That’s why [we] put it up on GitHub so that people can actually project or review it [to] say well, besides this is not right, this is true… Anyway, it’s an experiment.”

Jericho added: “My big thing is trying to remain as factual and neutral as possible. They (organizations) are already being called out under the banner of ‘wrong choice assholes’, in so many words, so the summary of their company incident is brief and to the point, with backing documentation.

“The idea was more around ‘you are on notice, researchers are now aware of your tactics, this isn’t good for anyone’.

“But, since the damage is done, they won’t be removed. If they backpedaled on a threat and gave us info, I would update to include that. So I think it does serve as a warning of sorts, but it isn’t meant to ‘punish’ the company.”

Making safer decisions

Casey John-Ellis agreed with Jericho, telling The Daily Swig that the repo was formed “to encourage folks to aggregate verified interactions where vulnerability reporting has proven to be legally unsafe”.

“The hope is for security researchers to be able to use this to make safer decisions, and for organizations to understand better what kinds of things they ought not to do when someone approaches them offering legitimate help – an ideal world would be where this type of interaction is a very normal, neutral, and expected part of being on the internet, but unfortunately, we still have a ways to go there,” they said.

“The open source element adds an additional layer of transparency and makes the right of reply easier. Both of these are important for objectivity, and for keeping information up to date.”

Changing attitudes

Research Threats contains guidance for both researchers and organizations on how to work together in a “perfect” coordinated disclosure.

Regarding the timeline, Sick Codes said that having the information displayed in such a way shows the historical changes of certain companies attitudes towards ethical hacking.

Notable incidents in the list include two entries in 2008 when Apple was accused of cancelling talks at Black Hat, one due to a non-disclosure agreement, and another apparently due to the apprehension from the company’s marketing team.

Sick Codes told The Daily Swig many companies won’t appear twice: “Once they fix up the policy and get everything sorted out, especially getting a proper vulnerability disclosure policy with safe harbor and that sort of stuff involved, where it strictly says, like Apple’s one [policy] which says, ‘this supersedes every other violation as long as you report it to Apple’.”

Recent cases

While the project may demonstrate changing attitudes from companies such as Apple and Google, the repo may also serve as a reality check for organizations who are thinking of taking legal action following the private disclosure of vulnerabilities.

The most recent entry relates to an incident previously reported by The Daily Swig, during which security researcher Rob Dyke said he was served with a legal notice after a vulnerability disclosure went sour.

This incident has still not been resolved, as Dyke detailed in a blog post, leading the security researcher to pre-emptively crowdsource his potential legal fees.

This article has been updated to include further comment