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

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.

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

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

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

Таблица, хранящая документы
Таблица, хранящая документы

Отдельно стоит упомянуть инструкцию по установке.

Инструкция по установке ДБО «ИНИСТ»
Инструкция по установке ДБО «ИНИСТ»

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

Интересно, что документация по установке ДБО «ИНИСТ», распространяемая банками, вообще ничего не говорит про возможность смены пароля, только «нужно ввести sysdba и masterkey».

 

2. СФТ

Второй пациент, разработанный софтверной компанией, — банк-клиент СФТ. Если просканировать Nmap’ом (или любым другим сканером сети) хост, на который был установлен этот клиент, то среди открытых портов обнаружится 3050-й TCP-порт, принадлежащий СУБД Firebird. Попытка подключиться к нему с помощью стандартной учетной записи SYSDBA также увенчается успехом. Для коннекта используются следующие параметры: версия сервера — Firebird 2.5, файл базы данных — C:\SFT\BankClient7\<название организации>\Database\work.mdf. Ну и плюс стандартная учетка SYSDBA:masterkey.

Внешний вид банк-клиента СФТ
Внешний вид банк-клиента СФТ

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

Внутренности базы данных ДБО-клиента СФТ
Внутренности базы данных ДБО-клиента СФТ

Обнаружилась и очень интересная фишка — при установке клиента на экран выводится пользователь и пароль для подключения к базе.

Логин и пароль для подключения к базе в plaintext’е
Логин и пароль для подключения к базе в plaintext’е

Вот так некоторые вендоры беспокоятся о безопасности пользователей своего ПО. Ну а теперь давай рассмотрим, как обстоят дела у собственных разработок банков.

 

3. «ИК Банк»

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

Для доступа к базе используются следующие параметры: версия сервера — Firebird 1.5, файл базы данных — C:\TIBCl3\CLB.FDB.

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

Инструкция по смене пароля для пользователя SYSDBA
Инструкция по смене пароля для пользователя SYSDBA
Внутреннее устройство базы ДБО-клиента «ИК Банка»
Внутреннее устройство базы ДБО-клиента «ИК Банка»
 

4. Уралпромбанк

Детище Уралпромбанка также базируется на использовании Firebird.

Банк-клиент Уралпромбанка
Банк-клиент Уралпромбанка

Здесь тоже никто не позаботился о смене стандартного пароля или о закрытии порта СУБД. Поэтому, используя все ту же магическую связку SYSDBA:masterkey, можно подключиться к базе банк-клиента с любой машины из локальной сети. Для этого надо всего лишь в настройках подключения выставить соответствующие параметры: версия сервера — Firebird 2.5, файл базы данных — C:\UralProm3\db\BANK.FDB.

База данных банк-клиента Уралпромбанка
База данных банк-клиента Уралпромбанка

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

 

5. Прочее

В интернете можно найти и другие банки и ДБО, в инструкции которых прямо прописана установка общеизвестных паролей для доступа по сети к внутренней БД банк-клиента. Примечательно, что большинство пользователей «толстых» банк-клиентов об этом могут и не догадываться. Банк предоставил ПО, его установили по инструкции, а про то, что можно влезть в БД по сети, никто и не знает. Так и продолжают появляться подобные бреши в ИБ компаний. Что касается ДБО с инструкциями по смене паролей по умолчанию, то тут все зависит от пользователя. Хотя в идеале пользователь ДБО должен сам проверять, что за СУБД используется банк-клиентом и какой там клиент, даже если в инструкции об этом ничего не сказано. Но ведь так почти никто не делает, большинство компаний не имеют отношения к IT вообще.

WARNING


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

Выводы

  1. Все дополнительные средства безопасности ДБО, такие как токены, цифровые подписи и подтверждение платежей по СМС, сводятся на нет при использовании СУБД с авторизацией по умолчанию, что чревато ощутимыми финансовыми потерями и компрометацией всего компьютера с критичной информацией.
  2. Разработчики ПО любят переносить ответственность на потребителя, указывая, что тот должен самостоятельно прикрывать сторонние лазейки в БД. Хотя сами могли бы добавить своему ДБО безопасности, автоматически устанавливая сложный пароль при инсталляции банк-клиента. Ну или хотя бы сделать принудительным шагом смену пароля от БД при первом запуске клиент-банка. Использовать не привилегированную учетную запись для доступа к БД, а ограниченную, чтобы при компрометации учетки был невозможен захват всего сервера. Соблюдать и другие общепринятые стандарты безопасности работы с СУБД.

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    1 Комментарий
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии