Почему традиционная защита от кражи денежных средств в системах ДБО уязвима

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


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


Эти задачи традиционно решаются с использованием средств строгой двухфакторной аутентификации и электронной подписи, выполненных в виде USB-токенов или смарт-карт (далее — токены).


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


  • хранят закрытый ключ в контейнере, доступ к которому для прикладного ПО предоставляется при предъявлении PIN-кода. Подпись при этом формируется программным СКЗИ в оперативной памяти ПК. Закрытый ключ при формировании подписи покидает токен, т.е. является извлекаемым;
  • самостоятельно генерируют ключевую пару (закрытый/открытый ключ). Подпись формируется «на борту» токена, в токен для этого передается хеш документа. Закрытый ключ никогда не покидает токен, т.е. является неизвлекаемым.

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


  1. Вредоносное ПО перехватывает PIN-код для токена при его вводе на клавиатуре ПК, затем с помощью этого PIN-кода расшифровывает содержимое контейнера на токене, получая таким образом доступ к самому закрытому ключу.
  2. Вредоносное ПО перехватывает закрытый ключ в оперативной памяти ПК в ходе выполнения операции, требующей его использования (например, при формировании ЭП).

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


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


  1. Атаки с подменой подписываемого документа. Пользователь видит на экране ПК одно платёжное поручение, а в момент его подписания вредонос¬ное ПО незаметно подменяет в нём реквизиты получателя и сумму. В токен для вычисления ЭП отправляется хеш подмененного документа. В результате деньги со счёта клиента банка «уходят» на счёт киберпреступника. Более того, вредоносное ПО после этого способно подменять отображаемые клиенту банка остатки на счетах. В результате пользователь может долго не подозревать о совершённой краже. Такие атаку могут быть реализованы различными способами.
    • Перехват трафика по протоколу USB-CCID.
    • Внедрение в код банковского приложения или браузера. Шифрованный канал, который может быть установлен между банковским приложением и токеном, в этом случае не помогает.

  2. Атаки, использующие состояние «залогиненности» токена. Получив удалённое управление, или, внедрив вредоносное ПО на компьютер клиента банка, киберпреступник может подписывать любые поддельные документы на его ключах в период, когда токен подключен к ПК и пользователь перед этим ввёл PIN-код. Перехватив заранее PIN-код с помощью вредоносного ПО, киберпреступник может сам «залогиниться» на токене и подписать на нём поддельный документ. Виртуальные клавиатуры не дают гарантию защиты от перехвата PIN-кода.

Можно снизить риски подобных атак путём чёткого следования политикам безопасности:


  • пользоваться легальным сертифицированным ПО;
  • своевременно устанавливать обновления;
  • установить и правильно настроить межсетевой экран;
  • использовать антивирус со свежей обновлённой базой;
  • установить и настроить модуль доверенной загрузки и контроля целостности среды.

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


Необходимость дополнительной защиты от мошенников известна и банкам, и регулятору. Данная проблема является достаточно актуальной. В частности, по информации «КоммерсантЪ» от 14 июля 2016 г. Минфин и ЦБ подготовили новые поправки по защите клиентов банков от несанкционированных операций. Поправки предлагают наделить банки правом приостанавливать транзакции, если есть подозрение, что операция совершается без согласия клиента, несмотря на правильно введённый пин-код и использование реальной электронной подписи. Т.е. масштаб бедствия таков, что законодатель явно допускает фрод и готовит рекомендации по противодействию ему.


Что реально используется сегодня для защиты от кражи денежных средств


Для защиты от кражи денежных средств в системах ДБО банки внедряют дополнительные меры.


  1. Серверные антифрод-системы, позволяющие выявлять подозрительные транзакции по тем или иным признакам.
  2. Trust Screen-устройства на клиентской стороне, позволяющие подтверждать ключевые реквизиты платёжных документов в доверенной среде таких устройств.

Серверные антифрод-системы


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


Справедливости ради стоит отметить, что на рынке появляются решения, способные дополнительно идентифицировать людей по голосу. Более распространённый вариант названия этой технологии содержит в себе слово «идентификация», а не «аутентификация», на что намекает даже Google:


c36c95bb4571477b9b924d597cf0df21.png

Идентификация, как правило, используется для представления своего идентификатора, а аутентификация — для доказательства, что субъект является тем, за кого себя выдаёт.


Голосовая идентификация не даёт 100% гарантию, что на том конце клиент банка. Существует технологии и даже готовые решения для клонирования голоса. И вполне возможно, что киберпреступники уже умеют или в ближайшем будущем научатся подделывать голос «жерты» так, чтобы успешно обманывать системы распознавания. Вместе с тем распознавание голоса является еще одним эшелоном, который позволяет снизить риск кражи денежных средств.


Trust Screen-устройства


3db0755cf0824c4d88a92757f9917f23.png

Trust Screen-устройство, как правило, представляют из себя небольшое устройство с экраном и (опционально) кнопками. Такое устройство используются на клиентской стороне и его основная задача — дать пользователю возможность подтвердить (или отклонить) транзакцию в доверенной среде, отличной от среды компьютера, в котором создаются платёжные документы. Классический сценарий использования Tust Screen-устройства выглядит так:


  1. Пользователь на компьютере подготавливает платёжное поручение с указанием реквизитов получателя и даёт банковскому приложению команду подписать платёжный документ и отправить его на исполнение.
  2. Банковское приложение отображает платёжный документ на экране ПК и дополнительно просит подтвердить его ключевые реквизиты на Trust Screen-устройстве.
  3. Пользователь смотрит на экран Trust Screen-устройства и подтверждает операцию специальной кнопкой на устройстве (или на сенсорномэкране устройства).
  4. В случае подтверждения платёжный документ подписывается с помощью используемого средства ЭП и подпись отправляется на сервер.

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


Слабым звеном при корректной реализации остаётся пользователь. Возможность кражи денежных средств в этом случае определяется тем, насколько ответственно пользователь сверяет реквизиты на Trust Screen-устройстве. Если при интенсивной работе заставлять его ежедневно подтверждать сотни документов, пользователь может начать делать это машинально, не уделяя достаточного внимания тому, что именно выводится на экран устройства. В связи с этим сценарий интеграции таких устройств в банковские системы должен уделять особое внимание удобству их использования.


К счастью, есть хороший способ существенно снизить количество документов, которые потребуется подтверждать на Trust Screen-устройстве без ущерба для безопасности. Решение — использовать «белые списки» доверенных контрагентов. В такой список включаются те контрагенты, с которыми пользователь работает регулярно и которым доверяет. Чем больше доля таких контрагентов, тем меньше транзакций требуется дополнительно подтверждать. Если из 100 транзакций около 90 будут исходить в адрес доверенных контрагентов, то пользователю потребуется подтвердить только 10 из 100.


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


Важным при работе с «белыми списками» является то, каким образом этот список создаётся и изменяется. Если киберпреступник сможет несанкционированно добавить себя в «белый список», вся идея таких списков становится ничтожной. Например, если «белый список» подготавливается пользователем в недоверенной среде, то к такому списку не может быть доверия.


Антифрод-терминал


134a2ecfe50a4dd494295b75e82338c1.png

Некоторое время назад мы вывели на рынок Trust Screen-устройство Антифрод-терминал. Данный продукт разрабатывался нами совместно с компанией Vasco, был основан на хорошо зарекомендовавшем себя устройстве DIGIPASS 920, которое было продано по всему миру в количестве более миллиона штук. Именно поэтому Антифрод-терминал так похож на него внешне.


Особенность Антифрод-терминала заключается в том, что устройство:


  1. Ведёт внутренний журнал операций. В этом журнале фиксируется информация, которая была отображена на экране устройства и подтверждена пользователем путём нажатия кнопки «ОК» на клавиатуре устройства.
  2. Содержит собственный криптографический чип, в котором реализована российская криптография.
  3. Подписывает журнал операций собственной ЭП на этом чипе.

Журнал операций не хранится в устройстве постоянно. Антифрод-терминал начинает вести журнал каждый раз заново при начале т.н. SWYX-режима работы устройства. SWYX означает Sign What You eXecuted — подписываю то, что выполняется. По окончании SWYX-режима терминал подписывает журнал собственной ЭП и возвращает его вместе с подписью в прикладное ПО. Для управления SWYX-режимом есть специальные команды, которые прикладное ПО отправляет на терминал.


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

eac06c71fc234b15816f9868c2408351.png

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


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


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


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


Новая версия Антифрод-терминала поддерживает любые типы средств ЭП


Первая версия Антифрод-терминала в качестве средства ЭП умела работать только со смарт-картами, которые подключались непосредственно к устройству. Однако на российском рынке за много лет накопилось достаточно большая инсталляционная база средств ЭП, выполненных в виде программных СКЗИ и/или USB-токенов. А переход на новые типы средств ЭП требует времени и дополнительных затрат как для банков, так и для конечных клиентов.


В связи с этим нами была разработана новая версия Антифрод-терминала, которая не накладывает никаких ограничений на тип используемого средства ЭП. Это может быть и программное СКЗИ, хранящее ключ в реестре или на обычной флешке, и программное СКЗИ, хранящее ключ ЭП на отчуждаемом USB-токене, и USB-токен с неизвлекаемым ключом ЭП, и смарт-карта ISO 7816.


Как нам удалось достичь этого? Архитектура Антифрод-терминала позволила полностью отделить функцию подписания документа от функции подтверждения на Антифрод-терминале. Работа со средством ЭП осуществляется как бы независимо от Антифрод-терминала. Средство ЭП ничего не знает о наличии Антифрод-терминала, а Антифрод-терминал ничего не знает о типе используемого средства ЭП, ему это и не нужно.


fd80ad1eac4c40d5be653a75e4b93872.png

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


Выполнение групповых операций


Для сокращения документов, которые нужно подтверждать на терминале, следует использовать «белые списки» доверенных контрагентов.


Важно то, что Антифрод-терминал позволяет безопасно создавать и изменять такие списки. Для этого достаточно все операции, связанные с изменением «белого списка», в том числе его создание, подтверждать на Антифрод-терминале. Это защищает от несанкционированного внесения изменений в «белый список» киберпреступниками.

59f75630e2fb4c61804154bd9f45027b.png

При выполнении групповой операции достаточно подтвердить сводное платёжное поручение в адрес всех контрагентов, попавших в «белый список», и каждое поручение в адрес контрагентов, не попавших в «белый список».


Для всех получателей, попавших в «белый список», клиент подписывает и подтверждает на терминале одно сводное платёжное поручение, содержащее, например:


  • общую сумму платежа в адрес получателей из «белого списка»;
  • число таких получателей или их список.

6fb8d154dc094d0da6c74e010bda7b65.png
ad4e1551fd814522983e8f521bdb9c53.png

Клиент подписывает и подтверждает на терминале каждое и оставшихся платёжных поручений.

Подписание произвольных документов


Антифрод-терминал позволяет отображать на своем экране любые текстовые данные длинной до 400 символом.


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

e129eb43e2bb4da49158f4c281faaf3c.png

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


Особенность интеграции Антифрод-терминала в прикладное ПО


При интеграции терминала в прикладное ПО доработки выполняются на клиентской и на серверной сторонах.


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


Перед обычным подписанием документа прикладная программа дополнительно:


  • формирует текстовую строку (до 400 символов), содержащую ключевые реквизиты документа;
  • отправляет эту текстовую строку на Антифрод-терминал и получает подтверждение/отклонение пользователя.

После обычного подписания документа прикладная программа дополнительно:


  • запрашивает у Антифрод-терминала журнал операций;
  • отправляет журнал операций вместе с подписанным документом на сервер ДБО.

4092dd02138840cb8f912ceacd2ad9bc.png

Сервер получает от клиента не только платёжный документ, но и подписанный журнал операций


После обычной проверки подписи документа прикладная программа дополнительно:


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

0ba9dd19ee204416b5c03d70c09e1f1d.png

В профиле клиента сохраняется журнал операций (нужен при разборе конфликтных ситуаций)


Тем самым на сервере дополнительно формируется юридически значимая доказательная база (с УЭП), что клиент получил именно этот документ, видел его и подтвердил подписание на своём (полученном в банке на своё имя) терминале.

Для интеграции Антифрод-терминала мы подготовили 2 типа комплектов разработчика:

  1. JaCarta SDK — для интеграции в десктопные приложения.
  2. JC-WebClient SDK — для интеграции в веб-приложения с поддержкой всех популярных браузеров.

Комментарии (0)

© Habrahabr.ru