Начало работы с TumarOne:

1) Пользователь должен зарегистрироваться в системе для того, чтобы начать пользоваться BugBounty платформой TumarOne,. При регистрации, необходимо создать аккаунт в качестве исследователя.
2) Необходимо пройти через процесс onboarding-а, где система собирает данные о вашем опыте в качестве исследователя, интересы и время, которое Пользователь готов посвятить исследованиям информационных систем TumarOne.
3) После успешной регистрации Пользователя ожидает инструкция пользования платформой, которая поможет Пользователю заполнить личные и контактные данные, а также покажет, как отправлять отчеты, следить за вознаграждениями и получать выплаты в случае успешно подтвержденных отчетов.
4) Прежде чем отправлять отчеты по уязвимостям, Пользователь должен внимательно ознакомиться с правилами пользования платформы в разделе “Правила”.

Политика раскрытия информации об уязвимостях:

Программа ограничена поиском технических уязвимостей в сервисах компании. Уязвимости — недостатки в системе, использование которых может намеренно нарушить её целостность, конфиденциальность или вызвать неправильную работу.
• Не раскрывать и не распространять информацию о найденной уязвимости общественности или третьим лицам до ее исправления.
• Если Пользователь будет следовать установленным правилам Bug Bounty, Оператор не будет преследовать или предпринимать какие-либо юридические действия, связанные с исследованием.
• Взаимодействовать только с собственными аккаунтами или с явного разрешения владельца аккаунта.

Приватные и Публичные программы:

Приватные программы – это программы, не предназначенные для общего доступа. Это подразумевает, что Пользователь можете искать уязвимости в таких программах только после получения специального приглашения на их взлом. Все отчеты о выявленных уязвимостях в этих программах остаются конфиденциальными, и Пользователь не имеет права публично обсуждать обнаруженные уязвимости.Все программы начинают свой путь как частные, но по мере того, как они становятся более опытными в обработке отчетов, при желании, они могут перейти в открытый доступ для широкой аудитории.
Публичные программы – это программы, являющиеся доступными для всех исследователей платформы. Это означает, что все исследователи на платформе, работа с публичными программами – отличный способ научиться определять уязвимости и повысить свою репутацию на платформе.

Личный кабинет:

1. После успешной регистрации, требуется включить функцию двухфакторной авторизации для защиты аккаунта и отчетов по найденным уязвимостям. Для подключения двухфакторной аутентификации Пользователь может перейти в личный кабинет и активировать его после установки приложения (подробная инструкция появляется при подключении двухфакторной аутентификации).
2. Затем, Пользователь может заполнить аккаунт личными данными, в том числе: контактная информация, социальные сети и платежная информация для успешной реализации выплат.

Отправка отчетов по уязвимостям:

1. Для того, чтобы отправить отчет по программам от TumarOne, Пользователю нужно перейти во вкладку “Мои отчеты” и нажать на кнопку “Добавить отчет”.
2. Далее, Пользователь может выбрать программу из списка доступных программ и нажать на кнопку “Отправить уязвимость”. Прежде чем отправлять какую-либо уязвимость, требуется ознакомиться с описанием программы, которая включает список доступных для проверки доменов, допустимые уязвимости и выставление баллов по уровням критичности уязвимостей.
3. Виды уязвимостей, которые не оплачиваются (уязвимости низкого уровня, которые не имеют критических последствий в случае их эксплуатации, в том числе):
● IDOR (отчеты по данному типу уязвимости принимаются только в случае высокого уровня критичности; уровень критичности определяется нашим специалистом при подтверждении наличия уязвимости);
● Любые виды уязвимости XSS, помимо Stored XSS (отчеты по уязвимости Stored XSS принимаются в зависимости от значимости веб-ресурса);
● Clickjacking;
● Insecure Redirect URI;
● Directory Listing Enabled (в зависимости от раскрывающихся данных; отчеты по этой уязвимости принимаются, в случае обнаружения критичных данных (пароли, бекапы, и Sensitive data exposure (в зависимости от раскрывающихся данных; отчеты по этой уязвимости принимаются, в случае обнаружения критичных данных);
● Включенный debug mode, в котором не раскрываются критические данные;
● CSRF уязвимости, найденные в функционале, который не является критичным;
● Раскрытие панели админа (Если багхантер находит панель админа, однако не способен произвести захват аккаунта или получать иную критическую информацию);
● User Enumeration без раскрытия критичных данных;
● Security Misconfiguration, в случае отсутствия доказательств реализации угрозы;
● Отказ в обслуживании;
● Спам;
● Социальная инженерия, направленная против сотрудников, подрядчиков или клиентов;
● Любые физические попытки по получению доступа к собственности или центрам обработки данных
● Владельца системы;
● Отчет с помощью автоматизированных инструментов и сканирований;
● Ошибки в стороннем программном обеспечении;
● Отсутствие заголовков безопасности, которые не ведут напрямую к уязвимости;
● Нарушение доверия SSL / TLS;
● Уязвимости, влияющие только на пользователей устаревших или непатентованных браузеров и платформ;
● Политики восстановления пароля и учетной записи, такие как срок действия ссылки для сброса или сложность пароля;
● Устаревшая запись DNS, указывающая на систему, которая не принадлежит владельцу системы.
4. При отправке отчета, требуется убедиться в наличии всех дополнительных подтверждающих файлов. Благодаря ним, команда модераторов может полностью убедиться в корректности отчета, что благополучно скажется на вероятности награждения за отправленную уязвимость.
5. После успешной отправке отчета, отчет переходит на статус “на рассмотрении. В следующем разделе Пользователь может ознакомиться со статусами отчетов на платформе TumarOne.
6. У исследователей есть возможность отозвать отчет в разделе "Мои отчеты" если при отправке отчета были введены некорректные данные или уязвимость не является актуальной. Данная функция доступна только когда статус отчета стоит "на рассмотрении", то есть, когда отчет еще не был проверен командой аналитиков безопасности.

Статусы отчетов:

1. Процесс с поступления отчетов до выплаты вознаграждения является не скорым и обработка запросов осуществляется до 3-х месяцев. Так как Оперататор отправляет отчеты владельцам систем еженедельно, некоторые владельцы систем (в публичных программах) могут не принимать отправленные уязвимости или же обработка уязвимостей может занимать долгое время. Команды платформы старается ускорить процесс обработки уязвимостей, и при успешном принятии отчета, Оператор незамедлительно выставляем вознаграждения при их наличии.
2. Составленные Пользователем отчеты поступают в систему сбора bugbounty, после чего им присваивается статус «на рассмотрении».
3. Следующим этапом отчеты проходят предварительный анализ и назначаются определенному аналитику безопасности. После чего отчету присваивается статус «отсортирован». Это означает, что отчет был проверен аналитиком безопасности, но еще не отправлен владельцем системы.
4. Аналитик безопасности в свою очередь проводит полный мониторинг и присваивает отчету один из следующих статусов:
a. «Отклонен модератором»: В случае если аналитик безопасности не обнаружит в вашем отчете уязвимость, отчет будет отклонен;
b. «Нужно больше информации»: В случае недостаточности информации для подтверждения уязвимости, аналитик безопасности отправляет Пользователю отчет на доработку и процесс обработки отчета осуществляется заново;
c. «Дубликат»: Если в отчете указаны уязвимости, которые ранее были обнаружены другим пользователем, отчет будет считаться дублированным. В таком случае очки и вознаграждение не начисляются;
5. «Отправлено владельцу»: Аналитик безопасности подтверждает наличие уязвимости и отправляет специалисту по работе с организациями. Специалист подготавливает официальное письмо с приложением справки об уязвимостях (отчета) и направляет в соответствующие организации, на информационных системах которых были обнаружены уязвимости.
6. Отчеты, отправленные на подтверждение владельцам информационных систем (сайтов) могут быть приняты или отклонены мотивированным отказом. В случае отклонения, Пользователю будут предоставлены ответы, полученные от владельцев сайтов. В случае принятия отчета, Пользователю может быть выделено награждение (по правилам награждения отчетов ознакомьтесь с разделом “Выплаты”).
7. Если владелец не ответит на отчет по уязвимости в течении 30 дней после ее отправки, отчет уходит в статус “Нет ответа от владельца” и Пользователю будут начислены соответствующие баллы без выплаты вознаграждения.
8. «Информативный»: Данный статус означает, что уязвимости, указанные в вашем отчете, являются лишь не критичной ошибкой и Пользователю могут начисляться только соответствующие баллы без выплаты вознаграждения.
9. За принятые отчеты владельцы информационных систем могут назначить определенную сумму вознаграждения. В случае, произведения выплаты вознаграждения, отчету присваивается конечный статус «Оплачен». Статус «Оплачен» отображается в разделе «Выплаты» в личном кабинете исследователя, где Пользователь может проследить свои вознаграждения за подтвержденные уязвимости (по правилам награждения отчетов подробнее в разделе “Выплаты”).
10. Если владелец системы принимает, однако не назначает вознаграждение или по прошествии 2-х месяцев, ответ от владельца информационных систем не будет получен, отчету присваивается статус «Принят», Пользователю начисляются соответствующие очки и отчет будет закрыт.
11. Приватные программы могут запросить повторную проверку на успешность устранения уязвимости, в таком случае, отчету присваивается статус «Повторная проверка». В личный кабинет исследователя приходит заявка на повторное тестирование, которое Пользователь может принять, в случае чего ему/ей начисляются дополнительные очки.
12. После прохождения повторной проверки Пользователь может указать в ответе была ли успешно исправлена уязвимость, присвоив статусы «Исправлено» и «Не исправлено». Статус меняется на «Исправлено» если Пользователь подтверждает исправность уязвимости, и на «Не исправлено» в обратном случае. На принятие повторного тестирования со стороны Пользователя есть ровно 2 недели с появление заявки, после истечения срока заявка на повторное тестирование будет автоматически отклонена.
13. После прохождения повторного тестирования, отчету присваивается статус «Принят» и далее процесс отчета проходит пункты 6, 9 и 10.

Верификация пользователей:

1. Для повышения уровня этичности сообщества исследователей существует процесс верификации аккаунта. Так как процесс вознаграждения не включает в себя подписание других договоров, Пользователи должны пройти процесс верификации.
2. Процесс верификации включает в себя предоставление электронной версии документа, удостоверяющего личность исследователя. Также, предоставление фотографии, где отчетливо видно ваше лицо с документом.
3. После успешной загрузки документов Оператор подтверждает личность пользователя.
4. При успешной верификации пользователя, исследователю будет доступна функция выплат в личном кабинете. Данный процесс значительно ускорит процесс награждения исследователей за найденные уязвимости, позволяя сократить количество подтверждающих договоров и прочих документов.
5. Важно отметить, что административная команда платформы не передает ваши данные третьим лицам.
6. Административная команда платформы/Оператор не несет ответственность за некорректно предоставленные данные исследователей.

Выплаты за подтвержденные уязвимости:

1. После того как отчету был присвоен статус «Принят» и была указана количественная выплата, отчет автоматически переходит в раздел “Выплаты”, где ему будет начислено вознаграждение. Важное примечание: для того, чтобы получить вознаграждение, Пользователю нужно пройти процесс верификации в личном кабинете. Подробнее в разделе "Верификация пользователей". Оператор свяжется с Пользователем лично для осуществления выплаты и подписания документов. Пользователи, в свою очередь, обязаны ознакомиться с публичной офертой и подписать АВР в качестве закрывающего документа.
2. Пользователь можете посмотреть вознаграждения по публичным и приватным программам, выбрав раздел “Публичные выплаты” или “Приватные выплаты”.
3. У каждой выплаты есть 5 статусов:
a. Выплате присваивается статус "На рассмотрении" при выделении вознаграждения Пользователю и ожидания подтверждения данной выплаты Оператором (администратором платформы).
b. Выплате присваивается статус “Требуется согласие” когда вознаграждение было подтверждено и вам нужно принять условия публичного договора путем нажатия на кнопку “Я согласен(-на) с условиями предоставления сервиса” в нижнем правом углу страницы.
c. После согласия с условиями предоставления сервиса, Пользователю необходимо выбрать метод оплаты. Выплата осуществляется с помощью банковской карты. Далее, Пользователю нужно указать реквизиты и сохранить данные. Оператор не хранит и не передает данные Пользователя третьим лицам, система выплат является занимается лишь сбором реквизитов и отправкой вознаграждений.
d. Далее, выплате присваивается статус “В обработке”, означающий что процесс выплаты проходит подтверждение со стороны команды сервиса обслуживающего банка.
e. При успешной верификации личности, согласия с условиями предоставления сервиса, подтверждения метода оплаты и принятия вознаграждения, статус выплаты меняется на “Оплачено” или “Отклонено”.
f. В случае статуса “Отклонено” статус, и причина ошибки отображается в личном кабинете, в разделе “Уведомления”. Далее, для того чтобы устранить ошибку, необходимо поменять реквизиты или метод оплаты в разделе “Платежная информация”, перейдя в “Личные данные”.
g. Если статус “Отклонено” присваивается из-за ошибки на стороне сервиса, Оператор незамедлительно приступает к ее устранению и связывается с Пользователем. В любом случае, пользователь может обратиться в техническую поддержку по электронному адресу info@tumar.one.
4. При согласии с условиями, Пользователю следует внимательно ознакомиться с их содержанием и подробной инструкцией.
5. Исследователям предоставляется Публичный договор об оказании услуг по предоставлению доступа к веб-ресурсу. Данный договор является публичным, соответственно согласие и акцепт условий выражается через форму сайта (checkbox), путем его нажатия.

Дополнительно:

Методические рекомендации:
● При обнаружении уязвимости, требуется сообщить Оператору об этом как можно скорее, чтобы команда платформы могла приложить все усилия для быстрого решения этой проблемы
● Нужно уметь вовремя остановиться. К примеру при SQLi достаточно вывести version() или подобную информацию и остановиться, а не дампить (сбрасывать) всю базу пользователей.
● Нужно действовать разумно и с ответственностью, чтобы избежать нарушений конфиденциальности, уничтожения данных, а также прерывания или ухудшения работы сервисов.
● Не использовать инструменты автоматического сканирования, это однозначно не прибавит Пользователю очков при рассмотрении отчёта.

Виды уязвимостей по уровням критичности для публичных программ:

Баллы по уровням критичности уязвимостей присуждаются следующим образом:
1) За низкий уровень критичности - от 0 до 30 баллов;
2) За средний уровень критичности - от 31 до 60 баллов;
3) За высокий уровень критичности - от 61 до 100 баллов.

Path Traversal -- 40-70 средне/высокая
Directory Listing Enabled -- 10-40 низкая/средняя
Insecure Redirect URI -- 5-10
Clickjacking -- 5
Brute Force -- 5
SQL Injection -- 50 - пустая база, 70 - полезная база
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. Высокий уровень критичности:

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. Средний уровень критичности:

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. Низкий уровень критичности:

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

Нужно учитывать, что уровень критичности зависит от того, к чему может привести выявленная уязвимость. Следовательно, аналитики безопасности индивидуально оценивают каждый отчет о выявленных уязвимостях. Также, следует помнить, что оценки уязвимостей отличаются у разных программ, поэтому прежде, чем отправлять отчет, Пользователь должен ознакомиться с описанием программы и следовать их правилам.