Celtra’s Vulnerability Disclosure Program

Status: Active

Valid until: 30.6.2030

Contact details: security@celtra.com

Security.txt: https://celtra.com/.well-known/security.txt

Celtra is committed to ensuring the security of its customers, employees, and their information. The Vulnerability Disclosure program is intended to provide security researchers with clear guidelines for conducting vulnerability discovery activities and to convey recommendations on submitting discovered vulnerabilities to us.

This page defines the following:

• what systems and types of research are covered under the Vulnerability Disclosure program;

• how to send us vulnerability reports;

• how long we ask security researchers to wait before publicly disclosing vulnerabilities;

• how we reward compliant disclosures.

This initiative is not a competition, but rather an experimental and discretionary rewards program. You should understand that we have the right to cancel the program at any time and the decision as to whether or not to pay a reward remains entirely at our discretion.

If you make a good faith effort to comply with the program rules during your security research, we will consider your research to be authorized. We will try to work with you to understand and resolve the issue quickly, and Celtra will not recommend or pursue any legal action related to your research.

Should legal action be initiated by a third- party against you for activities that were conducted in accordance with this program, we will make this authorization known.

By submitting reports or otherwise participating in the Vulnerability Disclosure program, you agree that you have read and will follow the below Rules of Engagement of this program.

1. Never use a finding to compromise/exfiltrate data or pivot to other systems. Use a proof of concept only to demonstrate an issue.

2. If sensitive information, such as personal information, credentials, etc., is accessed as part of a vulnerability, it must not be saved, stored, transferred, accessed, or otherwise processed after initial discovery. All copies of sensitive information must be returned to Celtra and may not be retained.

3. Researchers may not, and are not authorized to engage in any activity that would be disruptive, damaging or harmful to Celtra, its brands, customers, employees or its users. This among others includes: social engineering, phishing, physical security and denial of service attacks against users, employees, or Celtra and its affiliates as a whole.

4. Out of concern for the availability of our services to all users, please do not attempt to carry out DoS attacks, leverage black hat SEO techniques, spam people, or do other similarly questionable things. We also discourage the use of any vulnerability testing tools that automatically generate very significant volumes of traffic.

5. Your testing must not violate any law.

6. Researchers may not publicly disclose vulnerabilities (sharing any details whatsoever with anyone other than authorized Celtra employees), or otherwise share vulnerabilities with a third party, without Celtra’s express written permission before evaluation period ends (90 days).

7. Celtra will not give you any access to our systems to conduct white hat research.

Systems

Any system or service that handles sensitive data belonging to Celtra or Celtra clients is in the scope of the program. The vast majority of the sensitive content can be found on the following domains:

• *.celtra.com

• *.celtra.io

Examples:

• Main products:

  • https://hub.celtra.com and https://<client>.celtra.com

  • https://hub.celtra.io and https://<client>.celtra.io

• Support pages:

  • https://support.celtra.com

  • https://support.celtra.io

• Authentication Service:

  • http://auth.celtra.com

Additionally, Celtra stores sensitive data on third-party services such as Google Workspace, Atlassian Jira, GitHub, etc. Any flaws that can lead to sensitive data exposure or cause serious business interruption on systems not owned by Celtra that contain Celtra or Celtra customers' data, will also qualify (for example, Publicly shared employee calendars).

Types of vulnerabilities

In general, any design or implementation issue that substantially affects the confidentiality or integrity of user or customer data is in the program's scope.

Examples include:

• Cross-Site Scripting (XSS)

• Cross-Site Request Forgery (CSRF), except exclusions listed under out-of-scope section

• Authentication or Authorization Flaws (Broken Access Control)

• Sensitive Data Exposure

• Security Misconfiguration

• Server-Side Request Forgery (SSRF)

• Server-Side Template Injection (SSTI)

• SQL injection (SQLI)

• Remote Code Execution (RCE)

• Local or Remote File Inclusions

While the above list represents our primary focus for security research, we are interested in reports for all vulnerabilities that can lead to sensitive data disclosure or can cause serious business disruption.

Out-of-scope vulnerabilities & accepted risks

Approximately 90% of the submissions we receive through our vulnerability reporting program are ultimately deemed to have little or no practical significance to product security. The experience of reporting an issue and not qualifying for a reward can be disappointing to less experienced researchers – and the high volume of submissions makes it harder for us to spot valid, high-impact reports.

In the spirit of openness, we decided to publish examples of some of the most common non-qualifying report types, with a brief explanation of our reasoning behind not treating them as a security risk or otherwise not paying out rewards.

Invalid attack scenarios

• Any physical attack against the user's device, Celtra property or its data host providers;

• Social engineering of Celtra staff or contractors;

• Configuration issues on end-users' machines. (for example, password storage or cache settings);

• Attacks requiring a Man-in-the-Middle, with no other possible exploitation;

• Attacks affecting only the users of outdated browsers, plugins or OS.

• Non-maximal DNS configuration, such as email policy in SPF, DKIM, DMARC records, or non-use of DNSSEC.

• Issues involving weaker SSL/TLS cipher suites.

• Missing security flags in cookies, except for session cookies.

• Non-use of optional HTTP security headers without a demonstrable security impact.

• DDoS or other volumetric attacks requiring large traffic volumes.

Ability to discover platform users by email addresses

When you sign up for a Celtra account and create a profile, we display the email in multiple places and generally allow it to be discovered by others who already know your email address.

In this spirit, we do not treat reports of locations that allow you to discover email addresses, for example, login or commenting capabilities, as a security vulnerability.

Open redirectors

Open redirectors take you from a Celtra URL to another website chosen by whoever constructed the link. Some members of the security community argue that the redirectors aid phishing, because users may be inclined to trust the mouse hover tooltip on a link and then fail to examine the address bar once the navigation takes place.

Our take on this is that tooltips are not a reliable security indicator, and can be tampered with in many ways, so we generally hold that a small number of properly implemented redirectors offers fairly clear benefits and poses minimal practical risk.

Reflected file download

A so-called "Reflected File Download" (RFD) is a technique that allows the attacker to force the browser to initiate a file download from a given origin with partially-controlled content. That might be used to create a social engineering attack, in which users trust that the file is, for example, a legitimate software installer coming from a website users trust.

We understand this attack technique, but at the same time, believe it's not a very practical one. When deciding whether to execute a file, users rely on the context in which the file download was initiated, not on where the file was actually hosted. In some browsers, this information is not even displayed by default, and one can see it only on the Downloads page. RFD can be used to create a social engineering attack, but there are other, more practical ways to achieve the same.

CSV Excel formula injection

Occasionally, we get reports describing Excel formula injection into CSV files. Specifically, the reports mention that one of our products with an 'export to CSV' feature can be abused to inject Excel formulas into a generated file downloaded by the user. The attack scenario mentions that, under certain circumstances, those formulas could be executed by the application opening the CSV file (Microsoft Excel is commonly mentioned). The consequence is not just running arithmetic operations on a victim's machine (though we all like =1338-1), but may amount even to running arbitrary commands.

CSV files are just text files (the format is defined in RFC 4180), and evaluating formulas is a behavior of only a subset of the applications opening them - it's rather a side effect of the CSV format and not a vulnerability in our products which can export user-created CSVs. The application should mitigate this issue by importing/interpreting data from an external source, as, for example, Microsoft Excel does by showing a warning. In other words, the proper fix should be applied when opening the CSV files rather than when creating them.

In conclusion, we don't think the risk introduced by this behavior is significant enough to warrant a change in our product.

Lack of HTML sanitization where data is not intended to be rendered as HTML

Sometimes, we get reports that the API does not perform appropriate validation of user-supplied input, which is reflected back to the user. When such information is rendered as HTML content, it can be used to execute a cross-site scripting attack. In such cases, we take this as a severe security vulnerability that needs to be resolved as soon as possible. However, when input is rendered as a JSON or text file, it is not considered a security issue, because the browser will not execute any JavaScript.

Campaign preview is accessible if Campaign ID is known

This is an intentional design decision aimed at allowing easy sharing of preview links.

Auth service API keys visible

We received numerous reports claiming that visiting https://auth.celtra.com/api/keys will expose API keys for the Auth service. It's important to note that the exposure of API keys in certain scenarios is not necessarily a vulnerability in itself. API keys are sometimes required to be exposed or visible in specific contexts, depending on the design and usage of the API.

Mentioned endpoint returns the public key that is being used to verify the signatures of tokens that the service receives from the authorization server, and therefore, this is working as intended.

For example, Okta describes this practice here: https://developer.okta.com/docs/reference/api/oidc/#keys.

Logout CSRF

For better or worse, the design of HTTP cookies means that no single website can prevent its users from being logged out; consequently, application-specific ways of achieving this goal will likely not qualify.

Clickjacking

When evaluating reports of cross-site request forgery (CSRF) or clickjacking vulnerabilities, we always try to understand their impact when actually exploited. If a successful attack does not change the state of Celtra accounts in any way, or if the change is very inconsequential, the report will usually not qualify for a reward.

Similarly, cross-site request forgery for actions that do not require authentication, or can only be performed using other unpredictable values (passwords, secret invitation codes, etc.) are often also deemed to be non-issues.

Issues that result in Denial of Service (DoS)

We are aware that any issue resulting in Denial of Service is unpleasant and such scenarios should be prevented. However, any issue that could result in Denial of Service of Celtra webpages, servers at the network or application layer, or in any other system Celtra uses is unlikely to cause sensitive data disclosure. Therefore, reports addressing DoS will not qualify for a reward.

Commonly reported SSL/TLS vulnerabilities

Some reports mention that a server in the celtra.com domain supports weaker SSL/TLS cipher suites or even a deprecated TLS version.

The use of weaker cipher suites is often an accepted risk for backward compatibility, and such reports are not considered as qualifying for a reward. We do not believe the data encrypted using these older ciphers can be feasibly decrypted even by attackers with substantial resources. We welcome reports demonstrating the opposite.

We always carefully validate reports claiming the use of deprecated TLS versions.

SPF softfail (~all) policy

We take email security seriously and work to ensure nobody can impersonate @celtra.com or @celtra.io email addresses. Our goal is that all DMARC-compatible email services reject illegitimate spoofed emails or mark them as spam.

The softfail (~all) policy achieves this goal and is a deliberately chosen trade-off.

Issues related to software or protocols not under Celtra control

We are more than happy to be notified that any of the software, services or protocol we may use are vulnerable. However, we cannot reward you for anything not under our control.

Vulnerabilities found in systems offered by Celtra vendors where Celtra doesn’t have control, should additionally be reported directly to the vendor according to their disclosure policy (if any).

Issues without clearly identified security impact

Although we wanted to give you an overview of what kind of reports on vulnerabilities will most likely not qualify for a reward, we cannot list them all here. In general, any reported issue that cannot lead to sensitive data disclosure will probably be ruled out for any reward. Examples of such reports are usually issues identified by automated scanners, such as patches for security updates without known or practical exploits.

If you believe you’ve identified a security vulnerability on the Celtra platform and any of the associated tools used to provide you services on Celtra, please reach out to security@celtra.com providing the following:

1. Outline of the bug or description of the vulnerability,

2. Proof of exploitability that leads to sensitive data disclosure or modification (for example, a screenshot, or video).

When collaborating with us according to the program rules, you can expect us to:

• Work with you to understand and validate your report, including timely initial response to the submission;

• Remediate any proven and, from our side, confirmed in-scope vulnerabilities promptly;

• Recognize your contribution to improving our security if you are the first to report a unique vulnerability, and your report triggers a code or configuration change;

• Reward your contribution if eligible for a reward in a timely manner.

Celtra may reward responsible disclosure of vulnerabilities that can lead to sensitive data disclosure or cause significant business disruption. Contributors of identified and exploitable concerns verified by Celtra may be offered a reward at our discretion.

Eligibility for any monetary compensation is limited to the first person to report an unknown issue. We would usually offer a bounty based on the severity score. The severity final score is always determined by Celtra.

You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon your local law.

We would automatically decline any reward payouts if you are:

• A resident of, or make your Submission from, a country against which the United States has issued export sanctions or other trade restrictions (for example, Cuba, Iran, North Korea, Sudan and Syria);

• A person sanctioned by any country where Celtra and its subsidiaries have a registered business;

• Associated with a terrorist or criminal organization;

• Employed by Celtra or its subsidiaries (including former employees or contractors that conducted work for Celtra within the prior 12 months);

• An immediate family member of a person employed by Celtra Inc. or its subsidiaries or affiliates.

Other disqualifiers:

• Overwhelming our teams with messages;

• Use of hateful or threatening language when communicating with us;

• Reports on 0-day and other CVE vulnerabilities published for less than 60 days.