Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
Об ошибках в iBank 2 13.06.02 15:36 Число просмотров: 2233
Автор: cybervlad <cybervlad> Статус: Elderman
|
> доказать, что спорный софт получен им от
> > банка/производителя.
> В случае III можно предъявить апплет с возможностью подмены
> провайдера. Он подписан производителем.
Александр, но мы же договорились, что в случае применения "внешней" криптографии все, что не входит в аплет, поставляется клиенту на дискете, по договору с указанием контрольных сумм. Согласно требованиям по безопасности СКЗИ на клиентском рабочем месте должен быть обеспечен контроль целостности среды.
> получения неподписанной информации в WEB.( Состояние
> сервера можно поменять в секунды.)
> Но на скандал хватит. Вполне. Собственно никакой подмены
> на практике может и не быть. Главное, что банку будет также
Опять запутались ;) Поехали с начала.
О какой подмене речь? DLL получена пользователем на дискете. Аплет подписан. Или какую именно DLL загружать прописывается в XML?
> > Организационные меры всю жизнь были наиболее
> действенными
> > при низких затратах на их реализацию.
> IMHO, очень трудно помешать АСУшнику украсть скажем SSL/RSA
> ключ сервера если он сам его и генерирует.
1. Если админ сам генерирует и ставит ключ, то это не банк, а сарай.
2. Помешать можно.
> Чтобы обеспечить нормальный контроль надо посадить на
> прослушку (видеонаблюдение) как минимум специалиста равного
> класса.
Зачем видеонаблюдение и прослушка? Изменения в сервер вносятся не каждый день. Все это должно делаться коллегиально. Никто из админов не должен иметь возможность внести изменения на сервер единолично.
> Я согласен, что в крупных банках это может быть сделано, но
> сейчас ещё есть куча мелких.
Ну да. Можно смело покупать продукт в нормальном магазине, а можно пойти в сомнительную лавочку. Действительно, каждый выбирает сам, но о последствиях пусть тоже думает сам.
> Собственно в описанной ситуации доверия внутреннему
> контролю банка ЭЦП просто не нужна. Вполне хватит
> симметричного
> ключа (или пароля) известного клиенту и асушнику.
Ну конечно. По нормальной схеме асуизатор к "боевой системе" вообще подходить не должен.
> > Начинаем смотреть неувязки.
> > 1. Сотрудник банка настолько крут, что может
> "врезаться" в
> > канал между клиентом и Бифитом? Или у него столько
> денег на
> > подкуп тех. персонала сетей?
> В предложенном варианте Dll качается с сервера банка.
В каком? В демо?
> Клиенту в этом случае идти арбитраж бесполезно. Поэтому его
> защита и должна лежать на плечах разработчика.
Не согласен. Разработчик (Бифит) делает прикладной продукт ( i-bank), предусматривая в нем интерфейс с внешним криптографическим модулем. Целостность всей этой байды должна обеспечиваться СЗИ от НСД. Целостность кода аплета - ЭЦП и сертификатом Thawte.
> > меры с правильной передачей дистрибутива СКЗИ клиенту
> > (договор, контрольне суммы). И клиент будет защищен
> > юридически, и нечестному асуизатору в банке (буде
> такой
> > найдется) неповадно будет...
>
> Наверное, но будет ли это уже тонкий клиент? Многие его
> преимущества (мобильность и др.) пропадут.
Удобство и безопасность всегда в противофазе. "Истинно тонкий" и "абсолютно мобильный" клиент по определению не может быть безопасным, хотябы потому, что он исполняется в недоверенной среде. Если человек хочет безопасности, должен смириться с ограничением мобильности (необходимость инсталляции хотябы критичных компонентов). Хочет работать из интернет-кафе или просто с чужого оборудования - пусть понимает, что это опасно. Это почти как в сексе: либо один партнер (безопасно), либо разнообразие (со всеми вытекающими последствиями ;)).
|
|
<theory>
|
Reserved for RSN 07.06.02 12:19
Автор: 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
|
|
Имеет смысл обсуждать только ошибку III. Она, увы, серьёзна. 17.06.02 12:17
Автор: (Не)Случайный посетитель Статус: Незарегистрированный пользователь
|
Уважаемые коллеги.
Из нарисованной Александром картины моё внимание привлекла только третья из описанных ошибок.
В первых двух случаях можно бесконечно спорить о том кто должен решать проблемы : производитель СКЗИ или банк.
Например в аттаке вследствии получения приложений по открытым каналам виновны оба (ошибк I).
Поэтому предлагаю не тратить силы и время и переходить к главной из описанных ошибок:
Возможности скрытой подмены сотрудником банка СКЗИ на заглушку с целью получения секретного пароля.
Если эта ошибка соответствует действительности и присуствовала в действующих версиях продукта банкам следует вежливо попросить клиентов перегенерировать ключи.
Также компании Бифит следует незамедлительно отозвать подпись под апплетами уязвимых версий ( если у них предсмотрен механизм для этого), если нет, то изменить протоколы передачи и формат подписываемого сообщения.
Необходимости таких мер вызвана возможностью применения устаревшего апплета.
Иначе открываются перспективы для подрыва репутации самих банков.
Всего хорошего.
P.S. Считаю бессмысленным обсуждать вопрос о номере уязвимой версии т.к. для похищения ключа может быть применён любой подписанный код.
|
|
Об ошибках в iBank 2 11.06.02 18:58
Автор: Димитрий Статус: Незарегистрированный пользователь
|
Добрый день, Александр!
> 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
|
| |
Об ошибках в iBank 2 13.06.02 07:47
Автор: cybervlad <cybervlad> Статус: Elderman
|
Добрый день, Дмитрий!
> банк. Если банк не способен качественно решать свои
> кадровые вопросы, нанимая нелояльных сотрудников, или же
> периодически не контролируя лояльности своих сотрудников, а
> также создавая потенциальные возможности для
> злоупотреблений - это плохой банк.
Тут предлога не пропущено? ;) Как это банк должен создавать возможности для злоупотреблений?
> В этом случае единственным решением является привлечение
> некоего независимого Сертификационного Центра, который бы
> проводил независимую экспертизу на соответствие заявленным
> возможностям и отвечал бы финансово за выданный клиенту
Речь не о функциях. Даже имеющаяся сейчас сертификация по НДВ, как бы это помягче сказать, вызывает недоумение. Экспертиза утверждает, что в продукте нет недокументированных возможностей. А что, если она их просто не нашла?
Мне кажется, более правильный подход должен заключаться в том, чтобы всегда можно было доказать, что именно получил клиент от производителя/поставщика. Т.е. ЭЦП/контрольные суммы. Не доверяем банку/разработчику - пусть они будут подписаны третьей стороной (нотариусом). Но именно подписаны для фиксации состояния, а не в смысле проверки функционала.
> Вариант с публикациями хеш-функции от дистрибутива также
> влечет проблемы. Встанет вопрос: "Нет ли закладки в утилите
> верификации?" Ок. Выложим исходники. Но потом закрадутся
> сомнения в корректности работы классов java.math.*
А почему обязательно java? Зачем утилита верификации из того же источника? Большинство образов CDROM выкладываются на веб с контрольными суммами MD5 (защита от случайного искажения, ибо злоумышленник и сумму пересчитать не обломится). Чем проверять - личное дело каждого. Можно взять md5sum из pgp или другую утилиту, можно выдрать процедуру расчета MD5 из любого open source софта, можно, в конце концов, самому написать по формальному описанию алгоритма. Главное, чтобы был зафиксирован способ расчета и его результат.
Это самый эффективный по соотношению цена/результат способ.
> Далее вспомним о возможности наличия закладки в
> компиляторе, потом - в среде исполнение (например в
> Java-машине). После - встанет вопрос о наличие закладки в
> ОС, о проверке целостности всей среды.
Это уже для законченных параноиков ;)
> Но в самом конечном итоге мы всё равно придем к давно
> известной аксиоме - К НЕОБХОДИМОСТИ
> ДОВЕРИЯ.
Просто чем дальше углубляемся, тем меньше вероятность закладки. Я полностью с Вами согласен, что чему-то доверять надо. иначе лучше сразу застрелиться. Вопрос в установке планки доверия. На мой взгляд, доверие клиента банковскому софту должно характеризоваться примерно так: "Да, я доверяю банку, софт хороший, в нем нет закладок (один фиг проверить не могу!). Но мне нужна возможность корректного разрешения конфликтной ситуации, когда банк будет утверждать, что поставил мне один софт, а у меня на самом деле другой". Справедливо? Все-таки банк и клиент не до конца доверяют друг другу, иначе они бы применяли симметричные коды подтверждения достоверности, а не ЭЦП.
> Если же банк хочет защититься от недобросовестного
> сисадмина, то он должен организовать комиссию из трех
> человек (лучше из пяти, один из которых - провокатор),
> которые бы при формировании клиентского дистрибутива
> несколько раз совместно проверяли бы дискету, далее
Не очень понял, зачем тут провокатор...
> Использование протола SSL при загрузке дистрибутива с сайта
> исключит возможность подобных атак.
При одном условии: сертификат для SSL "правильный" (Thawte etc). К сожалению, у некоторых банков (не буду делать антирекламу, называя конкретные имена) стоит самоподписанный сертификат, что создает возможность MitM. Впрочем, в Вашем случае, все нормально, это просто уточнение ;)
|
| |
Об ошибках в iBank 2 13.06.02 02:53
Автор: Komlin Статус: Незарегистрированный пользователь
|
Доброго времени дня, Дмитрий.
> В подавляющем большинстве случаев для клиента само собой
> разумеется, что предлагаемое банком техническое решение
> безопасно, ибо потери в случае взлома системы, несет не
> столько клиент, теряя всего лишь свои кровные деньги (пусть
> и немаленькие), громадные потери несет банк - ибо банк
> теряет ДОВЕРИЕ - самый главный капитал в банковском бизнесе.
В том и только том случае если клиент может доказать непорядочность банка.
В остальных случаях мелкий клиент бессилен перед последним.
Сегодня же именно начинающим фирмам особенно удобен интернет банкинг.
200-500 руб. в месяц - это выгоднее, чем тратить пол-часа час на ежедневные поездки в банк за выписками.
> кадровые вопросы, нанимая нелояльных сотрудников, или же
> периодически не контролируя лояльности своих сотрудников, а
> также создавая потенциальные возможности для
> злоупотреблений - это плохой банк. И врядли бизнес такого
> банка будет успешным и долгосрочным.
Организационные методы контроля по определению менее стойки нежели математические решения. Никакие орг. методы не способны обеспечить надёжность сравнимую со математической стойкостью ключа.
> доверенным источником может быть компания-разработчик ПО.
> Но в компании-разработчике также работают люди, также есть
> наемные сотрудники, получающие зарплату, которые также
> могут оказаться нелояльны уже к своему работодателю.
Это на порядок меньший риск для начинающего клиента, особенно если речь идёт о провинции. Кроме этого сторонний продукт используется во многих банках и риск от внесения в него закладок на порядок выше.
IMHO, рядовому клиенту с операциями до $100000 в год нечего опасаться что кто-то из Бифита заинтересуется им лично. Непорядочный сотрудник банка, имеющий возможность остаться безнаказанным совсем другое дело.
> Что касается кода, то во всех версиях iBank 2 код апплетов
> и сервера приложения обфусцирован.
При небольшой практике в работе с декомпилятом обфусцирование просто не замечаешь.
Лично мне оно совершенно не мешало, даже не заметил его существования.
>*********************************************************
>
> Другими словами Александр заявляет, что у банковского
> IT-сотрудника, формирующего дистрибутив клиенту и
> передающего онный на дискете клиенту, существует
> возможность вместо истинного банковского ПО подсунуть
> клиенту ПО с закладкой, которое после выполнения своей
> "миссии" по похищению секретного ключа ЭЦП клиента заменит
> себя на правильный дистрибутив.
Нет. При правильной организации такой процедуры ( передачей на CD-R, с росписями на диске и в журнале, фиксацией контрольных сумм) эта процедура маловероятна.
Речь шла об атаке через WWW-сервер в предложенной процедуре ознакомления с продуктом.
> > 1) При рекомендованной производителем процедуре
> > предварительного ознакомлении клиента с продуктом
> компании
> > ему предлагается скачать и установить незаверенную
> > dll-библиотеку (bifitbzw.dll ) с сервера банка.
> Банки, имеющие Лицензии ФАПСИ на распространение,
> техническое обслуживание и предоставление услуг с
> использованием сертифицированных СКЗИ, ОБЯЗАНЫ
> ВЕСТИ ПОЭКЗЕМПЛЯРНЫЙ УЧЕТ СКЗИ и ОБЕСПЕЧИТЬ ПЕРЕДАЧУ СКЗИ
> КЛИЕНТУ ГАРАНТИРОВАННЫЙ ПУТЕМ.
Речь идёт о процедуре предварительного ознакомления, клиента с ПО банка предложенной в дистрибутиве iBank, на неё такие требования не распространяются, а никакой разницы в моменте инфицирования клиента нет. Даже если клиент впоследствии заменит библиотеки на нормальные, компьютер уже захвачен. IMHO, вполне достаточно демо-стенда на Бифит. Разумеется такую процедуру проходят немногие.
> Другими словами - в случае выкачивания библиотек с
> защищенного Web-сайта банка через протокол SSL сохраняется
> целостность выкаченного дистрибутива, ибо загружен онный из
> банка, являющегося доверенным источником.
Только доказать, что именно этот продукт получен из банка уже нельзя.
> Если есть столь полное понимание ситуации, Александр, тогда
> зачем писать всё вышеприведенное? Дабы привлечь
> общественность из пальца высосанной "ошибкой"? Странная
> позиция.
Я писал о частном случае ознакомления. На него приведённые утверждения не распространялись (см. выше).
Кроме того я не предрекал ему каких-то последствий, а просто указал на то, что эта возможность
избыточна и потенциально опасна.
IMHO для процедуры ознакомления вплоне достаточно апплета с собственным крипто Bifit на вашем же сервере.
Там отлично сделанный демо стенд.
> На самом деле изначально возможность банка
> самостоятельно подключать к iBank 2 внешние
> криптобиблиотеки, полностью соответствующие
> спецификациям JCA и JCE, была ФИЧЕЙ, а
> не багом.
При всех её потенциальных достоинтсвах с точки зрения банка, это всё же опасная фича.
Теперь любой апплет старой версии может быть использован для атаки. Ведь он нормально подписан
и у пользователя не оснований не доверять ему. (Собственно большинство пользователей поставят доверие к продукта Бифит по умолчанию, чтобы не отвечать ежедневно на один и тот же вопрос).
>
> > По утверждению разработчиков эта ошибка устранена в
> новых
> > версиях продуктов Бифит, но на сервере bifit.com пока
> лежит уязвимый вариант.
>
> Уважаемый Александр!
>
> Я искренне рад, что наше решение для Интернет-Банкинга -
> система iBank 2 - привлекает внимание независимых экспертов
> и специалистов в области информационной безопасности. В
> любом случае независимые исследования части или всего
> решения, глубоко до самых корней или не очень, никогда не
> бывают лишними.
Да, в конечном счёте, при таком подходе реальная безопасность Вашего продукта должна обойти конкурентов.
С уважением Александр.
|
| | |
Об ошибках в iBank 2 13.06.02 09:19
Автор: cybervlad <cybervlad> Статус: Elderman
|
Добрый день, Александр!
> В том и только том случае если клиент может доказать
> непорядочность банка.
Это должен доказывать эксперт. Клиенту надо лишь доказать, что спорный софт получен им от банка/производителя.
> Организационные методы контроля по определению менее стойки
> нежели математические решения. Никакие орг. методы не
> способны обеспечить надёжность сравнимую со математической
> стойкостью ключа.
Александр, сейчас Вас безопасники закидают гнилыми помидорами.
Организационные меры всю жизнь были наиболее действенными при низких затратах на их реализацию. Логика проста: криптографические/математические методы сами по себе уязвимы, если не принять орг. мер. Более того, орг. методами "математику" обойти можно, обраное неверно.
> Нет. При правильной организации такой процедуры (
> передачей на CD-R, с росписями на диске и в журнале,
> фиксацией контрольных сумм) эта процедура маловероятна.
> Речь шла об атаке через WWW-сервер в предложенной процедуре
> ознакомления с продуктом.
Кстати, из начального постинга это не очень ясно.
Хорошо, давайте рассмотрим модель нарушителя в этой атаке.
1. Это сотрудник банка.
2. Этот банк использует i-bank
3. Сотрудник "окучивает" потенциального клиента подключиться к системе удаленного управления счетом (или знает, что это сделали люди из подразделения "завленкания клиентов").
4. Клиент идет знакомиться с системой на демо-стенд Бифита.
5. Всемогущий сотрудник банка устраивает подмену части кода (DLL внешней СКЗИ) с целью внедрить закладку на комп. клиента чтобы в дальнейшем, когда клиент подключится "по-настоящему", утянуть его секретный ключ ЭЦП.
Начинаем смотреть неувязки.
1. Сотрудник банка настолько крут, что может "врезаться" в канал между клиентом и Бифитом? Или у него столько денег на подкуп тех. персонала сетей?
2. Насколько мне известно, на демо-стенде не используется внешняя криптография по лицензионным соображениям (Бифит может раздавать свой продукт как угодно, но отдавать чужие DLL у него права нет). Что и где в этом случае должен подменять злоумышленник?
3. Совсем не факт, что для ознакомления и последующей работы будет использован один и тот же компьютер. Соответственно, упираться ради неясного результата никто не будет.
Лирическое отступление: тогда уж до кучи с апплетом надо подписывать и %WINDIR%\winsock.dll.
> Я писал о частном случае ознакомления. На него приведённые
> утверждения не распространялись (см. выше).
Александр, а политика? Вы думаете, что рядовой клиент разберется
в обсуждаемом вопросе и поймет, что возможность атаки, носит, скорее, теоретический характер? А осадок останется: "То ли он украл, толи у него украли..."
И еще один принципиальный момент, касающийся доказательности etc. Хорошо, пусть будет ssl, пусть будет ЭЦП аплета и всей пачки. Клиентский софт позицируется как "тонкий", это не "абоненткий пункт сети секретной связи", выражаясь армейским языком, на котором ведутся журналы работы. Что клиент будет предъявлять в арбитраже? Типичная отмазка нечестного банка: "У нас все нормально, можете посмотреть на сервере, а откуда взялась эта кривая DLL на компьютере клиента, мы не знаем".
Нет, все-таки тут надо не мудрить, а принять недорогие орг. меры с правильной передачей дистрибутива СКЗИ клиенту (договор, контрольне суммы). И клиент будет защищен юридически, и нечестному асуизатору в банке (буде такой найдется) неповадно будет...
/Vlad.
|
| | | |
Об ошибках в iBank 2 13.06.02 11:33
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 13.06.02 11:50 Количество правок: 2
|
Привет Влад.
>Это должен доказывать эксперт. Клиенту надо лишь доказать, что спорный софт получен им от
> банка/производителя.
В случае III можно предъявить апплет с возможностью подмены провайдера. Он подписан производителем.
Принципиальной возможности строго доказать изменения или отсуствие таковых в xml невозможно по определению, как и влюбом другом случае
получения неподписанной информации в WEB.( Состояние сервера можно поменять в секунды.)
Но на скандал хватит. Вполне. Собственно никакой подмены на практике может и не быть. Главное, что банку будет также трудно
строго доказать обратное. На его заверения в надёжности орг. контроля всегда мжно ответить: Вы то лицо заинтересованное, за
вину сотрудника если её докажут отвечать Вам.
Здесь классическая ситуцация когда недоказанность вредна обеим сторонам.
> Александр, сейчас Вас безопасники закидают гнилыми
> помидорами.
> Организационные меры всю жизнь были наиболее действенными
> при низких затратах на их реализацию.
IMHO, очень трудно помешать АСУшнику украсть скажем SSL/RSA ключ сервера если он сам его и генерирует.
Чтобы обеспечить нормальный контроль надо посадить на прослушку (видеонаблюдение) как минимум специалиста равного класса.
Например, чтобы понять что он именно злонамеренно модифицирует xml, а не настраивает его надо также хорошо разбираться
в продукте.
Я согласен, что в крупных банках это может быть сделано, но сейчас ещё есть куча мелких.
Не знаю как в Москве, а у нас с десяток таких наберётся.
И таких примеров до кучи. Никто не говорит что оргметоды плохи, но IMHO стойкость подмены ключа правильном алгоритме очень
высока и сама по себе идеальная защита.
Собственно в описанной ситуации доверия внутреннему контролю банка ЭЦП просто не нужна. Вполне хватит симметричного
ключа (или пароля) известного клиенту и асушнику.
>
> Кстати, из начального постинга это не очень ясно.
Это моя вечная проблема. :(
> Хорошо, давайте рассмотрим модель нарушителя в этой атаке.
> 1. Это сотрудник банка.
> 2. Этот банк использует i-bank
> 3. Сотрудник "окучивает" потенциального клиента
> подключиться к системе удаленного управления счетом (или
> знает, что это сделали люди из подразделения "завленкания
> клиентов").
> 4. Клиент идет знакомиться с системой на демо-стенд Бифита.
> 5. Всемогущий сотрудник банка устраивает подмену части кода
> (DLL внешней СКЗИ) с целью внедрить закладку на комп.
> клиента чтобы в дальнейшем, когда клиент подключится
> "по-настоящему", утянуть его секретный ключ ЭЦП.
>
> Начинаем смотреть неувязки.
> 1. Сотрудник банка настолько крут, что может "врезаться" в
> канал между клиентом и Бифитом? Или у него столько денег на
> подкуп тех. персонала сетей?
В предложенном варианте Dll качается с сервера банка.
> 2. Насколько мне известно, на демо-стенде не используется
> внешняя криптография по лицензионным соображениям (Бифит
> может раздавать свой продукт как угодно, но отдавать чужие
> DLL у него права нет). Что и где в этом случае должен
> подменять злоумышленник?
Dll и ссылающаяся на них html-ина лежат в архиве iBank.zip.
> 3. Совсем не факт, что для ознакомления и последующей
> работы будет использован один и тот же компьютер.
Да, не факт. Как и обратное утверждение.
> Соответственно, упираться ради неясного результата никто не
> будет.
Не получиться с одним, получится с другим. Злоумышленнику в приниципе без разницы кого накрывать.
> И еще один принципиальный момент, касающийся
> доказательности etc. Хорошо, пусть будет ssl, пусть будет
> ЭЦП аплета и всей пачки. Клиентский софт позицируется как
> "тонкий", это не "абоненткий пункт сети секретной связи",
> выражаясь армейским языком, на котором ведутся журналы
> работы. Что клиент будет предъявлять в арбитраже?
Клиенту в этом случае идти арбитраж бесполезно. Поэтому его защита и должна лежать на плечах разработчика.
Это я позиции клиента говорю. Может в жизни оно и не так. По сути продукт-то продаётся банку, а их вопрос защищённости
клиента, когда последний не сможет ничего доказать не сильно волнует.
> Типичная
> отмазка нечестного банка: "У нас все нормально, можете
> посмотреть на сервере, а откуда взялась эта кривая DLL на
> компьютере клиента, мы не знаем".
> Нет, все-таки тут надо не мудрить, а принять недорогие орг.
> меры с правильной передачей дистрибутива СКЗИ клиенту
> (договор, контрольне суммы). И клиент будет защищен
> юридически, и нечестному асуизатору в банке (буде такой
> найдется) неповадно будет...
Наверное, но будет ли это уже тонкий клиент? Многие его преимущества (мобильность и др.) пропадут.
Александр.
|
| | | | |
Об ошибках в iBank 2 13.06.02 15:36
Автор: cybervlad <cybervlad> Статус: Elderman
|
> доказать, что спорный софт получен им от
> > банка/производителя.
> В случае III можно предъявить апплет с возможностью подмены
> провайдера. Он подписан производителем.
Александр, но мы же договорились, что в случае применения "внешней" криптографии все, что не входит в аплет, поставляется клиенту на дискете, по договору с указанием контрольных сумм. Согласно требованиям по безопасности СКЗИ на клиентском рабочем месте должен быть обеспечен контроль целостности среды.
> получения неподписанной информации в WEB.( Состояние
> сервера можно поменять в секунды.)
> Но на скандал хватит. Вполне. Собственно никакой подмены
> на практике может и не быть. Главное, что банку будет также
Опять запутались ;) Поехали с начала.
О какой подмене речь? DLL получена пользователем на дискете. Аплет подписан. Или какую именно DLL загружать прописывается в XML?
> > Организационные меры всю жизнь были наиболее
> действенными
> > при низких затратах на их реализацию.
> IMHO, очень трудно помешать АСУшнику украсть скажем SSL/RSA
> ключ сервера если он сам его и генерирует.
1. Если админ сам генерирует и ставит ключ, то это не банк, а сарай.
2. Помешать можно.
> Чтобы обеспечить нормальный контроль надо посадить на
> прослушку (видеонаблюдение) как минимум специалиста равного
> класса.
Зачем видеонаблюдение и прослушка? Изменения в сервер вносятся не каждый день. Все это должно делаться коллегиально. Никто из админов не должен иметь возможность внести изменения на сервер единолично.
> Я согласен, что в крупных банках это может быть сделано, но
> сейчас ещё есть куча мелких.
Ну да. Можно смело покупать продукт в нормальном магазине, а можно пойти в сомнительную лавочку. Действительно, каждый выбирает сам, но о последствиях пусть тоже думает сам.
> Собственно в описанной ситуации доверия внутреннему
> контролю банка ЭЦП просто не нужна. Вполне хватит
> симметричного
> ключа (или пароля) известного клиенту и асушнику.
Ну конечно. По нормальной схеме асуизатор к "боевой системе" вообще подходить не должен.
> > Начинаем смотреть неувязки.
> > 1. Сотрудник банка настолько крут, что может
> "врезаться" в
> > канал между клиентом и Бифитом? Или у него столько
> денег на
> > подкуп тех. персонала сетей?
> В предложенном варианте Dll качается с сервера банка.
В каком? В демо?
> Клиенту в этом случае идти арбитраж бесполезно. Поэтому его
> защита и должна лежать на плечах разработчика.
Не согласен. Разработчик (Бифит) делает прикладной продукт ( i-bank), предусматривая в нем интерфейс с внешним криптографическим модулем. Целостность всей этой байды должна обеспечиваться СЗИ от НСД. Целостность кода аплета - ЭЦП и сертификатом Thawte.
> > меры с правильной передачей дистрибутива СКЗИ клиенту
> > (договор, контрольне суммы). И клиент будет защищен
> > юридически, и нечестному асуизатору в банке (буде
> такой
> > найдется) неповадно будет...
>
> Наверное, но будет ли это уже тонкий клиент? Многие его
> преимущества (мобильность и др.) пропадут.
Удобство и безопасность всегда в противофазе. "Истинно тонкий" и "абсолютно мобильный" клиент по определению не может быть безопасным, хотябы потому, что он исполняется в недоверенной среде. Если человек хочет безопасности, должен смириться с ограничением мобильности (необходимость инсталляции хотябы критичных компонентов). Хочет работать из интернет-кафе или просто с чужого оборудования - пусть понимает, что это опасно. Это почти как в сексе: либо один партнер (безопасно), либо разнообразие (со всеми вытекающими последствиями ;)).
|
| | | | | |
Об ошибках в iBank 2 14.06.02 05:07
Автор: Komlin Статус: Незарегистрированный пользователь
|
> Александр, но мы же договорились, что в случае применения
> "внешней" криптографии все, что не входит в аплет,
> поставляется клиенту на дискете, по договору с указанием
> контрольных сумм. Согласно требованиям по безопасности СКЗИ
> на клиентском рабочем месте должен быть обеспечен контроль
> целостности среды.
Совершенно с Вами согласен, Влад. Процедура передачи внешних СКЗИ должна быть надёжной.
В принципе не так уж Важен конектретный механизм. Лучше всего - передача на внешнеем носителе CD-R
с фиксацией контрольных сумм, но допустима и подпись в апплете.
Проблема iBank описанная под номером III состоит в том, что в автоматически, без ведома и участия клиента,
подключается находящаяся на сервере неподписанная криптобиблиотека. Для этого достаточно чуть-чуть
изменить HTML -файл.
> Опять запутались.Опять запутались ;) Поехали с начала.
> О какой подмене речь? DLL получена пользователем на дискете. Аплет подписан.
Влад, речь идёт о другой ошибке, за # III. Она позволяет подключать библиотеки непосредственно
с сервера банка а не с машины клиента. Соответственно никакого ПО клиенту передавать не надо.
>Или какую именно DLL загружать прописывается в XML?
Почти так. Банк имеет право подключить свою JAR библиотеку с сервера, указав её имя в XML файле на сервере.
Кончено, Java это не DLL,захватитть машину она не сможет, а вот "засветить" секретный ключ или нестойко
сгенерировать его - пожалуйста
Поэтому я и считаю эту недоработку самой серьёзной из всех.
IMHO, Нельзя основывать защищённость клиента исключительно на оргметодах банка. В противном случае технология
цифровой подписи просто не нужна. В ней нет смысла если банк имеет доступ к секретному ключу.
Более грамотно и полно эта мысль изложенна на bankir.ru
Возвращаемся к ошибке II.
> > В предложенном варианте Dll качается с сервера банка.
> В каком? В демо?>
В инсталляте бифит. В предисловии написанно, что на сервере лежит подлинный инсталлят, отличающийся
лишь отсуствием лицензии.
> Не согласен. Разработчик (Бифит) делает прикладной продукт
> ( i-bank), предусматривая в нем интерфейс с внешним
> криптографическим модулем. Целостность всей этой байды
> должна обеспечиваться СЗИ от НСД. Целостность кода аплета -
> ЭЦП и сертификатом Thawte.
Только апплету надо предупреждать клиента, когда вместо заявленных стандартных
модулей бифит или Базис-Защита подключается совсем другой (это снова об ошибке III).
Ведь клиент вправе знать с чьей крипто он работает и иметь возможность проверить её подлинность?
Или я ошибаюсь?
> Удобство и безопасность всегда в противофазе. "Истинно
> тонкий" и "абсолютно мобильный" клиент по определению не
> может быть безопасным, хотябы потому, что он исполняется в
> недоверенной среде. Если человек хочет безопасности, должен
> смириться с ограничением мобильности (необходимость
> инсталляции хотябы критичных компонентов). Хочет работать
> из интернет-кафе или просто с чужого оборудования - пусть
> понимает, что это опасно. Это почти как в сексе: либо один
> партнер (безопасно), либо разнообразие (со всеми
> вытекающими последствиями ;)).
Не знаю, здесь от подмены библиотеки защититься очень легко встроив XML (и при желении DLL) в подписанную
часть апплета. Что и сделано в новой версии.
Александр.
|
|
Поправка 11.06.02 16:18
Автор: Komlin Статус: Незарегистрированный пользователь
|
> По утверждению разработчиков эта ошибка устранена в новых
> версиях продуктов Бифит, но на сервере bifit.com пока лежит
> уязвимый вариант.
Поправка, уязвимая версия осталась только на демо-стенде, но и оттуда она сегодня будет убрана.
|
|
Это чтобы застолбить номер мессаги и потом с других сайтов на нее ссылаться? :) 07.06.02 12:36
Автор: Sandy <Alexander Stepanov> Статус: Elderman
|
|
|
| |
Просто чтобы не править текст сообщения RSN, которое будет опубликовано завтра, и которое ссылается на это сообщение :) 07.06.02 23:22
Автор: dl <Dmitry Leonov>
|
|
|
| | |
2dl. Реконструкция ошибки. Угадал? 10.06.02 09:15
Автор: exhacker Статус: Незарегистрированный пользователь
Отредактировано 10.06.02 09:20 Количество правок: 2
|
Что-то новое на bugtraq'e. Раньше анонсов не встречалось.
Попробую догадаться про что.
На форуме bankir.ru промелькнуло сообщение комлина о наличие в ibank орг. ошибки в защите которая будет в воскресенье опубликованна на rsn. Потом подозрительно тихий ответ Бифита, "мы готовы ответить...", затёртое сообщение комлина, и удивлённые вопросы посетителей, что всё это значит. Здесь сообщения в обещанные сроки не появилось. Полагаю оно и непоявится поэтому и пишу сам..
Что значило слово "орг." Если "организационная" то это практически всё объясняет.
Полагаю комлин писал об ошибке связанной с ненадёжной инсталляцией ibank: об отсуствии сертификата на сервер bifit.com и подписи под некоторыми приложениями.
Это позволяет подменять программы при их установке.
Угадал?
Реконструкция ошибки в iBank.
Копия ответа с http://dom.bankir.ru/showthread.php?s=1b613c69e99fa65e9f042f304bf55f26&postid=380876#post380876
Ц и т а т а :
--------------------------------------------------------------------------------
Экспертик.
Орг. - значит организационная? Каким контекстом это может быть отнесено к программе?.
--------------------------------------------------------------------------------
Организационная – значит не в самой программе, а в её окружении и условиях применения (например инсталляции).
Наталья, раз уж Вы "эксперта" в своём нике держите, надобно уметь с пол-намёка догадываться
Этой фразы Комлина вполне достаточно. Может он мог рассказать подбробнее , но полагаю, ноги отсюда росли, а подробности не столь уж важны.
Не исключаю, что всё-таки ошибся и Комлин писал про другую ошибку, но эту рекомендую устранить как можно быстрее.
Зайдите на bifit.com, скачайте продукт. http://www.bifit.com/s-download.html
Ц и т а т а :
--------------------------------------------------------------------------------
" У нас нет никаких демонстрационных версий, lite-версий, пробных версий и т.п. На нашем сайте доступен единый коммерческий дистрибутив системы iBank 2. " (И апдейты к нему там же - моё прим).
--------------------------------------------------------------------------------
На этом можно и остановиться 8=)
Программа , её утилиты и апдейты передаются по http [ftp] . Только по нему 8={ ).
В переводе на профессиональный сие значит, что архив получаемый банком после скачивания зависит:
а) От провайдера бифит-а
б) от его (банка) провайдера.
в) от тех кто между провайдерами на канале сидит
г) от тех кто их сломать может.
SSLя или Сертификата там и в помине нет ( https://www.bifit.com выдаёт ошибку). Хочешь ни хочешь качай в открытую. И проверить неизменность скачанного нельзя.
После этого продукт предлагается устанавливать на ответственные участки работы банка и его клиентов
Почему их ещё ФАПСИ как лицензиата за такой способ передачи ПО и обновлений к нему не взгрело непонятно.
Такой способ передачи возможен только ежели речь едёт о заверенном (напр. цифровой подписью ПО). Смотрим архив. Общей подписи нет. Большинство приложений Java (например admin.jar) действительно заверены, но приложения третих сторон (драйверы JDBC от Oracle , сервлеты от Sun, какие-то dll-ки, tools.jar и т.д ) доступны для модификации, не говоря уж о батниках, которые их вызывают
Даже Микрософт позволяет получить свои коммерческие продукты по закрытым каналам. (https://www.microsoft.com)
Как люди, коммерческое крипто пишущее, важности его надёжной передачи не понимают не постижимо.
2Komlin: Я угадал? Речь шла:
об отсуствии у bifit.com сертификата (поддержки SSL) и незаверенности архива?
2Бифит
Понимаю для сервера это нагрузка и сертификат денег стоит, но клиенты то у Вас не простые , и программка не копеечный. Или Вы не знаете какие у провайдеров (особенно региональных) каналы надёжные или какая сейчас у их сотрудников зарплата (в среднем $300)?
Коли хорошего хакера под рукой не окажется - $1000 -$3000 сотруднику провайдера на закладку на канал с головой хватит (всего-то дела - запись в DNS на недельку поправить -).
За прямую дорожку на сервер банка (или к его клиенту) эту сумму рано или поздно заплатят.
Ежели Вам мои слова теоретизированием пустым кажутся вспомните как Ленту.Ру ломали. Никто об их стенки (firewall'ы) не бился (думаю они ещё попрочнее Ваших, да банковских будут). Тихонько провайдера накрыли и в нужный момент в аккурат на новогодние праздники поменяли новость на свою.
Подробности здесь: http://bugtraq.ru/review/archive/2000/09-01-0.html
Хорошо парень больной был и какую-то чушь написал. Ведь мог-бы пол-страны на уши поставить.
Сейчас так добрая половина взломов делается. Провайдер(канал) по определению более уязвим чем сервер.
Поэтому господа, не надо 50 баксов на сторонний сертификат жалеть. А лучше потратьте $$$ на авторизатора VeriSign , который в IE по умолчанию прописан . Потом гораздо дороже выйдет ежели выяснится, что банк или его клиента подменённым ПО нагреют.
А ещё лучше без крайней необходимости критичное к безопасности ПО с сервера не распространять вообще. Тем паче открытого.
С Уважением exHacker.
|
| | | |
тепло 10.06.02 21:24
Автор: dl <Dmitry Leonov>
Отредактировано 10.06.02 21:35 Количество правок: 1
|
Даже горячо :)
Насчет публикации - жду отмашки.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
