Experiences With Responsible Disclosure

Hackers have been an important part of the Internet since its creation. They are the ones who try to take the technology just over the edge to see what happens. This may mean that things break, or other interesting things happen. Sometimes this means new products are created, new ways of using technology becomes available to users, and sometimes things break. Many hackers feel an obligation to share their insights so that technology can be improved upon, this leads to public disclosures.

The Dutch National CyberSecurity Center has published a guideline for responsible disclosure. This guideline should help companies create and publish a procedure for ethical hackers to responsibly disclose vulnerabilities. The responsible disclosure guideline in short is that the company publishes how ethical hackers can contact the company, what the company expects from the reporter (being responsible, open communication, non-disclosure during the reporting, etc.), what the reporter can expect from the company (communication procedure, acknowledgement, possible reward, etc.)

Below I discuss two personal experiences where responsible disclosure was applicable.

Measuring Net-Neutrality

In a previous article I discussed why measuring netneutrality is hard. This is not really a security vulnerability, but the outcome of the measurement did have a public impact on the networks involved. So a responsible disclosure could have been in order. In this particular case I made the personal error of trusting journalism. Everyone will tell you not to, but I guess this is a lesson you only really learn by doing.

The person behind the Open Internet app first approached the media to publish their findings, in their eyes Simyo and KPN were blocking VOIP traffic. This lead to a publication on WebWereld, where KPN also denied the allegations. Then I came in and confirmed the findings of the Open Internet app. Believing that KPN was aware of the vulnerability, I contacted the journalist to publish the confirmation.

Fortunately I was able to repair the situation as this coincided with OHM2013. I contacted the KPN CISO team, and we did an ad-hoc responsible disclosure at the event. We worked out the problems with the measurement and the VOIP traffic, and I could present my findings just two days later, and we later jointly published on WebWereld.

Insecure Youfone Portal

Youfone is a virtual operator offering cheap mobile services using the KPN network. I found in October 2013 that their client portal did not use encryption when customers submit their login credentials. Even more frightening was that the password reset procedure did not use email confirmation, and would reset to the postal code and home address number. Digging deeper I also found that login credentials were stored in a session cookie, which meant that these were transmitted for every web request to the portal.

Unfortunately, Youfone did not (and still does not) have a contact for responsible disclosures. Going through their tech support was not successful. So I contacted the NCSC and received contact details of Youfone from them. I sent an email immediately explaining the seriousness. It took them two full days and lots of frustrating emails to finally get a phone call with the director. He finally agreed and promised a fix within a week. The password reset procedure was fixed soon after my phone call, and the encryption and session cookie took them about another week and a half. Interestingly, the creation date on the certificate states 22 July 2013, so they were already working on this for some time.

The whole procedure was incredibly frustrating. There was no acknowledgment, they did not keep me up to date on their progress and in the end also did not credit me with my finding. They only stated that they had “improved their website”. I was in the fortunate position of not having broken any laws, but otherwise the responsible disclosure procedure would have been even more stressful.

Conclusion

The NCSC has some good guidelines for creating responsible disclosure procedures. I just want to add that when you are designing a responsible disclosure, please think about the communication with the discloser. This person is coming to you with good intentions, so keep them updated on what you are doing. It is incredibly frustrating for them when they don’t feel they are taken seriously.

It is hard to write an indemnification clause in such a procedure, but something should be said about this. The discloser is taking a large risk reporting it directly, even if it is not entirely clear whether he broke the law. One of the first steps in your contact should be to agree on this, and this should be done in writing. Again, the discloser is doing the responsible thing in coming to you first, and that has to count for something.

Doing a responsible disclosure is an interesting experience. Even though gratitude is not always shown, it was an interesting experience nonetheless. It even got me a t-shirt.