Vulnerability Reports & Disclosure

Bug Bounty / Hackerone

HackerOne is a service that allows us to interact with external parties (e.g. independent security researchers) to collect, manage and disclose vulnerabilities that are discovered by them. HackerOne is managed by the Security Team. All members of Rocket.Chat can request access if they want or should collaborate directly with the external party. Hackerone runs parallel to Jira, which is used for internal collaboration. (HackerOne reports are linked to Jira issues once the report moves to under triage phase).

Vulnerability Reports & Disclosure

We have an established Vulnerability Management program that handles all layers of our application and infrastructure by using 8 main data sources, including our HackerOne program, internal pentest, vendors pentest, and tooling that runs vulnerability assessment scans in our ecosystem.

Secondary channels are:

  • Reports or questions come in from customers through our Support Desk or other direct channel.

  • Issues opened on the public issue trackers. The Security Team can not review all new issues and relies on everyone in the company to identify and label issues as ~security and mention security team members issues.

  • Issues reported by automated security scanning tools

For reported vulnerabilities:

  • If the source is HackerOne you can create an Jira issue automatically when moving the report to Triage phase (select "Create new Jira issue")

    • If the vulnerability was reported via a public issue on Github, remove it and refer the reporter to our email adress or HackerOne. Still open a Jira task, in case the reporter does not respond.

  • An initial determination is done by the Security Team as to severity and impact. Never dismiss a security report outright. Instead, follow up with the reporter, asking clarifying questions.

  • Remember to prepare patches, blog posts, email templates, etc. on or in other non-public ways even if there is a reason to believe that the vulnerability is already out in the public domain (e.g. the original report was made in a public issue that was later made confidential).

For all reported vulnerabilities, regardless of source, reporters should expect a first-response time of up to 5 (five) business days.

Our current SLA to deal with vulnerabilities are:

  • Critical: 14 days

  • High: 30 days

  • Medium: 60 days

  • Low: Best effort unless risk accepted

More information about our Vulnerability Management process can be found here.

To prepare a Security Fix

Security Fixes are developed by the Security Team or the proper Development Teams.

For our development teams: A dedicated step-by-step guideline of the policy aspects relevant for you can be found.

Fixes must be made available as per our support policy.

Security Fixes must not contain keywords such as "exploit", "hack", or similar and should be phrased technology-neutral. We want to explain what has changed, not describe exploit techniques.

Security fixes should be developed and have their testing done on private forks of the appropriate Rocket.Chat versions that will receive the fix. That means these PRs should not show up in the public repositories.

CVE IDs

We use CVE IDs to uniquely identify and publicly define vulnerabilities in our products. Since we publicly disclose all security vulnerabilities 30 (thirty) days after a patch is released, CVE IDs must be obtained for each vulnerability to be fixed. The earlier obtained the better, and it should be requested either during or immediately after a fix is prepared.

The Security Team currently requests CVEs either through the HackerOne form (preferred) or directly through MITRE's webform.

Keep in mind that some of our security releases contain security related enhancements which may not have an associated CWE or vulnerability. These particular issues are not required to obtain a CVE. CVE IDs obtained via the webform must be manually referenced in the HackerOne issue and Jira ticket.

When a Fix is Ready

When a patch has been developed, tested, approved, and a new release is being prepared, the dev team updates the Jira task with a reference to the PR(s).

Security then informs the researcher via HackerOne. Post a comment on the HackerOne issue to all parties informing them that a patch is ready and will be included with the next release. Provide release dates, if available, but try not to promise a release on a specific date if you are unsure. You may also share relevant code snippets with the researcher for him to comment on or verify the fix.

This is also a good time to ask if the researcher would like public credit in our release blog post and on our vulnerability acknowledgements page for the finding. We will link their name or alias to their HackerOne profile, Twitter handle, Facebook profile, company website, or URL of their choosing. Also ask if they would like the HackerOne report to be made public after the responsible disclosure period counting from the release. It is always preferable to publicly disclose reports unless the researcher has an objection.

For critical security issues, prepare a message for Rocket.Cat to be sent out on release day.

On Release Day

On the day of the security release several things happen in order:

  1. All security patches are pushed to the public repository (unless they are not already in there).

  2. The new Rocket.Chat version is published.

  3. For critical security fixes, an additional Rocket.Cat message is sent to all registered workspaces.

  4. The update process of the hosted workspaces is started by the infrastructure team

  5. The public is notified via the Rocket.Chat blog release post.

  6. The security updates page and the White Hat Hall of Fame are updated with appropriate credits to the reporting researchers.

Once all of these things have happened notify the HackerOne researcher that the vulnerability and patch are now public. The Jira issue should be closed and the HackerOne report should be closed as "Resolved". Public disclosure should occur if the Hacker has requested it and the responsible disclosure period is started. Any sensitive information contained in the HackerOne report should be sanitized before disclosure.

After release day

Swag for Reports

We award swag on a case by case basis. Details are in our responsible disclosure policy on HackerOne. When a report is closed, ask the reporter if they would like a swag code for free Rocket.Chat clothing or accessories. Swag codes are available by request from the operations team.

Responsible disclosure period ended

After the responsible disclosure period has ended, HackerOne will automatically release the report. Upon notification of the report release, update the CVE entry via the webform if it had been requested via the webform. Otherwise HackerOne will automatically update the CVE entry.

Last updated