Привет! Я Максим Бондарев, руковожу группой исследования уязвимостей операционных систем и программных комплексов в Positive Technologies.
Как выглядит реалистичная банковская среда для тренировок по кибербезопасности? На полигоне Standoff мы развернули инфраструктуру с платежным хабом и адаптером для подключения к системе быстрых платежей, которые были предоставлены компанией eKassir. Участники отрабатывают реализацию критических событий — от кражи базы платежей до подмены плательщика — с настоящим банковским ПО.
В статье мы детально разберем архитектуру киберполигона и реальные уязвимости, заложенные в систему. Расск��жу об устройстве STF Bank, о том, как мы воспроизводим банковскую среду с использованием реального вендорского программного обеспечения. Основное внимание уделим интеграции с системой быстрых платежей и моделированию критических событий.
Киберполигоны позволяют безопасно отрабатывать действия по обнаружению и отражению атак. Чтобы максимально приблизиться к реальности, требуется создать сложную инфраструктуру. Особый интерес для нас представляет банковский сектор из-за его критической важности и высоких рисков.
Критические события: кража базы данных Merchant Portal и подмена плательщика
Одним из критических событий была кража базы данных портала мерчанта — внешнего компонента решения eKassir «Адаптер для СБП». В нем хранятся данные об операциях через QR-коды СБП для всех клиентов банка с услугой эквайринга. Атака привела бы к серьезным финансовым и репутационным издержкам. На полигоне пентестеры получают уникальную возможность нажать красную кнопку — провести эту сложную атаку от начала до конца.
Другой смоделированный сценарий — оплата по QR-коду со счета другого клиента. Мы преднамеренно внедрили уязвимость в механизм списания средств. Она позволяла подменить счет плательщика на этапе проведения транзакции.
Инфраструктура — от вендорского ядра до магазинов и приложения
Готовое вендорское решение не работает изолированно: необходима офисная инфраструктура* и базовая платежная функциональность.
* Под инфраструктурой скрываются виндовый домен, пользовательские т��чки, серверы для приложений, сервер с MSSQL, пользовательские машины с Operation Studio (продукт для работы с платежной системой) и все остальное, что не описано в мануале по установке, так как подразумевается, что оно точно есть в любом банке.
Чтобы запустить ядро платежной системы на eKassir Operation Server, мы развернули доменную инфраструктуру Windows. В нее вошли Active Directory и центр сертификации для выпуска доверенных сертификатов, обеспечивающих подпись данных при передаче между компонентами.
Мы также cэмулировали работу персонала. Для операторов, управляющих платежными потоками и выполняющих функции поддержки, был создан пользовательский сегмент. Админский сегмент предоставил доступ к пользовательским рабочим станциям и серверной части.
Архитектуру полигона для эквайринга СБП можно разделить на три ключевых компонента:
Взаимодействие банка с платежными сервисами, включая серверы СБП.
Эквайринг для интернет-магазинов: генерация QR-кодов и подтверждение оплаты.
Клиентская часть для работы с QR-кодами: их считывание и списание средств.
Вендоры обычно поставляют только первый компонент. Банки самостоятельно разрабатывают или дорабатывают остальные элементы цепочки. Нам предстояло реализовать всю инфраструктуру с нуля.
Помимо доменной среды, мы развернули четыре интернет-магазина на WordPress. Они торговали цифровыми товарами. Каждый магазин имел уникальную специфику и преднамеренно внедренные уязвимости. К примеру, в Dream Fashion Shop присутствовала уязвимость LFI. Это позволяло атакующим изучить исходный код плагина для интеграции с банковским эквайрингом. После оформления заказа плагин запрашивает у банка создание платежа и получает QR-код для оплаты.
Для оплаты покупатель использовал наше мобильное приложение для Android, разработанное на React Native. Со стороны клиента приложение отправляло запрос к API процессинга, а бэкенд выполнял базовые проверки, например определял достаточность средств на счете. После успешных проверок запрос на оплату передавался в eKassir Operation Server.
Взаимодействие с сервером вендора происходило по стандартному протоколу eKassir V3, используемому для связи терминалов и касс с платежным ядром.
Подключение к реальным серверам НСПК было невозможно, поэтому мы заменили эту часть цепочки заглушками с поддержкой настоящих протоколов СБП. Необязательную функциональность вроде возвратов мы опустили, но в результате вендорское ПО работало так, словно взаимодействовало с продуктивной средой.
Мы изучили документацию и обнаружили, что модули вендора используют для взаимодействия очереди NATS. Мы подключили магазины напрямую к этим очередям — потребовалось вывести их из защищенного платежного сегмента. В реальном банке такая ошибка архитектуры недопустима, но на полигоне она идеально моделирует последствия человеческого фактора.
Лазейка для красной команды — ошибка в настройке очередей NATS. Следующий шаг — проверка со стороны магазина: была ли проведена оплата конкретного заказа по QR-коду. В реальных условиях вендор использует коллбэки для уведомления магазина через заданный эндпойнт, однако наш сценарий ограничивал эту функциональность.
Обработчик очереди реализован простым микросервисом. Его код приведен ниже.
export default class Shops {
constructor() {
this.shops = [
{
"url": "http://dream-fashion.shop.stf/?wc-api=sbp_qr",
"key": "86LBz7DU3pHlVkxhF"
},
{
"url": "http://fashion-glory.shop.stf/?wc-api=sbp_qr",
"key": "9D1ki91oIq9X6rl2LMXim"
},
{
"url": "http://quality-goods.shop.stf/?wc-api=sbp_qr",
"key": "42E3dMofPhyRa34bgrezyir6VtG48t0"
},
{
"url": "http://quality-retail.shop.stf/?wc-api=sbp_qr",
"key": "09E17rthhLJNQwjKFsdy542"
},
]
}
reportShops(qr) {
this.shops.forEach(el => axios.get(`${el.url}&id=${qr}&key=${el.key}`).catch(err => {}));
}
}Микросервис получает из очереди идентификатор оплаченного QR-кода. Затем он оповещает все мага��ины, отправляя запросы на вебхуки нашего WordPress-плагина. Плагин проверяет наличие заказа с таким кодом. Если все в порядке — помечает заказ как оплаченный и предоставляет клиенту ссылку для скачивания товара.
Заключение
В результате проделанной работы мы воспроизвели на полигоне бизнес-процесс эквайринга для интернет-магазинов, максимально приблизив его к реальности. Наша инфраструктура включает вендорское ядро eKassir, самописные компоненты и реалистичные сценарии атак. Это позволяет отрабатывать киберучения в условиях, адекватных таковым в настоящем банковском секторе.
За время эксплуатации полигона было накоплено множество подобных практических кейсов. Мы планируем и дальше делиться этим опытом в следующих статьях, подробно разбирая сценарии и архитектурные решения.
Для участия в проекте eKassir предоставил нам Payments Hub (платежный хаб) и «Адаптер для СБП». Вендор ежегодно передает свое ПО на киберполигон Standoff, чтобы изучить обратную связь от специалистов по информационной безопасности и участников атакующих команд. Полученные результаты используются для доработки и повышения надежности продуктов, которые применяются в промышленной эксплуатации банками и безопасность которых является критически важной.
