23 октября, понедельник 14:45
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

О надежности и безопасности ИБ

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • О надежности и безопасности ИБ

    "Не вынесла душа поэта" очередного пустого наезда со стороны г-на Capt на ненадежность и незащищенность истинно тонких решений для Интернет-Банкинга в топике "Статистика Internet-banking". Посему был открыт новый топик, где я постарался высказать свое исключительно личное субъективное мнение. Итак:
    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>отправил Capt
    Я думаю, что любой клиент банка согласится взять дискету с дополнительной системой защиты транзакций. А установка, насколько я знаю, занимает не более 1-ой минуты. Так что, и банк и клиент банка лучше будут использовать Интернет-клиент чуть ╚потолще╩, чем у самого что ни на есть ╚истинно тонкого клиента╩ БИФИТ, но более надёжного и защищённого, ведь дело касается денег.[/quote]

    БОльшая защищенность решений, основанных на установке спец.ПО у клиента, IMHO, не более чем иллюзия. В общем случае, атаку на конкретное нативное спец. ПО, установленное у клиента, провести на порядок легче, чем на Java-апплет, которого нет на компьютере клиента. В случае с Java-апплетом атаку с целью модификации или некорректного исполнения последнего можно попробовать провести на виртуальную Java-машину Web-браузера. При этом надо обеспечить нормальную работоспособность любых апплетов, но в случае исполнения определенного апплета не выполнять или выполнять другим образом определенные функции, заложенные в апплете. Как технический специалист, полностью погруженный в эту тему, считаю, что уровень сложности такой задачи по модификации JVM чрезвычайно высок. Это эквивалетно модификации микрокода микропроцессора с целью некорректного исполнения только определенной конкретной прогаммы, а все остальные должны совершенно нормально работать.

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

    Далее будет немного технических моментов. При подписи html-формы, в полях которой могут быть и поля платежки, отправляемой клиентом в банк, клиентское спец.ПО формирует ЭЦП от полей html-формы, и методом POST (реже GET) по протоколу http отправляет параметры в банк (естественно еще и всё шифруя). В банке данные поступают на серверную часть спец.ПО, расшифровываются, проверяется ЭЦП. Здесь все нормально. А вот дальше начинается прореха. Серверная часть спец.ПО передает Web-приложению поля html-формы, которые были подписаны, ID ключа, ЭЦП, результат проверки подписи. Но самое главное, серверное спец.ПО не передает Web-приложению через четко определенный служебный параметр список полей html-формы, которые были подписаны.

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

    В Банке уже на серверной части спец.ПО происходит расшифровка и проверка ЭЦП. ЭЦП корректна (пока все нормально). Далее серверная часть спец.ПО передает Web-приложению пришедший http-запрос вместе с пришедшими параметрами. Web-приложение получает из запроса ID ключа, ЭЦП и результат проверки. Так как результат проверки ЭЦП положительный, Web-приложение считывает параметры из заполенной (модифицированной) html-формы. Но Web-приложение не знает и не может знать, что в первоначальную html-форму было добавлено дополнительное поле, которое также участвовало в процедуре подписи на стороне клиента! Web-приложение сохраняет в БД только те поля, о которых оно знало (то есть поля платежки), сохраняет ЭЦП, ID-ключа, время подписи, но, самое главное, не сохраняет в БД вставленное клиентом-злоумышленником значение дополнительного поля.

    В итоге, в БД сохраняется не весь ранее подписанный документ. Потом при проверке ЭЦП выясняется, что ЭЦП то некорректна! В банке нет электронного документа с корректной ЭЦП клиента, на основании которого банк выполнил те или иные действия по счету клиента. А платеж банк уже исполнил и денюжки со счета клиента уплыли. Клиент же выставил притензию и просит доказать банк, на основании чего тогда банк списал деньги.

    В общем-то это упрощенное описание, но уже технически опробованное на некоторых решениях, развернутых для опытной эксплуатации. Это один из примеров непродуманного сопряжения технологии Proxy SSL с Web-приложениями. Есть другие. И здесь никто не ломал никакие криптографические алгоритмы. Эти алгоритмы просто неправильно использовались. Этот пример еще раз подтверждает давно брошенную фразу Брюса Шнайера: "Системы защиты не ломают - их обходят".

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

    Только к одному призываю, чтобы пиарщики и маркетологи не брали на себя функции технических специалистов, не рассказывали, начитавшись PCWeek'а, как работает в продаваемых ими продуктах механизмы защиты информации. Ну вспомните, что написал Барсуков (Банк'с Софт Системс) по поводу BS-Defender'а - это же была, с точки зрения специалиста, полная глупость, пустое перечисление алгоритмов и используемых методов!

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

  • #2
    Речь идет не об абстрактной ошибке, а о реальных конкретных проектах/продуктах, продвигаемых и эксплуатирующих разными организациями в Интернете. Баг как раз и кроется в том, что Web-приложение не знает (и не может знать) о существовании дополнительного поля, вставленного реальным зарегистрированным клиентом-злоумышленником. Естественно серверная часть модуля защиты видит, какие поля были подписаны. И баг исправляется с помощью передачи от серверной части модуля защиты Web-приложению еще одного параметра, содержащего список полей, которые были присланы от клиента в запросе POST, и которые были подписаны клиентом. В этом случае, Web-приложение увидев, что в списке полей, подписанных клиентом, присутствует лишнее поле, сразу отвергнет документ, и не будет анализировать параметр "результат проверки ЭЦП клиента".

    Предлагаемый Вами (Seva) вариант проверки ЭЦП после того, как документ был сохранен Web-прложением в Сервере БД, также устраняет описанный баг. Но в этом случае серверная часть модуля защиты должна кроме всего прочего еще и работать с Сервером БД. Я же описывал баг, присутсвующий в решении типа "Proxy SSL". Когда ЭЦП проверяется непосредственно в http-запросе клиента, и Web-приложению возвращается в том числе и результат проверки.

    Повторюсь, это не абстрактный теоретический баг. Это конкретно присутствующий баг в одном из СКЗИ российского разработчика (находящегося при этом в фазе получения Сертификата Соответствия ФАПСИ).

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

    Комментарий


    • #3
      Хмм... Да, интересный подход. Но мне кажется, что вы упускаете из виду возможность того, что пришедшая шифрованная/подписанная HTML-форма может проходить предварительную разборку. Т.е. сначала она анализируется, затем нужные поля (которые как раз и составляют "электронный документ") кладутся в базу, а уже затем выполняются какие-либо действия... В этом случае такой фокус с hidden-полем не пройдет, как МНЕ кажется

      Комментарий


      • #4
        Хм... Да, вы правы. Хотя я считаю, что это - всего лишь недосмотр проектировщиков этой системы. В принципе, их система тоже вполне жизнеспособна, все, что нужно для корректной работы - всего лишь прошивание структуры запроса в серверную часть. Она будет брать только нужные поля и проверять подпись под НИМИ. При этом ваша искаженная форма будет признана неверной Поля передавать не надо, с базой работать тоже... Исправить не так уж и сложно. Или я не прав?

        Комментарий


        • #5
          Ребята! Это одна сторона дела. Другая - пользователь. Он может потерять ключи, их могут перехватить и т.п. Самое действенное средство - динамические пин-коды на банковские транзакции!!!

          Герасимов Александр

          Комментарий


          • #6
            Реплика г-на Д.Репана по поводу того, что "прореха" в защите системы Internet-Banking, рассматриваемая в теме "О надежности и безопасности ИБ", это -

            "... конкретно присутствующий баг в одном из СКЗИ российского разработчика (находящегося при этом в фазе получения Сертификата Соответствия ФАПСИ)",

            дает основание полагать, что речь идет о продукте Inter-PRO разработки Сигнал-КОМ. Вполне, однако, возможно, что г-н Д.Репан имел ввиду какой-то другой продукт, поскольку описываемая им ситуация невозможна в тех реально эксплуатируемых банковских приложениях, где в качестве средства защиты HTTP-трафика используется Inter-PRO.
            Компания Сигнал-КОМ до сих пор не ввязывалась в дискуссии с г-ном Репаном , т.к. его способ полемики со своими конкурентами для нас неприемлем (хотя нельзя не восхищаться талантливым маркетинговым ходом Дмитрия, который он избрал для рекламы своего продукта). Тем не менее, по просьбе наших реальных и потенциальных клиентов мы вынуждены прокоментировать приведенный в топике пример, поскольку получили ряд писем и звонков с просьбой разъяснить ситуацию: о нашей ли компании идет речь и действительно ли имеет место описанная некорректность взаимодействия "...серверной части спец.ПО защиты (проверяющей ЭЦП под полями html-форм и шифрование данных) с Web-приложением". Кроме того, мы получили несколько писем примерно такого содержания: "Вы все-таки делаете ошибку, когда не комментируете подобные высказывания Репана на Банкире.Ру, так как многие посетители принимают их за чистую монету".

            Теперь по существу. Подробное описание процедуры проверки подписи HTML-форм сервером Inter-PRO приводится в руководстве пользователя, которое можно скачать со страницы: www.signal-com.ru/eng/articles/images/p1/index_inter.html

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

            "Для возможных повторных проверок электронных подписей в будущем (например, для разрешения споров) приложения должны сохранять в своей базе данных сами параметры формы, устанавливаемые в переменной окружения QUERY_STRING (для метода GET) или считываемые из стандартного ввода (для метода POST) в виде:

            name1=value1&name2=value2&name3=value3 . . . nameN=valueN,

            а также значения трех переменных окружения - HTTP_SIGNATURE, HTTP_CERTIFICATE и HTTP_SUBJECT."

            Т.о., сервер приложения банка сохраняет в своей БД подпись (HTTP_SIGNATURE), необходимые данные для проверки подписи и сами подписанные данные в том виде, как они поступили на Inter-PRO Server(ВМЕСТЕ с полем, добавленным злоумышленником-клиентом, а не так, как считает г-н Репан: только то, что имеет отношение к платежному документу, без добавленного поля). Сохраненный набор данных позволяет проверить подпись в режиме off-line в случае возможного возникновения споров в будущем. Естественно, банковское приложение анализирует структуру полученных данных формы и если обнаруживает несоответствие стандартной форме платежного документа (включая наличие лишних полей)или неверно заполненные поля, сообщает клиенту, почему его "документ" не принят к исполнению, несмотря на то, что подпись подтверждается. Поскольку вместе с модулем Inter-PRO Server банку передается исполняемый модуль (fverify.exe) или соответствующая dll для проверки подписи под содержимым полученной формы, некоторые банковские приложения еще раз выполняют проверку подписи содержимого формы уже непосредственно на сервере приложений, перед окончательным принятием решения об исполнении платежного поручения.
            ═══ Таким образом, описанная г-ном Д.Репаном "атака" может быть связана с неправильным использованием банковским сервером приложений предоставленного ему инструмента защиты, но уж никак не с некорректностью работы самого средства защиты Inter-PRO. К счастью, все наши партнеры, использующие в банковских приложениях защиту на базе Inter-PRO, достаточно опытные специалисты и не позволяют себе делать таких элементарных ошибок, которые обсуждаются уважаемым г-ном Репаном.

            Всего доброго,
            Сигнал-КОМ

            Комментарий


            • #7
              BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Компания Сигнал-КОМ до сих пор не ввязывалась в дискуссии с г-ном Репаном, т.к. его способ полемики со своими конкурентами для нас неприемлем (хотя нельзя не восхищаться талантливым маркетинговым ходом Дмитрия, который он избрал для рекламы своего продукта).[/quote]

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

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

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

              Комментарий

              Пользователи, просматривающие эту тему

              Свернуть

              Присутствует 1. Участников: 0, гостей: 1.

              Обработка...
              X