Почему традиционная защита от кражи денежных средств в системах ДБО уязвима
Статья Николая Афанасьева, менеджера по развитию продуктов компании "Аладдин Р.Д."
Банковские электронные сервисы напрямую или опосредованно оперируют деньгами. А там, где есть деньги, всегда найдутся те, кто захочет их украсть. Особый интерес у киберпреступников вызывают системы дистанционного банковского обслуживания для юридических лиц, так как на счетах последних аккумулируются значительные суммы денежных средств.
Для защиты от кражи денежных средств в таких системах, как правило, требуется решить следующие основные задачи: проверить подлинность пользователя, а также подлинность и целостность электронного документа, выражающего намерение пользователя. На практике, таким документом является платёжное поручение, в числе реквизитов которого задаются сумма денежных средств и счёт получателя.
Эти задачи традиционно решаются с использованием средств строгой двухфакторной аутентификации и электронной подписи, выполненных в виде USB-токенов или смарт-карт (далее – токены).
Токены, имеющиеся на нашем рынке, условно можно разделить на 2 типа.
- Хранят закрытый ключ в контейнере, доступ к которому для прикладного ПО предоставляется при предъявлении PIN-кода. Подпись при этом формируется программным СКЗИ в оперативной памяти ПК. Закрытый ключ при формировании подписи покидает токен, т.е. является извлекаемым.
- Самостоятельно генерируют ключевую пару (закрытый/открытый ключ). Подпись формируется “на борту” токена, в токен для этого передается хеш документа. Закрытый ключ никогда не покидает токен, т.е. является неизвлекаемым.
При использовании токена первого типа кража ключа может быть реализована как минимум двумя способами.
- Вредоносное ПО перехватывает PIN-код для токена при его вводе на клавиатуре ПК, затем с помощью этого PIN-кода расшифровывает содержимое контейнера на токене, получая таким образом доступ к самому закрытому ключу.
- Вредоносное ПО внедряется в код программы и перехватывает закрытый ключ в оперативной памяти ПК в ходе выполнения операции, требующей его использования (например, при формировании ЭП).
После того, как ключ оказался “в руках” киберпреступника, последний получает возможность подписывать любые поддельные документы на этом ключе. Кража денежных средств в этом случае может быть реализована путём навязывания банковскому сервису подписанных на ключе легального клиента банка поддельных платёжных поручений, в которых в качестве счёта получателя денежных средств указан счёт киберпреступника или связанных с ним лиц. Особую опасность при взломе контейнера представляет возможность бесконтрольного тиражирования закрытого ключа. Подписывать транзакции с его помощью становится возможно с любого компьютера.
При использовании токена второго типа, с неизвлекаемым ключом электронной подписи, такой токен надёжно защищает ключ от кражи. Однако киберпреступники с помощью вредоносного ПО, сделанного с учётом специфики работы атакуемой системы, научились подписывать поддельные документы без кражи ключей.
- Атаки с подменой подписываемого документа. Пользователь видит на экране ПК одно платёжное поручение, а в момент его подписания вредоносное ПО незаметно подменяет в нём реквизиты получателя и сумму. В токен для вычисления ЭП отправляется хеш подменённого документа. В результате деньги со счёта клиента банка “уходят” на счёт киберпреступника. Более того, вредоносное ПО после этого способно подменять отображаемые клиенту банка остатки на счетах. В результате пользователь может долго не подозревать о совершённой краже. Такие атаки могут быть реализованы различными способами.
- Перехват трафика по протоколу USB-CCID.
- Внедрение в код банковского приложения или браузера. Шифрованный канал, который может быть установлен между банковским приложением и токеном, в этом случае не помогает.
- Атаки с подписью посторонних поддельных документов. Получив удалённое управление, или, внедрив вредоносное ПО на компьютер клиента банка, киберпреступник может подписывать любые посторонние (в том числе платёжные) документы на его ключах в период, когда токен подключен к ПК. Такие атаки могут быть реализованы следующими способами:
- использование состояния “залогиненности”, когда токен подключен к ПК и пользователь ввёл PIN-код. В этот момент вредоносное ПО отправляет в токен хеш постороннего документа и вычисляет ЭП;
- перехватив заранее PIN-код с помощью вредоносного ПО, киберпреступник может сам “залогиниться” на токене и подписать на нём посторонний документ. Виртуальные клавиатуры не дают гарантию защиты от перехвата PIN-кода.
Можно снизить риски подобных атак путём чёткого следования политикам безопасности:
- пользоваться легальным сертифицированным ПО;
- своевременно устанавливать обновления;
- установить и правильно настроить межсетевой экран;
- использовать способный бороться с руткитами антивирус со свежей обновлённой базой;
- установить и настроить модуль доверенной загрузки и контроля целостности среды.
Такой подход мог бы быть оправдан в закрытой корпоративной среде, контролируемой администраторами безопасности. Однако на массовом рынке пользователи вряд ли будут следовать всем этим правилам. Это дорого и требует наличия специальных знаний и навыков. Более того, даже выполнение всех этих правил всё равно не может дать гарантии защиты от атак киберпреступников.
Необходимость дополнительной защиты от мошенников известна и банкам, и регулятору. Данная проблема является достаточно актуальной. В частности, по информации «КоммерсантЪ» от 14 июля 2016 г. Минфин и ЦБ подготовили новые поправки по защите клиентов банков от несанкционированных операций. Поправки предлагают наделить банки правом приостанавливать транзакции, если есть подозрение, что операция совершается без согласия клиента, несмотря на правильно введённый PIN-код и использование реальной электронной подписи. Т.е. масштаб бедствия таков, что законодатель явно допускает фрод и готовит рекомендации по противодействию ему.
Что реально используется сегодня для защиты от кражи денежных средств
Для защиты от кражи денежных средств в системах ДБО банки внедряют дополнительные меры.
- Серверные антифрод-системы, позволяющие выявлять подозрительные транзакции по тем или иным признакам.
- Trust Screen-устройства на клиентской стороне, позволяющие подтверждать ключевые реквизиты платёжных документов в доверенной среде таких устройств.
Серверные антифрод-системы
Серверные антифрод-системы, использующие те или иные математические модели, в том числе технологии машинного обучения, с учётом накопления данных позволяют со временем снижать вероятность возникновения ошибок первого (ложная тревога) и второго (пропуск реальной атаки) родов, что положительно сказывается на их эффективности. Плюсом таких антифрод-систем с точки зрения пользователей интернет-банкинга является то, что такие системы, как правило, не изменяют обычный для пользователя порядок вещей. Пользователь как работал с системой, так и продолжает работать, от него не требуется выполнять дополнительные действия. В случае выявления подозрительных транзакций на его денежном счету с ним связываются и запрашивают подтверждение. Тем не менее, риск пропуска атак сохраняется, так как киберпреступники придумывают всё более изощрённые способы атак. Более того, при целевой атаке, даже если антифрод-система выявит подозрительную транзакцию, киберпреступник может заранее узнать номер телефона клиента, на который будет звонить банк для подтверждения транзакции, и перенаправить вызов на свой телефон. О том, что перенаправление звонков вполне возможно и не является чем-то фантастическим, писалось тут. Если речь идёт о крупных суммах денежных средств, то такая атака становится вполне оправданной с точки зрения затрат.
Справедливости ради стоит отметить, что на рынке появляются решения, способные дополнительно идентифицировать людей по голосу. Более распространённый вариант названия этой технологии содержит в себе слово “идентификация”, а не “аутентификация”, на что намекает даже Google:
Идентификация, как правило, используется для представления своего идентификатора, а аутентификация – для доказательства, что субъект является тем, за кого себя выдаёт.
Голосовая идентификация не даёт гарантии того, что на том конце клиент банка. Существуют технологии и даже готовые решения для клонирования голоса. И вполне возможно, что киберпреступники уже умеют или в ближайшем будущем научатся подделывать голос “жертвы” так, чтобы успешно обманывать системы распознавания. Вместе с тем, распознавание голоса является ещё одним эшелоном, который позволяет снизить риск кражи денежных средств.
Trust Screen-устройства
Trust Screen-устройство, как правило, обладает небольшими размерами, снабжено экраном и (опционально) кнопками. Оно используется на клиентской стороне, его основная задача – дать пользователю возможность подтвердить (или отклонить) транзакцию в доверенной среде, отличной от среды компьютера, в котором создаются платёжные документы. Классический сценарий использования Trust Screen-устройства выглядит так:
- Пользователь на компьютере подготавливает платёжное поручение с указанием реквизитов получателя и даёт банковскому приложению команду подписать платёжный документ и отправить его на исполнение.
- Банковское приложение отображает платёжный документ на экране ПК и дополнительно просит подтвердить его ключевые реквизиты на Trust Screen-устройстве.
- Пользователь смотрит на экран Trust Screen-устройства и подтверждает операцию специальной кнопкой на клавиатуре или на сенсорном экране.
- В случае подтверждения платёжный документ подписывается с помощью используемого средства ЭП, и подпись отправляется на сервер.
Плюсом использования таких устройств является то, что при их корректной реализации и правильной интеграции в прикладное ПО существенно снижается риск кражи денежных средств.
Слабым звеном при корректной реализации остаётся пользователь. Возможность кражи денежных средств в этом случае определяется тем, насколько ответственно пользователь сверяет реквизиты на Trust Screen-устройстве. Если при интенсивной работе заставлять его ежедневно подтверждать сотни документов, пользователь может начать делать это машинально, не уделяя достаточного внимания тому, что именно выводится на экран устройства. В связи с этим сценарий интеграции таких устройств в банковские системы должен уделять особое внимание удобству их использования.
К счастью, есть хороший способ существенно снизить количество документов, которые потребуется подтверждать на Trust Screen-устройстве без ущерба для безопасности. Решение – использовать “белые списки” доверенных контрагентов. В такой список включаются те контрагенты, с которыми пользователь работает регулярно и которым доверяет. Чем больше доля таких контрагентов, тем меньше транзакций требуется дополнительно подтверждать. Если из 100 транзакций около 90 будут исходить в адрес доверенных контрагентов, то пользователю потребуется подтвердить только 10 из 100.
Многие банки уже давно практикуют использование таких списков и без использования Trust Screen-устройств для повышения доверия к транзакциям. В некоторых случаях такие списки банки создают сами для каждого клиента на основании истории его взаимодействия с контрагентами. В других случаях банки предоставляют пользователям возможность самим формировать такие списки.
Важным при работе с “белыми списками” является то, каким образом этот список создаётся и изменяется. Если киберпреступник сможет несанкционированно добавить себя в “белый список”, вся идея таких списков становится ничтожной. Например, если “белый список” подготавливается пользователем в недоверенной среде, то к такому списку не может быть доверия.
Антифрод-терминал
Некоторое время назад мы вывели на рынок Trust Screen-устройство Антифрод-терминал. Данный продукт разрабатывался нами совместно с компанией VASCO, был основан на хорошо зарекомендовавшем себя устройстве DIGIPASS 920, которое было продано по всему миру в количестве более миллиона штук. Именно поэтому Антифрод-терминал так похож на него внешне.
Особенность Антифрод-терминала заключается в том, что устройство:
- Ведёт внутренний журнал операций. В этом журнале фиксируется информация, которая была отображена на экране устройства и подтверждена пользователем путём нажатия кнопки “ОК” на клавиатуре устройства.
- Содержит собственный криптографический чип, в котором реализована российская криптография.
- Подписывает журнал операций собственной ЭП на этом чипе.
Журнал операций не хранится в устройстве постоянно. Антифрод-терминал начинает вести журнал каждый раз заново при начале т.н. SWYX-режима работы устройства. SWYX означает Sign What You eXecuted – подписываю то, что выполняется. По окончании SWYX-режима терминал подписывает журнал собственной ЭП и возвращает его вместе с подписью в прикладное ПО. Для управления SWYX-режимом есть специальные команды, которые прикладное ПО отправляет на терминал.
Перед выдачей клиенту Антифрод-терминал регистрируется в учётной системе банка с привязкой к его открытому ключу. Соответствующий закрытый ключ терминала является неизвлекаемым и хранится на встроенном в терминал криптографическом чипе.
После подписания документа и подтверждения его ключевых реквизитов на Антифрод-терминале клиентское прикладное ПО отправляет на сервер не только подписанный документ, но и подписанный журнал операций. Сервер проверяет подпись документа и подпись журнала. Проверка подписи журнала позволяет убедиться в том, что пользователь работает с доверенным, зарегистрированным терминалом и защищает от подделки устройства на клиентской стороне. После аутентификации терминала сервер сверяет реквизиты из подписанного документа с реквизитами, подтверждёнными пользователем на Антифрод-терминале (из подписанного терминалом журнала), и при их совпадении принимает документ на исполнение.
Журнал операций сохраняется на сервере банка для возможности разбора конфликтных ситуаций и расследования инцидентов.
Наличие такого журнала является также дополнительной мотивацией для клиентов более внимательно относиться к процедуре подтверждения, так как журнал впоследствии может быть использован банком в качестве доказательной базы.
Для защиты от “лени клиентов” в Антифрод-терминале реализован дополнительный контроль того, что пользователь ознакомился со всеми данными, которые были отображены на экране терминала. Если данные не вместились на один экран, то терминал не позволит подтвердить операцию до тех пор, пока пользователь не прокрутит их до конца. Это также важно и с точки зрения доказательной базы, так как такая реализация позволяет при необходимости доказать, что пользователь собственноручно прокрутил все данные до конца, проверив все реквизиты, и подтвердил операцию, ознакомившись со всеми реквизитами.
Защита от повторной отправки журнала операций в банк
Журнал операций Антифрод-терминала содержит специальное поле Reference, предназначенное для хранения идентификатора платёжного документа. При создании и сохранении платёжного документа сервер присваивает ему идентификатор. При подтверждении реквизитов этого документа на Антифрод-терминале прикладное ПО на клиентской стороне вызывает команду, в составе параметров которой содержится этот идентификатор. Терминал вместе с данными, которые клиент подтвердил на устройстве, записывает в журнал в поле Reference этот идентификатор. Сервер при проверке журнала дополнительно проверяет соответствие идентификатора платёжного документа на сервере идентификатору из поля Reference журнала.
Такая реализация позволяет защититься от перехвата журнала и попыток его повторного навязывания вместе с копиями уже однажды одобренных документов. Такое навязывание могло бы привести к опустошению счета. Но идентификатор надёжно привязывает журнал к конкретному экземпляру платёжного документа.
Новая версия Антифрод-терминала поддерживает любые типы средств ЭП
Первая версия Антифрод-терминала в качестве средства ЭП умела работать только со смарт-картами, которые подключались непосредственно к устройству. Однако на российском рынке за много лет накопилось достаточно большая инсталляционная база средств ЭП, выполненных в виде программных СКЗИ и/или USB-токенов. А переход на новые типы средств ЭП требует времени и дополнительных затрат как для банков, так и для конечных клиентов.
В связи с этим нами была разработана новая версия Антифрод-терминала, которая не накладывает никаких ограничений на тип используемого средства ЭП. Это может быть и программное СКЗИ, хранящее ключ в реестре или на обычной флешке, и программное СКЗИ, хранящее ключ ЭП на отчуждаемом USB-токене, и USB-токен с неизвлекаемым ключом ЭП, и смарт-карта ISO 7816.
Как нам удалось достичь этого? Архитектура Антифрод-терминала позволила полностью отделить функцию подписания документа от функции подтверждения на Антифрод-терминале. Работа со средством ЭП осуществляется как бы независимо от Антифрод-терминала. Средство ЭП ничего не знает о наличии Антифрод-терминала, а Антифрод-терминал ничего не знает о типе используемого средства ЭП, ему это и не нужно.
Если в качестве средства ЭП используется USB-токен, то он подключается в один USB-порт ПК, а Антифрод-терминал – в другой. Прикладное ПО работает с USB-токеном как со средством ЭП, а с Антифрод-терминалом – как со средством доверенного подтверждения ключевых реквизитов документа.
Выполнение групповых операций
Для сокращения документов, которые нужно подтверждать на терминале, следует использовать “белые списки” доверенных контрагентов.
Важно то, что Антифрод-терминал позволяет безопасно создавать и изменять такие списки. Для этого достаточно все операции, связанные с изменением “белого списка”, в том числе его создание, подтверждать на Антифрод-терминале. Это защищает от несанкционированного внесения изменений в “белый список” киберпреступниками.
При выполнении групповой операции достаточно подтвердить сводное платёжное поручение в адрес всех контрагентов, попавших в “белый список”, и каждое поручение в адрес контрагентов, не попавших в “белый список”.
Сводное платёжное поручение может содержать:
- общую сумму платежа в адрес получателей из “белого списка”;
- число таких получателей или их список.
Подтверждение такого сводного платёжного поручения позволяет защититься от атак, направленных на опустошение счёта компании в пользу доверенных контрагентов (например, в налоговую).
Клиент подписывает и подтверждает на терминале каждое из оставшихся платёжных поручений.
Подписание произвольных документов
Антифрод-терминал позволяет отображать на своем экране любые текстовые данные длиной до 400 символов.
Это позволяет подтверждать не только платёжные документы, но и операции подписания произвольных неструктурированных документов. Для таких документов следует отображать на Антифрод-терминале ключевые данные таких документов, которыми могут быть, например, существенные условия договоров, соглашений. Например:
Благодаря тому, что операция подписания логически отделена от операции подтверждения сохраняется возможность подписывать реальный документ, а не некую структуру, которая включает в себя этот документ или хеш от этого документа. Это позволяет пользователям после подписания документа в личном кабинете видеть реальный подписанный документ и отдельно подпись от этого реального документа.
Преимущества от совместного использования серверных антифрод-систем и Антифрод-терминала
При рассмотрении серверных антифрод-систем было отмечено, что в случае обнаружения подозрительных транзакций, совершённых с использованием, например, простой электронной подписи, возникает необходимость связаться с клиентом, чтобы он подтвердил или отклонил операцию. Как мы уже говорили, звонок клиенту по телефону не гарантирует, что операцию подтвердит сам клиент, так как киберпреступник может перенаправить вызов на свой телефон и даже попробовать склонировать голос клиента.
Описанную проблему доверенного подтверждения подозрительных транзакций может успешно решить Антифрод-терминал. Достаточно уведомить клиента о необходимости подтвердить операцию и запросить это подтверждение через Антифрод-терминал.
Особенность интеграции Антифрод-терминала в прикладное ПО
При интеграции терминала в прикладное ПО доработки выполняются на клиентской и на серверной сторонах.
Особенность интеграции заключается в том, что доработки не изменяют текущую реализацию подписания платёжных документов, а дополняют её.
Перед обычным подписанием документа прикладная программа дополнительно:
- формирует текстовую строку (до 400 символов), содержащую ключевые реквизиты документа;
- отправляет эту текстовую строку на Антифрод-терминал и получает подтверждение/отклонение пользователя.
После обычного подписания документа прикладная программа дополнительно:
- запрашивает у Антифрод-терминала журнал операций;
- отправляет журнал операций вместе с подписанным документом на сервер ДБО.
Сервер получает от клиента не только платёжный документ, но и подписанный журнал операций.
После обычной проверки подписи документа прикладная программа дополнительно:
- проверяет подпись журнала, осуществляя тем самым строгую аутентификацию терминала;
- вычисляет хеш от данных платёжного документа, которые клиент должен был подтвердить на экране терминала;
- сравнивает вычисленный хеш с хешем из журнала операций;
- при несовпадении обработка документа блокируется.
В профиле клиента сохраняется журнал операций (нужен при разборе конфликтных ситуаций).
Тем самым на сервере дополнительно формируется юридически значимая доказательная база (с усиленной электронной подписью), что клиент получил именно этот документ, видел его и подтвердил подписание на своём (полученном в банке на своё имя) терминале.
Для интеграции Антифрод-терминала в прикладное ПО подготовлены два типа комплектов разработчика:
- JaCarta SDK – для интеграции в настольные приложения (предоставляется по запросу).
- JC-WebClient SDK – для интеграции в веб-приложения с поддержкой всех популярных браузеров.