информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetГде водятся OGRыЗа кого нас держат?
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
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Reserved for RSN 07.06.02 12:19  Число просмотров: 5851
Автор: 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
<theory> Поиск 








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


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