Автор: Максим Федотенко

Атаки на системы ДБО

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

Рисунок 1. Классификация атак на интернет-банки

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

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

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

Обычно трояны имеет несколько функциональных возможностей (см. Рисунок 2):

• Предоставляют удаленный доступ к компьютеру пользователя для выполнения мошеннических действий под видом аутентифицированного пользователя (стрелка 1 на Рисунок 2). Такие возможности, например, имеют трояны Lurk, Buhtrap, Corkow (модуль HVNC).
• Собирают данные web-форм браузера, отвечающие за ввод учетных данных (логинов и паролей), а также ключевых данных при использовании криптографической аутентификации в интернет-банке (стрелка 2 на Рисунок 2). Далее данные передаются злоумышленнику. Такое поведение демонстрирует, например, Corkow (модуль FG).
• Перехватывают весь клавиатурный ввод и передает его злоумышленнику (стрелка 3 на Рисунок 2). При этом задача злоумышленника немного сложнее, чем в предыдущем пункте, т.к. ему из всего потока клавиатурного ввода нужно определить учетные данные пользователя.
• Внедряют модуль для осуществления Web-inject в браузере (стрелка 4 на Рисунок 2). Модуль разрабатывается таким образом, чтобы внедрить Javascript в HTTP-ответы от сервера интернет-банка в браузере пользователя. Таким образом, при помощи технологии web-inject злоумышленник может локально модифицировать страницы, которые видит пользователь, или информацию, отсылаемую пользователем в банк. Например, злоумышленник может внедрить в страницу логина ссылку на фишинговый сайт, запрос номера телефона пользователя или подменить реквизиты платежа, отправляемого в банк. Такое поведение демонстрируют, например, Lurk и Corkow.
• Перехватывают сетевой трафик на уровне браузера или ниже для того, чтобы модифицировать данные платежных документов, передаваемых в банк (стрелка 5 на Рисунок 2).
• В последнее время становятся все более популярными одностраничные web-приложения (Single Page Application, SPA), которые используют один web-документ как оболочку для всех web-страниц и организующий взаимодействие с пользователем через динамически подгружаемые данные, обычно при помощи технологии AJAX и идеологии REST-сервисов. SPA напоминают обычные приложения для операционной системы, но исполняются в браузере [4]. Именно в случае использования таких одностраничных Web-приложений начинают появляться угрозы не столько модификации данных при помощи web-inject сколько модификации их на сетевом уровне браузера, т.к. их структура становится прозрачной – это простой JSON.
• Модифицирует системные настройки проксирования для перенаправления трафика на копию сайта интернет банка, созданную злоумышленником (стрелка 6 на Рисунок 2). Причем в случае HTTPS могут использоваться самоподписанные сертификаты на домен банка.

Рисунок 2 . Функциональные возможности троянов

Далее приводится несколько примеров программ-троянов для осуществления таких атак. Согласно отчету [3] их активно использовали различные преступные группировки для осуществления атак в 2016 году.
Троян ProxyAdder осуществляет изменение настроек браузеров для перенаправления соединений браузера на определенный proxy-сервер. Он также устанавливает свой сертификат безопасности на компьютере жертвы в доверенные корневые. В начале 2016 года была зафиксирована атака на клиентов Сбербанка, а позже – ВТБ24 и Русский Стандарт.

Троян RTM появился в конце 2015 года. Для распространения трояна используются связки эксплойтов Beps, Angler, RIG. Он нацелен на такие банки как Сбербанк, ВТБ24, Райфайзен и некоторые другие. Троян является модульным, его модули подменяют реквизиты, считывают нажатия клавиатуры, подменяют DNS-сервера и сертификаты безопасности, осуществляют снимки экрана и т.п.

Также в 2016 году были зафиксированы [3] инциденты с троянами для компьютеров Jupiter (aka Bolek), Buhtrap, Ranbyus. А совсем недавно была ликвидирована преступная группировка Lurk, использующая одноименный троян для хищений в интернет-банках [4]. Этот троян также использовал модули, которые осуществляли “автозалив” (внедрение инжектов в браузере пользователя), подмену java-классов оригинального java-апплета, а также удаленное управление компьютером на базе VNC. Все эти методы использовались в том числе для подмены реквизитов платежных документов клиента. Более подробно с работой Lurk можно ознакомиться в [5].

Методы защиты клиента

Защитить клиента, например, от подмены реквизитов платежа, банк может при помощи аутентификации транзакции по другому (out-of-band) каналу. Обычно такая защита осуществляется банками при помощи SMS-сообщений, отправляемых на мобильный телефон клиента. При этом на телефон клиента высылается SMS-сообщение с деталями транзакциями и одноразовым кодом для ее подтверждения.
Также банки могут применять системы антифрода, которые также имеют возможности по борьбе с таким видом мошенничества.

Дополнительное подтверждение реквизитов с использованием SMS-сообщения

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

• Во-первых, для проведения полноценной атаки злоумышленники устанавливают не только троян на компьютер, где работает интернет-банк, но также внедряют троянца на телефон клиента (в основном это касается платформы Android). Надо сказать, что в случае юридических лиц такая технология полностью оправдана, т.к. сумма одной мошеннической транзакции может составлять на порядки больше суммы в канале физических лиц, а заметить кражу клиент может и через полгода. Причем как было замечено в разделе 1 технология “автозалива” применяется уже и в троянах на платформе Adnroid, т.е. при этом злоумышленнику необходимо захватить только одно устройство клиента.

Рисунок 3. APT-атака на интернет-банк с модификацией SMS (Красным цветом выделены мошеннические операции)

• Во-вторых, в случае подтверждения операции с использованием SMS-сообщений в процессе передачи сообщений возникают провайдеры сотовой связи и их процессы замены номеров телефонов, SIM-карт и т.п. Тем самым банк вынужден контролировать принадлежность номера телефона своему клиенту и замену SIM-карт, дабы исключить ситуации по отправке SMS-сообщений на телефон мошенника. Например, часто возникают ситуации по нелегитимной выдаче новой SIM-карты к телефонному номеру клиента по поддельным паспортам или в случае мошенничества сотрудников операторов сотовой связи. Поэтому банк вынужден использовать дополнительные меры контроля, получая информацию от операторов сотовой связи по замене SIM-карт и заставляя клиентов подтверждать смену SIM-карты также и в банке. При этом в случае отсутствия у банков эффективных средств удаленной аутентификации клиентов в контактном центре клиенту приходится физически посещать отделение банка для подтверждения факта замены SIM-карты.

 

Рисунок 4. APT-атака на интернет-банк с заменой SIM-карты (Красным цветом выделены мошеннические операции)

• В-третьих, операция отсылки SMS-сообщения достаточно затратная для банков, а в случае получения информации по замене SIM-карты от сотовых операторов стоимость возрастает дополнительно;
• В-четвертых, как мы понимаем, SMS-сообщения передаются через сети сотовых операторов и, возможно, агрегаторов. При этом возможна подмена текста SMS-сообщений между банком и клиентом недобросовестными сотрудниками этих организаций. Тем более что на данный момент сотовые операторы не осуществляют долгосрочное хранение SMS-сообщений в целях разбора конфликтных ситуаций.
• В-пятых, в последнее время получили широкое распространение атаки на сигнальные протоколы сотовых сетей – SS7. Более подробно о таких атаках можно прочесть в [7]. Таким образом, злоумышленник, используя недорогое оборудование или некоторые сервисы, может перехватывать SMS-сообщения и звонки пользователей, определять их местоположение и т.п.
• В-шестых, учитывая всеобщий тренд на использование клиентами мобильных приложений для работы с интернет-банком и активизацию работы злоумышленников по созданию троянов для мобильных устройств [3], доверие к использованию SMS-сообщений будет все более снижаться;
• В-седьмых, подтверждение операций при помощи SMS-кода считается простой электронной подписью [6]. Процедура разбора конфликтной ситуации при использовании простой электронной подписи является достаточно сложной с юридической точки зрения, необходимо очень аккуратно прописывать в договорных отношениях с клиентом моменты, касающиеся ее использования. Поэтому судебная практика в данном вопросе весьма неоднозначна, особенно с учетом привлечения клиентом экспертов по компьютерной безопасности.

Использование SMS-сообщений признано не вполне безопасным даже на уровне Правительства РФ [8]. Однако методы предлагаемые Минкомсвязи – использование аппаратных или программных генераторов одноразовых паролей на основе времени (Time-based One-time Password Algorithm - RFC 6238 https://tools.ietf.org/html/rfc6238), не могут в полной мере защитить от атак с подменой реквизитов, т.к. в них отсутствует возможность подтвердить реквизиты платежа. Данный способ подтверждает только личность пользователя при аутентификации и может применяться для аутентификации пользователей в таких системах как ЕСИА (Единая система идентификации и аутентификации. https://esia.gosuslugi.ru/).

Защита клиента при помощи систем антифрода

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

Обычно системы антифрода предоставляют решения по аналитике конкретно от атак на клиента при помощи троянов. Например, система антифрода RSA Adaptive Authentication для контроля троянов в браузере клиента предоставляет javascript “rsa.js”, который запускается на странице интернет-банка в браузере пользователя и контролирует его работу. Скрипт собирает и передает в систему антифрода следующую информацию:

• отпечаток устройства – сериализованные данные, содержащие информацию о браузере клиента, экране пользователя, часовой пояс, языки браузера, операционной системы и пользовательские, разрешение использования java-апплетов и javascript-скриптов в браузере, подключенные к браузеру дополнительные модули и т.п.;
• информацию о DOM-модели каждой странице пользователя, на которой производится активная операция с интернет-банком. Под информацией о DOM-модели понимается: названия всех javascript-функций текущей страницы, названия и свойства iframe-элементов и элементов, которые требуют действий пользователя на странице – полей ввода, кнопок, элементов выбора и т.п.;
• информацию о событиях на странице – нажатии клавиш и перемещении мыши;
• информацию о наличии дополнительных proxy-серверов на пути прохождения трафика к серверу банка;
• при помощи интерактивного взаимодействия с системой антифрода пытается обнаружить наличие трояна, который эксплуатирует удаленный доступ к компьютеру пользователя.

5 .Схемы работы скрипта системы антифрода RSA Adaptive Authentication

Далее система антифрода RSA Adaptive Authentication на основе своей статистики и черных списков пытается определить вероятность наличия трояна на компьютере клиента. К сожалению, на данный момент даже сам вендор признал неэфективность большинства перечисленных механизмов для определения троянов на компьютере клиента интернет-банка.

Существуют и другие системы защиты от троянов, например, Group-IB Bot-Trek Secure Bank, IBM Trusteer, Kaspersky Fraud Prevention, эффективность которых возможно выше вследствие большей направленности именно на подобный сегмент атак, однако они также не являются полной панацеей.

Использование доверенных устройств

Технологии доверенных сред

На данный момент можно заметить намечающийся тренд в обеспечении безопасности платежей в интернет-банке – это использование доверенных сред. Под доверенным средами понимается:

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

Первый путь предполагает использование, например, мобильного антивируса, виртуальных машин или использование элементов безопасности (Secure Element). Очевидно, что использование мобильного антивируса не может организовать полностью доверенного окружения, хотя бы даже на примере использования антивирусов на персональных компьютерах, которые уже давно не дают высокой степени уверенности, что компьютер не заражен. Zero-day атаки антивирусы в основном не распознают даже с использованием эвристических механизмов. Работа виртуальных машин внутри мобильного устройства сильно нагружает само устройство, да и также не дает уверенности в защите. Использование элементов безопасности в мобильном устройстве или на SIM-карте в целом достаточно перспективное направление. К сожалению, доступ к элементам безопасности для стороннего программного обеспечения в платформе Apple iOS закрыт, поэтому в таких решениях используются устройства с операционной системой Android. При этом в элементе безопасности может храниться ключ аутентификации клиента и он будет подтверждать при помощи него операции. Такую технологию постепенно внедряется, например, Мегафон [9]. Однако в среде Android данная технология имеет свои уязвимости, которые может свести на нет использование элементов безопасности.

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

Специализированные доверенные устройства для интернет-банка юридических лиц

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

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

6 . Атака на интернет-банк с токеном при помощи трояна

Таким образом, для защиты клиентов, которые работают с токеном, все равно приходится осуществлять подтверждение платежных операций по другому каналу (например, теми же самыми SMS-сообщениями). Общепринятая практика при этом – использование списка доверенных контрагентов или списка шаблонов. Т.е. клиент один раз подтверждает при помощи SMS-сообщения реквизиты контрагента или шаблон в качестве доверенного, а затем все платежные поручения, созданные в адрес подтвержденного контрагента или с использованием доверенного шаблона, принимаются интернет-банком подписанные токеном без использования дополнительного подтверждения.

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

Токен с экраном

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

Токены с экраном в настоящий момент производятся такими фирмами как, например, Рутокен (Рутокен PINPad), SafeTech (SafeTouch), Инфокрипт. Все они имеют USB-интерфейс для получения документов на подпись. Кроме этого, можно сказать еще, например, об устройствах, использующих оптический интерфейс, например, SafeNet eToken 3500 или AGSES-карты. Все он реализуют концепцию доверенного устройства, но с разными каналами взаимодействия.

Устройства обеспечивают двухфакторную аутентификацию – пользователю необходимо обладать устройством и знать PIN-код. Ввод PIN-кода происходит на сенсорном экране устройства в доверенной среде, что обеспечивает дополнительную защиту от мошенничества.

Токен с экраном также используется для удовлетворения требованиям 63-ФЗ “Об электронной подписи” в части необходимости подтверждения платежей с отображением подписываемой платежной информации.

Далее в статье будет описан один из вариантов встраивания токенов с экраном в Интернет-банк юридических лиц.

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

Интеграция токена с экраном и Интернет-банка

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

Визуализация и шаблонизация

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

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

<!PINPADFILE RU>
<!>невидимый текст
<N>ФИО:<V>Петров Петр Петрович Москва, Пионерская ул, д. 3, кв. 72
<N>Перевод со счета:<V>42301810001000075212
<N>Сумма:<V>150000
<N>Валюта:<V>RUR
<N>Наименование получателя:<V>Иванова Елена Ивановна
<N>Номер счета получателя:<V>40817810338295201618
<N>БИК банка получателя:<V>044525225
<N>Наименование банка получателя:<V>ОАО 'БАНК ДЕМО' Г. МОСКВА
<N>Номер счета банка получателя:<V>30101810400000000225
<N>Назначение платежа:<V>перевод личных средств

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

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

Например, в нашем случае структура документа выглядит следующим образом:

ATTRIBUTES:
GlobalID=b5b509cd-7ff0-4599-b2dd-15083828d0f4
DocType=PayDocRu
DocTypeVersion=2.0
FIELDS:
DocInfo.DocDate=2016-06-06 00:00:00.0
DocInfo.DocNumber=7
DocInfo.DocSum=654.00
PaymentInfo.Destination=ВтомчислеНДС 18 % - 99.76
PaymentInfo.NDS=99.76
PaymentInfo.OperationType=01
PaymentInfo.Payer.BankAccount=30101810100000000716
PaymentInfo.Payer.BankBIC=044525716
PaymentInfo.Payer.BankName=ПАО "ВТБ 24"
PaymentInfo.Payer.OrgINN=2323121234
PaymentInfo.Payer.OrgName=ОООТестКлиент
PaymentInfo.Receiver.BankAccount=30101810400000000225
PaymentInfo.Receiver.BankBIC=044525225
PaymentInfo.Receiver.BankName=ПАО "СБЕРБАНКРОССИИ"
PaymentInfo.Receiver.OrgAccount=40702810200000000001
PaymentInfo.Receiver.OrgINN=1212121212
PaymentInfo.Receiver.OrgName=ООО "ООПРР"

В заголовке (ATTRIBUTES) присутствуют такие поля как тип документа (DocType), версия структуры документа и т.п. В полях (FIELDS) записываются такие данные о документе, как его название, номер, счет плательщика, счет получателя, сумма и т.п.

Для каждого типа документа в Интернет-банке хранится шаблон обработки. Шаблон обработки представляет собой XML-структуру, которая определяет атрибуты, связанные с обработкой и подписанием документа, а именно:

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

Рассмотрим пример шаблона.

<?xml version='1.0' encoding='UTF-8'?>
<Template name="PayDocRu.for_pay" version='1.0' date="06.06.2016">
<Header>
<ObjType>Document</ObjType>
<DocType>PayDocRu</DocType>
<Sign>
<Channel>Token</Channel>
<SubChannel>HTTP</SubChannel>
<Type>Single</Type>
<Confirm>Default</Confirm>
</Sign>
</Header>
<Body>
<Style1 ForeColor="F08020" Font="Sans" Width='40' XBefore='8' XAfter='4' YBefore='2' YAfter='120' Wrap='Off' />
<Origin ForeColor='F08020' BgColor='A0B0C0' Font='Serif' FontSize='5' Style='1'/>
<Single Style='1'>
<Field Order="1">"РПП №"</Field>
<Field Order="1" Col="2">DocInfo.DocNumber</Field>
<Field Order="2">"Получатель"</Field>
<Field Order="2" Col="2">PaymentInfo.Receiver.OrgName</Field>
<Field Order="3">"Счет"</Field>
<Field Order="3" Col="2">PaymentInfo.Receiver.OrgAccount</Field>
</Single>
</Body>
</Template>

Шаблон имеет атрибуты – название, версия и дата шаблона, и состоит из обязательных разделов – “Header” и “Body”.

В заголовке шаблона указывается информация о том, для чего предназначен шаблон:

• какому типу документа соответствует (тег DocType);
• на каком устройстве его использовать (например, для токенов, для SMS или PUSH-уведомлений. О других видах будет далее в статье). Определяется тегом Channel;
• используется для подписания единичного документа или пакета документов (тег Type);
• необходимое подтверждение. Например, визуализировать на экране и ожидать реакцию пользователя или просто подписать без визуализации (тег Confirm).

Задавая значения данных параметров, можно указать токену в каком случае можно использовать данный шаблон. Например, только если значение DocType в шаблоне соответствует типу подаваемого на токен документа (поле DocType документа). Также можно определить для какого типа визуализировать документ, а для какого нет (если подписание документа не несет рисков мошенничества, то визуализировать его и не нужно).

В теле шаблона указывается какие атрибуты документа отображать пользователю на экране и каким образом. Любые сущности могут быть отражены в любом из столбцов, причем столбцов может быть не 2, а три или четыре, главное, чтобы все они могли быть адекватно отражены на экране токена. В формате шаблона предусмотрены подразделы, отвечающие за отображение атрибутов единичного документа (Single) и атрибутов в случае пакетного подписания (Packet). При помощи отдельных атрибутов тегов в каждом из этих подразделов мы можем настроить используемые типы и размеры шрифтов, а также цвета.

Пакетное подписание

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

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

<?xml version='1.0' encoding='UTF-8'?>
<Template name="PayDocRu.for_pay.Packet" version='1.0' date="06.06.2016">
<Header>
<ObjType>Document</ObjType>
<DocType>PayDocRu</DocType>
<Sign>
<Channel>Token</Channel>
<SubChannel>HTTP</SubChannel>
<Type>Packet</Type>
<Confirm>Default</Confirm>
</Sign>
</Header>
<Body>
<Style1 ForeColor="F08020" Font="Sans" Width='40' XBefore='8' XAfter='4' YBefore='2' YAfter='120' Wrap='Off' />
<Origin ForeColor='F08020' BgColor='A0B0C0' Font='Serif' FontSize='5' Style='1'/>
<Single Style='1'>
<Field Order=1>”№ ”</Field>
<Field Order=1 Col=2>DocNumber</Field>
<Field Order=2>”Сумма”</Field>
<Field Order=2 Col=2>DocSum</Field>
</Single>
<Packet>
<Field Order=1>”Платежные поручения”</Field>
<Field Order=2>”Кол-во: ”$num</Field>
<Field Order=3>”Сумма: ”$sum</Field>
</Packet>
</Body>
</Template>

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

Формирование данных для подписи

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

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

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

Подписание документов

Для корректной работы экранной технологии подпись документа должна включать дополнительные атрибуты, содержащие информацию о том, как подписывался документ. При этом используется технология Cryptographic Message Syntax (CMS) или PKCS7. Подпись формируется в формате отсоединенного CMS с набором подписанных атрибутов. Однако можно использовать, например, и XML Signature.

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

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

Токен проверяет подпись шаблона (в соответствии со стандартом X.509) и, тот факт, что шаблон подписан сертификатом банка. Далее если в шаблоне указана необходимость (тег Confirm) токен визуализирует документ или пакет документов. Если же в шаблоне явно указано, что визуализировать не нужно, то токен с экраном не будет визуализировать документ и без подтверждения подписывает документ. Такая логика реализована специально, чтобы показывать на экране только документы, подверженные высокому риску мошенничества.

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

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

Как указывалось ранее токен подписывает документы, формируя CMS-конверты отсоединенной подписи. При этом в конверте содержится вся необходимая информация, определяемая стандартом RFC 5652 (указание на сертификат, при помощи которого подписывался документ, или сам сертификат/цепочка сертификатов, алгоритм и значение подписи, стандартные подписываемые атрибуты). Также в CMS-конверт введены дополнительные подписываемые атрибуты:

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

Эти атрибуты проверяются в интернет-банке при получении банком подписанного документа и отправки его на исполнение.

Проверка подписи в Интернет-банке

Самое интересное начинается при проверке подписи документа в Интернет-банке. Необходимо кроме стандартной проверки математического совпадения подписи, проверки по CRL и т.п. (в соответствии со стандартом X.509), проверить, что документ подписывался нужным шаблоном и именно так как написано в шаблоне. Логика такой проверки приведена на следующем рисунке. Эта логика предполагает, что мы уже проверили подпись в соответствии с X.509 и она является верной.

Рисунок 7. Процесс проверки подписи документа

В начале интернет-банк должен проверить на основе данных подписанных атрибутов, что документ подписан токеном и этот токен принадлежит именно клиенту, от имени которого установлена сессия с интернет-банком. Далее он смотрит на значение хеш-функции шаблона, которое находится в подписанных атрибутах CMS-конверта подписи. Если значение не присутствует, то интернет-банк проверяет по своей базе данных необходимость использования шаблона для данного документа. В случае если шаблон не нужен, то проверяет был ли при подтверждении задействован тот тип подтверждения документа, который установлен по умолчанию для токена с экраном (это визуализация и нажатие на кнопку). Если да, то подпись верна. Если же нет или необходимо использовать шаблон, то считает, что данное действие выполнял мошенник и отвергает такое подписание.

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

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

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

Так в общем чертах выглядит процесс проверки подписи токеном с экраном интернет-банком.

Общий процесс работы интернет-банка с токеном с экраном

В заключении раздела, посвященному интеграции токена с экраном с системой интернет-банка, рассмотрим общий процесс его работы с интернет-банком (см. Рисунок 8 ).

Рисунок 8 . Процесс подписания документа в Интернет-банке токеном с экраном с использованием браузера

(1) Клиент формирует в интернет-банке платежный документ, (2) документ отправляется в банк. Затем (3) банк формирует дайджест документа и вместе с ним передает шаблон, привязанный к данному типу документа, и (4) отправляет их на токен клиента. (5) Токен визуализирует клиенту на экране документ и запрашивает подтверждение. (6) После акцепта токен (7) подписывает документ и (8) отсылает подпись в формате CMS-конверта в интернет-банк на банк. (9) После этого происходит процесс проверки подписи и соответствия подписываемых атрибутов, описанный чуть выше.

Интеграция с Антифрод системой

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

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

Дополнительный контроль в системах антифрода обычно реализуется звонком клиенту (или клиент должен перезвонить) для уточнения банком, что данную операцию проводил именно клиент, а не мошенник. В случае использования токена с экраном у антифрода появляется новый путь осуществления дополнительного контроля. Например, если в организации-клиенте ДБО несколько обычных пользователей (с обычными токенами или подписывающие операции при помощи SMS-сообщений) и один, обладающий токен с экраном, то платежные поручения, подписанные обычными пользователями и по каким-то причинам признанными антифродом подозрительными, могут отправляться на дополнительный контроль пользователю, имеющему токен с экраном. Таким образом, не нужно будет производить отзвоны клиенту с множеством дополнительных контролей, например, актуальности номера телефона, контроля замены SIM-карты, роуминга клиента и т.п., и можно ограничиться дополнительной подписью подозрительных документов в интернет-банке при помощи токена с экраном.

Преимущества использования токенов с экраном для клиентов банка

Исходя из того, что было написано выше, можно констатировать тот факт, что использовать токен с экраном для клиентов выгодно – он повышает как удобство так и безопасность платежей клиента в интернет-банке.
Что касается безопасности платежей, то:

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

Если рассматривать удобство работы пользователей с интернет-банком, то необходимо отметить следующие факты.

В разделе 3.2 говорилось, что общепринятой практикой для интернет-банка является использование списка доверенных контрагентов, которые подтверждаются клиентом по альтернативному каналу, например, при помощи SMS-сообщений. Такое подтверждение очень неудобно для клиентов в особенности при большом количестве платежей и использовании Толстого клиента интернет-банка. В этом случае клиентом формируется и подписывается большое количество платежных документов в режиме офлайн, а потом одним скопом они отправляются в банк. При этом если получатели не находятся в списке доверенных, то эти платежи не будут приняты банком и клиенту нужно отдельно заполнять список и подтверждать каждую новую запись при помощи ввода одноразового пароля из SMS-сообщения. Причем при подтверждении записей контрагентов необходимо будет каждый раз “выводить на связь с банком” Толстого клиента. В случае же использования токена с экраном платеж, подписанный им, не будет проверяться по списку контрагентов и будет исполняться банком без каких-либо дополнительных условий по защите от мошенничества.

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

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

 

Развитие технологии доверенных устройств для интернет-банка

Общие принципы

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

Такое устройство должно иметь возможность работать с интернет-банком в разных режимах и по различным каналам. Если токен с экраном использовал только USB канал, то доверенное устройство должно использовать все современные каналы, такие как: USB, Wi-Fi, Bluetooth, NFC, GPRS/3G/4G, камера и, возможно, другие. Причем неоспоримым преимуществом такого устройства может быть схожесть по форм-фактору с мобильными телефонами – флагманами известных производителей, например, Apple iPhone.

Внешний вид может быть, например, таким.

Рисунок 9. Пример внешнего вида доверенного устройства

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

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

Сценарии использования доверенного устройства в интернет-банке

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

Наиболее легким для внедрения сценарием является подписание и подтверждение платежа при помощи SMS-канала или PUSH-уведомлений.

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

Рисунок 10 . Сценарий подтверждения платежа по SMS-каналу без ввода одноразового пароля

В данном случае для работы не обязательно подключение устройства к сети Интернет, однако ответные SMS-сообщения могут быть дороги для клиента. Тогда клиент может использовать SIM-карты, которые в скором времени будут выпускаться банками в качестве виртуальных операторов связи [10]. Наверняка тарифы для операций “своих” интернет-банков будут дешевыми или даже бесплатными.

В случае же использования PUSH-уведомлений (см. Рисунок 11 ) используется подключение к сети Интернет доверенного устройства. Сценарий идентичен до момента отправки документа на доверенное устройство. Отправка осуществляется при помощи PUSH-сервиса, а после подтверждения клиентом, ответное сообщение подписывается и отправляется по сети Интернет через, например, шлюз который используют мобильные приложения в интернет-банк.

Рисунок 11 . Сценарий подтверждения платежа при помощи PUSH-уведомления без ввода одноразового пароля

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

Использование Bluetooth-канала (см. Рисунок 12 ) особенно интересно для Толстого (офлайн) клиента интернет-банка. В этом случае до передачи документов в банк взаимодействие с банком не требуется, а доверенное устройство может быть одновременно подключено к нескольким компьютерам.

Рисунок 12 . Сценарий подписания платежей по Bluetooth-каналу

В случае если спроектированное таким образом доверенное устройство покажет себя перспективным возможно уже портирование мобильных приложений банка на эту доверенную платформу (см. Рисунок 13 ).

Рисунок 13 . Сценарий использования доверенных устройств для мобильных приложений интернет-банка

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

И наконец, как уже не раз говорилось выше, возможно подтверждение платежей сделанных другими пользователями организации, но которые по каким то причинам определены системой антифрода в качестве подозрительных. Возможный сценарий в этом случае таков. Система антифрода отправляет PUSH-уведомление на подтверждение подозрительного платежа на доверенное устройство, пользователь его подтверждает и устройство отправляет подписанный ответ обратно в антифрод (см. Рисунок 14 ).

Рисунок 14 . Сценарий подтверждения подозрительных платежей, выявленных системой антифрода

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

Список литературы

1. Laerte Peotta, Marcelo D. Holtz, Bernardo M. David, Flavio G. Deus, Rafael Timóteo de Sousa Jr.
   “A FORMAL CLASSIFICATION OF INTERNET BANKING ATTACKS AND VULNERABILITIES”.
   International Journal of Computer Science & Information Technology (IJCSIT), Vol 3, No 1, Feb 2011.
2. Group-IB. Отчет “HI-TECH CRIME TRENDS 2016”.
3. Group-IB. Отчет “Threat evolution in Q3 2016”.
4. https://мвд.рф/mvd/structure1/Upravlenija/Upravlenie_K_MVD_Rossii/Publikacii_i_vistuplenija/item/7883879/
5. Лаборатория Касперского. Исследование “Банковский троянец Lurk: специально для России”. https://kasperskycontenthub.com/securelist-russia/files/2016/06/Lurk_report_RUS.pdf
6. Федеральный закон “Об электронной подписи” от 06.04.2011 №63-ФЗ.
7. Positive Technologies. Отчет “Статистика основных угроз безопасности в сетях SS7 мобильной связи”.
8. Известия. Статья “SMS-коды признали опасными для оплаты”. http://izvestia.ru/news/636180
9. Мегафон. “Электронная подпись появилась в SIM-картах “Мегафона”. http://corp.megafon.ru/press/news/20150817-1148.html
10. Новость о создании Сбербанком виртуального оператора связи на базе Tele2.
    http://www.rbc.ru/technology_and_media/13/04/2016/570e4f7b9a794799bdc9026e
    http://tass.ru/ekonomika/3711502