Светозар Яхонтов

Директор по развитию бизнеса ООО «Протекшен Технолоджи»

Исходя из нашей практики, около половины проектов по защите программного обеспечения на устройствах банковского самообслуживания запускаются после взлома. За последние два года на территории Российской Федерации произошло более 30 инцидентов, в основном, атак типа «прямой диспенс» на банкоматы в двух десятках банков. Ряд банков подвергся повторяющейся серии атак, так как не хватило ресурсов оперативно реализовать контрмеры на территориально распределенной сети устройств.

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

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

По моему мнению подобная ситуация стала возможной в следствие:

• Безучастности служб, ответственных за меры технической защиты и реакции на инциденты в вопросах эксплуатации сети устройств самообслуживания. Возможно, это происходит из-за того, что во многих, чаще, крупных банках инфраструктура дистанционных каналов обслуживания не входит в область контроля служб информационной безопасности. Так сложилось исторически в период бурной экспансии каналов дистанционного обслуживания.
• Использования на устройствах, не поддерживаемых и не обновляемых версий операционных систем и прикладного ПО, что делает программную среду банкомата уязвимой – недавние примеры WannaCry и Petya.

При этом многие, чаще, крупные банки имели возможность уделить внимание вопросам защищенности программного обеспечения банкоматов. Есть примеры банков, которые можно считать «лучшей практикой» по мировым меркам. Но есть и обратное – среди банков, в разное время начинавших внедрение специализированных средств программной защиты, можно найти примеры незавершенных проектов. Несмотря на достаточное финансирование проектов и доступность ресурсов для развертывания и администрирования, банки не смогли преодолеть весьма распространенные стоп-факторы. Дьявол, как известно, кроется в мелочах.

Специализированные средства программной защиты для банкоматов реализованы на технологиях белых списков. Зловреды для атаки на банкоматы пишут на заказ, к антивирусным аналитикам они не попадают, средства защиты, созданные по «черным спискам» для защиты ПО, для банкоматов неэффективны.

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

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

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

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

Если инженер попытается запустить новое ПО на банкомате с функционирующей защитой по белым списком, то результаты предсказуемо будут следующими:

• Либо старт инсталлятора будет заблокирован т.к. контрольной суммы данного инсталлятора нет в правилах;
• Либо после внесения изменений будут блокированы последующие попытки старта измененных исполняемых файлов.

Оба варианта нежелательны для службы эксплуатации.

И тогда инженер отключает защиту на устройстве. Вносит изменение в ПО. И… покидает банкомат. Для внесения изменений в правила контроля (белые списки процессов) требуется определенные знания как в части эксплуатации средства защиты, так и детальное понимание какие именно изменения были внесены.

Свою работу он выполнил, вопросы защищенности ПО на банкомате не в его зоне ответственности.

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

Уже спустя квартал существенная часть банкоматов сети остается либо с отключенной защитой, либо, после включения защиты, неработоспособной. Учесть внесенные изменения спустя столь долгий срок не представляется возможным. Аварийное восстановление работоспособности банкомата является весьма затратным мероприятием. И после повторения ситуации один-два раза принимается решение по прекращению эксплуатации средства защиты вовсе. Доступность сети с точки зрения бизнеса приоритетно.

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

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

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

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

Здесь остановлюсь подробнее с примерами

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

По нашей статистике около 80% банков в России использует в качестве средства удаленного администрирования ПО на устройствах RAdmin. Сам функционал и доступные привилегии данного средства администрирования является брешью в защите без реализации дополнительных мер контроля (ограничения системных привилегий обеспечивающих процессов, ограничение сценариев запуска, ограничение сетевой активности процессов и т.д.). При этом клиентская часть данного средства администрирования распространяется с использованием скриптов, содержащих в незамаскированном виде пароль и порты, и не удаляется из файловой системы после развертывания.

Подобное стало возможным вследствие отсутствия внутреннего контроля за использованием ПО на устройствах самообслуживания.

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

В качестве примера последствий отсутствия такой позиции банка поделюсь наблюдением.

В четырех банках-операторах банкоматов NCR в состав ПО банкоматов входят утилиты NIRCMD.exe и PSKILL.exe. При этом данные файлы определяются антивирусными сканерами как вирусы. Анализ файлов показал:

• Версия NIRCMD.exe 1.85 датируется 2006 годом. Компания NIRSOFT не подтвердила авторство данного файла. Все современные версии NIRCMD.exe на сайте производителя (актуальная версия датируется 2017 годом) не определяются антивирусными сканерами как угрозы.
• Версия PSKILL.exe датируется концом 2006 года и не имеет сертификата издателя. Все версии PSKILL.exe начиная с середины 2006 года имеют сертификат Microsoft Root и не определяются антивирусными сканерами как угрозы.

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

До сих пор происхождение данных файлов на устройствах остается невыясненным.

Наиболее продвинутые практики реализации режима безопасной эксплуатации ПО на устройствах самообслуживания мы наблюдаем в отдельных операторах крупных сетей устройств в странах Юго-Восточной Азии. Высокие темпы проникновения как традиционных, так и новых банковских услуг в регионе, высокая степень детерминации услуг для разных категорий клиентов требуют весьма оперативно и регулярно вносить обновления, выводящие на рынок новые банковские продукты. Использование традиционного подхода с навесными средствами программной защиты не обеспечивают требуемые темпы распространения обновления в защищенном режиме. Технические меры защиты реализуются на этапе разработки самих платежных приложений:

• Самозащита собственных компонентов платежных приложений от попыток несанкционированной модификации.
• Механизмы безопасного внесения изменений в ПО.
• Средства мониторинга активности процессов.

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