Удаленный взлом банков через ошибки конфигурации СУБД.

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

Взлом банков через ошибки в ПО Клиент-банк

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

[ad name=»Responbl»]

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

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

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

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

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

[ad name=»Responbl»]

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

Результаты

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

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

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

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

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

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

[ad name=»Responbl»]

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

1. «ИНИСТ»

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

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

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

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

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

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

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

[ad name=»Responbl»]

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

2. СФТ

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

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

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

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

3. «ИК Банк»

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

[ad name=»Responbl»]

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

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

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

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

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

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

5. Прочее

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

Выводы

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