Копилка

«Копилка» — файловое хранилище без доступа третьих лиц и стороннего контроля.

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

Кибериспытание

Jet Infosystems (NTEs)

Jet Infosystems (Company) is a system integrator and one of the top ten largest tech companies and the top five IT service providers in Russia. We implement unique solutions that we test ourselves. We take on complex projects that others consider impossible: building a data center in permafrost, launching a virtual mobile operator from scratch in six months, or building an IT and clearing infrastructure for a new national payment system in just a few months.

Инфосистемы Джет - системный интегратор, который входит в десятку крупнейших ИТ-компаний России и в ТОП-5 поставщиков ИТ-услуг. Мы первыми внедряем уникальные решения, которые испытали на себе. Реализуем сложные комплексные проекты, которые другим кажутся невозможными: можем построить ЦОД в вечной мерзлоте, запустить с нуля виртуального оператора связи за полгода или за несколько месяцев построить ИТ-инфраструктуру и систему клиринга для новой национальной платежной системы.

Инфосистемы Джет

# Программа Bug Bounty продукта PT NGFW
Программа Bug Bounty продукта PT NGFW направлена на выявление и подтверждение уязвимостей, которые могут привести к компрометации сетевой защиты, обходу политик безопасности и механизмов инспекции трафика, получению несанкционированного административного доступа к NGFW и системе управления, а также использованию компонентов продукта в качестве точки входа для атак на инфраструктуру заказчика.

PT NGFW — это межсетевой экран нового поколения, обеспечивающий глубокую инспекцию трафика, контроль приложений и пользовательской активности, интеграцию с системами управления идентификацией (Microsoft Active Directory), а также высокопроизводительную систему предотвращения вторжений (IPS), встроенную в конвейер обработки трафика. Уязвимости в продукте могут приводить к полному обходу сетевой защиты, нарушению сегментации, компрометации учетных данных и снижению уровня защищённости всей корпоративной сети.

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

### Веб-интерфейс, CLI NGFW и система управления
* Обход аутентификации в web-консоли системы управления, приводящий к получению административного доступа.
* Обход аутентификации в CLI системы управления, позволяющий выполнить административные команды без надлежащей авторизации.
* Обход аутентификации в CLI NGFW, приводящий к получению полного контроля над устройством.
* Кража сессии администратора и выполнение произвольных действий в UI (Reflected XSS).
* Персистентный контроль над интерфейсом управления с возможностью внедрения бэкдоров (Stored XSS).
* Использование интерфейсов NGFW и системы управления как промежуточного узла для атак на внутренние компоненты, сервисы и внешние интеграции (LDAP, SSO и др.).
* Несанкционированное чтение или изменение логов, конфигураций и пользовательских данных, влияющее на корректность аудита и политик безопасности.
* Удалённое выполнение кода (RCE) через web-интерфейс или API управления.
* Небезопасная десериализация в API конфигурации, приводящая к выполнению произвольного кода или нарушению целостности настроек.
* SQL-инъекции в системе логирования, позволяющие получить доступ к данным или нарушить работу механизмов аудита.
* Получение прав root в Linux-системе NGFW или системе управления, приводящее к полной компрометации устройства и сетевой защиты.темой для расшифрования SSL/TLS-трафика между пользователями и хранилищами, позволяющая реализовать атаку типа Man-in-the-Middle и получить доступ к передаваемым данным.

**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 100 000 - 300 000 р. |
|Средний | 50 000 - 100 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

PT NGFW

Программа Bug Bounty продукта PT NGFW

Positive Technologies — ведущий разработчик решений для кибербезопасности. Наши технологии и сервисы используют более 2300 организаций по всему миру, в том числе 80% компаний из рейтинга «Эксперт-400». Уже 20 лет наша основная задача — предотвращать хакерские атаки до того, как они причинят неприемлемый ущерб бизнесу и целым отраслям экономики. Positive Technologies — первая и единственная компания из сферы кибербезопасности на Московской бирже (MOEX: POSI).

Positive Technologies

# Программа Bug Bounty продукта PT Container Security
Программа Bug Bounty продукта PT Container Security направлена на выявление и подтверждение уязвимостей, которые могут привести к компрометации контейнерной и оркестраторной инфраструктуры, обходу механизмов защиты на этапах сборки, развёртывания и исполнения контейнеров, нарушению процессов DevSecOps, а также получению несанкционированного контроля над кластерами и хостовыми системами.

PT Container Security — это решение для комплексной защиты гибридной облачной инфраструктуры, предназначенное для безопасной разработки и эксплуатации программных систем, использующих контейнерную виртуализацию. Продукт обеспечивает защиту контейнеров, образов, реестров, кластеров и оркестраторов (Docker, Kubernetes) на протяжении всего жизненного цикла — от CI/CD до runtime. Уязвимости в продукте могут напрямую влиять на безопасность критических сервисов и устойчивость всей облачной инфраструктуры.

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

### 1. Центральная консоль управления и API
- Обход аутентификации или авторизации в единой консоли управления мультикластерной инфраструктурой, позволяющий получить несанкционированный доступ к управлению кластерами и политиками безопасности.
- XSS или CSRF в веб-интерфейсе, используемом для управления правилами, пользователями и настройками, приводящие к выполнению действий от имени привилегированных пользователей.

### 2. Сканирование образов и реестров
- Обход механизмов сканирования уязвимостей (CVE) в образах контейнеров, включая образы на базе отечественных операционных систем (Astra Linux, RedOS), приводящий к распространению уязвимых компонентов в продакшене.
- SSRF при интеграции с реестрами контейнерных образов (Artifactory, Nexus, GitLab Registry, Yandex Container Registry) через их API, позволяющий атаковать внутренние сервисы или инфраструктурные компоненты.

### 3. Admission Controller
- Выполнение команд (exec) в контейнере в обход запрещающих правил, установленных на уровне admission-контроллера.
- Cluster Takeover, включая получение прав cluster-admin через ошибки в admission webhook, сервисных аккаунтах или механизмах проверки токенов (TokenReview API).
- Внедрение небезопасного контейнера в кластер в обход политик безопасности, например контейнера с привилегированным доступом или с монтированием чувствительных томов хоста.

### 4. Защита рантайма (Runtime Security)
- Обход механизмов мониторинга на базе eBPF, предназначенных для обнаружения подозрительной активности в запущенных контейнерах.
- Подмена, перехват или нарушение управления агентом защиты (DaemonSet), установленным на узлах кластера.
- Побег из контейнера (Container Escape) на хостовую ОС несмотря на активный мониторинг системных вызовов и действующие правила безопасности.


**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

PT Container Security

Программа Bug Bounty продукта PT Container Security

# Программа Bug Bounty продукта PT Application Inspector
Программа Bug Bounty продукта PT Application Inspector направлена на выявление и подтверждение уязвимостей, которые могут привести к компрометации процессов анализа безопасности приложений, искажению результатов SAST/DAST/IAST/SCA-проверок, утечке исходного кода и данных анализа, а также использованию компонентов системы в качестве точки входа для атак на инфраструктуру заказчика.

PT Application Inspector — это комплексная платформа анализа безопасности приложений, объединяющая статический, динамический, интерактивный анализ, анализ компонентов с открытым исходным кодом (SCA), а также механизмы сигнатурного и паттерн-матчинга. Продукт применяется для защиты приложений различного масштаба — от публичных веб-сервисов до критичных корпоративных и государственных систем. Уязвимости в продукте способны напрямую повлиять на достоверность результатов анализа и безопасность цепочки разработки (SDLC).

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

### 1. Веб-интерфейс и API управления
- Обход аутентификации в интерфейсе управления, позволяющий получить несанкционированный доступ к проектам, результатам анализа и настройкам системы.
- XSS в полях ввода, используемых при работе с проектами, параметрами сканирования или отчётами, позволяющий выполнить произвольный код в браузере пользователя.
- Небезопасная десериализация в API, приводящая к выполнению произвольного кода или компрометации компонентов системы.
- Path Traversal при загрузке исходного кода для анализа, позволяющий читать или перезаписывать произвольные файлы на сервере.

### 2. Анализ исходного кода
- Подмена результатов анализа через инъекции в метаданные проекта, приводящая к искажению выводов о наличии или отсутствии уязвимостей.
- Некорректная обработка известных уязвимостей (CVE), позволяющая скрыть реальные уязвимости в анализируемом коде или внедрить ложные результаты.

### 3. База данных уязвимостей
- SQL-инъекции в механизмах поиска и фильтрации уязвимостей, позволяющие получить доступ к данным системы или нарушить её работоспособность.
- XSS в отчётах, генерируемых системой, приводящий к компрометации сессий пользователей или выполнению действий от их имени.
- Обход механизмов проверки целостности базы сигнатур уязвимостей, позволяющий подменить или отключить правила обнаружения.

### 4. Система правил (Rule Engine)
- Удалённое выполнение кода (RCE) через кастомные правила анализа, используемые для расширения функциональности системы.
- Подмена или модификация системных правил анализа через уязвимости контроля доступа, приводящая к искажению результатов проверки приложений.

### 5. Интеграции с CI/CD
- SSRF в функциях интеграции с системами CI/CD (Jenkins, GitLab и др.), позволяющий атаковать внутренние сервисы или инфраструктуру.
- Утечка учетных данных систем сборки, используемых для автоматического анализа приложений в пайплайнах.
- Удалённое выполнение кода (RCE) через хуки CI/CD, приводящее к компрометации среды сборки или разработки.

### 6. Архитектура и развертывание
- Уязвимости в контейнерах, приводящие к побегу из изолированной среды и доступу к хост-системе.
- Раскрытие чувствительной информации в сообщениях об ошибках, позволяющее упростить дальнейшую атаку или получить сведения об архитектуре системы.


**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

PT Application Inspector

Программа Bug Bounty продукта PT Application Inspector

# Программа Bug Bounty продукта PT Sandbox
Программа Bug Bounty продукта PT Sandbox направлена на выявление и подтверждение уязвимостей, которые могут привести к обходу механизмов детектирования вредоносного ПО, выполнению вредоносного кода вне изолированной среды, компрометации инфраструктуры песочницы, а также снижению эффективности защиты от целенаправленных атак.

PT Sandbox — это локально разворачиваемая песочница для анализа неизвестного и сложного вредоносного ПО, включая эксплойты нулевого дня, программы-вымогатели и целевые атаки. Продукт использует сочетание статического и поведенческого анализа, корреляционных правил, сетевых сенсоров, ML-алгоритмов и механизмов наблюдения за операционной системой. Уязвимости в PT Sandbox могут приводить к пропуску вредоносных объектов, нарушению изоляции среды анализа, а также компрометации компонентов системы и смежной инфраструктуры.

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:
В рамках данной программы уязвимости классифицируются по уровням обхода, отражающим глубину и критичность воздействия на механизмы анализа и изоляции PT Sandbox.

### Обход изоляции

| Название уязвимости | Описание | Требования к вектору атаки |
| --- | --- | --- |
| Побег из песочницы (Sandbox Escape) | Файл, отправленный на поведенческий анализ, меняет контекст исполнения и начинает выполнять код в хостовой ОС или на уровне гипервизора. Результатом обхода должна быть возможность выполнения произвольного кода на хостовой системе или нарушение её работоспособности. | Исследователь имеет возможность отправлять файлы на анализ извне любым поддерживаемым способом. Допускается ручной поведенческий анализ файлов в интерфейсе продукта. |

### Обход детектирования документов и форматов

| Название уязвимости | Описание | Требования к вектору атаки |
| --- | --- | --- |
| Пропуск вредоносного документа                         | Необнаруженное исполнение вредоносного кода в контексте пользователя с использованием документов популярных офисных приложений (MS Office, LibreOffice, PDF и др.). Допускается условное выполнение вредоносного поведения вне PT Sandbox.            | Файл должен запускаться по клику пользователя, не требовать дополнительного ПО и предназначаться для поддерживаемой платформы и ОС. |
| Сокрытие активного элемента в офисном документе        | Вредоносный элемент корректно реализует опасное поведение, но не обнаруживается статическим анализом PT Sandbox. Возможные техники включают OLE-объекты, макросы, DDE, ActiveX, JavaScript, OpenAction, внешние источники данных и надстройки Office. | Файл должен быть валидным документом, запускаться по клику и предназначаться для поддерживаемой платформы и ОС.                     |
| Сокрытие популярного формата от поведенческого анализа | Валидный исполняемый файл или документ ошибочно классифицируется как неактивный и не передаётся в виртуальную среду для анализа (например, EXE или офисный документ).                                                                                 | Файл должен предназначаться для поддерживаемой PT Sandbox платформы и ОС.                                                           |

### Частичный обход и уязвимости интерфейсов

| Название уязвимости | Описание | Требования к вектору атаки |
| --- | --- | --- |
| Пропуск вредоносного исполняемого файла | Необнаруженное исполнение вредоносного кода с использованием исполняемых файлов (EXE, ELF) в контексте пользователя. Допускается условное выполнение вредоносного поведения вне среды PT Sandbox. | Файл должен запускаться по клику пользователя, не требовать дополнительных условий и быть предназначен для поддерживаемой платформы и ОС.                |
| Веб-интерфейс и API: обход авторизации  | Уязвимости в интерфейсе и публичном API, включая обход авторизации, XSS на основе отправленного на анализ контента, небезопасную десериализацию и Path Traversal при загрузке файлов.             | Исследователь может отправлять файлы через веб-интерфейс, Public API или почтовые интеграции, а также имеет сетевой доступ к доступным сервисам системы. |


**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

PT Sandbox

Программа Bug Bounty продукта PT Sandbox

# Программа Bug Bounty продукта PT Application Firewall
Программа Bug Bounty продукта PT Application Firewall направлена на выявление и подтверждение уязвимостей, которые могут привести к обходу механизмов веб-защиты, снижению эффективности фильтрации атак, компрометации интерфейса управления политиками безопасности, а также использованию WAF в качестве точки обхода или усиления атак на защищаемые приложения.

PT Application Firewall — это средство защиты веб-приложений, предназначенное для предотвращения эксплуатации уязвимостей без внесения изменений в само приложение. Продукт анализирует входящий и исходящий HTTP/HTTPS-трафик, применяет политики безопасности и механизмы поведенческого анализа. Уязвимости в WAF могут приводить как к прямому обходу защитных правил, так и к искажению логики защиты, создавая ложное ощущение безопасности.

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

### 1. Веб-интерфейс и API управления
- Обход аутентификации или авторизации в интерфейсе управления, позволяющий получить несанкционированный доступ к настройкам политик безопасности.
- XSS в разделах настройки правил или просмотра логов, позволяющий похитить активную сессию администратора или выполнить действия от его имени.
- SQL-инъекции (SQLi) в полях ввода, используемых для создания кастомных правил, фильтров или исключений.

### 2. Ядро защиты (обход WAF)
- Обход механизмов парсинга HTTP/HTTPS-трафика с использованием нестандартных кодировок, разделения запросов или техник HTTP Request Smuggling.
- Обход правил фильтрации через Unicode-нормализацию, преобразование регистра, манипуляции с HTTP-методами или форматами запросов.
- Обход геолокационных и IP-ограничений путём подмены IP-заголовков, использования CDN, прокси или цепочек промежуточных узлов.
- Обход механизмов ограничения частоты запросов (Rate Limiting) через распределённые атаки или подмену идентификаторов сессий.
- Обход защиты от ботов (CAPTCHA, JavaScript-challenge) с использованием автоматизации и техник обхода проверок.

### 3. Обработка трафика и анализ
- Уязвимости в парсерах протоколов (HTTP, XML, JSON), приводящие к утечке памяти, отказу в обслуживании или удалённому выполнению кода (RCE).
- Обход механизмов проверки загружаемых файлов с использованием полиморфных техник или нестандартных форматов данных.
- Нарушение работы механизмов SSL/TLS-декодирования через использование специфических шифров, нестандартных параметров или версий протоколов, что может приводить к некорректному анализу защищённого трафика.


**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

PT Application Firewall

Программа Bug Bounty продукта PT Application Firewall

# Программа Bug Bounty продукта PT Data Security
Программа Bug Bounty продукта PT Data Security направлена на выявление и подтверждение уязвимостей, которые могут привести к несанкционированному доступу к данным, компрометации механизмов инвентаризации и классификации информации, нарушению процессов мониторинга рисков и инцидентов, а также утечке чувствительных данных из корпоративных хранилищ.

PT Data Security — это платформа нового поколения для обеспечения полной видимости и защиты данных вне зависимости от формата и места их хранения. Продукт объединяет инвентаризацию, автоматизированную классификацию и мониторинг данных, обеспечивая централизованный контроль над инфраструктурой хранения и обработки информации. Уязвимости в продукте способны напрямую повлиять на конфиденциальность, целостность и доступность данных, включая критичные и регуляторно значимые сведения.

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

### 1. Интерфейс управления и API
- Обход аутентификации или авторизации с получением доступа к интерфейсу управления (UI) продукта, позволяющий просматривать или изменять конфигурацию системы.
- Обход аутентификации или авторизации в методах API, предназначенных для управления активами, классами данных, рисками и инцидентами, приводящий к несанкционированному доступу к чувствительной информации.

### 2. Интеграции с СУБД и системами хранения данных
- Получение доступа к учетным данным в открытом виде, используемым системой для инвентаризации и классификации содержимого в защищаемых хранилищах данных.
- Компрометация закрытого ключа или сертификата, используемого системой для расшифрования SSL/TLS-трафика между пользователями и хранилищами, позволяющая реализовать атаку типа Man-in-the-Middle и получить доступ к передаваемым данным.


**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

PT Data Security

Программа Bug Bounty продукта PT Data Security

# Программа Bug Bounty продукта MaxPatrol O2
MaxPatrol O2 — это система, предназначенная для автоматического обнаружения и обработки инцидентов информационной безопасности, происходящих в IT-инфраструктуре организации.

MaxPatrol O2 упрощает работу экспертов по ИБ: обнаружение инцидентов происходит автоматически, а процесс управления инцидентами максимально автоматизирован. В веб-интерфейсе отображаются подробные сведения о хакерских действиях, а также предоставляются инструменты для быстрого расследования атаки. Благодаря MaxPatrol O2 работа с инцидентами становится эффективнее, что обеспечивает своевременное реагирование на угрозы ИБ и повышает защищенность инфраструктуры.


## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**


## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

## 1. Веб-интерфейс и API
- Обход аутентификации или авторизации в интерфейсе управления O2, ведущий к доступу к данным и функциям другого тенанта или администратора.
- XSS (межсайтовый скриптинг) в любом поле ввода, позволяющий похитить сессию администратора системы.
- SSRF (Server-Side Request Forgery) в функциях интеграции, позволяющий атаковать внутренние компоненты системы O2 или подключенные сенсоры.
- Небезопасная десериализация в API, используемом для обмена данными между компонентами O2 и сенсорами, ведущая к удалённому выполнению кода (RCE).

## 2. Ядро анализа (Threat Modeling Engine)
- Манипуляция с данными Threat Modeling Engine, приводящая к построению неверного графа атак и образованию «слепых зон» в защите.
- Обход механизмов корреляции событий, позволяющий скрыть активность злоумышленника от системы (например, создание событий, которые O2 не сможет корректно «склеить» в цепочку).
- Подмена или порча данных об активах, уязвимостях или топологии сети, приводящая к неверной оценке уровня опасности цепочек активности.


## 3. Интеграции и сенсоры
- Подмена данных, поступающих в O2 от сенсоров (MaxPatrol SIEM, EDR, PT NAD и др.), ведущая к ложным срабатываниям или сокрытию атак.
- RCE через обработку файлов от интегрированных систем (например, при анализе файлов из PT Sandbox).
- Уязвимости в механизмах обогащения контекста, например, SSRF при обращении к внешним системам для верификации IP-адресов или хэшей.

## 4. Автоматизированное реагирование
- Неавторизованный запуск сценариев реагирования, приводящий к нарушению работы бизнес-процессов (например, несанкционированное отключение узлов сети или учётных записей через интегрированный EDR).
- Обход сценариев реагирования, позволяющий злоумышленнику оставаться в системе, даже если его активность была обнаружена.


**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

MaxPatrol O2

Программа Bug Bounty продукта MaxPatrol O2

# Программа Bug Bounty продукта MaxPatrol VM
Программа Bug Bounty продукта MaxPatrol VM направлена на выявление и подтверждение уязвимостей, которые могут привести к нарушению процессов управления уязвимостями, искажению данных об ИТ-инфраструктуре, ошибочной приоритизации рисков, а также использованию системы в качестве точки входа для атак на инфраструктуру заказчика.

MaxPatrol VM — это система управления уязвимостями нового поколения, предназначенная для построения и сопровождения полного цикла vulnerability management: от инвентаризации активов и выявления уязвимостей до приоритизации, контроля устранения и оценки общего уровня защищённости организации. Уязвимости в продукте могут напрямую влиять на корректность принимаемых решений по безопасности, приводить к формированию «слепых зон» в защите и снижать эффективность реагирования на реальные угрозы.

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

### 1. Веб-интерфейс и API управления
- Обход аутентификации или авторизации в интерфейсе управления, позволяющий получить несанкционированный доступ к функционалу системы.
- Обход ограничений прав доступа, включая доступ к данным другого тенанта или организации в многоарендной архитектуре.
- XSS (межсайтовый скриптинг), позволяющий похитить активную пользовательскую сессию или выполнить действия от имени пользователя.
- SQL-инъекции (SQLi) или командные инъекции в полях ввода, используемых для управления активами, задания правил обработки уязвимостей или формирования отчётов.
- Небезопасные прямые ссылки на объекты (IDOR) в API, позволяющие одному пользователю получить доступ к данным, настройкам или результатам сканирования другого пользователя или организации.

### 2. Управление активами и данными
- Path Traversal при работе с отчётами или загружаемыми файлами, ведущий к чтению, удалению или модификации произвольных файлов на сервере.
- Подмена данных об активах, приводящая к некорректной оценке критичности узлов, приоритетов устранения уязвимостей и формированию «слепых зон» в защите.
- Обход механизмов контроля целостности данных, позволяющий скрыть отдельные активы или уязвимости от системы управления уязвимостями.

### 3. Сканирование и анализ
- Обход механизмов обнаружения уязвимостей, приводящий к ложноотрицательным результатам, при которых реально существующие уязвимости не выявляются системой.
- SSRF (Server-Side Request Forgery) в функциях, выполняющих проверки или сбор информации, позволяющий атаковать внутренние компоненты инфраструктуры или сторонние сервисы.
- Нарушение работы механизма ретроспективного анализа, который используется для выявления новых уязвимостей без повторного сканирования, что может приводить к устаревшим или некорректным данным о состоянии безопасности.

### 4. Аутентификация и авторизация
- Недостатки контроля доступа, позволяющие пользователю с низкими привилегиями повысить их до уровня администратора системы.
- Уязвимости в механизмах хранения или передачи учетных данных, используемых для сканирования в режиме «белого ящика», включая возможность их компрометации или повторного использования.

### 5. Компоненты продукта и внутренние взаимодействия
- Использование интерфейсов системы как промежуточного узла для атак на её компоненты, внутренние модули, внешние интеграции (LDAP, SSO и др.) или иные узлы инфраструктуры заказчика.


**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

MaxPatrol VM

Программа Bug Bounty продукта MaxPatrol VM

# Программа Bug Bounty продукта PT Dephaze
Программа Bug Bounty направлена на выявление и подтверждение уязвимостей в продукте PT Dephaze — автоматизированном решении для постоянной проверки вашей инфраструктуры.

PT Dephaze — автопентест, который показывает, как далеко сможет продвинуться хакер в вашей инфраструктуре.
Регулярный пентест — один из объективных способов проверить защищённость инфраструктуры. Долгие перерывы между тестированиями накапливают бреши в безопасности. PT Dephaze позволяет сделать проверку защищённости постоянной и безопасной — чтобы вы могли устранять проблемы до того, как ими воспользуются злоумышленники.

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

## 1. Веб-интерфейс и API управления
- Обход аутентификации или авторизации в консоли управления симуляциями и агентами.
- XSS (межсайтовый скриптинг) в разделах создания сценариев атак или просмотра отчётов, позволяющий похитить сессию администратора.
- Небезопасная десериализация в API, используемом для планирования заданий или получения результатов от агентов, ведущая к удалённому выполнению кода (RCE).
- SSRF (Server-Side Request Forgery) в функциях, выполняющих проверки целей симуляции, позволяющий атаковать внутренние системы.

## 2. Движок симуляции атак
- Обход «безопасного режима» выполнения сценариев, приводящий к реальному нарушению работы целевых систем (например, вызвавший DoS на критичном сервере).
- Подмена или порча результатов симуляции (отчётов) через уязвимости в механизме сбора и агрегации данных.
- Несанкционированное выполнение произвольного кода или команд на целевой системе, не входящих в библиотеку разрешённых сценариев.

## 3. Агенты BAS
- Удаление, остановка или обход защиты агента BAS без соответствующих привилегий на целевой системе.
- Компрометация агента для получения контроля над системой, на которой он запущен.
- Подмена телеметрии, отправляемой агентом на центральный сервер, для сокрытия реальной активности или маскировки атаки.

## 4. Библиотека атак и сценариев
- Обновление библиотеки атак из внешнего ненадёжного источника (например, через уязвимость в механизме обновлений).
- Инъекция вредоносного сценария в общую библиотеку, который будет выполнен другими пользователями системы.


**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |
 

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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

PT Dephaze

Программа Bug Bounty продукта PT Dephaze

# Программа Bug Bounty продукта MaxPatrol SIEM
Программа Bug Bounty продукта MaxPatrol SIEM направлена на выявление и подтверждение уязвимостей, которые могут привести к нарушению процессов сбора, хранения и анализа данных о событиях, происходящих в IT-инфраструктуре организации, а также использованию системы в качестве точки входа для атак на инфраструктуру заказчика.

MaxPatrol SIEM — это система, которая предназначена для сбора, хранения и анализа данных о событиях, происходящих в IT-инфраструктуре организации. Это позволяет обеспечивать мониторинг информационной безопасности как всей инфраструктуры, так и отдельных подразделений, узлов и приложений.

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

### 1. Веб-интерфейс и API управления
- Cross-site Scripting/межсайтовый скриптинг (XSS), позволяющая похитить сессию администратора или выполнить действия от имени администратора.
- Cross-Site Request Forgery/межсайтовая подделка запроса (CSRF), позволяющая изменить конфигурацию системы
- Insecure Direct Object Reference/небезопасная прямая ссылка на объект (IDOR), позволяющая одному пользователю получить доступ или удалить данные другого тенанта или актива
- SQL-инъекции (SQL-injection) в параметрах API или интерфейса, используемых для управления активами или задачами сбора данных

### 2. Аутентификация и авторизация
- Обход аутентификации или авторизации на любом этапе входа в систему (например, через сброс пароля), позволяющий получить несанкционированный доступ к функционалу системы.
- Недостатки контроля доступа позволяющие пользователю с низкии привилегиями повысить их до уровня администратора системы
- Уязвимости в механизме единого входа

### 3. Обработка данных и корреляции
- Server-Side Request Forgery (SSRF) — в функционале обогащения событий (например, при проверке IP-адресов во внешних сервисах), приводящая к атакам на внутренние системы.
- Уязвимости десериализации — в механизмах обработки и корреляции событий, приводящие к выполнению произвольного кода.
- Path Traversal — при работе с файлами логов или конфигураций, собираемых с активов.

### 4. Интеграции и сторонние сервисы
- Небезопасное хранение данных — учетных данных, используемых для подключения к внешним системам.
- Удалённое выполнение кода (RCE) через анализ файлов — в интегрированных компонентах (например, при проверке файлов в песочнице).

### 5. Архитектура и развертывание
- Уязвимости в контейнерах Docker — приводящие к побегу из контейнера и компрометации хостовой системы.
- Чтение произвольных файлов — на стороне SIEM через уязвимости в компонентах (например, в СУБД LogSpace / Elasticsearch).


**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

MaxPatrol SIEM

Программа Bug Bounty продукта MaxPatrol SIEM

# Программа Bug Bounty продукта PT Industrial Security Incident Manager (ISIM)

PT Industrial Security Incident Manager (ISIM) — единая точка мониторинга безопасности промышленных ИТ-инфраструктур.
PT ISIM обеспечивает комплексный мониторинг безопасности промышленных ИТ-инфраструктур, помогает обнаруживать современные киберугрозы и таргетированные кибератаки.

Решение позволяет выполнить важную часть требований ФСТЭК России по защите объектов КИИ и покрывает меры приказа ФСТЭК России № 239: предотвращение вторжений (компьютерных атак) (СОВ) и реагирование на компьютерные инциденты (ИНЦ).

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

## 1. Центральная консоль (Overview Center) и API
- Обход аутентификации или авторизации в интерфейсе управления, ведущий к получению прав администратора или доступу к данным другого тенанта / распределённой площадки.
- XSS (межсайтовый скриптинг) в интерфейсе просмотра инцидентов или построения топологии сети, позволяющий похитить сессию администратора.
- Небезопасная десериализация в API, используемом для агрегации данных с сенсоров, ведущая к удалённому выполнению кода (RCE).

## 2. Сенсоры (View Sensor) и анализ трафика
- Обход механизмов анализа (DPI) промышленных протоколов (Siemens S7, IEC 60870-5-104, Modbus TCP, OPC UA и др.) через нестандартные кодировки, разделение пакетов или использование недокументированных функций ПЛК.
- Подмена или порча телеметрии, отправляемой сенсором на центральную консоль, для сокрытия следов атаки в сети АСУ ТП.
- Отказ в обслуживании (DoS) сенсора через специально сформированный сетевой трафик, приводящий к «слепой зоне» в мониторинге.

## 3. Механизмы детектирования угроз
- Обход сигнатурных правил и базы PT ISTI с помощью техник обфускации, имитирующих легитимный технологический трафик.
- Обход поведенческого анализа и контроля целостности сети, позволяющий злоумышленнику оставаться необнаруженным при несанкционированном подключении к сети АСУ ТП или изменении проекта ПЛК.
- Генерация множества ложных инцидентов для маскировки реальной атаки.

## 4. Управление ПЛК и техпроцессом
- Несанкционированное управление ПЛК (изменение микропрограмм, проектов, режимов работы) через уязвимости в логике продукта, которая должна это детектировать.
- Сокрытие неавторизованного изменения технологических параметров (например, уставок, режимов работы оборудования), которые PT ISIM должен обнаруживать.


**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

PT ISIM

Программа Bug Bounty продукта PT Industrial Security Incident Manager (ISIM)

# Программа Bug Bounty продукта MaxPatrol 360
MaxPatrol 360 — это современное решение по управлению инцидентами и управлению кибербезопасностью для организаций любого масштаба, от корпоративных SOC до MSSP.
Платформа помогает выстроить полный жизненный цикл работы с инцидентами ИБ — от организации сбора и обработки данных до расследования, реагирования и аналитики, обеспечивая высокий уровень киберустойчивости и прозрачности процессов.

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

## 1. Единая консоль управления & API
- Обход аутентификации или авторизации в единой консоли управления, ведущий к получению прав администратора платформы или доступу к данным другого тенанта.
- XSS (межсайтовый скриптинг) в любом поле ввода интерфейса, позволяющий похитить сессию администратора системы.
- Небезопасная десериализация в API, используемом для обмена данными между компонентами платформы, ведущая к удалённому выполнению кода (RCE).

## 2. Межмодульное взаимодействие и данные
- Нарушение целостности и конфиденциальности данных, передаваемых между модулями платформы (например, через нешифрованные каналы, отсутствие проверки подписи или подделку сообщений).

## 3. Автоматизированное реагирование
- Неавторизованный запуск сценариев реагирования, приводящий к нарушению работы бизнес-процессов (например, несанкционированное отключение узлов сети, блокировка пользователей, изменение политик безопасности).

**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

MaxPatrol 360

Программа Bug Bounty продукта MaxPatrol 360

# Программа Bug Bounty продукта PT Network Attack Discovery
Программа Bug Bounty продукта PT Network Attack Discovery направлена на выявление и подтверждение уязвимостей, которые могут привести к нарушению корректности детектирования атак, компрометации данных о сетевой активности, нарушению расследования инцидентов, а также использованию компонентов системы в качестве точки входа в инфраструктуру заказчика.

PT Network Attack Discovery — это система класса Network Detection and Response (NDR/NTA), предназначенная для обнаружения атак на сетевом периметре и внутри корпоративной сети. Продукт обеспечивает выявление скрытых угроз, детектирование подозрительной активности, включая анализ зашифрованного трафика, хранение и корреляцию данных об атаках, а также интеграцию с внешними системами безопасности. Уязвимости в продукте могут оказывать прямое влияние как на уровень защищённости инфраструктуры, так и на достоверность принимаемых решений при реагировании на инциденты.

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

### 1. Веб-интерфейс и API управления
XSS или CSRF в интерфейсе управления, позволяющие изменить параметры детектирования, правила корреляции событий или получить доступ к чувствительным данным системы.
Обход аутентификации или недостатки контроля доступа (IDOR) в консоли управления, ведущие к доступу к данным другой дочерней площадки, инсталляции или получению прав администратора.
SQL-инъекции (SQLi) или командные инъекции, позволяющие выполнять произвольные запросы к базе данных или команды в контексте серверных компонентов продукта.

### 2. Анализ трафика и детектирование
Подделка или повреждение сетевого трафика, приводящие к отказу в обслуживании (DoS) компонентов анализа или получению удалённого выполнения кода (RCE) на сенсоре.
Уязвимости в парсерах сетевых протоколов (поддерживается более 85 протоколов), приводящие к утечке памяти, нарушению корректности анализа сетевых данных или выполнению произвольного кода.

### 3. Хранение и обработка данных
Path Traversal при доступе к хранимым PCAP-файлам или извлечённым объектам, ведущий к чтению, удалению или перезаписи произвольных файлов на сервере.
Уязвимости, позволяющие атакующему удалить или изменить доказательную базу уже зафиксированных атак, что может привести к сокрытию следов компрометации и искажению результатов расследования инцидентов.

### 4. Интеграции и внешние системы
SSRF в функционале интеграции с внешними системами (например, при проверке файлов в PT Sandbox или отправке оповещений в SIEM), позволяющий атаковать внутренние сервисы и компоненты инфраструктуры.
Небезопасная десериализация данных при получении информации от PT MultiScanner или других систем экосистемы Positive Technologies, способная привести к выполнению произвольного кода или компрометации компонентов системы.

**Примечание: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

PT NAD

Программа Bug Bounty продукта PT Network Attack Discovery

# Программа Bug Bounty продукта MaxPatrol EDR
Программа Bug Bounty продукта MaxPatrol EDR направлена на выявление и подтверждение уязвимостей в продукте MaxPatrol EDR — комплексном решении для безопасности конечных точек.

MaxPatrol EDR — комплексное решение для безопасности конечных точек.
По мере стремительного развития ИТ-инфраструктур компаний инструменты и методы злоумышленников также совершенствуются и становятся всё более изощрёнными, чтобы обходить традиционные средства защиты.

Для своевременного обнаружения таких угроз и уверенного реагирования на них необходимо понимать контекст происходящего на конечных точках, динамически отслеживать угрозы, связывать отдельные события в единую картину и выстраивать цепочки атак. MaxPatrol EDR позволяет быстро выявлять сложные угрозы и целевые атаки, уверенно реагировать на инциденты и автоматизировать рутинные операции с учётом специфики кибербезопасности и процессов конкретной компании.

## Ограничения
**На момент запуска программы доступ к тестовым стендам продукта предоставляется ограниченно.**
**Расширенный доступ будет предоставлен позднее, по мере готовности инфраструктуры и процедур сопровождения.**

## Общие положения:

Типы уязвимостей, принимаемые к рассмотрению. Мы принимаем отчёты об уязвимостях следующих категорий (но не ограничиваемся ими):

## 1. Центральная консоль управления и API
- Обход аутентификации или авторизации в консоли управления EDR.
- XSS (межсайтовый скриптинг) в интерфейсе просмотра событий безопасности и расследования инцидентов.
- Небезопасная десериализация в API, используемом для сбора телеметрии с агентов.
- Атака на консоль управления через поддельных или неавторизованных агентов (например, DoS или эксплуатация уязвимостей агента для воздействия на сервер).
- Подмена или нарушение целостности отправки телеметрии с сервера агентов в SIEM-систему.
- SSRF (Server-Side Request Forgery) в функциях интеграции с SIEM/SOAR-системами.

## 2. Агент EDR на конечных точках
- Обход или отключение защиты агента EDR через уязвимости в драйвере ядра.
- Удаление или остановка агента без соответствующих привилегий (например, из-под стандартной учётной записи пользователя).
- Нарушение работоспособности запущенного агента через манипуляции с окружением (например, путём изменения системных настроек, зависимостей или ресурсов).
- Обход контроля приложений и выполнение запрещённого кода в обход политик EDR.

## 3. Проактивная защита
- Обход встроенных механизмов предотвращения эксплуатации уязвимостей (Anti-Exploitation), таких как ASLR, DEP, Control Flow Guard и т.п.

**Примечание 1: К рассмотрению принимаются отчеты связанные с Windows агентами EDR и серверной частью (консолью управления)**
**Примечание 2: Уязвимости, не ведущие к реальному риску (например, теоретические или без подтверждения эксплуатации), могут быть отклонены или оценены как «информационные» без денежного вознаграждения.**

## Вознаграждения

Размеры вознаграждений описаны в таблице ниже:

|Уровень критичности| Размер выплаты |
|---|---|
|Критический | 300 000 - 500 000 р. |
|Высокий | 150 000 - 300 000 р. |
|Средний | 50 000 - 150 000 р. |
|Низкий | 0 - 50 000 р. |


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

Уровень критичности уязвимости определяется в ходе триажа и подтверждения отчёта с учётом влияния на безопасность продукта.
Окончательное решение по уровню критичности уязвимости принимается командой безопасности продукта.

## Требования к участникам
Участвовать в программе могут все заинтересованные исследователи в возрасте от 18 лет.
Исследователи в возрасте от 14 до 18 лет имеют право участвовать в программе только при наличии письменного согласия родителей или законного представителя.
Действующие сотрудники Positive Technologies и бывшие сотрудники, с момента увольнения которых прошло менее 3 лет, могут участвовать в программе, но не могут претендовать на вознаграждение.

### Исследователям необходимо:
* Соблюдать правила, которые устанавливает Positive Technologies в своей программе по раскрытию уязвимостей, а также правила платформы The Standoff 365 Bug Bounty.
* Соблюдать правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, случайным образом полученную в ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным.
* Поддерживать общение с командой по безопасности, направлять ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давать обратную связь, если у специалистов возникнут вопросы об отчете.
* Не разглашать информацию об уязвимости. Право на публикацию информации о найденной уязвимости остается за Positive Technologies.
* Раскрытие уязвимости допустимо только при наличии исправления и публично зарегистрированного идентификатора CVE/BDU.
* Багхантер может изъявить желание о раскрытии отчета - PT обязуется запустить процесс согласования регистрации идентификатора уязвимости.

## Вознаграждения за уязвимости
Positive Technologies не выплачивает вознаграждение:
- за отчеты сканеров безопасности и других автоматизированных инструментов;
- раскрытие несекретной информации (наименования ПО или его версии, технические параметры и метрики системы и пр.);
- информацию об IP-адресах, DNS-записях и открытых портах;
- проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации;
- уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ;
- отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации;
- отчеты об отсутствии SSL и других лучших практик (best current practices);
- уязвимости, информацию о которых ранее передали другие участники конкурса (дубликаты отчетов);
- уязвимости 0-day или 1-day, информация о которых получена командой по безопасности из открытых источников;
- уязвимости к атаке перебором, если в отчете не описан метод, имеющий существенно более высокую эффективность, чем прямой перебор.

MaxPatrol EDR

Программа Bug Bounty продукта MaxPatrol EDR

###	Правила для нас
- Мы отвечаем в течение 7 рабочих дней.
- Мы обрабатываем отчеты в течение 21 рабочего дня после ответа.
- Мы можем увеличить сроки обработки отчетов, но в таком случае мы проинформируем вас о задержке.
- Мы определим сумму вознаграждения в течение 21 рабочего дня после обработки.
- Мы сделаем все возможное, чтобы в процессе обработки отчета вы были в курсе нашего прогресса.

###	Правила для вас
- Будьте этичным хакером и уважайте конфиденциальность других пользователей.
- Старайтесь избегать нарушений конфиденциальности, уничтожения данных, а также прерывания или ухудшения качества наших сервисов.
- Если вы проводите исследование веб-ресурсов и API, **обязательно указывайте в HTTP-заголовке `User-Agent X-BugBounty` со значением `your_username`**. Это поможет избежать потенциальной блокировки.
- При регистрации учетной записи для тестирования в поле «Фамилия» используйте слово `Standoff`.
- Инструменты автоматического сканирования должны быть ограничены 30 запросами в секунду к одному целевому узлу.
- При обнаружении нескольких проблем безопасности, подготовьте отчеты о каждой из выявленных уязвимостей отдельно.
- Включите в отчет информацию об **IP-адресе**, с которого происходило тестирование, а также информацию **о времени тестирования.**
- Используйте только собственные учетные записи.
- Не совершайте действия, которые могут нанести ущерб компании, ее инфраструктуре, клиентам и партнерам.
- Используйте базовые команды для POC или другие минимальные доказательства наличия уязвимости в системе.
- Свяжитесь с нами, если вы понимаете, что для дальнейшего тестирования вам необходимо нарушить эти правила.

###	Скоуп

Диапазон исследуемых IP-адресов - 188.254.86.129 - 188.254.86.158:

**Уровень 1**
- Критичные веб-сервисы:
•	Официальные веб-порталы Росфинмониторинга (188.254.86.133, 188.254.86.136)
•	Основные сайты и домены организации (188.254.86.133)
•	Порталы для внешних пользователей (188.254.86.136)
- Критичные API:
•	REST/JSON API на основных порталах Росфинмониторинга (188.254.86.133, 188.254.86.136)
•	Интеграционные сервисы (188.254.86.133, 188.254.86.136)

**Уровень 2**
-	Важные сервисы:
•	Специализированные системы финансового мониторинга (188.254.86.133)
•	Почтовые веб-интерфейсы и связанные сервисы (188.254.86.135)
•	Вспомогательные порталы для участников финансового рынка
•	Информационные системы общего доступа
-	Вспомогательные API:
•	SOAP/XML сервисы для внешних организаций
•	Webhook endpoints для уведомлений и callback'ов
•	API отчетности и статистики (188.254.86.133)
•	API третьих лиц интегрированные в системы

**Уровень 3** 
- Инфраструктурные сервисы:
•	SMTP и почтовые серверы (188.254.86.143, 188.254.86.144)
•	Relay и пересылочные сервисы (188.254.86.130)
•	Технические поддомены и служебные интерфейсы
•	Системы мониторинга и статистики

###	Размеры вознаграждений

Уровень критичности |	Уровень 1	|Уровень 2|	Уровень 3|
|-------------------------|---------------|------------|-------------|
|Критический	|100 000 – 150 000 руб.	|75 000 – 112 500 руб.	|50 000 – 75 000 руб.|
|Высокий|	50 000 – 100 000 руб.|	37 500 – 75 000 руб.|	25 000 – 50 000 руб.|
|Средний|	15 000 – 50 000 руб.	|5 000 – 15 000 руб.|	0 руб.|
|Низкий|	5 000 – 15 000 руб.|	0 руб.	|0 руб.|

###	Правила раскрытия информации
-	Отправляйте отчеты только через форму на платформе.
-	Не допускается разглашать сведения об уязвимости до их публичного раскрытия Росфинмониторингом.
-	В случае нарушения данных правил, мы будем вынуждены исключить вас из списка участников данной и любых других программ Росфинмониторинга, а также принять меры, соответствующие УК РФ.

###	Исключения  
Мы не выплачиваем вознаграждение за:
-	Отчеты сканеров безопасности и других автоматизированных инструментов.
-	Информацию об IP-адресах, DNS-записях и открытых портах без демонстрации эксплуатации.
-	Проблемы и уязвимости, которые основаны на версии используемого продукта, без демонстрации их эксплуатации.
-	Уязвимости, эксплуатацию которых блокируют СЗИ, без демонстрации обхода СЗИ (например, WAF).
-	Отчеты о небезопасных шифрах SSL и TLS без демонстрации их эксплуатации.
-	Self-XSS и другие уязвимости, напрямую не влияющие на пользователей или данные приложения.
-	Разглашение технической или нечувствительной информации (например, версии продукта или используемого ПО, информации об IP--адресах, DNS-записях, открытых портах).	
-	Раскрытие публичной информации о пользователе, например nickname.
-	Тестирование SMTP-серверов и relay-сервисов методами, нарушающими работу почтовых сервисов или приводящими к рассылке спама.
-	Попытки relay-атак через почтовые и пересылочные серверы без предварительного согласования.
-	Отчеты об отсутствующем механизме защиты/лучшей текущей практике (например отсутствие CSRF маркера, защита от framing/clickjacking) без демонстрации реального влияния на безопасность пользователя или системы.
-	Сообщения об опубликованных и неопубликованных политиках SPF и DMARC.
-	Кроссайтовые подделки запросов, приводящие к выходу из системы (logout CSRF).
-	В части уязвимостей 3rd party компонентов – принимаем только отчеты с доказанным влиянием на инфраструктуру Росфинмонтиоринга.
-	Безопасность рутированных, jailbreaked или иным образом модифицированных устройств и приложений.
-	Возможность обратного инжиниринга приложения или отсутствие бинарной защиты.
-	Open redirections принимаются только в том случае, если определено влияние на безопасность, например возможность кражи авторизационного токена.
-	Ввод неформатированного текста, звука, изображения, видео в ответ сервера вне пользовательского интерфейса (например, в данных JSON или сообщении об ошибке), если это не приводит к подмене пользовательского интерфейса, изменению поведения пользовательского интерфейса или другим негативным последствиям.
-	Same Site scripting, reflected download и подобные атаки с сомнительным воздействием.
-	Отчеты, связанные с CSP, для доменов без CSP и доменных политик с небезопасными eval и/или небезопасными inline.
-	Гомографические атаки IDN.
-	XSPA (сканирование IP/портов во внешние сети).
-	Инъекция формул Excel CSV.
-	Скриптинг в документах PDF.
-	Атаки, требующие полного доступа к локальной учетной записи или профилю браузера.
-	Теоретические атаки без доказательства возможности использования.
-	Уязвимости отказа в обслуживании (DoS) связанные с отправкой большого количества запросов или данных (флуд).
-	Возможность отправки большого количества сообщений.
-	Возможность отправки спама или файла вредоносного ПО.
-	Раскрытие информации через внешние ссылки, не контролируемые компанией.
-	Раскрытие неиспользуемых или должным образом ограниченных ключей JS API (например, ключ API для внешнего картографического сервиса).
-	Сообщения о возможных DDoS-атаках.
-	Раскрытие частных IP-адресов или доменов, указывающих на частные IP-адреса.
-	Сообщения о публично доступных панелях входа.
-	Clickjacking.
-	Обход проверки на root и jailbreak.
-	Утечка конфиденциальных маркеров (например, маркера сброса пароля) доверенным третьим лицам по защищенному соединению (HTTPS).

###	Недопустимые действия
Исследователям запрещено:
-	Получать доступ к данным других пользователей без их согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию.
-	Воздействовать на учетные записи других пользователей без их разрешения.
-	Использовать обнаруженную уязвимость в личных целях.
-	Использовать инструменты тестирования, автоматически генерирующие значительные объемы трафика и приводящие к атакам с исчерпанием ресурсов.
-	Проводить атаки, наносящие вред целостности и доступности сервисов (например, DoS-атаки, брутфорс-атаки).
-	Проводить физические атаки на персонал, дата-центры и офисы Росфинмониторинга.
-	Проводить атаки с использованием техник социальной инженерии (фишинг, вишинг и т. д.).
-	Разглашать сведения об уязвимости до их публичного раскрытия Росфинмониторингом.

Росфинмониторинг: Публичные сервисы

Федеральная служба по финансовому мониторингу

Росфинмониторинг

# What reports and vulnerabilities are accepted
As part of the Bug Bounty program, we review reports of real vulnerabilities that may affect the security of the cloud platform services and K2 Cloud customer data.

### Priority
- Remote Code Execution (RCE);
- Injections (SQL, XML, SSTI, etc.);
- Reading or writing arbitrary files (LFI, RFI);
- SSRF (with demonstration of real impact);
- Access control vulnerabilities (IDOR, vertical/horizontal escalation);
- Authentication and authorization deficiencies;
- Business logic errors allowing bypass of financial/functional restrictions;
- Disclosure of sensitive or confidential information;
- Other vulnerabilities capable of affecting platform/data operation or security.

### Special attention
Critical scenarios related to gaining control over infrastructure, bypassing cloud isolation, accessing other customers' resources, violating service integrity and availability.
- - -
# Program scope
The program scope covers all resources that are part of the K2 Cloud platform:

### Web console for managing cloud resources
* [console.k2.cloud](https://console.k2.cloud)

### Cloud platform service domains
* autoscaling.ru-msk.k2.cloud
* autoscaling.ru-spb.k2.cloud
* backup.ru-msk.k2.cloud
* backup.ru-spb.k2.cloud
* cloudtrail.ru-msk.k2.cloud
* cloudtrail.ru-spb.k2.cloud
* cloudwatch.ru-msk.k2.cloud
* cloudwatch.ru-spb.k2.cloud
* directconnect.ru-msk.k2.cloud
* directconnect.ru-spb.k2.cloud
* ec2.ru-msk.k2.cloud
* ec2.ru-spb.k2.cloud
* efs.ru-msk.k2.cloud
* efs.ru-spb.k2.cloud
* eks.ru-msk.k2.cloud
* eks.ru-spb.k2.cloud
* elb.ru-msk.k2.cloud
* elb.ru-spb.k2.cloud
* ext.ru-msk.k2.cloud
* ext.ru-spb.k2.cloud
* iam.k2.cloud
* paas.ru-msk.k2.cloud
* paas.ru-spb.k2.cloud
* primary.k2.cloud
* route53.k2.cloud
* ru-msk.console.k2.cloud
* ru-spb.console.k2.cloud
* s3.ru-msk.k2.cloud
* s3.ru-spb.k2.cloud

The current [API reference and description](https://docs.k2.cloud/en/api/index.html) of platform services are always available on our [public documentation website](https://docs.k2.cloud/en/).

- - -
# What is not accepted within the program
Some categories of issues are not accepted within the K2 Cloud Bug Bounty program and are not subject of bounty.

### Findings without practical value
- automated reports from scanners and other tools, if no proof of manual vulnerability exploitation is provided;
- disclosure of non-confidential or publicly available information: software version, username, public profiles, image metadata, technical headers and parameters;
- messages about best-practices non-compliance (e.g., absence of certain HTTP headers or CSP/DMARC/SPF/DNSSEC settings) are not accepted as standalone vulnerabilities unless real security impact is demonstrated (e.g., possibility of clickjacking attack, email spoofing, etc.);
- messages about open ports, IP addresses, DNS records without practical exploit;
- vulnerabilities related only to product/protocol version (e.g., "OpenSSL X.Y.Z is used"), without real exploitation scenario;
- reports about "logical" or "UI" errors without security impact.

### Theoretical or impractical vulnerabilities
- Blind SSRF and open redirects if security impact is not demonstrated or possibility of exploitation for access to sensitive data is not shown;
- theoretical attacks not confirmed by practical Proof of Concept;
- problems related to demo stands, test environments, training domains and services if there is no threat to main infrastructure.

### Methods excluded from the program
- attacks affecting service availability (DoS, flood, spam, brute-force, performance tests, resource exhaustion);
- social engineering attacks (phishing, interaction with customers, partners or company employees);
- vulnerabilities requiring physical access, modified or compromised devices, etc.

### Other exclusions
- vulnerabilities in third-party services, client projects or external integrations that do not affect K2 Cloud platform security and its users
- problems related to absence of obfuscation or code reversal possibility without confirmed security impact;
- errors discovered by current or former company employees (within a year after dismissal);
- information obtained from public buckets in K2 Cloud.
- - -
# Testing rules and ethics
To ensure service security and proper program operation, follow these principles.

### Test responsibly
- use only your accounts or specially allocated test accounts;
- do not disrupt service operation, do not delete or modify other users' data;
- avoid actions that may lead to data loss, impact on other users or customers;
- do not do actions that may affect service availability for customers (DoS, flood, brute-force, etc.);
- do not use automated scanning tools with high intensity.

### Prohibited
- researching vulnerabilities in K2 Cloud customer infrastructures (often these are addresses like *.elastic.k2.cloud);
- social engineering: phishing, spam, attempts to gain access through customers, partners or company employees;
- physical impact on equipment, offices, data centers and other company facilities;
- publishing or disclosing vulnerability information before they are fixed and without written consent from K2 Cloud;
- using discovered vulnerabilities for personal gain or bypassing tariff limitations.

### Restrictions on especially sensitive categories
- to confirm vulnerabilities like RCE, SQL injections, LFI/RFI, SSRF and other potentially dangerous bugs, use the minimal impact and safe exploits for Proof of Concept (e.g., sleep, reading /etc/passwd, request demonstration);
- for dangerous operations (privilege escalation, infrastructure interference) - coordinate actions with the K2 Cloud security team before testing at [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).

### Maintain confidentiality
- all information about discovered vulnerabilities must remain between the researcher and K2 Cloud security team until written permission for publication is obtained.

### Participation principles
- follow ethics and laws - your actions must comply with information security rules and applicable legislation;
- follow program conditions - review the rules before starting testing;
- respect team decisions - if you disagree, justify your position and provide evidence, we are open to dialogue;
- the final reward decision is made by the K2 Cloud team.
- - -
# Report formatting requirements
Reports are accepted exclusively on the Standoff365 platform. To expedite review of your request and increase your chances of receiving a reward, include in the report:
- **Vulnerability name and description**
- **Category**
- **CVE (if available)**
- **Criticality level analysis according to CVSS v3.1**
- **Address (or component) of the affected service**
- **Step-by-step exploitation scenario description:**
 - how the vulnerability was discovered;
 - what actions, parameters or conditions are needed for reproduction;
 - who and how can exploit the vulnerability.
- **Technical Proof of Concept (PoC):**
 - request/response examples, commands, scripts;
 - screenshots, video - if this helps verify the vulnerability (links to external sources are prohibited);
 - testing date and time.
- **Impact assessment:**
 - what data, services, users or infrastructure may be affected.
- **Remediation recommendations**
- **Your K2 Cloud account login (if used)**

> Each report should describe one vulnerability. If the exploit is built on a chain of vulnerabilities, you may include them in one report. In this case, the description must be made as clear as possible and all required information for each vulnerability must be indicated in the report. 
> Screen recording and screenshots are welcome but do not replace detailed textual description and PoC. 
> Reports without necessary data for reproduction may be returned for revision.

 Please ensure the report is structured and easy to read. Brief text error checking will make it more understandable and expedite review.
- - -
# Report processing and rewards
### Review process
- All reports are checked by the K2 Cloud security team.
- We usually provide the first response within **5 business days**.
- Full report review, validity determination and criticality level assessment usually takes up to **14 business days**.
- The decision on vulnerability seriousness, need for remediation and reward amount is made individually, considering: technical novelty, real impact level, exploitation complexity, affected services, potential mass impact and other factors.
- Rewards are paid only for the first valid reports on a specific vulnerability (duplicates are not paid).
- Vulnerabilities without confirmed security impact or with theoretical scenarios may be recognized as informative and remain unpaid.
- The reward amount is determined individually and depends on vulnerability seriousness and its security impact.
- Reward amount determination is carried out within **30 calendar days** after vulnerability validity confirmation and final report status establishment.
- In exceptional cases, review or payment timeframes may be increased, but in such cases we will definitely notify the researcher about reasons and estimated timelines.

### Reward amounts
|Vulnerability type|Reward range|Explanation|
|---|---|---|
|Remote Code Execution (RCE), access to internal infrastructure|150 000 — 300 000 ₽|Implies confirmed ability to execute arbitrary code on internal infrastructure servers of the cloud platform or gain access to internal services/networks. Theoretical scenarios and reports without PoC are not paid.|
|Server-side injections (SQLi, XML, SSTI, etc.)|50 000 — 150 000 ₽|Important are cases where the vulnerability leads to reading/changing data or system compromise. Reports based only on DBMS version or without confirmed data access are not paid.|
|Reading/writing arbitrary files (LFI, RFI, XXE)|30 000 — 120 000 ₽|Special attention is given to cases of accessing sensitive system or user files, or the ability to upload and execute files.|
|Privilege escalation (vertical or horizontal)|30 000 — 90 000 ₽|Horizontal - access to other users' data. Vertical - user → admin. Especially valuable are scenarios allowing management of others' resources or execution of admin functions.|
|Insecure Deserialization with confirmed impact|30 000 — 90 000 ₽|Only cases where the vulnerability leads to: - remote code execution (RCE); - privilege escalation or bypass of control mechanisms; - unauthorized access to confidential data; - manipulation of critical object attributes (e.g., role, access rights). Attacks leading exclusively to denial of service (DoS) are considered out of scope.|
|SSRF (with proven security impact)|20 000 — 60 000 ₽|The vulnerability must allow access to internal services, cloud metadata or perform malicious actions. Blind SSRF without demonstrated impact (e.g., without data leakage or filter bypass) is not paid.|
|Access control vulnerabilities, IDOR, disclosure of critical/confidential data|20 000 — 60 000 ₽|These include cases where one user can access data or operations of another. Information about access to public or insignificant data (e.g., nicknames) may be recognized as informative and remain unpaid.|
|Authentication and session management errors|20 000 — 60 000 ₽|Category includes login bypass, session fixation or theft, token compromise. Comments like "session lives too long" without exploit are not paid.|
|XSS (only with proven impact: token theft, action execution on behalf of user)|20 000 — 60 000 ₽|Important are substantial cases where, for example, XSS allows stealing tokens, executing actions on behalf of users or affecting sensitive data. Self-XSS or XSS affecting only the researcher is not paid.|
|CSRF (only if it affects critical functions)|20 000 — 60 000 ₽|Valuable are cases where the attack allows changing passwords, managing users and their rights, changing important service settings, billing parameters, etc. Logout CSRF or insignificant actions may be recognized as informative and remain unpaid.|
|Business logic errors, bypass of financial and functional restrictions|individually|Reward is determined individually as impact may be unique. Example: bypassing paid features or tariff restrictions.|
|Other confirmed vulnerabilities|individually|Main condition - real confirmed impact on user or infrastructure security.|

### How we determine criticality and reward amount
Vulnerability criticality assessment is conducted by the K2 Cloud security team and is always based on a combination of factors. After receiving a report, we consider not only technical details but also practical risk for customers and services. The analysis considers, among other things:
- how the vulnerability can affect user data and their availability;
- scale of the problem: does it affect one customer, a separate service, or infrastructure as a whole;
- level of preparation and conditions required for an attacker to exploit (e.g., presence of special rights or chains of multiple bugs);
- probability of discovery and attack repetition by other researchers or attackers;
- need for end-user involvement or possibility to automate the attack;
- possible business consequences, including reputational risks and customer trust.

This combination of criteria allows us to assess severity as objectively as possible and prioritize remediation.
For unification of assessment, we use **CVSS v3.1**, but the final decision is always made by the security team based on context and specifics of the particular case.

### How criticality relates to payouts
The rules of the program specify a reward range for each vulnerability category. The specific amount paid to the researcher depends on the vulnerability's criticality level:
- vulnerabilities with limited impact receive rewards closer to the lower range boundary;
- more serious problems that may affect multiple services or users are assessed in the middle of the range;
- the most dangerous cases (mass impact, critical business or customer damage) are rewarded closer to the upper range boundary.

> For some categories (e.g., **XSS** or **CSRF**) maximum impact is usually limited to the scope of a single user or session. In such cases, rewards are distributed within low and medium criticality levels, and the upper range limit applies only in the presence of truly non-standard impact (e.g., XSS in admin panel, bypass of protective mechanisms, or using XSS as part of a chain for a more serious attack).
 
The payout amount is directly related to the risk level of the discovered vulnerability.

### Duplicate handling rules
We pay a reward only for the first received report (provided it contains all the information necessary to reproduce the vulnerability). Any subsequent reports covering the same vulnerability will be marked as duplicates. Reports describing similar attack vectors may also be considered duplicates if our security team believes that information from a single report is sufficient to fix all possible attack vectors or issues.
The original report may be submitted either by an external researcher or be a description of the issue prepared by the K2 Cloud team.
- - -
# Technical details and support
### Access to K2 Cloud
To obtain access to a test account in K2 Cloud for research purposes:
1. Write to [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).
2. In the email, provide a link to your confirmed profile on the Standoff365 platform.
3. We will provide access and necessary consultations.

### Contacting the team
For questions about Bug Bounty participation, report formatting, or policy clarification, write to [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).
We are always open to constructive dialogue with researchers.

### Updating and changing rules
K2 Cloud reserves the right to change Bug Bounty program conditions, as well as report assessment criteria and payment procedures without prior notice.
- - -
# Let's make K2 Cloud safer together
We thank everyone who helps make K2 Cloud safer and more reliable for customers!

Your research is valued, and we are ready to cooperate honestly and openly with everyone interested in real improvement of information security level of our services.

All questions, wishes and suggestions for program development are accepted at [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).

K2 Cloud

[K2 Cloud](https://k2.cloud/) is a cloud provider with integrator expertise. We build and protect cloud infrastructure for our customers and strive to deliver the highest possible service reliability.
To make our cloud platform even more secure, we are launching a Bug Bounty program and invite information security professionals to collaborate with us in identifying vulnerabilities.

K2 Cloud — облачный провайдер с экспертизой интегратора: проводим аудит вашей ИТ-инфраструктуры, предлагаем способы ее оптимизации, реализуем комплексные проекты по развертыванию, сопровождению и развитию ИТ-сервисов в безопасной инфраструктуре.

## Правила для нас

Мы уважаем время и усилия наших исследователей;
Мы отвечаем в течение 5 рабочих дней;
Мы обрабатываем отчеты в течение 10 рабочих дней после ответа;
Мы можем увеличить сроки обработки отчетов, но в таком случае мы проинформируем вас о задержке;
Мы определим сумму вознаграждения в течение 15 рабочих дней после обработки;
Мы сделаем все возможное, чтобы в процессе обработки отчета вы были в курсе нашего прогресса.

## Правила для вас

Будьте этичным хакером и уважайте конфиденциальность других пользователей;
Соблюдайте правила, которые устанавливает Минцифры России в рамках данной программы, а также правила платформы The Standoff 365 Bug Bounty;
Соблюдайте правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, которая была получена случайным образом ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным;
Избегайте ситуаций, которые могут привести к прерыванию или ухудшению качества наших услуг. Инструменты автоматического сканирования должны быть ограничены 30 запросами в секунду к одному целевому узлу, суммируя все инструменты и потоки, работающие параллельно;
Поддерживайте общение с командой безопасности Минцифры России, направляйте ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давайте обратную связь, если у специалистов возникнут вопросы по отчету;
Сообщайте нам обо всех обнаруженных уязвимостях путем создания отчета (кнопка **Сдать отчет** рядом с названием программы);
Участниками программы могут быть только граждане Российской Федерации в возрасте от 18 лет.

## Скоуп

* do.gosuslugi.ru
* 109.207.2.97


В программе участвуют только указанные домены и IP-адреса. Все остальные домены и ресурсы (включая базы данных, почтовые серверы и так далее) в скоуп не входят.

## Вознаграждения за уязвимости

| Уязвимость (по уровню опасности) | Вознаграждение |
| ------------ | ------------ |
| Критический | 200 000 – 500 000 ₽ |
| Высокий | 50 000 – 200 000 ₽ |
| Средний | 30 000 – 50 000 ₽ |
| Низкий | 5 000 – 15 000 ₽ |

## Публичное раскрытие информации об уязвимости

**Публичное раскрытие информации о найденных в рамках программы уязвимостях в данный момент не предусмотрено.**

## Мы не принимаем и не рассматриваем:

*	Отчеты сканеров уязвимостей и других автоматизированных инструментов;
*	Раскрытие информации, не являющейся конфиденциальной, например версии продукта;
*	Раскрытие публичной информации о пользователе, например nickname;
*	Отчеты, основанные на версии продукта/протокола без демонстрации реального наличия уязвимости;
*	Отчеты об отсутствующем механизме защиты/лучшей текущей практике (например отсутствие CSRF-маркера, защита от framing/clickjacking) без демонстрации реального влияния на безопасность пользователя или системы;
*	Сообщения об опубликованных и неопубликованных политиках SPF и DMARC;
*	Кроссайтовые подделки запросов, приводящие к выходу из системы (logout CSRF);
*	Уязвимости партнерских продуктов или сервисов, если пользователи/учетные записи ЕСИА не затронуты напрямую;
*	Безопасность рутированных, jailbreaked или иным образом модифицированных устройств и приложений;
*	Возможность обратного инжиниринга приложения или отсутствие бинарной защиты;
*	Open redirections принимаются только в том случае, если определено влияние на безопасность, например возможность кражи авторизационного токена;
*	Ввод неформатированного текста, звука, изображения, видео в ответ сервера вне пользовательского интерфейса (например, в данных JSON или сообщении об ошибке), если это не приводит к подмене пользовательского интерфейса, изменению поведения пользовательского интерфейса или другим негативным последствиям;
*	Same Site scripting, reflected download и подобные атаки с сомнительным воздействием;
*	Отчеты, связанные с CSP, для доменов без CSP и доменных политик с небезопасными eval и/или небезопасными inline;
*	Гомографические атаки IDN;
*	XSPA (сканирование IP/портов во внешние сети);
*	Инъекция формул Excel CSV;
*	Скриптинг в документах PDF;
*   Self-XSS без демонстрации импакта;
*	Атаки, требующие полного доступа к локальной учетной записи или профилю браузера;
*	Атаки со сценариями, где уязвимость в стороннем сайте или приложении требуется как необходимое условие и не демонстрируется;
*	Теоретические атаки без доказательства возможности использования;
*	Уязвимости отказа в обслуживании (DoS), связанные с отправкой большого количества запросов или данных (флуд);
*	Возможность отправки большого количества сообщений;
*	Возможность отправки спама или файла вредоносного ПО;
*	Раскрытие информации через внешние ссылки, не контролируемые Минцифры России (например, поисковые dork’и к приватным защищенным областям robots.txt);
*	Раскрытие неиспользуемых или должным образом ограниченных ключей JS API (например, ключ API для внешнего картографического сервиса);
*	Возможность выполнить действие, недоступное через пользовательский интерфейс, без выявленных рисков безопасности;
*	Уязвимости раскрывающие только учетные записи пользователей, не содержащие пароля или иных персональных данных.

## Недопустимые действия

Исследователям запрещено:

* Воздействовать на учетные записи других пользователей без их разрешения;
* Использовать обнаруженные уязвимости в личных целях;
* Использовать инструменты тестирования уязвимостей, автоматически генерирующие значительные объемы трафика и приводящие к атакам с исчерпанием ресурсов;
* Проводить атаки, наносящие вред целостности и доступности сервисов (например, DoS-атаки, брутфорс-атаки и т.д.), пытаться эксплуатировать уязвимость, нацеленную на исчерпание ресурсов. Следует сообщить о проблеме команде по безопасности Минцифры России, которая проведет атаку в тестовой среде;
* Проводить физические атаки на персонал, дата-центры и офисы Минцифры России или поставщиков услуг;
* Проводить атаки на системы Минцифры России с использованием техник социальной инженерии (фишинг, вишинг и т.д.) и спам-рассылки клиентам, партнерам и сотрудникам;
* Исследовать серверную инфраструктуру, где размещены веб-приложения;
* Проникать во внутренние системы веб-сервисов и приложений информационных систем Минцифры России, а также иных информационных ресурсов Минцифры России. Программа по поиску уязвимостей в веб-сервисах и приложениях информационных систем Минцифры России должна заканчиваться взломом порталов и закреплением на них, строго без дальнейшего проникновения Исследователем во внутренние системы веб-сервисов и приложений информационных систем Минцифры России;
* Совершать попытки получения доступа к учетным записям, данным пользователей или к любым другим конфиденциальным данным, выходящим за пределы действий, минимально необходимых для демонстрации найденной уязвимости;
* Осуществлять целенаправленную выгрузку персональных данных граждан из внутренних систем веб-сервисов и приложений, а также иных информационных ресурсов, не указанных в программе.

## Политика тестирования RCE

Тестирование уязвимостей, которые могут приводить к удаленному исполнению кода, должно выполняться в соответствии с данными правилами:

Во время тестирования запрещены любые действия на сервере кроме:

Выполнения команд ifconfig (ipconfig), hostname, whoami, id;
Чтения содержимого файлов /etc/passwd и /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini);
Создания пустого файла в каталоге текущего пользователя.

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Политика тестирования SQL-инъекций

Тестирование уязвимостей, которые могут приводить к внедрению команд SQL, должно выполняться в соответствии с данными правилами:

Во время тестирования запрещены любые действия на сервере кроме:

Получения данных о текущей БД (SELECT database()), ее версии (SELECT @@version), текущего пользователя (SELECT user(), SELECT system_user()) или имени хоста (SELECT @@hostname);
Получения схемы БД (SELECT table_schema), списка таблиц в ней (SELECT table_name) и имен столбцов в таблицах (SELECT column_name);
Выполнения математических, конверсионных или логических запросов (включая использование SLEEP) без извлечения данных (кроме тех, что перечислены выше).

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Политика загрузки и чтения файлов

Тестирование уязвимостей, которые могут приводить к чтению произвольных файлов на сервере или произвольной загрузке файлов, должно выполняться в соответствии с данными правилами:

Запрещенные действия при загрузке файлов:

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

При получении возможности чтения произвольных файлов на сервере запрещены любые действия кроме чтения таких файлов, как /etc/passwd и /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini).

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Требования к оформлению отчета

Отчет об уязвимости должен содержать:

* Название уязвимости;
* Название продукта и версию затрагиваемого ПО (компонента);
* Проверку концепции (proof of concept) или подробное описание обнаруженной уязвимости и шагов по ее воспроизведению;
* Описание сценария атаки: кто может использовать уязвимость, для какой выгоды, как она эксплуатируется и т.д.;
* Рекомендации по устранению уязвимости.

Видео и скриншоты могут быть приложены к отчету об ошибке, но не могут его заменить.
Если при исследовании сервисов Минцифры России обнаружено несколько проблем безопасности, необходимо подготовить отчет о каждой выявленной уязвимости отдельно.
Передача информации об обнаруженной уязвимости происходит путем создания отчета (кнопка **Сдать отчет** рядом с названием программы).

ФГИС ДО

Федеральное министерство, которое занимается вопросами ИТ, связи и массовых коммуникаций. В зоне ответственности Минцифры — формирование профильных нормативно-правовых актов и развитие отраслей в интересах граждан, бизнеса и госсектора.

Минцифры России

## Правила для нас

Мы уважаем время и усилия наших исследователей;
Мы отвечаем в течение 5 рабочих дней;
Мы обрабатываем отчеты в течение 10 рабочих дней после ответа;
Мы можем увеличить сроки обработки отчетов, но в таком случае мы проинформируем вас о задержке;
Мы определим сумму вознаграждения в течение 15 рабочих дней после обработки;
Мы сделаем все возможное, чтобы в процессе обработки отчета вы были в курсе нашего прогресса.

## Правила для вас

Будьте этичным хакером и уважайте конфиденциальность других пользователей;
Соблюдайте правила, которые устанавливает Минцифры России в рамках данной программы, а также правила платформы Standoff 365 Bug Bounty;
Все отправляемые запросы по этой программе должны содержать уникальный HTTP заголовок, который доступен на платформе. Для получения заголовка необходимо выполнить вход в свою учетную запись на платформе;
Соблюдайте правила конфиденциальности информации. Запрещено получать доступ к данным другого пользователя без его согласия, изменять и уничтожать их, а также раскрывать любую конфиденциальную информацию, которая была получена случайным образом ходе поиска уязвимостей или их демонстрации. Преднамеренный доступ к этой информации запрещен и может быть признан незаконным;
Избегайте ситуаций, которые могут привести к прерыванию или ухудшению качества наших услуг. Инструменты автоматического сканирования должны быть ограничены 30 запросами в секунду к одному целевому узлу, суммируя все инструменты и потоки, работающие параллельно;
Поддерживайте общение с командой безопасности Минцифры России, направляйте ей отчеты о выявленных уязвимостях, оформленные согласно требованиям, и давайте обратную связь, если у специалистов возникнут вопросы по отчету;
Сообщайте нам обо всех обнаруженных уязвимостях путем создания отчета (кнопка **Сдать отчет** рядом с названием программы);
Участниками программы могут быть только граждане Российской Федерации в возрасте от 18 лет.
Информация, полученная в рамках участия в программе, является конфиденциальной. Её распространение (в том числе публикация) на тематических форумах, в чатах (закрытых чатах), социальных сетях и т.п., используя информационно-телекоммуникационную сеть Интернет, возможно только с письменного разрешения Минцифры России.
Все отправляемые запросы по этой программе должны содержать уникальный HTTP заголовок, который доступен на платформе. Для получения заголовка необходимо выполнить вход в свою учетную запись на платформе;
Исследователи обязаны отправлять отчеты обо всех уязвимостях, обнаруженных в сервисах Минцифры РФ.


## Скоуп

* 109.207.1.155
* 109.207.1.178
* 109.207.8.43
* 109.207.1.71
* kcr.gosuslugi.ru
* frgu3.gosuslugi.ru


В программе участвуют только указанные домены и IP-адреса. Все остальные домены и ресурсы (включая базы данных, почтовые серверы и так далее) в скоуп не входят.

## Вознаграждения за уязвимости

| Уязвимость (по уровню опасности) | Вознаграждение |
| ------------ | ------------ |
| Критический | 200 000 – 500 000 ₽ |
| Высокий | 50 000 – 200 000 ₽ |
| Средний | 30 000 – 50 000 ₽ |
| Низкий | 5 000 – 15 000 ₽ |

## Публичное раскрытие информации об уязвимости

**Публичное раскрытие информации о найденных в рамках программы уязвимостях в данный момент не предусмотрено.**

## Мы не принимаем и не рассматриваем:

*	Отчеты сканеров уязвимостей и других автоматизированных инструментов;
*	Раскрытие информации, не являющейся конфиденциальной, например версии продукта;
*	Раскрытие публичной информации о пользователе, например nickname;
*	Отчеты, основанные на версии продукта/протокола без демонстрации реального наличия уязвимости;
*	Отчеты об отсутствующем механизме защиты/лучшей текущей практике (например отсутствие CSRF-маркера, защита от framing/clickjacking) без демонстрации реального влияния на безопасность пользователя или системы;
*	Сообщения об опубликованных и неопубликованных политиках SPF и DMARC;
*	Кроссайтовые подделки запросов, приводящие к выходу из системы (logout CSRF);
*	Уязвимости партнерских продуктов или сервисов, если пользователи/учетные записи ЕСИА не затронуты напрямую;
*	Безопасность рутированных, jailbreaked или иным образом модифицированных устройств и приложений;
*	Возможность обратного инжиниринга приложения или отсутствие бинарной защиты;
*	Open redirections принимаются только в том случае, если определено влияние на безопасность, например возможность кражи авторизационного токена;
*	Ввод неформатированного текста, звука, изображения, видео в ответ сервера вне пользовательского интерфейса (например, в данных JSON или сообщении об ошибке), если это не приводит к подмене пользовательского интерфейса, изменению поведения пользовательского интерфейса или другим негативным последствиям;
*	Same Site scripting, reflected download и подобные атаки с сомнительным воздействием;
*	Отчеты, связанные с CSP, для доменов без CSP и доменных политик с небезопасными eval и/или небезопасными inline;
*	Гомографические атаки IDN;
*	XSPA (сканирование IP/портов во внешние сети);
*	Инъекция формул Excel CSV;
*	Скриптинг в документах PDF;
*   Self-XSS без демонстрации импакта;
*	Атаки, требующие полного доступа к локальной учетной записи или профилю браузера;
*	Атаки со сценариями, где уязвимость в стороннем сайте или приложении требуется как необходимое условие и не демонстрируется;
*	Теоретические атаки без доказательства возможности использования;
*	Уязвимости отказа в обслуживании (DoS), связанные с отправкой большого количества запросов или данных (флуд);
*	Возможность отправки большого количества сообщений;
*	Возможность отправки спама или файла вредоносного ПО;
*	Раскрытие информации через внешние ссылки, не контролируемые Минцифры России (например, поисковые dork’и к приватным защищенным областям robots.txt);
*	Раскрытие неиспользуемых или должным образом ограниченных ключей JS API (например, ключ API для внешнего картографического сервиса);
*	Возможность выполнить действие, недоступное через пользовательский интерфейс, без выявленных рисков безопасности;
*	Уязвимости раскрывающие только учетные записи пользователей, не содержащие пароля или иных персональных данных.

## Недопустимые действия

Исследователям запрещено:

* Воздействовать на учетные записи других пользователей без их разрешения;
* Использовать обнаруженные уязвимости в личных целях;
* Использовать инструменты тестирования уязвимостей, автоматически генерирующие значительные объемы трафика и приводящие к атакам с исчерпанием ресурсов;
* Проводить атаки, наносящие вред целостности и доступности сервисов (например, DoS-атаки, брутфорс-атаки и т.д.), пытаться эксплуатировать уязвимость, нацеленную на исчерпание ресурсов. Следует сообщить о проблеме команде по безопасности Минцифры России, которая проведет атаку в тестовой среде;
* Проводить физические атаки на персонал, дата-центры и офисы Минцифры России или поставщиков услуг;
* Проводить атаки на системы Минцифры России с использованием техник социальной инженерии (фишинг, вишинг и т.д.) и спам-рассылки клиентам, партнерам и сотрудникам;
* Исследовать серверную инфраструктуру, где размещены веб-приложения;
* Проникать во внутренние системы веб-сервисов и приложений информационных систем Минцифры России, а также иных информационных ресурсов Минцифры России. Программа по поиску уязвимостей в веб-сервисах и приложениях информационных систем Минцифры России должна заканчиваться взломом порталов и закреплением на них, строго без дальнейшего проникновения Исследователем во внутренние системы веб-сервисов и приложений информационных систем Минцифры России;
* Совершать попытки получения доступа к учетным записям, данным пользователей или к любым другим конфиденциальным данным, выходящим за пределы действий, минимально необходимых для демонстрации найденной уязвимости;
* Осуществлять целенаправленную выгрузку персональных данных граждан из внутренних систем веб-сервисов и приложений, а также иных информационных ресурсов, не указанных в программе.

## Политика тестирования RCE

Тестирование уязвимостей, которые могут приводить к удаленному исполнению кода, должно выполняться в соответствии с данными правилами:

Во время тестирования запрещены любые действия на сервере кроме:

Выполнения команд ifconfig (ipconfig), hostname, whoami, id;
Чтения содержимого файлов /etc/passwd и /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini);
Создания пустого файла в каталоге текущего пользователя.

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Политика тестирования SQL-инъекций

Тестирование уязвимостей, которые могут приводить к внедрению команд SQL, должно выполняться в соответствии с данными правилами:

Во время тестирования запрещены любые действия на сервере кроме:

Получения данных о текущей БД (SELECT database()), ее версии (SELECT @@version), текущего пользователя (SELECT user(), SELECT system_user()) или имени хоста (SELECT @@hostname);
Получения схемы БД (SELECT table_schema), списка таблиц в ней (SELECT table_name) и имен столбцов в таблицах (SELECT column_name);
Выполнения математических, конверсионных или логических запросов (включая использование SLEEP) без извлечения данных (кроме тех, что перечислены выше).

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Политика загрузки и чтения файлов

Тестирование уязвимостей, которые могут приводить к чтению произвольных файлов на сервере или произвольной загрузке файлов, должно выполняться в соответствии с данными правилами:

Запрещенные действия при загрузке файлов:

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

При получении возможности чтения произвольных файлов на сервере запрещены любые действия кроме чтения таких файлов, как /etc/passwd и /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini).

При необходимости проведения иных действий необходимо предварительно согласовать их с нашими специалистами безопасности.

## Требования к оформлению отчета

Отчет об уязвимости должен содержать:

* Название уязвимости;
* Название продукта и версию затрагиваемого ПО (компонента);
* Проверку концепции (proof of concept) или подробное описание обнаруженной уязвимости и шагов по ее воспроизведению;
* Описание сценария атаки: кто может использовать уязвимость, для какой выгоды, как она эксплуатируется и т.д.;
* Рекомендации по устранению уязвимости.

Видео и скриншоты могут быть приложены к отчету об ошибке, но не могут его заменить.
Если при исследовании сервисов Минцифры России обнаружено несколько проблем безопасности, необходимо подготовить отчет о каждой выявленной уязвимости отдельно.
Передача информации об обнаруженной уязвимости происходит путем создания отчета (кнопка **Сдать отчет** рядом с названием программы).

ФРГУ

Реестр государственных услуг

Programs