Vulnerabilities are everywhere

Security researchers and vendors must work together closely to raise the security level of everyday technology. Based on a decade of hacking research at SRLabs, this post looks at best practices in vulnerability disclosure – both for the researcher and the vendor.

Security researchers find vulnerabilities all over the place. The Common Vulnerabilities and Exposures (CVE) database lists more than 150,000 security issues. With the Internet of Things, cybersecurity is no longer only about protecting data, networks, and systems, but also about stopping the exploitation of vulnerabilities that affect cars, power plants, medical devices, and other technologies. Here at SRLabs, we have found vulnerabilities in a number of technologies, including SIM cards, the Ethereum Blockchain, and Alexa & Google Home.

But sharing these research results with the affected organizations can be tricky — the disclosure of vulnerabilities is a complex process with different stakeholders. It also lacks a clear legal framework. Nevertheless, it is worth the challenge in striving towards making the Internet a safer place and technical infrastructure secure and reliable.

Private disclosure, full disclosure, responsible disclosure

Security researchers face a choice when it comes to dealing with a vulnerability they found. There are three types of disclosures:

• Private disclosure
  The vulnerability is only reported to the affected organization. The organization decides if and when the public is informed. As a result, some vulnerabilities will never be known to the public. This is often the case with bugs in private networks, and the majority of bug bounty programs work this way. Here, an agreement is struck between a security researcher and a company in which the bug details are exchanged for recognition and sometimes compensation.

• Full disclosure
  The finder has not been in contact with the vendor prior to publishing a vulnerability. The consequence is that there are no patches available yet. Often, the vulnerability is exploitable and users can be affected negatively. Regardless, full disclosure can sometimes be the last resort to encourage organizations to fix a vulnerability if they are unresponsive or delaying the fix unreasonably.

• Responsible disclosure (also known as Coordinated Vulnerability Disclosure, CVD)
  The finder of a new vulnerability engages with the vendor in order to verify the problem, make them fix or patch the issue and work out a date at which the vulnerability will be disclosed to the public.

Responsible disclosure is usually the best way to balance the interests of the finder, the vendor, and the users — but it can be challenging. In trying to make the world a more secure place, you need to be willing to keep trying – sometimes for months.

Responsible disclosure 101

The stakeholders involved in a successful coordinated vulnerability disclosure are:

• The researcher of a vulnerability (often also the reporter) who notifies the vendor.
• The vendor, who maintains (and often created) the product in question, and who is in charge of fixing the problem — for example by distributing patches.
• Sometimes also a coordinator, e.g. a bug bounty platform, who manages the disclosure process.

Clear communication and management of expectations are key for a successful CVD. Usually, a CVD has six phases which require the different actors to work together:

1. Discovery of the vulnerability by the researcher
2. Vulnerability report from the researcher to the vendor
3. Validation and triage by the vendor (with additional information from the researcher if needed)
4. Remediation plan to fix the vulnerability (development and testing of a fix, possibly supported by the researcher)
5. Deployment of the patch to affected systems
6. Public awareness of the vulnerability to motivate users to install the patches

For more details on CVDs, see The CERT Guide to Coordinated Vulnerability Disclosure.

Approximate timelines:

• Hosted web application → ~2 weeks
• Enterprise software → 1–2 months
• Firmware → up to 3 months

What you should do if you found a vulnerability…

…while researching:

• Make sure that your testing is legal (as far as possible given unclear frameworks in some jurisdictions)
• Do not change any data, the system itself, or create backdoors
• Protect private information
• Check that the vulnerability has not already been found (e.g. via CVE)
• Determine the organization responsible for issuing a CVE ID and request one

…when getting in touch with the affected company:

• Try your best to inform them (use LinkedIn, Twitter, etc. if contact details are unclear)
• Provide a clear and detailed report (product, tools used, test configuration)
• Propose a timeline to set clear expectations
• Answer questions and help them triangulate the problem
• Do not ask for money — could be interpreted as blackmail

…throughout the CVD:

• Know your limits: fixing the bug is the vendor’s job
• If communication breaks down, involve an independent coordinator
• Avoid information leaks (wrong CC, oversharing at conferences)
• Share information (research methods, CVE-ID) with the community after patch deployment

…when the company does not respond or fix the vulnerability:

• Be patient, but stick to your proposed timeline
• Involve a coordinator as a mediator
• Submit the vulnerability report to the national CERT
• Publish a Proof of Concept (PoC) to drive change (respect embargoes where applicable)
• Consider full disclosure only as a last resort — without publishing exploit code

What you should do if you have a product and want to encourage CVD:

• Provide clear contact information for reporting security issues (with encryption, e.g., PGP key)
• Publish a CVD statement with clear process and timelines
• Develop resources to respond and patch promptly
• Maintain open and respectful communication with researchers
• Do not sue researchers — they are helping you
• Offer rewards/credits; consider a bug bounty program
• After addressing the vulnerability, publish the details
• Remember: disclosure does not make you look bad — it shows you care about user safety
• Work with a cybersecurity company to proactively scan and fix vulnerabilities

Research and responsible disclosure at SRLabs

The team at SRLabs is dedicated to hacking research because we want to make the Internet more secure. Instead of finding individual programming bugs, SRLabs explores structural security issues to gain a deeper understanding of how classes of bugs work.

Through analyzing technologies and protocols, we learn how systems are (mis)designed. This is why researching SIM cards was so interesting: in order to fix the security risk, they had to be redesigned using state-of-the-art cryptography, and in-network SMS filtering had to be implemented in mobile networks.

Investing in good relationships with vendors proved helpful in successful CVD. Nevertheless, we also had to do one full disclosure once, when a company threatened to sue us instead of fixing the vulnerability.

To enable other researchers to dive deeper, it is important to deliver detailed descriptions of research processes and discovered issues through responsible disclosure. Including the perspective of affected companies encourages constructive discourse. Follow-ups on our research can also drive technology evolution (e.g. in the Android ecosystem).

The SRLabs team is currently researching 5G network technology and conducting a census of Internet vulnerabilities.

If either of these sound interesting to you, get in touch — we are looking for motivated researchers to join us on this journey.