Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Reserved for RSN 07.06.02 12:19 Число просмотров: 6017
Автор: Komlin Статус: Незарегистрированный пользователь Отредактировано 11.06.02 14:57 Количество правок: 3
|
Предисловие.
Уважаемые читатели, заранее прошу Вас извинить за сумбурность и нечёткость изложения, вызванную недостатком времени и моими литературными неспособностями. ;)
IMHO, одной из причин популярности у клиентов программ для управлением счётом сторонних разработчиков является их надёжность по отношению к махинациям недобросовестных сотрудников АСУ Банка (это чисто теоретическая ситуация, мне такие прецеденты неизвестны).
Именно с целью оценить стойкость популярнейшего в РФ продукта iBank от компании Бифит и было проведено данное исследование ( в нём также частично затронуты вопросы безопасности банка). Следует отметить:
a) Обнаруженные схемы атаки на клиента возможны лишь при непорядочности со стороны сотрудников банка, что практически невероятно.
b) Подобное исследование стало возможно лишь благодаря политике открытости проводимой компанией Бифит, наличию общедоступной демо-версии и необфуцированного кода апплетов.
c) Руководство компании подробно, терпеливо и вежливо отвечало на мои вопросы, что и позволило получить описанную ниже картину.
d) Большинство из описанных ошибок легко устраняется организационными методами защиты принятыми в банках или грамотным подходом их сотрудников к вопросам безопасности.
В исследовании не рассматривались вопросы стойкости тонкого ПО с точки зрения безопасности браузера. Предполагалось, что клиент использует последние версии браузера и имеет стандартные системы защиты (антивирус, антитроян, файревол). Рассматривались схемы атаки, которые не должны были вызвать срабатываний защитных систем у клиента
Исследуемый продукт брался с демо-стенда сервера www.bifit.com, и свободно распространяемого для опытной эксплуатации дистрибутива, соответственно все замечания относятся к этим продуктам и их схеме распространения.
http://www.bifit.com/a-demo.html
http://www.bifit.com/s-download.html
Суть и причины ошибок (ошибки расположены в порядке возрастания из значимости и применимости с точки зрения автора, т.е. самая серьёзная -ошибка III)
************************************************************** I ) Отсутствие поддержки безопасного соединения с сервером www.bifit.com позволяет злоумышленнику в некоторых случаях подменить скачиваемое банком для опытной эксплуатации ПО или обновления к нему. Эта недоработка и её последствия гораздо лучше чем удалось мне описаны в нижестоящем сообщении exHacker;a.
http://www.bugtraq.ru/cgi-bin/forum.mcgi?type=sb&b=15&m=50356 "Реконструкция ошибки"
Следует отметить, что по словам сотрудников Бифит и их клиентов компания всегда готова предоставить дистрибутив лично или выслать почтой заверенной цифровой подписью( Обновления клиентам высылаютсятолькописьмом с подписью).
Также руководство компании пообещало ( а позднее повторило это обещание на форуме) в ближайшее время установить поддержку SSL на сервер. Насколько мне известно эта поддержка уже была в их планах.
************************************************************** II) В версии iBank со сторонней криптографией, при недобросовестности сотрудника банка, существует потенциальная возможность исполнения на машине клиента неподписанного кода с правами подписанного без каких-либо уведомлений пользователя.
"Отравленный" код будет исполняться с правами и от имени браузера (или его JVM) и соответственно не будет заблокирован/отслежен большинством firewall'ов и антитроянов, включая даже zonealarm. Эта ошибка позволяет легко и незаметно захватить машину даже опытного пользователя с грамотно поставленной защитой.
Причина:
1) При рекомендованной производителем процедуре предварительного ознакомлении клиента с продуктом компании ему предлагается скачать и установить незаверенную dll-библиотеку (bifitbzw.dll ) с сервера банка.
2) В классе AncortUtils апплета client.jar (client.cab) библиотека bifitbzw.dll вызывается методом System.loadLibrary() без какой-либо проверки её подлинности. Поскольку в IE апплет подписан с полными правами, то функции данной библиотеки будут исполнены вне зависимости от наличия или отсутствия в ней цифровой подписи.
3) По умолчанию, библиотека загружается из ненадёжного (по сравнению с апплетом) источника (сервера банка), при этом не предусмотрено никакой процедуры верификации на предмет искажения (www.../cert_crypto/bifitbz.dll )
3) Банк также получает данную библиотеку по открытым каналам в составе неподписанного архива. (http://www.bifit.com/s-download.html , файл архива IBANK2.ZIP адрес в архиве \ibank-2.0-se\lib\native\win32\bifitbz.dll)
В связи с этим недоработки 1,3 дают возможность непорядочному администратору подменить библиотеку на свой собственный код( заменяющийся после исполнения на исхожную библиотеку) и захватить контроль над машиной пользователя.
Следует отметить, что эта проблема возникает только если клиент решит предварительно ознакомиться с работой системы. При других вариантах подключения банки, имеющие лицензию ФАПСИ обязаны передавать библиотеку с заверением её контрольной суммы.
************************************************************** Ш) Схема подключения библиотек криптоалгоритмов, задаваемая внешними файлами храняшимися на сервере, позволяет непорядочному сотруднику банка заменить стандартные библиотеки генерации ключей и подписи данных на свою собственную. Эта операция весьма трудоёмка, но вполне реальна, с учётом, что за основу можно взять открытые оригинальные библиотеки изменив их лишь в деталях. Для её реализации в параметр ARCHIVE тега апплета файла makekeys.htm (client.htm) добавляется ещё один архив (неподписанный), и меняется наименование библиотеки в xml-файле.
Атака возможна в отношении апплетов client.jar и makekeys.jar
*-*-*-*-*-*-*- *.htm
<APPLET
...
ARCHIVE=..., badprovider.jar
...
Класс провайдера задаётся вызовом Class.forName(s1)
Security.addProvider((Provider)Class.forName(s1).newInstance());
s1 берётся из *transport.xml
-*-*-*-*-*-*- <CryptoEngine>
<Security provider="com.bifit.security.provider.AncortApplet" />
Последний оператор можно заменить например на
<Security provider="badcom.FalseApplet" />
(класс badcom.FalseApplet находится в библиотеке badprovider.jar ).
По утверждению разработчиков эта ошибка устранена в новых версиях продуктов Бифит, но на сервере bifit.com пока лежит уязвимый вариант.
C Уважением A. V. Komlin
|
- Reserved for RSN - Komlin 07.06.02 12:19 [6017]
|
|
|