Responsible Disclosure
We have an established Vulnerability Management program that handles all layers of our application and infrastructure by using different data sources, including our bug bounty program, external and internal penetration tests, automated tooling, support channels, and so forth.
It is important that all security researchers who want to report vulnerabilities to Rocket.Chat follow this policy. By doing so, there’s a guarantee that security issues are being shared privately and will remain so until a fix is released.
If you have any suggestions or questions about this process, feel free to email us at security@rocket.chat.
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 , but all members of Rocket.Chat can request access if they want or should need to collaborate directly with the external party. Hackerone
HackerOne runs parallel to Jira, which is used for internal collaboration . (- however, HackerOne reports are must be 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")
as per our vulnerability management process.
GitHub Issues
If the vulnerability was reported via a public issue
...
, we may remove it and refer the reporter to our email
...
address or HackerOne.
...
We will still open a Jira
...
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.
...
issue and track it internally.
The deletion of the issue may happen because, depending on the severity of the vulnerability, attackers may use it to exploit Rocket.Chat servers in the wild until a fix is released.
Vulnerabilities SLA
For all reported vulnerabilities, regardless of source, reporters should expect a first-response time of up to 5 (five) business days.
...
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.
| Info |
|---|
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 webformCVEs will always be obtained for critical and high-severity vulnerabilities, while medium and low vulnerabilities will have their relevance evaluated before requesting a CVE.
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:
All security patches are pushed to the public repository (unless they are not already in there).
The new Rocket.Chat version is published.
For critical security fixes, an additional Rocket.Cat message is sent to all registered workspaces.
The update process of the hosted workspaces is started by the infrastructure team
The public is notified via the Rocket.Chat blog release post.
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
The Security Team currently requests CVEs either through the HackerOne form (preferred) or directly through MITRE's webform.