МЕТОД ПРОВЕРКИ ЦЕЛОСТНОСТИ КОДА НА ОСНОВЕ ХЕШИРОВАНИЯ

Макарычев П.П.1, Карпов А.Е.2
1Пензенский государственный университет, д.т.н., профессор
2Пензенский государственный университет, магистрант 2-го курса

Аннотация
Статья посвящена методу проверки целостности кода на основе хеширования.

Ключевые слова: хеширование


METHOD FOR CHECKING THE INTEGRITY OF THE CODE BASED ON THE HASH

Makarychev P.P.1, Karpov A.E.2
1Penza State University, Ph.D. (doktor nauk) in technics, Professor
2Penza State University, 2nd year master degree student

Abstract
This paper is about method for checking the integrity of the code based on the hash.

Рубрика: 05.00.00 ТЕХНИЧЕСКИЕ НАУКИ

Библиографическая ссылка на статью:
Макарычев П.П., Карпов А.Е. Метод проверки целостности кода на основе хеширования // Современные научные исследования и инновации. 2012. № 6 [Электронный ресурс]. URL: https://web.snauka.ru/issues/2012/06/14852 (дата обращения: 29.03.2024).

Введение

Последние годы, по данным исследований антивирусных компаний, характеризуются повышением активности вредоносного кода [2]. Современные вредоносные программы представляют собой сложные технические продукты, использующие множество методов для обхода штатных средств защиты информации, обеспечиваемых операционными системами, а также средств защиты антивирусных программ. Угрозы начинают принимать черты информационной войны, о чём может свидетельствовать атака с применением компьютерного червя Stuxnet [10]. В таких условиях АСУ критического применения нуждаются в наиболее надёжных средствах защиты. Одной из тенденций в создании безопасной среды является разработка средств, обеспечивающих целостность кода, посредством выполнения его контроля.

Целостность ресурсов информационной системы – состояние ресурсов информационной системы, при котором их изменение осуществляется только преднамеренно субъектами, имеющими на него право, при этом сохраняются их состав, содержание и организация взаимодействия [1]. Контроль целостности кода заключается в проверке состояния кода исполняемых модулей. Можно выделить следующие виды контроля целостности кода:

  • контроль запуска (загрузки) кода;
  • контроль времени выполнения;
  • комбинированный.

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

    Для проверки целостности используются следующие методы контроля:

  • сравнение данных [4; 6; 13];
  • сравнение значений хеш-функций [14; 15];
  • установка защиты на память, содержащую код [5; 8; 12; 14; 16];
  • проверка целостности потока выполнения [3; 7; 9; 15].

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

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

  • определить, какие именно части исполняемых модулей не должны изменяться (и соответственно являются объектами контролирования целостности);
  • разработать модель выполнения контроля целостности кода и алгоритм проверки целостности.

    Определение неизменяемых частей исполняемых модулей

    При решении задачи определения неизменяемых частей, во-первых, была проанализирована спецификация формата PE – Microsoft Portable Executable and Common Object File Format [11]. По итогам анализа данной спецификации выделены следующие части структуры PE, которые не должны модифицироваться:

  • заголовок MS-DOS полностью (структура IMAGE_DOS_HEADER);
  • заголовок PE полностью (структура IMAGE_NT_HEADERS32 или IMAGE_NT_HEADERS64), включая заголовки разделов (структуры IMAGE_SECTION_HEADER);
  • разделы, в описании характеристик которых (поле Characteristics структуры IMAGE_SECTION_HEADER) не установлен флаг разрешения записи (IMAGE_SCN_MEM_WRITE), за исключением частей разделов, содержащих информацию об импорте (таблицы поиска импорта – Import Lookup Table, таблицы адресов импорта – Import Address Table).

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

  • поле AddressOfEntryPoint структуры IMAGE_OPTIONAL_HEADER из заголовка PE (IMAGE_NT_HEADERS32/64) изменяется у всех управляемых сборок .NET в процессе инициализации;
  • поле ImageBase структуры IMAGE_OPTIONAL_HEADER из заголовка PE (IMAGE_NT_HEADERS32/64) изменяется у всех исполняемых модулей, у которых в поле DllCharacteristics структуры IMAGE_OPTIONAL_HEADER задан флаг IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE; данный флаг указывает, что к данному модулю необходимо применить механизм рандомизации адресного пространства (Address Space Layout Randomization, ASLR [9]);
  • в заголовках разделов (структуры IMAGE_SECTION_HEADER) значения полей VirtualSize, SizeOfRawData, PointerToRawData, PointerToRelocations, PointerToLinenumbers, NumberOfRelocations, NumberOfLinenumbers в памяти могут отличаться от значений в исполняемом файле.

    Помимо этого в ходе исследования, проводимого с помощью прототипа, было выявлено, что у модулей, выполняющихся в режиме ядра, разделы, имеющие флаг IMAGE_SCN_MEM_DISCARDABLE, могут выгружаться из памяти после загрузки без возможности последующего возврата в память. К таким разделам, как правило, относятся разделы “INIT” (содержат код инициализации модуля), “.reloc” (содержат информацию, необходимую для переадресации) и “.rsrc” (содержат ресурсы).

    Таким образом, если исполняемый модуль – это совокупность заголовка и разделов:

    ,

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

    .

    Модель и алгоритм контроля целостности кода

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

    Контролируемые разделы могут иметь переадресованные данные, которые будут изменяться при загрузке модуля по различным базовым адресам. Как было отмечено ранее, в проекте SecVisor [14] эта проблема решается путём выполнения проверки до применения переадресации. Поскольку в данной работе необходимо обеспечить как проверку целостности загрузки, так и времени выполнения, то такой подход не применим, поэтому предлагается переадресуемые данные при подсчёте значения хеш-функции необходимо пропускать.

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

    Опишем формально эталонную информацию, которая должна использоваться при определении целостности каждого исполняемого модуля. В соответствии с вышеизложенным эталонная проверочная информация имеет вид:

    (1)

    где:

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

    Пусть – исполняемый модуль, . Проверяемая информация модуля m, .

    Тогда эталонная проверочная информация для модуля m:

    где f – функция вычисления хеша от заголовка исполняемых модулей, ExtractRelocations – функция извлечения информации о переадресации из разделов “.reloc”, g – функция вычисления хеша от раздела.

    Из определения (1) следует, что хранилище эталонной проверочной информации:

    . (2)

    Определим функцию поиска эталонной проверочной информации по значению хеш-функции от заголовка.

    Пусть значение хеш-функции .

    Тогда функция поиска эталонной проверочной информации выполняет отображение вида:

    .

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

    На рисунке 1 представлен предлагаемый в данной работе алгоритм проверки целостности модуля.

    Входные данные: Module – информация об исполняемом модуле; Storage – хранилище с эталонной проверочной информацией.

    Переменные: Status – статус проверки целостности модуля; CheckedInfo – проверяемые участки модуля; HeaderHash – значение хеш-функции от заголовка модуля; EtalonInfo – эталонная проверочная информация о модуле; I – счётчик проверяемых разделов; curScnHash – значение хеш-функции от текущего проверяемого раздела.

    Результат: значение переменной Status; возможные значения – «Целостность не нарушена», «Неизвестный модуль», «Целостность модуля нарушена».

    Рисунок 1 – Алгоритм проверки целостности модуля; вид – контроль комбинированный; метод – сравнение значений хеш-функции

    Выводы

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

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

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


Библиографический список
  1. Рекомендации по стандартизации Р 50.1.056-2005
  2. Отчёт McAfee об угрозах за первый квартал 2012 / McAfee Labs, 2012
  3. Федоров А.Е. Контроль целостности программ методом построения семантических графов / А.Е. Федоров А.П. Ващенко, В.Д. Стрельников, А.В. Толчеев, М.В. Вострикова // Теория и техника радиосвязи. – 2010. – № 2
  4. Abdulmalic M.D. Windows Vista Kernel-Mode: Functions, Security Enhancements and Flaws / M.D. Abdulmalic, S.M. Abdulmalic, M. Conover // Leonardo Jounal of Sciences, 7(12), 2008
  5. Barham, P. Xen and the art of virtualization / P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, A. Wareland // In SOSP ’03: Proceedings of the nineteenth ACM symposium on Operating systems principles. – New York, NY, USA, 2003
  6. Conover, M. Assessment of Windows Vista Kernel-Mode Security / M. Conover / Symantec, 2006
  7. Criswell, J. Secure virtual architecture: A safe execution environment for commodity operating systems / J. Criswell, A. Lenharth, D. Dhurjati, V. Adve // In Proceedings of ACM Symposium on Operating Systems Principles. – Stevenson, WA, USA, 2007
  8. Garfinkel, T. A virtual machine introspection based architecture for intrusion detection / T. Garfinkel, M. Rosenblum // In Proceedings of 10th Network and Distributed Systems Security Symposium. – Sand Diego, California, USA, 2003
  9. Kiriansky, V. Secure Execution via Program Shepherding / V. Kiriansky, D. Bruening, Saman P. Amarasinghe // InProceedings of the 11th USENIX Security Symposium. – Berkeley, CA, USA, 2002
  10. Matrosov, A. Stuxnet Under the Microscope / A. Matrosov, E. Rodionov, D. Harley, J. Malcho / ESET, 2011
  11. Microsoft Portable Executable and Common Object File Format / Microsoft Corporation, 2010
  12. Rutkowska, J. Qubes OS Architecture. Version 0.3 / J. Rutkowska, R. Wojtczuk, 2010 [Электронный ресурс]. URL: http://qubes-os.org/files/doc/arch-spec-0.3.pdf
  13. Rutkowska, J. System Virginity Verifier. Defining the Roadmap for Malware Detection on Windows System / J. Rutkowska // In Proceedings of HITB 2005. – Kuala Lumpur, Malaysia, 2005
  14. Seshadri, A. SecVisor: A tiny hypervisor to provide lifetime kernel code integrity for commodity OSes / A. Seshadri, M. Luk, N. Qu, A. Perrig // In SOSP ’07: Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles. – New-York, NY, USA, 2007
  15. Sgandurra, D.. Measuring the Semantic Integrity of a Process Self : Ph.D. Thesis / D. Sgandurra; Universita di Pisa. – Pisa, 2010
  16. Wang, J. HyperCheck: A Hardware-Assisted Integrity Monitor / J. Wang, A. Stavrou, A. Ghosh // In Proceedings of 13th International Symposium Recent Advances in Intrusion Detection. – Ottawa, Ontario, Canada, 2010


Количество просмотров публикации: Please wait

Все статьи автора «AndrewKarpov»


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

Связь с автором (комментарии/рецензии к статье)

Оставить комментарий

Вы должны авторизоваться, чтобы оставить комментарий.

Если Вы еще не зарегистрированы на сайте, то Вам необходимо зарегистрироваться:
  • Регистрация