CC BY
71
3. Воронцов В. В., Котенко И. В. Модели обнаружения и сдерживания сетевых червей на основе проактивного подхода // Материалы V Санкт-Петербург. межрегион. конф. „Информационная безопасность регионов России (ИБРР-2007)", 23—25 окт. 2007 г. СПб., 2007. С. 47—48.
4. Котенко И. В., Воронцов В. В. Проактивный подход к обнаружению и сдерживанию сетевых червей // Тр. Междунар. науч.-техн. конф. „Интеллектуальные системы (AIS 07)" и „Интеллектуальные САПР (CAD-2007)". М.: Физматлит, 2007. Т. 2. С. 61—68.
Сведения об авторах Виктор Васильевич Воронцов — СПИИРАН, научно-исследовательская
сти; E-mail: vorontsov@comsec.spb.ru Игорь Витальевич Котенко — СПИИРАН, научно-исследовательская
сти; E-mail: ivkote@iias.spb.su
Поступила в редакцию 06.05.08 г.
группа компьютерной безопасно-группа компьютерной безопасно-
УДК 004.056
В. А. Десницкий, И. В. Котенко
МОДЕЛЬ ЗАЩИТЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ НА ОСНОВЕ МЕХАНИЗМА „УДАЛЕННОГО ДОВЕРИЯ"
Предложен подход к построению модели защиты программ от несанкционированных изменений и вмешательств с использованием механизма „удаленного доверия". Рассмотрены основные составляющие элементы механизма и принципы его функционирования. Предложены два варианта реализации механизма замещения мобильного модуля на основе парадигмы аспектно-ориентирован-ного программирования.
Ключевые слова: защита программного обеспечения, удаленное доверие, верификация, мобильный модуль, динамическое замещение.
Введение. Проблема защиты программного обеспечения от несанкционированных изменений и вмешательств („взлома") представляет собой важное направление в области компьютерной безопасности и является актуальной, в первую очередь, для разработчиков программного обеспечения и владельцев авторских прав на него. Современные средства защиты от взлома должны гарантировать корректное функционирование программ в соответствии с заданными требованиями и ограничениями. В противоположность антивирусным средствам, главной целью которых является защита программного и аппаратного обеспечения от влияния программ, полученных извне и содержащих компрометирующий их вирусный код, механизмы защиты от взлома предназначены для защиты программ со стороны потенциально ненадежного программного окружения. Несанкционированные модификации могут совершаться злоумышленником посредством разнообразных программных инструментов, таких как декомпиляторы, дизассемблеры, отладчики, „прикрепляемые" к выполняющейся программе, эмуляторы, дамперы и снифферы [1].
В настоящее время известно достаточно большое количество приемов защиты программного обеспечения от взлома. Однако используемые программные методики, реализующие защитные механизмы, являются достаточно слабыми и могут относительно легко быть нейтрализованы взломщиком (противником) за сравнительно небольшое время. Действительно, как показывает практика, любой программный метод, реализующий защиту программ, с большой долей вероятности может быть устранен человеком, обладающим определенными знаниями и владеющим необходимыми техническими средствами.
Таким образом, любой метод защиты может быть взломан за определенное время. Из этого следует, что для адекватной защиты программ от взлома необходимо создание принципиально новой схемы (модели). В частности, такая схема, помимо технологических сложностей нейтрализации защитных механизмов, должна учитывать решения, позволяющие накладывать временные ограничения на работу злоумышленника. В этой ситуации по истечении некоторого периода времени механизм защиты претерпевает изменения, сводящие на нет всю или некоторую часть усилий злоумышленника по осуществлению взлома.
Основным элементом рассматриваемой в настоящей статье модели защиты программного обеспечения от взлома является механизм „удаленного доверия" [2]. Данный механизм предполагает осуществление защиты программных приложений посредством их программной верификации удаленным защищенным сервером в реальном времени. Рассмотрим более детально основные положения данного подхода.
Сущность механизма „удаленного доверия". Основными объектами предлагаемой модели защиты являются клиентская программа, которая выполняется на ненадежном хосте и подлежит защите, и удаленный защищенный сервер, функционирующий на надежном хосте. Таким образом, предполагается, что защищаемая программа выполняется в среде, проверить надежность и достоверность которой не представляется возможным. Программа подвержена атакам со стороны пользователей, намеренных нарушить ее корректное выполнение. Для осуществления таких компрометирующих программу действий злоумышленник может использовать разнообразные инструменты взлома. Цель предлагаемого механизма защиты — гарантировать неизменность и корректность работы клиентской программы, работающей в потенциально враждебном окружении. В рамках рассматриваемой модели считается, что сервер, функционирующий в пределах надежного хоста, не может быть взломан. (Иначе говоря, защита хоста от удаленных сетевых атак представляет собой задачу, выходящую за рамки данной работы.) Для обеспечения функционирования механизма защиты необходимо наличие постоянного сетевого соединения между клиентской программой и удаленным надежным сервером.
Схема механизма „удаленного доверия" приведена на рисунке.
Удаленный ненадежный хост
Схема механизма „удаленного доверия "
Один из важнейших принципов рассматриваемого подхода — внедрение в защищаемую программу специального переносимого (мобильного) программного модуля, основными элементами которого являются монитор и генератор подписей. В функцию монитора входит непрерывное и последовательное осуществление определенного набора проверок (верификаций)
клиентской программы во время ее выполнения, а также частично на стадии ее загрузки. Функции проверки включают верификацию бинарного кода, текущего состояния программы (в том числе, памяти, регистров и стека), используемых в программе структур данных, выполняющихся процессов, версий используемых библиотек, состояния операционной системы и пр. К проверкам также можно отнести выполнение специальных вычислений, чувствительных к изменениям программы. Возможны и другие виды верификаций. Важной особенностью переносимого модуля является то, что он не поставляется совместно с программой, а загружается с надежного хоста во время первой загрузки клиентского приложения и далее регулярно обновляется.
В соответствии с предлагаемым подходом при обнаружении вмешательств сервер прекращает предоставление данному клиенту любых сервисов, программных обновлений и других видов сопровождения. Основное условие применимости рассматриваемого механизма заключается в необходимости использования программой сетевых коммуникаций с другими хостами. Другими словами, программа либо должна осуществлять обмен данными с другими клиентами (как, например, программы 1Р-телефонии, чаты и т.п.), либо для ее работы необходимо наличие поддержки со стороны специализированного удаленного сервера (очевидным примером являются антивирусные программы, для корректной работы которых требуется периодическое обновление антивирусных баз).
Генерация и проверка цифровых подписей. При использовании рассматриваемого подхода клиент должен регулярно, с определенной периодичностью, отправлять надежному серверу результаты проверок, а также собранные монитором данные, характеризующие текущее состояние программы. Эта информация проходит стадию шифрования и затем отправляется надежному серверу в виде последовательности подписей. За процесс их формирования ответствен специальный компонент — генератор подписей, находящийся в составе загружаемого модуля. Главные задачи, связанные с отправляемыми серверу подписями, — однозначная идентификация клиента, который их создал, и выяснение различных характеристик, позволяющих определить корректность текущего состояния программы. Важным требованием к подписям является сложность их анализа потенциальным злоумышленником, не имеющим соответствующих криптографических ключей. Кроме того, стоит отметить требование об уникальности подписей (различие для каждого клиента и для каждого запуска программы), а также их неповторяемости (для предотвращения атак, основанных на повторной отправке ранее сформированных подписей).
Получив информацию от клиента, надежный сервер производит ее дешифрование, затем интерпретирует подписи и анализирует результаты верификаций и собранную клиентским монитором дополнительную информацию. За эти действия отвечает специальный располагающийся на сервере компонент, в функцию которого входит проверка подписей. После этого на основе полученных данных сервер принимает решение о том, было ли совершено вмешательство в работу клиентской программы или нет. Сервер считает программу некорректной, т.е. взломанной, если обнаруживает, что хотя бы одна из проверок завершилась с отрицательным результатом.
Динамическое замещение мобильного модуля. Важнейшей процедурой рассматриваемого подхода является замещение мобильного модуля. Этот механизм состоит в том, что во время выполнения программы происходит регулярная отправка сервером клиенту новой версии модуля, которая содержит обновленные версии функций верификации и сбора данных о программе. После доставки кода модуля на клиентскую машину осуществляется его установка в выполняющуюся программу без ее перезагрузки или приостановки. Замена модуля производится для повышения его устойчивости ко взлому. Возможные модификации кода модуля могут содержать изменения ключа шифрования, алгоритма работы модуля, его количественных и качественных характеристик и пр.
Для усложнения выполнения потенциальным злоумышленником атак на программу и, следовательно, увеличения времени их реализации программа может быть защищена также другими доступными методами и приемами защиты, например методами обфускации [3].
Период замещения модуля рассчитывается на основе оценивания времени, необходимого злоумышленнику для реализации взлома программы. Цель настоящего механизма — определить такой период замещения, чтобы не дать возможности противнику осуществить взлом программы в течение этого периода, когда будет функционировать определенная версия модуля. Основное требование к реализации механизма замещения состоит в том, чтобы время, затрачиваемое злоумышленником на взлом мобильного модуля, не оказывалось ниже определенного значения для всех последующих версий модуля при условии, что противник смог взломать предыдущие версии модуля.
В случае атаки на программу, если злоумышленник станет блокировать процедуру замещения модуля, надежный сервер обнаружит вмешательство, получив „старые" подписи. Если же злоумышленник сможет заблокировать процесс отправки подписей серверу, то их отсутствие также будет трактоваться сервером как вмешательство в работу программы. В обоих случаях надежный сервер получает основание для принятия решения о том, что программа была атакована.
Методика расчета требуемого периода замещения может основываться на оценке вычислительной сложности выполнения атак на рассматриваемый механизм защиты, в том числе, сложности обратной разработки, де-обфускации, приемов преодоления применяемых дополнительных средств защиты. Дополнительными средствами оценки времени замещения могут служить экспериментальные и статистические методики, позволяющие учитывать человеческий фактор в процессе взлома программы. Такие оценки строятся на основе информации, предоставляемой экспертами в области безопасности, в том числе, на базе анализа действий специальных групп программистов (так называемых „красных команд"), которые позволяют на практике оценить стойкость механизмов защиты.
Дополнительным требованием, накладываемым на механизм замещения мобильного модуля, является взаимопроникновение кода модуля и кода клиентской программы, что позволяет обеспечить максимально возможное равномерное распределение кода модуля по коду программы. Данное требование непосредственно связано с целью повышения стойкости целевого приложения к атакам.
Распределение проверок между клиентом и сервером. Выполнение проверок может проходить как на ненадежном хосте, где выполняется клиентская программа, так и на надежном хосте, где функционирует сервер. Монитор клиентской программы, помимо того, что он выполняет функции верификации, также ответствен за сбор некоторой дополнительной информации, в частности входных данных для проверок, которые могут отправляться серверу. Поэтому в рамках сервера возможно частичное или полное повторение проверок, проведенных на стороне клиента. Возможно также выполнение отдельных проверок исключительно на сервере. В то же время следует учитывать, что полное перенесение проверок на сервер противоречит принципу, согласно которому программный код приложения должен выполняться в пределах клиентской машины. В противном случае рассматриваемый механизм „удаленного доверия" становится слабо масштабируемым и утрачивает возможность обеспечивать корректную работу большого числа клиентов.
Помимо своей основной функции, монитор может также проверять корректность самого себя как части верифицируемой программы. Еще одно архитектурное улучшение основывается на реализации модуля с несколькими мониторами, каждый из которых способен верифицировать другие мониторы. Особенностью данного решения является необходимость одновременной модификации всех мониторов мобильного модуля для совершения противником атаки, удовлетворяющей его целям.
Реализация мобильного модуля на основе аспектно-ориентированного программирования. Для реализации механизма замещения мобильного модуля выбрана концепция ас-пектно-ориентированного программирования (АОП). АОП предоставляет возможность проводить изменения программы в реальном времени за счет внедрения небольших фрагментов кода — аспектов. АОП-машина [4] должна обеспечивать необходимый уровень взаимопроникновения кода модуля и остальной части кода программы, а также сокрытие кода модуля.
Для реализации мобильного модуля были выбраны АОП-машины, осуществляющие внедрение аспектов во время выполнения программы (runtime). При реализации этих АОП-машин используются средства отладчика, прикрепляемого к выполняющейся программе. Для выполнения аспектного кода отладчик приостанавливает работу программы, „исполняет" нужный программный метод и затем возобновляет выполнение программы. Другой вариант — это JIT-подход (just-in-time), применяемый только в случае управляемого кода. В соответствии с JIT-подходом все программные изменения происходят, когда компилятор переводит объектный код в native (родной) код.
Заключение. Итак, представлен общий подход к построению модели защиты программ на основе механизма „удаленного доверия". Главной целью предлагаемого подхода является обеспечение неизменности программы и правильности ее работы в потенциально враждебном окружении посредством обнаружения и уведомления доверенного хоста о несанкционированной модификации защищаемой программы. Реализация данного механизма позволяет гарантировать невозможность противнику использовать полноценным образом „взломанную" копию программы. Перспективные направления исследований связаны с детальной разработкой отдельных элементов механизма „удаленного доверия", их реализацией и анализом эффективности.
Работа выполнена при финансовой поддержке Российского фонда фундаментальных исследований (проект № 07-01-00547), программы фундаментальных исследований ОИТВС РАН (контракт № 3.2/03), Фонда содействия отечественной науке, а также при частичной финансовой поддержке, осуществляемой в рамках проекта Евросоюза RE-TRUST (контракт № 021186-2).
список литературы
1. Atallah M., Bryant E., Stytz M. A survey of anti-tamper technologies // J. of Defence Software Eng. 2004. Nov. P. 12—16.
2. Десницкий В. А., Котенко И. В. Модели удаленной аутентификации для защиты программ // Тр. Междунар. науч.-техн. конф. „Интеллектуальные системы (AIS'07)" и „Интеллектуальные САПР (CAD-2007)". М.: Физматлит, 2007. С. 43—50.
3. Collberg C., Thomborson C. Watermarking, tamper-proofing, and obfuscation-tools for software protection // IEEE Computer Society. 2001. Nov. P. 735—746.
4. Десницкий В. А. Реализация механизма замещения мобильного модуля на основе парадигмы аспектно-ориентированного программирования // Материалы V Межрегион. конф. „Информационная безопасность регионов России (ИБРР-2007)". СПб., 2007. С. 49—50.
Сведения об авторах
Василий Алексеевич Десницкий — СПИИРАН, научно-исследовательская группа компьютерной безопасности; E-mail: desnitsky@comsec.spb.ru Игорь Витальевич Котенко — СПИИРАН, научно-исследовательская группа компьютерной безопасности; E-mail: ivkote@iias.spb.su
Поступила в редакцию 06.05.08 г.
