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

WARNING


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

Где собака зарыта

В прошлом номере мы рассмотрели, как некорректно настроенная СУБД (а наличие включенной дефолтной учетной записи с известными всем логином/паролем и возможность доступа к серверу по сети трудно назвать корректной настройкой) может свести на нет все меры по разграничению доступа для персонала. Мы убедились, что, даже не имея на руках никаких 0day-сплоитов, не обладая никакими суперспособностями, практически любой человек, хоть немного связанный с IT, может спокойно получить доступ в любую точку предприятия или офиса (даже до кабинета гендира). Кто пропустил — рекомендую ознакомиться, может быть когда-нибудь в жизни пригодится. Надо сказать, что такой уязвимости оказались подвержены не только СКУД-системы, но и приложения дистанционного банковского обслуживания.

Речь о простой случайности/халатности, когда «толстый» клиент ДБО открывает порт СУБД (Firebird) наружу. Зачем это нужно — не совсем понятно. А еще меньше понятно, зачем разработчики оставляют стандартные логин и пароль от этой базы данных неизменными. В результате клиенты открывают счет в банке, устанавливают на компьютер бухгалтера клиент системы ДБО, который открывает доступ к внутренней базе данных всем сотрудникам компании. Эти сотрудники могут внести любое изменение в БД, например подменить реквизиты счета ежемесячного платежного поручения, и, когда придет время его оплатить, деньги компании уйдут не туда, куда планировалось. При этом использование токенов и СМС-кодов подтверждения не спасает — бухгалтер сам вставит токен и введет код из СМС, ведь он думает, что оплачивает легальную платежку. И все это реализуется без использования банковских троянов и не через интернет, не оставляет никаких следов и логов. Выяснить потом, как это произошло и тем более кто это сделал, будет крайне сложно, если вообще получится.

Да и без модификации БД можно обойтись — через доступ к БД возможно удаленно выполнять произвольные команды ОС с правами SYSTEM и захватить компьютер бухгалтера целиком!

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

 

Поиск уязвимых клиентов

Проверить наличие такой особенности в ДБО достаточно легко. Нужно установить клиентское приложение, выяснить, какая СУБД используется, и узнать, доступна ли она по сети, попробовать перебрать стандартные пароли (для Firebird это sysdba:masterkey). Проблема оказалась в другом — достать экземпляр ДБО порой сложно, для этого нужно открывать счет в банке, где он используется. А это время, формальности и обоснованные подозрения сотрудников банка. Да и заводить десятки счетов на одну компанию не очень хочется, а использовать подставные фирмы для этого трудоемко, особенно если учесть, что коммерческой выгоды здесь никакой нет.

Поэтому проверить все клиенты ДБО, которые хотелось, мне не удалось. Но среди проверенных некоторые оказались уязвимы. Про них и будет речь. Стоит, однако, учитывать, что у некоторых из этих систем есть версии с другими СУБД, где исследуемая уязвимость отсутствует.

 

Результаты

Условно все рассмотренные системы можно разделить на два типа, в зависимости от разработчика ПО:

  • ДБО, разработанные софтверной компанией. Внедряются в разные банки как готовое решение;
  • ДБО собственной разработки. Используется только в конкретном банке.

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

Установив системы ДБО и проверив на наличие уязвимости, я обнаружил, что ей подвержены:

  • две системы ДБО, разработанные софтверной компанией: банк-клиенты «ИНИСТ» и СФТ;
  • две системы ДБО собственной разработки банка: «ИК Банк» и Уралпромбанк.

Как я уже говорил, получение экземпляров ПО на тестирование — достаточно сложная процедура, и проверить удалось далеко не все варианты, которые хотелось. Тем не менее к части недоступных вариантов получилось добыть документацию, на основании которой можно сделать вывод, что эти системы также с большой долей вероятности уязвимы (сюда относится OTP Bank Ukraina).

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

 

1. «ИНИСТ»

Разработка компании «ИНИСТ» доступна в двух версиях, в зависимости от используемой СУБД. Уязвима версия с СУБД Firebird. Второй вариант, основанный на MS Jet Database Engine, лишен такого недостатка — никакие порты наружу не торчат, а значит, в этом случае система устойчива к описываемым воздействиям.

Внешний вид системы «ИНИСТ»
Внешний вид системы «ИНИСТ»

Ну а Firebird по старой доброй привычке открывает порт для всей локальной сети.

Открытый в локальную сеть порт СУБД Firebird
Открытый в локальную сеть порт СУБД Firebird

Подключиться к нему можно с помощью утилиты IBExpert. Для этого в настройках подключения к базе указываем адрес удаленного сервера, протокол TCP/IP, версию сервера Firebird 1.5 и файл базы данных C:\Program Files\INIST\IBCRemote31\bcdb.fdb, логин и пароль по умолчанию SYSDBA:masterkey.

Подключившись к БД, можно узнать любую информацию из банк-клиента и даже подправить ее удаленно. Например, узнать хеш пароля от ДБО-клиента.

Хеш пароля от ДБО-клиента
Хеш пароля от ДБО-клиента

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

Продолжение доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все материалы на сайте

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Вариант 2. Купи один материал

Заинтересовала информация, но нет возможности оплатить подписку? Тогда этот вариант для тебя! Обрати внимание: этот способ покупки доступен только для материалов, опубликованных более двух месяцев назад.


1 комментарий

  1. Loy

    25.04.2016 at 03:53

    Потрясающи, впечатляет)

Оставить мнение

Check Also

Господин Самоуничтожение. Как в домашних условиях смастерить Rubber Ducky со встроенной пиротехникой

Представь: ты втыкаешь в USB какую-то флешку, и вдруг в браузере открывается окно, где гру…