Bug bounty program

1. About Bug Bounty Program

The Bug Bounty program is focused on enhancing the security of Vivid Money's applications and services.
The Bug Bounty program is extended to external researchers who accept the terms and conditions of this program.
All requests from external researchers are considered on an individual order.
Rewards under the bug bounty program are only possible subject to the terms and conditions described in this program.
Vivid Money Company reserves the right not to respond to research requests, denied the right to remuneration, request additional information, as well as to change the rules and conditions of the program.

2. Privacy policy

Any interactions in the framework of the Bug Bounty program are possible only after the signing of an NDA (nondisclosure agreement) between Vivid Money and the researcher.
Without the written consent of Vivid Money, researchers are prohibited from disclosing discovered vulnerabilities, information about discovered vulnerabilities, and also shares any information about the work related to searching for vulnerabilities in Vivid Money applications and services.
Vivid Money reserves the right to decline requests for public disclosure of vulnerabilities found in Vivid Money applications and services.

3. Scope for researchers

Vivid Money is an ecosystem that consists of various applications and services, available through unified mobile application user interface and web resources.
The scope to find vulnerabilities are:
Any requests that do not fall into this scope will not be considered.

4. Restrictions

The Bug Bounty program is limited only to technical and logical vulnerabilities that may be contained in Vivid Money applications and services.
The program Bug Bounty does not address vulnerabilities that may apply to one of the following categories:
  • Spam.
  • Vulnerabilities that require social engineering/phishing.
  • Reports of phishing and other social engineering techniques.
  • DDOS attacks.
  • Hypothetical issues that do not have any practical impact.
  • Security vulnerabilities in third-party applications/libraries and on third-party websites integrated with Vivid Money.
  • Scanner output or scanner-generated reports.
  • Issues found through automated testing.
  • Publicly-released bugs in Internet software within 30 days of their disclosure.
  • Man-in-the-Middle attacks.
  • Host header injections without a specific, demonstrable impact.
  • Self-XSS without the ability to attack other users.
  • Login/logout CSRF.
  • CSRF and XSS without influencing sensitive data.
  • Bypass checking for root and jailbreak.
  • Messages about the possibility of mobile application reverse engineering.
  • Information about IP addresses, DNS records and open ports.
  • Disclosure of public information about users.
  • Clickjacking.
  • Messages about disadvantages of using SMS codes.
  • The ability to unlimited sending SMS and Email.
  • Reports of incorrect implementation of the rounding in the conversion transfers between the estimated, cumulative and brokerage accounts.
  • Lack of recommended security mechanisms without an additional attack vector (for example, HTTP security headers, cookie safety flags or CSRF protection).
  • Unsafe configured TLS or SSL without an attack vector.
  • Open Redirect without an additional attack vector (for example, token theft authorization).
  • Content Substitution on page.
  • Vulnerabilities that require the implementation of complex or improbable scenarios of user interaction.
  • Tabnabbing.
  • Full Path Disclosure.
  • Vulnerabilities, a necessary condition for the operation of which is the presence of malicious software, root rights or Jailbreak on the device.
  • Using outdated or potentially vulnerable software without an additional attack vector.
  • Disclosure of technical or insensitive information (for example, product versions or software used).
  • Cache-control related issues.
  • Lack of security flags in cookies.
  • UX/UI bugs and spelling mistakes.
  • Broken Link Hijacking.
  • Problems with the mobile application:
    • o No cashback is credited for the purchase.
    o Application functions are not available.
    o The mobile application crashes.

5. Rules and Conditionals

5.1 General rules

When searching for vulnerabilities in Vivid Money applications and services, should be to follow the rules:
  • For testing should use only your own accounts.
  • You are allowed to use the credentials of other users for testing, provided that they have explicitly agreed to provide the credentials.
  • Vivid Money does not issue additional accesses and accounts (including test accounts) for testing.
  • Any attempts to access other people's credentials of users of Vivid Money applications and services are prohibited.
  • When searching for vulnerabilities, it is prohibited to violate the integrity, availability and confidentiality conditions for Vivid Money applications and services.
  • Any activity that could damage the company's applications, infrastructure, customers and partners is prohibited.
    Note – examples of prohibited activities: social engineering, phishing, denial of service attacks, compromise
  • To confirm the presence of vulnerabilities should be used minimally adequate set of checks. Checks should not affect other users or application performance and service Vivid Money
    Note – if this condition is not met, investigation of vulnerabilities is strictly prohibited.

5.2 Priority order for requests

Requests related to similar vulnerabilities can be considered on a priority order:
  • Remote code execution (RCE).
  • Injections (for example, SQL-injections).
  • XXE.
  • LFR/LFI/RFI.
  • SSRF.
  • Memory leaks.
  • Business logic vulnerabilities.
  • IDOR.
  • Access control vulnerabilities.
  • Disclosure of sensitive information.
  • Account takeover.
  • Lack of Authentication / Authorization.
  • XSS and CSRF with impact on sensitive data.

5.3 RCE testing rules

During RCE testing, any actions on the server are prohibited except:
  • Execution of commands ifconfig (ipconfig), hostname, whoami.
  • Creation of an empty file in the directory of the current user.
All other actions must be coordinated with the Vivid Money security team.

5.4 SQL-injection testing rules

During testing SQL-injection, any actions on the server are prohibited except:
  • Get information about the current database, its version, the current user or hostname.
  • Get the database schema, list of tables in it, and column names in tables.
  • Execute math, conversion, or logical queries (including using SLEEP) without retrieving data (other than those listed above).
All other actions must be coordinated with the Vivid Money security team.

5.5 Rules for uploading and reading files

During testing of loading and reading files, it is prohibited to perform the following actions:
  • Read, change, modify, delete and replace any files on the server (including system files).
  • Downloading files that could cause a denial of service (for example, large files).
  • Downloading malicious files (for example, malware or spyware).

6. Determining the criticality of vulnerability

The severity level of the vulnerabilities found is determined by the Vivid Money security team.
After receiving the report from the researchers, the Vivid Money security team conducts its own checks and determines the severity level for the vulnerability found.
When determining the level of criticality, the following factors are also taken into account:
  • The level of privileges required to implement the attack.
  • Difficulty in detection and operation.
  • The presence of a requirement for interaction with the user.
  • Impact on the integrity, availability and confidentiality of the affected data.
  • Impact on business risks and reputational risks.
  • The number of users affected.

7. Requirements for the reporting

One report should describe one vulnerability. The exceptions are those cases when vulnerabilities are either linked or can be combined into a chain.
The vulnerability report should contain the following information:
  • Description of the vulnerability (score, impact, critical, etc.).
  • Аttack vector.
  • Steps of playback.
  • Analysis of criticality.
  • Recommendations for elimination.
  • Type of vulnerability.
  • Screenshots or video confirming the availability of vulnerability and demonstrating playback steps.
  • An example of a formatted query.
Failure to comply with the reporting requirements may lead to a decrease in the amount of remuneration.
If the report is not enough data to check for vulnerabilities, the payment of compensation is not carried out.

8. Time for consideration of the report

Each report is reviewed individually by the Vivid Money security team.
The duration of the report review depends on the degree of criticality for the vulnerability found and the workload of the team.
On average, each report is reviewed within TWO WEEKS.

9. Rewards

The reward is paid only for the discovery of previously unknown vulnerabilities.
Payment is carried out subject to all conditions, rules and restrictions of this program, in case of violation of which, the payment is not made.

10. Reward payment

The reward is paid only for the first received report on the vulnerability found.
Payment is made provided that the report contains all the information necessary to confirm the vulnerability.
Any subsequent reports covering the same vulnerability or containing similar attack vectors will be marked as duplicate.
The amount of the award paid is final and non-negotiable.
Payment is made on condition that the researcher sends all the information requested in Invoice. An invoice will be sent separately for filling.

11. Contacts

The information on the vulnerabilities found should be sent to [email protected].
The subject of e-mail should begin wirh a phrase [BugBountyReport]. An example [BugBountyReport] – SQL injection.