Фатальные ошибки в банковском программном обеспечении

Статья создана: , обновлена:

Киберпреступность

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

К сожалению, в нашей стране это объективная реальность, которую нужно воспринимать как есть. Сегодняшняя статья будет посвящена киберпреступникам и их методам увода денег.

Я не буду говорить о кредитках, webmoney и paypal, а поговорим о другом департаменте киберпреступности, который опустошает счета в банках. Весь текст основан на личном опыте, когда проводил работу над проектов в банковском секторе, а именно - проводил расследования инцидентов, анализ ситуаций, и просто на опыте различных тестов банков и анализе банковского программного обеспечения.

Банк - Клиент

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

Для защиты банковских транзакций лучше использовать проверенное программное обеспечение.

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

Это называется «платежное поручение». Далее операционист банка (сотрудник) просматривает все накопившиеся платежные поручения и жмет кнопку «ОК», после чего программное обеспечение, снимает деньги со счета пользователя в базу данных и формирует файл/запись в базу данных/иное указание для банка, куда отправляются деньги. Потом происходит возня с обработкой коррсчетов между банками, чтобы переправить деньги на нужный счет, но все это уже не так интересно. Тут в дело вступает наше законодательство и правила Центробанка (самый главный банк страны). В частности, при работе с юридическими лицами (фирмы, компании, корпорации и так далее) требуется, чтобы платежные поручения были заверены цифровой подписью. Но не простой, а единственно правильной - на ГОСТ алгоритме. В итоге операционист получает только те платежки, подпись которых проверена, далее он смотрит назначение платежа, его описание и жмет «ОК». После этой фазы можно не сомневаться - деньги дойдут куда нужно.

Как это выглядит

  • Аутентификация в системе Банк - Клиент.
  • Формирование платежного поручения.
  • Подпись (часто подписи надо ставить две - от бухгалтера и директора).
  • Отправка в банк.
  • Подтверждение платежки операционистом в банке.
  • Банк осуществляет операцию.

Это общее условное описание действий. На самом деле многое зависит от типа банк - клиента, от правил банка и так далее и тому подобное.

Классификация банковских клиентов

Системы ДБО бывают разными, и поэтому работа с ними тоже протекает по - разному. Проведу быструю классификацию:

  • Толстый Банк - Клиент.
  • Тонкий Банк - Клиент.
  • Интернет - Клиент.
  • Мобильный - Клиент.
  • ATM - Клиент.

Толстый клиент

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

Тонкий клиент

Банковский клиент работает со счетом из браузера. Это означает, что он работает уже через WEB - интерфейс (иногда через специальный интерфейс на Java и локальной базы у него нет, но, тем не менее, ему накатываются плагины к браузеру в виде Java - апплетов или ActiveX, чтобы делать подписи (электронная подпись ставится локально, так как секретный ключ находится у клиента). Зачем ActiveX? Затем, что в Windows по умолчанию нет криптопровайдера для подписи согласно ГОСТ. Поэтому необходимо дополнительное программное обеспечение, которое будет ставить подпись по всем законам.

Интернет клиент

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

Мобильный клиент

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

ATM клиент

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

Юридические лица

Итак, почему юридические лица?

Во - первых, у них большой поток денег и множество переводов в сутки. Если добавить одну маленькую платежку, ну, скажем, на один - два миллиона рублей, то такая платежка на фоне остальных не вызовет подозрения у операциониста. И потом, у юридических лиц нет подтверждения через мобильники и прочей лабуды, что напридумывали для физических лиц взамен электронно - цифровой подписи (ЭЦП) на платежку (у них только ЭЦП). Следующий фактор - больше возможностей для маневра и взлома. Фактически, взламывая ЛЮБУЮ фирму или компанию, можно смело утверждать, что где - то там в локальной сети есть компьютер с установленным банк - клиентом. Более того, в действительно больших фирмах финансисты, которые от имени фирмы осуществляют платежи, имеют договоры сразу с НЕСКОЛЬКИМИ банками и банковский клиент соответственно, более того, они же не придумывают и тем более, не знают, что именно они делают. Что я сейчас сказал? :) Вот именно - не знают. В большинстве случаев такие операторы просто получают ТЕКСТОВЫЙ ФАЙЛ без подписи из 1С или из ERP (электронный документооборот) - системы со списком, куда, сколько отправить, что они уже и выполняют в банк-клиенте. Кто с логикой дружит тот прекрасно понимает как это ОГРОМНАЯ уязвимость в банковском переводе.

Электронно-цифровая подпись (ЭЦП)

Вкратце: подпись - это результат хэш - функции от текста платежки, «зашифрованной» на закрытом ключе клиента. Хотите посмотреть как реально выглядит электронная подпись? Жмите на ссылку.

Банк, получая платежку, проверяет хэш от текста полученной платежки, потом «расшифровывает» подпись открытым ключом клиента и сверяет результат. Если хэши совпали, значит, это действительно платежка от клиента, и текст платежки достоверен. Решаются задачи целостности, идентификации клиента и, кроме того, сам клиент потом НЕ МОЖЕТ отказаться от этой платежки, так как она подписана верным ключом. Дело в том, что между банком и клиентом подписывается договор, согласно которому все платежки с верной электронной подписью банк должен отправлять. Поэтому, если кто - то украдет ключ пользователя, подпишет платежку, то банк обязан исполнить ее, выполняя денежный перевод, куда сказано. И если клиент потом пойдет с претензиями, что, мол, это не я отправлял, банк покажет договор, покажет бумажки о генерации ключа, о признании этого ключа клиентом, о том, что ключ был верный, и что денег клиенту он не должен. Короче, сам потерял ключ - сам и виноват, банк ничего возмещать не обязан (хотя может, если клиент ему дорог и сумма небольшая). Программное обеспечение, работающее с электронно цифровой подписью по ГОСТу, у нас гордо зовется «Система Криптографической Защиты Информации» (СКЗИ). Такое программное обеспечение проходит «типа проверку» ФСБ и на него выдаются соответствующие сертификаты! Алгоритм подписи - ГОСТ Р 34.10 2001. При этом алгоритм хеш - функции - ГОСТ Р 34.11 - 94.

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

USB Token

Многие банки, интеграторы - безопасники и так далее говорят, что USB Token защитит всех нас от хищения электронно цифровой подписи. Что же такое USB Token? Это железка в виде USB устройства, внешне похожего на обычную флешку. Внутри этой «флешки» прошит секретный ключ и микро - схема, которая принимает на вход данные, подписывает их по ГОСТу внутри себя (с помощью ключа) и на выход обратно кидает уже подпись. Это достаточно круто, ведь тогда ключ нельзя скопировать и украсть. Но, к сожалению, можно просто подменить входные данные или вообще поставить жертве R - Admin, а можно и туннелировать трафик USB на машину злого хакера. В общем, все это - не панацея, а недавние реализации зловредов уже включали в себя такой функционал. Так что USB Token просто снижает риски, но настроив тунелинг (например взломав по 445 порту) можно легко перехватить этот самый хэш ключик. Это все, что про него можно сказать. Хотя есть более крутые Токены с одноразовыми паролями и так далее, но массового внедрения пока нет, да и слабые места в виде перехвата ввода пароля и использование его для подложной платежки также возможны и сильная защита на Token безопасности не добавляет. Слабое место остается одно!

Итог

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

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

Грабим караваны зная, как вся это каша работает, рассмотрим теперь, как нехорошие люди уводят деньги.

Дополнительная информация по теме

Антиспаммерское программное обеспечение

Полезные советы и рекомендации тем, кто неоднократно находил в своем ящике письма, которые можно смело назвать спамом

Социальное программное обеспечение

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

Правила безопасности при работе с банковским программным обеспечением

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

Работая дома, правильно подбираем оборудование и программное обеспечение

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

Ссылка для обмена:

Ссылка для форума:

Ссылка для сайта:

Есть вопросы, замечания, дополнения? Пишите в комментариях.
Заказать тексты для сайта (онлайн форма) - цена от 60 рублей, срок 24 часа
ошибки в банках, программное обеспечение

Страница: Фатальные ошибки в банковском программном обеспечении

Дата публикации: 2010-10-26 13:08. Последние изменения: 2016-02-27 13:51

наверх