информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяЗа кого нас держат?Атака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Phrack #70/0x46 
 Возможно, Facebook наступил на... 
 50 лет электронной почте 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Об ошибках в iBank 2 11.06.02 18:58  Число просмотров: 6481
Автор: Димитрий Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Добрый день, Александр!

> IMHO, одной из причин популярности у клиентов программ для
> управлением счётом сторонних разработчиков является их
> надёжность по отношению к махинациям недобросовестных
> сотрудников АСУ Банка (это чисто теоретическая ситуация,
> мне такие прецеденты неизвестны).

ИМХО, исключительно неверное утверждение.

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

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

В подавляющем большинстве случаев для клиента само собой разумеется, что предлагаемое банком техническое решение безопасно, ибо потери в случае взлома системы, несет не столько клиент, теряя всего лишь свои кровные деньги (пусть и немаленькие), громадные потери несет банк - ибо банк теряет ДОВЕРИЕ - самый главный капитал в банковском бизнесе.

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

Если же задаться целью обеспечить надежность решения по отношению к махинациям нелояльных банковских IT-сотрудников, то необходимым условием как минимум является получение клиентом дистрибутива из доверенного источника (коим банк мы уже не считаем). Тогда таким доверенным источником может быть компания-разработчик ПО. Но в компании-разработчике также работают люди, также есть наемные сотрудники, получающие зарплату, которые также могут оказаться нелояльны уже к своему работодателю.

В этом случае единственным решением является привлечение некоего независимого Сертификационного Центра, который бы проводил независимую экспертизу на соответствие заявленным возможностям и отвечал бы финансово за выданный клиенту дистрибутив (выполняя функции Хранилища дистрибутивов). Но и в этом Сертификационном Центре также работают люди, и проблема лояльности сотрудников уже ляжет на плечи Центра.

Вариант с публикациями хеш-функции от дистрибутива также влечет проблемы. Встанет вопрос: "Нет ли закладки в утилите верификации?" Ок. Выложим исходники. Но потом закрадутся сомнения в корректности работы классов java.math.*

Далее вспомним о возможности наличия закладки в компиляторе, потом - в среде исполнение (например в Java-машине). После - встанет вопрос о наличие закладки в ОС, о проверке целостности всей среды.

И под конец - микрокод с самом процессоре (ведь все последующие CPU после i8080 - то есть вся x86 линейка строится не на жесткой реализации логики исполнения в железе, а на микрокоде), коему в силу критичности финансовых (и уж не дай Бог военных) приложений, не стоит доверять...

Некоторые совсем конкретные параноики могут вспомнить о наличие контроллера прямого доступа к памяти в различных контроллерах-адаптера, и как следствие, обход защищенного уровня CPU с доступом к критически важным (ядро менеджера задач, менеджера безопасности ОС) областям оперативной памяти.

И так можно продолжать до бесконечности...

Но в самом конечном итоге мы всё равно придем к давно известной аксиоме - К НЕОБХОДИМОСТИ ДОВЕРИЯ.

Повторяюсь, клиента не должно заботить наличие в банках каких-то проблемных мест - расширенные права сисадмина и пр. Клиент получил от Банка дистрибутив. Клиент доверяет банковскому ПО. Всё.

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

> Именно с целью оценить стойкость популярнейшего в РФ
> продукта iBank от компании Бифит и было проведено данное
> исследование ( в нём также частично затронуты вопросы
> безопасности банка). Следует отметить:
> a) Обнаруженные схемы атаки на клиента возможны лишь при
> непорядочности со стороны сотрудников банка, что
> практически невероятно.

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

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

Спасибо, Алекснадр, за понимание нашей позиции.

Да, мы действительно открыты для взаимодействия. На нашем сайте всегда доступен дистрибутив коммерческой верси iBank 2 (демо-верии не сущеcтвует - есть демостенд, дабы желающие могли не ставить систему самому, а просто ознакомиться с "колокольни" Клиента и Операциониста).

Что касается кода, то во всех версиях iBank 2 код апплетов и сервера приложения обфусцирован.

> c) Руководство компании подробно, терпеливо и вежливо
> отвечало на мои вопросы, что и позволило получить описанную
> ниже картину.

Да уж, старались :-) Правда подробные объяснения отнимают массу времени и сил, но с другой стороны появляется рабочий материал для расширения FAQ'а.

> d) Большинство из описанных ошибок легко устраняется
> организационными методами защиты принятыми в банках или
> грамотным подходом их сотрудников к вопросам безопасности.

По поводу ошибок мы не со всеми высказанными предложениями согласны. См. ниже.

> Исследуемый продукт брался с демо-стенда сервера
> www.bifit.com, и свободно распространяемого для опытной
> эксплуатации дистрибутива, соответственно все замечания
> относятся к этим продуктам и их схеме распространения.
> http://www.bifit.com/a-demo.html
> http://www.bifit.com/s-download.html

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

> Суть и причины ошибок (ошибки расположены в порядке
> возрастания из значимости и применимости с точки зрения
> автора, т.е. самая серьёзная -ошибка III)
>*********************************************************

Ну что ж, начнем, прям по пунктам.

> I ) Отсутствие поддержки безопасного соединения с сервером
> www.bifit.com позволяет злоумышленнику в некоторых случаях
> подменить скачиваемое банком для
> опытной
эксплуатации ПО или обновления к нему.

Да, действительно, возможность подмены сайта БИФИТа у злоумышленника существует. Сложность атаки на подмену ресурса далеко нетривиальная и организационно сложна.

Первым направлением является получение привелегий рута и подмена записи в зоне bifit.com на DNS-серверах зоны bifit.com, либо подмена (или добавление записи) DNS-сервера банка, который используется потенциальной жертвой, собравшейся выкачать дистрибутив iBank 2.

Вторым направлением является взлом Web-сайта БИФИТа и подмена дистрибутива.

Третье направление - организация на трассе от банка до Web-сайта БИФИТа ложного www.bifit.com. Требует наличие возможности управлять маршрутизаторами одного из провайдеров, находящегося между банком и сайтом БИФИТа.

Использование протола SSL при загрузке дистрибутива с сайта исключит возможность подобных атак.

> Также руководство компании пообещало ( а позднее повторило
> это обещание на форуме) в ближайшее время установить
> поддержку SSL на сервер. Насколько мне известно эта
> поддержка уже была в их планах.

Все верно. Скоро включим SSL.

>*********************************************************
> II) В версии iBank со сторонней криптографией, при
> недобросовестности сотрудника банка, существует
> потенциальная возможность исполнения на машине клиента
> неподписанного кода с правами подписанного без каких-либо
> уведомлений пользователя.

Другими словами Александр заявляет, что у банковского IT-сотрудника, формирующего дистрибутив клиенту и передающего онный на дискете клиенту, существует возможность вместо истинного банковского ПО подсунуть клиенту ПО с закладкой, которое после выполнения своей "миссии" по похищению секретного ключа ЭЦП клиента заменит себя на правильный дистрибутив.

Я уже не раз в своих письмах упоминал, что ДОВЕРИЕ КЛИЕНТА В БАНКОВСКОМУ ПО - НЕОБХОДИМОЕ УСЛОВИЕ ДЛЯ РАБОТЫ СИСТЕМЫ.

Иначе при любых раскладах, вне зависимости от того толстый это или тонкий клиент, разработка БИФИТа, БСС или самого банка - клиент всегда будет ссылаться на недоверие к ПО, предоставляемое банком. И не важно КАК предоставленное - на дискете, CD-ROM'е, через Web или еще как-то.

Если говорить в общем, то "доверие клиента к ПО, предоставлемому банком - необходимое условие вообще для любой системы Банк-Клиент или Интернет-Банк, вне зависимости от разработчика".

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

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

> "Отравленный" код будет исполняться с правами и от имени
> браузера (или его JVM) и соответственно не будет
> заблокирован/отслежен большинством firewall'ов и
> антитроянов, включая даже zonealarm. Эта ошибка позволяет
> легко и незаметно захватить машину даже опытного
> пользователя с грамотно поставленной защитой.

Александр, я уже писал, что в системе iBank 2 Java-апплеты инициализируют DLL-ки (сертифицированное СКЗИ), переданные клиенту из банка на дискете под роспись в журнале поэкземплярного учета и Акта приемки-передачи. Это стандартная процедура для передачи любых сертифицированных СКЗИ.

Также в инструкциях по использованию сертифицированных СКЗИ есть упоминание об соблюдении клиентом "чистоты" среды исполнения, наличия кроме всего прочего внешних механизмов контроля целостности ПО.

> Причина:
>
> 1) При рекомендованной производителем процедуре
> предварительного ознакомлении клиента с продуктом компании
> ему предлагается скачать и установить незаверенную
> dll-библиотеку (bifitbzw.dll ) с сервера банка.

Здесь явное непонимание.

Банки, имеющие Лицензии ФАПСИ на распространение, техническое обслуживание и предоставление услуг с использованием сертифицированных СКЗИ, ОБЯЗАНЫ ВЕСТИ ПОЭКЗЕМПЛЯРНЫЙ УЧЕТ СКЗИ и ОБЕСПЕЧИТЬ ПЕРЕДАЧУ СКЗИ КЛИЕНТУ ГАРАНТИРОВАННЫЙ ПУТЕМ.

Но даже если какой-то из банков решил облегчить жизнь своим клиентам, и выложил СКЗИ на Web, то клиенты онные библиотеку будут скачивать через браузерный HTTP поверх SSL, и ручками копировать файлы в каталог с ОС. Апплеты автоматически и самостоятельно DLL-ки не инсталлируют!

Другими словами - в случае выкачивания библиотек с защищенного Web-сайта банка через протокол SSL сохраняется целостность выкаченного дистрибутива, ибо загружен онный из банка, явяющегося доверенным источником.

> 2) В классе AncortUtils апплета client.jar (client.cab)
> библиотека bifitbzw.dll вызывается методом
> System.loadLibrary() без какой-либо проверки её
> подлинности.

Во-первых, СКЗИ передана гарантированным путем, исключающим модификацию.

Во-вторых, если есть задача проверять среду исполнения от возможных внешних атак, то лучше использовать специально созданные для этих целей СЗИ. Например от ОКБ САПРа или Информзащиты. Да и модификации не обязательно подвергать СКЗИ - для похищения секретного ключа ЭЦП клиента правильнее уж сразу "приклеиться" к дисковым операциям и клавиатуре.

> 3) По умолчанию, библиотека загружается из ненадёжного (по
> сравнению с апплетом) источника (сервера банка), при этом
> не предусмотрено никакой процедуры верификации на предмет
> искажения (www.../cert_crypto/bifitbz.dll )

Опять непонимание. Клиент получает дистрибутив на дискете из банка. Либо выкачивает через SSL опять же с сайта банка (как впрочем и стартовые HTML-страницы, и Java-апплеты). В общем см. выше.

> 3) Банк также получает данную библиотеку по открытым
> каналам в составе неподписанного архива.

См. выше Ваши, Александр, же заявления о передаче дистрибутива от БИФИТа банкам.

> Следует отметить, что эта проблема возникает только если
> клиент решит предварительно ознакомиться с работой системы.
> При других вариантах подключения банки, имеющие лицензию
> ФАПСИ обязаны передавать библиотеку с заверением её
> контрольной суммы.

Если есть столь полное понимание ситуации, Александр, тогда зачем писать всё вышеприведенное? Дабы привлечь общественность из пальца высосанной "ошибкой"? Странная позиция.

>*********************************************************
> Ш) Схема подключения библиотек криптоалгоритмов, задаваемая
> внешними файлами храняшимися на сервере, позволяет
> непорядочному сотруднику банка заменить стандартные
> библиотеки генерации ключей и подписи данных на свою
> собственную. Эта операция весьма трудоёмка, но вполне
> реальна, с учётом, что за основу можно взять открытые
> оригинальные библиотеки изменив их лишь в деталях. Для её
> реализации в параметр ARCHIVE тега апплета файла
> makekeys.htm (client.htm) добавляется ещё один архив
> (неподписанный), и меняется наименование библиотеки в
> xml-файле.
>
> Атака возможна в отношении апплетов client.jar и
> makekeys.jar

На самом деле изначально возможность банка самостоятельно подключать к iBank 2 внешние криптобиблиотеки, полностью соответствующие спецификациям JCA и JCE, была ФИЧЕЙ, а не багом.

То есть раньше банк самостоятельно мог определить какие СКЗИ использовать в своем конкретном случае и переопределять это по мере необходимости. Подобные возможности присутствуют в подавлающем большинстве решений Б-К и И-Б.

Но потом, позже, из коммерческих соображений, мы взяли данную возможность исключительно под наш контроль, и теперь банки только с нашего ведома и согласия могут использовать то или иное стороннее СКЗИ.

Именно для этого в последних версиях iBank 2 - версии 2.0.1.4 и выше настройки используемого криптопровайдера перекочевали из внешних XML-описаний в подписанные архивы с Java-апплетами.

> По утверждению разработчиков эта ошибка устранена в новых
> версиях продуктов Бифит, но на сервере bifit.com пока лежит
> уязвимый вариант.

Уважаемый Александр!

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

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

Успехов Вам, Александр!

С уважением, Репан Димитрий
Компания "БИФИТ" - www.bifit.com
<theory> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach