Добро пожаловать в Bug-Bounty Т-Банк!

Оглавление

• Область действия

1. Где искать уязвимости?
2. Какие уязвимости искать?
3. Что не нужно присылать?
4. Что не претендует на вознаграждение?

• Правила участия

1. Общие правила
2. Правила тестирования
3. Политика раскрытия информации об уязвимостях
4. Идентификация трафика
5. Политика тестирования RCE
6. Политика тестирования SQL инъекций
7. Политика загрузки и чтения файлов

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

1. Таблица выплат
2. Определение критичности уязвимости
3. Благотворительность
4. Примечания

• FAQ

1. Как составить хороший отчет?
2. Предоставляются ли учетные данные для тестирования?
3. Как и в какие сроки проверяются отчеты?
4. Как осуществляется работа с дубликатами?

Область действия

Где искать уязвимости?

• Т-Банк
• Т-Инвестиции
• Т-Бизнес
• Т-Мобайл
• Т-ID
• Т-Мессенджер
• Т-Страхование
• Т-Путешествия
• Т-Работа
• Т-Платежи

• Вселенная ассистентов
  Где найти - в веб-версии и в мобильном приложении в чатах, шопинг-ассистент - в приложении Долями, получить доступ - https://ai.tbank.ru/assistants/
• Чат-бот, толк-бот
  Где найти - в чате поддержки или во время звонка в поддержку
• Умная камера
  Где найти - в приложении на главной и в платежах
• T-Fusion
  Где найти - Бот для Т-Образования
• VoiceKit
  Где найти - в звонках (колл-центр, секретарь)

Какие уязвимости искать?

• Удаленное исполнение кода (RCE);
• Инъекции (например, SQL-инъекции или XML-инъекции);
• LFR/LFI/RFI;
• SSRF;
• Утечки памяти;
• Уязвимости бизнес-логики;
• IDOR;
• Уязвимости контроля доступа;
• Раскрытие чувствительной информации;
• Угон аккаунта;
• Недостатки аутентификации/авторизации;
• XSS и CSRF с воздействием на чувствительные данные;
• Prompt Injection;
• Insecure Output Handling;
• Model Denial of Service;
• Input Manipulation Attack.

Что не нужно присылать?

• Сообщения об уязвимостях в сервисах, не относящихся к экосистеме Т-Банка;
• Сообщения о мошеннических схемах, злоупотреблении легитимным функционалом (такие сообщения рекомендуем присылать в чат поддержки, вознаграждение за подобные репорты в рамках баг-баунти не полагается);
• Проблемы, никак не связанные с безопасностью;
• Сообщения о возможных DDOS-атаках;
• Информацию об IP-адресах, DNS-записях и открытых портах;
• Сообщения о применении фишинга и других техник социальной инженерии;
• Отчеты сканеров уязвимостей и других автоматизированных средств;
• Сообщения о публично доступных панелях входа;
• Clickjacking;
• Разглашение публичной информации о пользователях;
• Сообщения о недостатках использования 4-х символьных смс-кодов;
• Сообщения о неправильной реализации округлений на конверсионных переводах между расчетными, накопительными и брокерскими счетами (на такие транзакции установлены лимиты);
• Обход проверки на root и jailbreak;
• Сообщения о возможности обратной разработки мобильный приложений;
• Сообщения о фактически некорректных ответах со стороны AI продуктов.

Что не претендует на вознаграждение?

• Self-XSS, XSS в непопулярных или устаревших браузерах, Flash-based XSS;
• CSRF и XSS без воздействия на чувствительные данные;
• Отсутствие рекомендованных механизмов защиты* (например, HTTP заголовков безопасности, флагов безопасности cookie или защиты от CSRF);
• Ошибки в настройке CORS*;
• Использование устаревшего или потенциально уязвимого стороннего ПО*;
• Атаки, связанные с мошенничеством или кражей;
• Возможность неограниченной отправки СМС и email;
• Атаки типа DOS*;
• Небезопасно сконфигурированные TLS или SSL*;
• Разглашение информации о существовании в системе данного имени пользователя, email или номера телефона;
• Full Path Disclosure;
• Разглашение технической или нечувствительной информации* (например, версии продукта или используемого ПО, stacktrace);
• Open Redirect без дополнительного вектора атаки (например, кражи токена авторизации);
• Подмена контента на странице;
• Tabnabbing;
• Уязвимости, требующие выполнения сложного или маловероятного сценария взаимодействия с пользователем;
• Уязвимости, необходимым условием эксплуатации которых является наличие вредоносного ПО, root-прав или jailbreak на устройстве;
• Атаки, требующие MITM чужого соединения или физической близости с чужим устройством (например, атаки через NFC, Bluetooth, Wi-Fi и shoulder surfing);
• Маловероятные или теоретические атаки без доказательств возможности их осуществления

Правила участия

Общие правила

• Область действия bug-bounty программы ограничивается техническими уязвимостями в сервисах компании. Если вы столкнулись с проблемами, которые никак не связаны с безопасностью, обратитесь в службу поддержки клиентов.
• При обнаружении 0-day или 1-day уязвимости, официальный патч которой был менее недели назад, выплата награды осуществляется на усмотрение команды безопасности Т-Банка и рассматривается в каждом конкретном случае.

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

• Для проведения тестирования используйте только свои собственные учетные записи либо учетные записи пользователей, который явно выразили свое согласие. Не пытайтесь получить доступ к чужим аккаунтам или любой конфиденциальной информации.
• Во время поиска уязвимостей следует избегать нарушения конфиденциальности, целостности и доступности информации в наших сервисах.
• Запрещена любая деятельность, которая может нанести ущерб приложениям компании, ее инфраструктуре, клиентам и партнерам. Примеры запрещенных действий: социальная инженерия, фишинг, атаки типа "Отказ в обслуживании", физическое воздействие на инфраструктуру.
• Для подтверждения наличия уязвимости используйте минимально возможный POC (Proof of Concept). В случае, если это может повлиять на других пользователей или же работоспособность системы, свяжитесь с нами для получения разрешения. Дальнейшая эксплуатация уязвимостей строго запрещена.
• Автоматическое сканирование должно быть ограничено 5 запросами в секунду.

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

• Запрещено раскрывать уязвимости или делиться какими-либо подробностями без письменного разрешения команды безопасности Т-Банка.
• Мы оставляем за собой право отклонить любой запрос на публичное раскрытие отчета.

Идентификация трафика

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

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

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

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

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

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

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

Таблица выплат

Определение критичности уязвимости

• Уровень привилегий, необходимый для реализации атаки;
• Трудность обнаружения и эксплуатации;
• Наличие требования взаимодействия с пользователем;
• Влияние на целостность, доступность и конфиденциальность затронутых данных;
• Влияние на бизнес-риски и репутационные риски;
• Количество затронутых пользователей.

Благотворительность

Примечания

• Почта для связи: bug-hunters@tinkoff.ru.
• Вознаграждение выплачивается только в случае, если команда безопасности Т-Банка посчитает, что все условия правил выполнены и выявленная уязвимость является значимой.
• Размер выплаченной награды является окончательным и не подлежит обсуждению.

FAQ

Как составить хороший отчет?

• Описание уязвимости;
• Шаги воспроизведения;
• Анализ критичности;
• Рекомендации по устранению.

• URL уязвимого приложения;
• Тип обнаруженной уязвимости;
• Скриншоты или видеозапись, подтверждающие наличие уязвимости и демонстрирующие шаги воспроизведения;
• Пример форматированного запроса из BurpSuite (или любой другой POC);
• В некоторых случаях куски кода.

Предоставляются ли учетные данные для тестирования?

Как и в какие сроки проверяются отчеты?

Как осуществляется работа с дубликатами?