Getting started with TumarOne:

1) The user must register in the system in order to start using the TumarOne BugBounty platform. When registering, the user needs to create an account as a researcher.
2) It is necessary to go through the onboarding process, where the system collects data about user's experience as a researcher, interests and time that the User is willing to devote to research on TumarOne information systems.
3) After successful registration, the User will receive instructions for using the platform, which will help the User fill in personal and contact data, as well as show how to send reports, monitor rewards and receive payments in case of successfully confirmed reports.
4) Before sending vulnerability reports, the User should carefully read the terms of use of the platform in the "Rules" section.

Vulnerability Disclosure Policy:

The program is limited to searching for technical vulnerabilities in the company's services. Vulnerabilities are flaws in the system, the use of which can intentionally violate its integrity, confidentiality, or cause malfunctioning.
• Not to disclose or disseminate information about the vulnerability found to the public or to third parties until it is fixed.
• If the User follows the established Bug Bounty rules, the Operator will not pursue or take any legal action related to the research.
• Interact only with own accounts or with the explicit permission of the account owner.

Private and Public Programs:

Private software is software that is not intended to be shared. This implies that the User can search for vulnerabilities in such programs only after receiving a special invitation to hack them. All reports on identified vulnerabilities in these programs remain confidential, and the User has no right to publicly discuss the vulnerabilities detected.
All programs start their journey as private, but as they become more proficient in processing reports, they can become publicly available to a wide audience if desired.
Public programs are programs that are available to all researchers on the platform. This means that all researchers on the platform, working with public programs is a great way to learn how to identify vulnerabilities and increase the user's reputation on the platform.

Personal account:

1. After successful registration, the user needs to enable the two-factor authentication function to protect the account and report on vulnerabilities found. To enable two-factor authentication, the User can go to the personal account and activate it after installing the application (detailed instructions appear when connecting two-factor authentication).
2. Then, the User can fill in the account with personal data, including: contact information, social networks and payment information for the successful implementation of payouts.

Vulnerability reporting:

1. In order to send a report on programs from TumarOne, the User needs to go to the “My reports” tab and click on the “Add report” button.
2. Next, the User can select a program from the list of available programs and click on the “Submit vulnerability” button. Before submitting any vulnerability, the user needs to read the description of the program, which includes a list of domains available for scanning, acceptable vulnerabilities, and scoring by vulnerability severity levels.
3. Types of vulnerabilities that are not paid for (low-level vulnerabilities that do not have critical consequences if exploited, including):
● IDOR (reports on this type of vulnerability are accepted only if the severity level is high; the severity level is determined by our specialist when the vulnerability is confirmed);
● Any type of XSS vulnerability other than Stored XSS (reports on the Stored XSS vulnerability are accepted depending on the significance of the web resource);
● Clickjacking;
● Insecure Redirect URI;
● Directory Listing Enabled (depending on the data being disclosed; reports on this vulnerability are accepted if critical data (passwords, backups, etc.) are detected);
● Sensitive data exposure (depending on the data being disclosed; reports on this vulnerability are accepted if critical data is detected);
● Enabled debug mode, which does not disclose critical data;
● CSRF vulnerabilities found in functionality that is not critical;
● Disclosure of the admin panel (If the bug hunter finds the admin panel, but is not able to take over the account or receive other critical information);
● User Enumeration without disclosure of critical data;
● Security Misconfiguration, if there is no evidence that the threat has materialized;
● Denial of service;
● Spam;
● Social engineering directed against employees, contractors, or customers;
● Any physical attempts to gain access to property or data centers
● Owner of the system;
● Report with automated tools and scans;
● Errors in third-party software;
● No security headers that don't directly lead to the vulnerability;
● SSL/TLS Trust Breach;
● Vulnerabilities that affect only users of outdated or non-proprietary browsers and platforms;
● Password and account recovery policies, such as expiration of the reset link or password complexity;
● An outdated DNS record that points to a system that does not belong to the owner of the system.
4. When submitting a report, the user needs to make sure that they have all the additional supporting files. Thanks to them, the moderation team can fully verify the correctness of the report, which will have a positive impact on the probability of rewarding the submitted vulnerability.
5. After the report is successfully submitted, the report status moves to "under review". In the next section, the User can get acquainted with the status of reports on the TumarOne platform.
6. Researchers have the option to retract the report in the "My Reports" section if incorrect data was entered when submitting the report or the vulnerability is not up-to-date. This feature is available only when the status of the report is “under review”, that is, when the report has not yet been reviewed by the security analysis team.

Report status:

1. The process from receipt of reports to payment of remuneration is not quick and the processing of requests is carried out up to 3 months. Since the Operator sends reports to system owners on a weekly basis, some system owners (in public programs) may not accept the submitted vulnerabilities, or vulnerability processing may take a long time. The platform's teams try to speed up the process of processing vulnerabilities, and upon successful acceptance of the report, the Operator immediately issues rewards, if any.
2. The reports generated by the User are sent to the bugbounty collection system, after which they are assigned the status “pending”.
3. In the next step, the reports are pre-analyzed and assigned to a specific security analyst. After that, the report is assigned the "sorted" status. This means that the report has been reviewed by a security analyst but has not yet been submitted by the system owner.
4. The security analyst, in turn, conducts full monitoring and assigns one of the following statuses to the report:
a. “Rejected by moderator”: If the security analyst does not find a vulnerability in the report, the report will be rejected;
b. “Need more information”: If there is not enough information to confirm the vulnerability, the security analyst sends a report to the User for revision and the report processing process is carried out again;
c. “Duplicate”: If the report contains vulnerabilities that were previously discovered by another user, the report will be considered duplicate. In this case, points and rewards are not awarded;
5. “Sent to Owner”: A security analyst confirms the existence of the vulnerability and sends it to the organization specialist. The specialist prepares an official letter with a vulnerability certificate (report) attached and sends it to the relevant organizations on whose information systems the vulnerabilities were detected.
6. Reports sent for confirmation to the owners of information systems (sites) may be accepted or rejected by a reasoned refusal. In case of rejection, the User will be provided with the answers received from the site owners. In case of acceptance of the report, the User may be allocated an award (for the rules for awarding reports, see the "Payments" section).
7. If the owner does not respond to the vulnerability report within 30 days after it is sent, the report goes to the “No response from the owner” status and the User will be awarded the corresponding points without paying a reward.
8. “Informative”: This status means that the vulnerabilities identified in the report are only a non-critical bug and the User can only be awarded the corresponding points without paying a reward.
9. For accepted reports, the owners of information systems can assign a certain amount of remuneration. In case of payment of remuneration, the report is assigned the final status “Paid”. “Paid” status is displayed in the “Payouts” section of the researcher's personal account, where the User can track their rewards for confirmed vulnerabilities (for more information on the rules for awarding reports, see the “Payouts” section).
10. If the owner of the system accepts, but does not assign a reward or after 2 months, no response will be received from the owner of the information systems, the report is assigned the status “Accepted”, the User is awarded the appropriate points and the report will be closed.
11. Private programs may request a re-check for the success of the vulnerability, in which case the report is assigned the “Retest” status. A request for retesting is sent to the researcher's personal account, which the User can accept, in which case he/she is awarded additional points.
12. After passing the re-check, the User can indicate in the response whether the vulnerability has been successfully patched by assigning the statuses “Fixed” and “Not fixed”. The status changes to “Fixed” if the User confirms that the vulnerability is serviceable, and to “Not fixed” if the User confirms that the vulnerability is in good working order, and the User has exactly 2 weeks from the appearance of the application, after the expiration of the period, the application for retesting will be automatically rejected.
13. After passing the retest, the report is assigned the status “Accepted” and then the report process goes through points 6, 9 and 10.

User Verification:

1. To increase the level of ethics of the research community, there is an account verification process. Since the reward process does not include the signing of other contracts, Users must go through a verification process.
2. The verification process includes the provision of an electronic version of the researcher's identity document. Also, providing a photo where the user's face with the document is clearly visible.
3. Upon successful uploading of the documents, the Operator confirms the identity of the user.
4. Upon successful verification of the user, the researcher will have access to the payout function in the personal account. This process will significantly speed up the process of rewarding researchers for vulnerabilities found, reducing the number of supporting contracts and other documents.
5. It is important to note that the platform's administrative team does not share your data with third parties.
6. The administrative team of the platform/Operator is not responsible for incorrectly provided data of researchers.

Payouts for confirmed vulnerabilities:

1. After the report has been assigned the “Accepted” status and a quantitative payment has been specified, the report is automatically transferred to the “Payouts” section, where it will be credited with remuneration. Important note: in order to receive a reward, the User needs to go through the verification process in his personal account. For more information, see the “User Verification” section. The Operator will contact the User personally to make payments and sign documents. Users, in turn, are required to familiarize themselves with the public offer and sign the EDS as a closing document.
2. The user can view the rewards for public and private programs by selecting the “Public Payments” or “Private Payments” section.
3. Each payout has 5 statuses:
a. The payout is assigned the status "Under consideration" when the payout is allocated to the User and waiting for confirmation of this payment by the Operator (the administrator of the platform).
b. The payout is assigned the “Signature Required” status when the reward has been confirmed and the user needs to accept the terms of the public contract by clicking on the “I agree with the terms of service” button in the lower right corner of the page.
c. After agreeing to the terms of service, the User must choose a payment method. Payment is made by bank card. Next, the User needs to specify the details and save the data. The Operator does not store or transfer the User's data to third parties, the payment system is only engaged in collecting details and sending rewards.
d. Next, the payout is assigned the “Processing” status, which means that the payout process is confirmed by the bank service.
e. Upon successful identity verification, agreement with the terms of service, confirmation of the payment method and acceptance of the reward, the payment status changes to “Paid” or “Rejected”.
f. In the case of the “Rejected” status, the status and the reason for the error are displayed in the user's personal account, in the “Notifications” section. Next, in order to eliminate the error, the user needs to change the details or payment method in the “Payment Information” section by going to “Personal Data”.
g. If the “Rejected” status is assigned due to an error on the service side, the Operator immediately proceeds to eliminate it and contacts the User. In any case, the user can contact technical support at info@tumar.one.
4. If agreeing to the terms, the User should carefully read their content and detailed instructions.
5. Researchers are provided with a Public Agreement for the provision of services for the provision of access to a web resource. This agreement is public, accordingly, the consent and acceptance of the terms is expressed through the form of the site (checkbox), by clicking it.

Additionally:

Guidelines:
● If a vulnerability is detected, it is necessary to inform the Operator about it as soon as possible so that the platform team can make every effort to quickly resolve this problem
● The user needs to be able to stop in time. For example, with SQLi, it is enough to output version() or similar information and stop, rather than dumping (dumping) the entire user base.
● The user must act reasonably and responsibly to avoid breaches of confidentiality, destruction of data, and interruption or deterioration of services.
● Do not use automatic scanning tools, this will definitely not add points to the User when reviewing the report.

Types of vulnerabilities by severity levels for public programs:

Vulnerability severity scores are awarded as follows:
1) For a low level of criticality - from 0 to 30 points;
2) For the average level of criticality - from 31 to 60 points;
3) For a high level of criticality - from 61 to 100 points.

Path Traversal -- 40-70 Medium/High
Directory Listing Enabled -- 10-40 Low/Medium
Insecure Redirect URI -- 5-10
Clickjacking -- 5
Brute Force -- 5
SQL Injection -- 50 - empty base, 70 - payload
XML External Entity Injection -- 50-70
Local File Inclusion -- 50
Remote Code Execution -- 50-100
Authentication Bypass -- 50-90
Account Takeover -- 50-90
Insecure Direct Object References -- 10-90
Stored XSS -- 20-30
Reflected XSS -- 10-20
Server-Side Request Forgery -- 40-60
Cross-Site Request Forgery -- 10-20
Race Condition -- 10-90
Server-Side Template Injection -- 20-80

1. High level of criticality:

Path Traversal (Directory Traversal)
SQL Injection
Remote Code Execution (RCE)
Local File Inclusion
Remote File Inclusion
Authentication Bypass
Account Takeover
Insecure Direct Object References (IDOR) XML External Entity Injection (XXE)

2. Medium level of criticality:

Directory Listing Enabled
Insecure Direct Object References (IDOR) Server-Side Request Forgery
Race Condition
Sensitive Data Exposure
Server-Side Template Injection
Stored XSS
XML External Entity Injection (XXE)

3. Low Criticality:

Cross-site Request Forgery
Sensitive Data Exposure Insecure
Redirect URI
Clickjacking
Brute Force
Reflected XSS
SMS flood
Open Redirect URI

It should be borne in mind that the severity level depends on what the identified vulnerability can lead to. Consequently, security analysts individually evaluate each vulnerability report. Also, it should be remembered that vulnerability assessments differ from one program to another, so before sending a report, the User should familiarize himself with the description of the program and follow their rules.