OX App Suite

Company

Open-Xchange is a leading provider of communication, security and productivity platforms. We are committed to a borderless Internet that is open, safe and free, allowing users to protect their own data and privacy. To achieve this goal, we build open-source software, which is the sole scope of this bounty program. OX App Suite is our SaaS-based web service to collaborate and manage business information.

Since our APIs and source code are both publicly documented and exposed, we rely on strong authentication, crypto implementations and do not support the concept of security by obscurity. At the same time, we're delivering our software in a way that it comes with secure defaults. For this program, we offer access to a hosted sandbox and also invite you to install our software on your premises for research, contribution and usage.

We also run bug-bounty programs for our other products:

• PowerDNS
• Dovecot

Program Rules

• We believe that no technology is perfect and that working with skilled security researchers is crucial in identifying weaknesses in our technology.
• If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.
• Any type of denial of service attacks is strictly forbidden, as well as any interference with our infrastructure.
• We are providing you access to a sandbox environment to make research easier. This has some security controls disabled (2FA, CSP...) to make it easy to validate findings. Those are intentional and don't qualify for bounty.
• The sandbox environment will re-set itself once a week. Do not store valuable information there.
• You can set up a lab environment for your own research based on public software packages, containers and source-code. However, we will not accept reports which are specific to your lab's configuration and cannot be reproduced on our deployments.

Moreover you must avoid:

• Tests that could cause degradation or interruption of our service (refrain from using automated tools, and limit yourself about requests per second).
• Editing our public wiki on GitHub.
• Uploading, sending or injecting malware to Open-Xchange and contractors
• Using data acquired by compromising customer or employee accounts

Vulnerabilities which have already been reported to us (including reports received outside YesWeHack, for example from -customers or penetration tests) are considered as "Duplicate" in case they describe a similar attack type, regardless of which component is affected.

The triage team will use the "One Fix One Reward" process: if two or more endpoints use the same code base and a single fix can be deployed to fix all the others weaknesses, only one endpoint will be considered as eligible for a reward and other reports will be closed as Informative. We reward based on vulnerability, not per endpoint.

Eligibility and Responsible Disclosure

We are happy to thank everyone who submits valid reports which help us improve the security of App Suite, however, only those that meet the following eligibility requirements may receive a monetary reward.

• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability (see below)
• Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through yeswehack.com
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots as necessary. PoC exploit code is highly appreciated.
• You must not leak, manipulate, or destroy any user data.
• You must not be a former or current employee of Open-Xchange or one of its contractors.
• Reports about vulnerabilities are examined by our security analysts.
• Our analysis is always based on worst-case exploitation of the vulnerability, as is the reward we pay.
• When reviewing source-code, the "main" or "master" branches represent the current versions that are available as packages and on the sandbox environments. Only reports for those branches will be eligible for bounty, if there is a master and main branch, the main branch takes precedence.
• For packages the last two released minor versions are eligible for bounty.

Reports of leaks and exposed credentials

In the context of this program, we do not intend to encourage, accept or reward reports of leaks that are not applicable to our program scope and identified outside of our program scope, such as:

• Exposed credentials in/from an out-of-scope asset/source
• Sensitive information exposed in/from an out-of-scope asset/source
• Credentials provided on purpose, for example access to a Sandbox installation

Also, in order not to encourage dark and grey economies, in particular the purchase, resale and trade of identifiers or stolen information, as well as all types of dangerous behavior (e.g. social engineering, ...), we will not accept or reward any report based on information whose source is not the result of failure on the part of our organization or one of our employees.

This excludes, but is not limited to:

• Stolen credentials gathered from unidentified sources
• Exposed credentials that are not applicable on the program scope
• Exposed GitHub/GitLab (or similar) instance with no direct relation with our program scope
• Exposed secrets (e.g. API tokens/keys or other technical credentials) that are not directly related to the program scope
• Exposed PII on an out-of-scope asset

	Source of leak is in-scope	Source of leak belongs to Open-Xchange but is out-of-scope	Source of leak does not belong to Open-Xchange and is out-of-scope
Impact is in-scope (e.g. valid credentials on an in-scope asset)	Eligible	Eligible	Not Eligible
Impact is out-of-scope (e.g. valid credentials for an out-of-scope asset)	Eligible	Not Eligible	Not Eligible

Important precautions and limitations

As a complement to the program rules and testing policy :

• DO NOT alter compromised accounts by creating, deleting or modifying any data
• DO NOT use compromised accounts to search for post-auth vulnerabilities (they will not be eligible anyway)
• DO NOT include Personally Identifiable Information (PII) in your report and please REDACT/OBFUSCATE the PII that is part of your PoC (screenshot, server response, JSON file, etc.) as much as possible.
• In case of exposed credentials or secrets, limit yourself to verifying the credentials validity
• In case of sensitivie information leak, DO NOT extract/copy every document or data that is exposed and limit yourself to describe and list what is exposed.

Sandbox installation

We're offering a hosted sandbox environment for you to execute research using shared accounts. Please note that other researchers may access and use your data on a shared account. The environment will reset each Sunday at 06:00 UTC, so please make sure to keep backups of your research.

Mail delivery on this environment is inbound and local-only, which means you cannot send mail to external addresses. However, you can send E-Mail to the accounts, between the accounts as well as using IMAP and SMTP to connect to the mailbox using the same host and credentials as used for web access. Furthermore no anti-virus or anti-spam solution is being used to ease research.

You can obtain user-level access to the sandbox installation using credentials from the list below.

Account semantics

Access is controlled through user-accounts, like "user.one@sandbox-1.open-xchange.com". Besides the obvious representation as an E-Mail Address, this format has semantics which are valuable to know for your research.

The @ is a user and "context" (tenant) delimiter, where the first part represents the user account and the second part defines the context. All users within the same context can "see" each other within the application, but are separated from other contexts. As an example, "​user.one@sandbox-1.open-xchange.com​" and "​user.one@sandbox-2.open-xchange.com​" are two fully separated user accounts, while "​user.one@sandbox-1.open-xchange.com​" and "​user.two@sandbox-1.open-xchange.com​" can work together within the same context and are supposed to access shared data.

Non-web access

Using UA identifier tokens of popular CalDAV/CardDAV/WebDAV clients (e.g. "Lightning" or "DataAccess") will internally redirect requests at ​https://sandbox.open-xchange.com/​ to our DAV servlet rather than providing access to the web interface. For research, you can use ​https://sandbox.open-xchange.com/servlet/dav​ directly. Using https://sandbox.open-xchange.com/servlet/webdav.infostore​ grants access to WebDAV based file access to "Drive".

Software packages

You can use on-premise installations of our software free of charge and have a look at its inner workings. We expect that you're using up-to-date versions of our software and related services, hardened configurations as well as a set of strong credentials.

Learn more from overviews and guides at ​https://oxpedia.org/ and find an installation script at https://gitlab.open-xchange.com/qa/ox-installer. Technical documentation is provided at https://documentation.open-xchange.com/​.

Source-code

Source-code can be cloned via Git from our public GitLab repositories:

• https://gitlab.open-xchange.com/oss/appsuite

Mind that each component has various integration points, APIs and subcomponents that are in scope. Mind that not all repositories are in scope for this program (See: "Out-Of-Scope"). Please refer to our documentation to learn more.

Rating and Disclosure

We use CWE, CVE, CVSS to rate and categorize vulnerabilities. Any vulnerability will be publicly disclosed after sufficient time has passed for operators to deploy updates. Advisories use CSAF and will be published on our update sites, mailing-lists and external mailing-lists like fulldisclosure. Please understand that we handle the full disclosure process and expect that you do not disclose any findings yourself, we will include researcher credits if requested.