Реализация способа обнаружения эксплойтов на основе профиля разностей между адресами вызовов функций

Размещено на http://www.allbest.ru/

Реализация способа обнаружения эксплойтов на основе профиля разностей между адресами вызовов функций

А.Д. Кечахмадзе,

Ю.В. Косолапов, канд. техн. наук

Аннотация

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

Введение

Наличие ошибок в программе может создавать угрозу исполнения нелегитимного кода (эксплойта) в контексте процесса этой программы. Особую опасность создают эксплойты нулевого дня, против которых разработчиками программы еще не выпущено обновления, а также сигнатуры которых еще не попали в базы данных средств обнаружения компьютерных вирусов и систем обнаружения/предотвращения атак [1]. Для выявления эксплойта нулевого дня система защиты должна отличать нелегитимное исполнение кода в контексте процесса защищаемой программы от легитимного. Такая система обычно на этапе обучения составляет профиль легитимного исполнения защищаемой программы, а в случае отклонения от этого профиля на этапе эксплуатации генерирует соответствующий сигнал тревоги. Заметим, что причиной отклонения может являться как нелегитимное, так и легитимное исполнение кода, - например, редко вызываемого кода программы. В первом случае говорят об истинном обнаружении эксплойта, а во втором - о ложном обнаружении, которое называется ошибкой первого рода. С другой стороны, если система защиты сообщает об отсутствии аномалий в исполнении защищаемой программы (когда сигналы тревоги не генерируются), то причиной этому может служить исполнение как действительно легитимного кода, так и эксплойта (например, замаскированного под легитимный код) [2]. В последнем случае говорят о ложном пропуске аномалии и называют его ошибкой второго рода. Очевидно, что чем меньше вероятность ошибок первого и второго рода, тем лучше для пользователей таких систем защиты: с одной стороны, реже потребуется выполнять анализ ложных обнаружений, а с другой, - меньше риск оставить атаку незамеченной.

В [3, 4] предлагается и исследуется способ обнаружения эксплойтов на основе построения профиля расстояний между вызовами функций. Под расстоянием понимается разность между двумя виртуальными адресами возврата из соответствующих этим адресам функций. Результаты [3, 4] показали потенциальную применимость такого способа. В настоящей работе этот способ совершенствуется в части формирования профиля: предлагается способ упорядочивания модулей защищаемой программы. Во-первых, это позволяет упростить этап обучения на независимых запусках программы и, таким образом, исключить влияние технологии ASLR (Address Space Layout Randomization) рандомизации адресного пространства процесса. Во-вторых, предложенный способ упорядочивания позволяет учитывать расстояния между функциями, вызванными из ранее не загружавшихся в память модулей, что в [3, 4] не было учтено. Усовершенствованный способ в настоящей работе программно реализован для операционной системы Windows x32, причем разработанное программное средство позволяет автоматизировать процесс обучения для любой защищаемой программы. В качестве примера для защищаемой программы FireFox проведены эксперименты, направленные на оценку вероятностей ошибок первого и второго рода в зависимости от длительности обучения и схемы обучения.

Способ обнаружения эксплойтов

Источником данных для определения поведения программы уже долгое время являются последовательности вызовов функций прикладного программного интерфейса операционной системы, совершаемых в ходе выполнения защищаемой программы (см., например, [5 - 7]). В дальнейшем такие функции будем называть API-функциями (API - Application Program Interface), а их вызовы - API-вызовами. В операционной системе (ОС) Windows к API-функциям относятся, например, функции GetProcAddress, LoadLibraryA, LdrGetProcedureAddress, VirtualAlloc. В [3, 4] предлагается способ получения новой информации из последовательности API-вызовов: профиль расстояний. Этот профиль может позволить отличить легитимное исполнение кода от нелегитимного. Опишем этот способ обнаружения.

Назовем трассой вызовов последовательность API-вызовов, совершаемых в защищаемой программе P между запуском программы и ее завершением. Каждый вызов С, совершаемый программой P, может быть описан четверкой: именем вызываемой функции f, адресом возврата г, номером потока t, в контексте которого вызвана функция, и именем модуля m программы P, из которого совершается вызов. Вызовы Ci = (f\,r\,t\,m\) и C2 = (firiJiWi) будем называть соседними в трассе вызовов, если t1 = t2 и вызов С2 следует в трассе вызовов сразу за С1. Величину dfi, f2) = г2 - г1 будем называть расстоянием между API-вызовами С1 и С2.

Так как при разных запусках программы P порядок загрузки используемых этой программой модулей псевдослучаен в силу технологии ASLR, нельзя гарантировать, что модуль m будет загружаться по одному и тому же адресу. Поэтому требуется механизм однозначного проецирования модуля m на его уникальный адрес, который будем называть логическим адресом. Отметим, что в результате проекции модуля изменяются адреса возвратов вызовов из этого модуля. При использовании такого механизма появляется возможность вычислить расстояния по трассам, полученным при разных запусках программы, так как вычисление расстояний проводится между спроецированными вызовами.

В настоящей работе такой механизм отличается от механизма, предложенного в [3, 4], и реализуется следующим образом:

модули программы P проецируются на некое пространство в порядке их появления в трассе первого запуска;

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

Таким образом, во-первых, каждый модуль имеет свой уникальный (логический) адрес загрузки, а во-вторых, не теряется информация об API- вызовах из модулей, которые не были загружены при первом запуске. Стоит отметить, что в [3, 4] карта загрузки модулей строилась только по первому запуску программы P, а новые модули, которые загружались в последующих запусках, не учитывались. Для простоты будем полагать, что все вызовы из трассы API-вызовов уже спроецированы за счет описанного выше механизма. нелегитимный программный код

Отметим, что не все API-функции представляют интерес для использования их в эксплойтах. В [8], например, можно найти расширенный перечень API-функций ОС Windows, которые обычно используются эксплойтами. Обозначим через L множество имен отслеживаемых API-функций, т.е. таких функций, вызовы которых будут источником информации для определения поведения программы.

В [3, 4] профилем расстояний D(P) программы P называется семейство множеств

D(P) = {Df,g | fg EL], Dfg = {di(fg), d2(fg), ...}.

В профиле D(P) каждое множество Dfg состоит из возможных расстояний для соседних вызовов API-функций с именами f и g (причем функция с именем g вызывается после функции с именем f). Учитывая описанный выше механизм проецирования, профиль D(P) можно строить по разным легитимным запускам программы P. В этом случае он представляет собой описание ее нормального (легитимного) поведения, а способ выявления эксплойтов через аномалии в поведении сводится к обнаружению расстояний, не входящих в профиль D(P). Проверка принадлежности расстояний к профилю может осуществляться как в ходе исполнения программы, так и по сгенерированной программой трассе. В первом случае имеется возможность предотвратить выполнение эксплойта, но замедляется производительность самой программы. Во втором случае нет существенного падения производительности, однако обнаружение эксплойта выполняется постфактум.

Реализация способа обнаружения эксплойтов

С целью реализации описанного выше способа обнаружения эксплойтов разработана библиотека перехвата и журналирования API-вызовов, совершаемых защищаемой программой P. Список L имен отслеживаемых функций библиотека загружает из текстового файла. Внедрение библиотеки перехвата в процесс программы P выполняется с помощью другой разработанной утилиты - инъектора. Программа-инъектор принимает на вход имя исполняемого файла защищаемой программы P и имя библиотеки перехвата, а результатом работы инъектора является работающий процесс программы P с внедренной библиотекой перехвата. При завершении процесса программы P в текстовой файл с уникальным именем записывается трасса вызовов. С помощью множественных запусков программы-инъектора может быть сгенерировано любое требуемое количество файлов с трассами вызовов. Для генерации нового профиля D(P) по этим файлам разработан скрипт train.js на платформе Node.js. Скрипт принимает набор файлов с трассами вызовов и генерирует модель, хранящуюся в файле model.json. Эта модель содержит в себе карту проекций модулей и профиль D(P). Стоит отметить, что модель может содержать в себе данные сразу по нескольким программам, поскольку некоторые программы могут состоять из нескольких исполнимых файлов. Для пополнения существующего профиля разработан скрипт addtrain.js, позволяющий по новым трассам обновить (пополнить) существующий профиль D(P). Также разработан скрипт test.js, выполняющий проверку заданных файлов с трассами вызовов на наличие таких соседних вызовов, расстояние между которыми не содержится в модели, описываемой файлом model.json. Выходом работы этого скрипта является количество нетипичных расстояний, а также число всех вызовов, записанных во все трассы вызовов, что позволяет посчитать долю нетипичных вызовов по отношению ко всем вызовам в трассе. Отметим, что скрипт test.js определяет расстояние между вызовами как нетипичное, если хотя бы один из вызовов был совершен из ранее неизвестного модуля (из модуля, который не содержится в карте проекций модулей из файла model.json). Таким образом, скрипт test.js может использоваться для выявления постфактум нетипичного исполнения кода, т.е. для выявления эксплойтов.

Исходный код библиотеки перехвата и журналирования, а также код программы-инъектора размещены в публичном репозитории GitHub по адресу https://github.com/andrewslock/windows-log-functions. Скрипты train.js, add train.js и test.js соответственно созданию новых профилей расстояний, пополнению существующих профилей и анализу трасс вызовов расположены по адресу https://github.com/andrewslock/analyszer.

Экспериментальное исследование

В качестве защищаемой программы P для экспериментального исследования в настоящей работе, как и в [3, 4], выбран веб-браузер FireFox. Чтобы задействовать как можно больший функционал браузера, в качестве параметров были использованы самые популярные сайты в различных категориях по версии сайта similarweb.com [9]. В работе проведено пять видов экспериментов, нацеленных на исследование применимости способа обнаружения исполнения несанкционированного кода на основе расстояний между соседними API-вызовами. Напомним, что вероятность принять легитимное расстояние за нетипичное называется вероятностью ошибки первого, а вероятность принять нетипичное расстояние, вызванное эксплойтом, за легитимное, - вероятностью ошибки второго рода. Во всех пяти экспериментах исследовалась зависимость этих ошибок от схемы обучения модели. Для исследования вероятности ошибки второго рода на базе библиотеки перехвата реализована библиотека симуляции работы эксплойта.

Целью первого эксперимента является исследование поведения вероятностей ошибок первого и второго рода в зависимости от роста модели (от длительности обучения). Эксперимент разбит на десять этапов, причем для любых двух разных этапов множества используемых сайтов (параметров для FireFox) не пересекаются. В каждом этапе происходит запуск защищаемой программы FireFox на восьми сайтах из случайно выбранных категорий для получения трассы вызовов с целью обучения, а также запуск на других двух сайтах, не входящих в обучающую выборку, для получения трассы вызовов с целью тестирования модели. Отметим, что при запуске на двух сайтах также симулировалось выполнение эксплойта. С каждым этапом профиль расстояний увеличивал и включал профиль, полученный на предыдущем этапе. На каждом этапе происходит сравнение трассы вызовов для тестирования с текущим профилем расстояний. Расстояния, полученные из трасс вызовов для тестирования, не аккумулировались. В рамках эксперимента на каждом этапе вычисляются две величины: вероятность ошибки первого рода fp и вероятность ошибки второго рода fn. Формулы вычисления fp и fn имеют следующий вид:

fp = w/n, fn = 1 - t/nt ,

где w - количество нетипичных расстояний на текущем этапе; n - количество всех вызовов в трассе текущего этапа, полученной на этапе тестирования; t - количество обнаруженных эксплойтов (количество нетипичных расстояний, которые были вызваны эксплойтом, причем несколько нетипичных расстояний, вызванных одним вызовом эксплойта, считались за одно); nt - количество совершенных вызовов эксплойта (количество совершенных симуляций работы эксплойта).

Второй эксперимент схож с первым, за исключением того, что количество этапов увеличено с 10 до 20, а трассы вызовов для тестирования теперь аккумулируются также в профиль D(P), как и трассы для обучения. Таким образом, нетипичные расстояния, обнаруженные во время тестирования, добавляются в профиль D(P).

Третий эксперимент повторяет второй, однако теперь в каждом этапе два сайта для тестирования выбираются случайно из десяти сайтов для обучения.

Результаты первых трех экспериментов показаны в табл. 1.

Таблица 1

Как видно из таблицы, во всех трех экспериментах наблюдается тенденция снижения значения fp. С целью оценки вероятности второго рода fn в работе реализована симуляция работы эксплойта. Симуляция эксплойта происходит путем вызова одной случайной функции из списка отслеживаемых функций в случайный момент времени. В функциях-перехватчиках журналируемых функций, помимо самого процесса записи вызова, находится логика вызова эксплойта: каждый вызов функции перехватчика имеет вероятность 0.1 запустить эксплойт посредством вызова функции callRandomFunction. Эксплойт может быть запущен только один раз. При его запуске в функции callRandomFunction выбирается одна случайная функция из списка журналируемых функций и вызывается с пустым списком параметров. Такой вызов случайной журналируемой функции попадает в трассу вызовов. Определить, что вызов был сделан эксплойтом, можно по адресу возврата: он будет ссылаться на область памяти функции

callRandomFunction. Так как эксплойт срабатывает только вследствии вызова функции-перехватчика одной из журналируемых функций, на трассе вызовов остается больше, чем просто вызов эксплойта, - два соседних вызова f и е, где f - функция, перехватчик которой вызвал эксплойт; е - случайная функция эксплойта. Во всех экспериментах расстояния между f и е всегда были нетипичными («эксплойт» всегда обнаруживался). При этом программа P = FireFox никогда не имела таких расстояний между f и е в своем профиле D(P) при обучении, т.е. значение fn во всех экспериментах нулевое.

В четвертом эксперименте ставилась задача исследовать поведение вероятности fp в зависимости от подхода к запускам программы P в период обучения. Другими словами, требовалось установить, какой подход предпочтительнее использовать при обучении: несколько коротких запусков программы P или один долгий запуск этой программы. Для случайной выборки десяти сайтов из двухсот были выполнены следующие действия: 1) короткий запуск FireFox на заданном сайте (в течение тридцати секунд), повторенный пять раз; 2) долгий запуск FireFox на заданном сайте (в течение двух с половиной минут), повторенный два раза.

Трассы, полученные при коротких запусках, были использованы для построения первой модели (первый файл model.json). Для построения второй модели (второй файл model.json) использовалась трасса одного из долгих запусков, а трассы при другом долгом запуске использовались для тестирования первой и второй моделей. В табл. 2 показаны: Ді - доля нетипичных вызовов при тестировании по первой модели; Д2 - доля нетипичных вызовов при тестировании по второй модели, а также их отношение.

Таблица 2

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

В пятом эксперименте ставилась задача исследовать зависимость доли нетипичных расстояний от порядка действий пользователя в программе FireFox. Для выборки десяти случайных сайтов из двухсот были проделаны следующие действия: 1) для каждого сайта выбраны три действия, образующие шесть возможных последовательностей их порядка (номера последовательностей от 1 до 6); 2) для каждой последовательности п были выполнены два запуска - обучающий и для тестирования; 3) трассы, полученные после обучающего запуска, образуют модель, с которой сравниваются трассы, полученные при всех шести тестирующих запусках.

Сравнения для одного сайта образуют шесть подэтапов и всего тридцать шесть значений долей нетипичных расстояний. В каждом подэтапе с обучающей последовательностью п вычислялась разница между средним значением долей нетипичных расстояний у последовательностей, отличающихся от п, и долей самой последовательности п (ее тестируемый запуск). Таким образом, для каждого сайта было получено шесть значений, среднее значение оі которых показывает степень зависимости количества нетипичных расстояний от выбора последовательности п с порядковым номером i = 1,..., 6. для обучения профиля: чем значение больше (нуля), тем больше доля нетипичных расстояний у трасс, последовательность которых отличается от обучающей, и чем значение меньше (нуля), тем больше доля расстояний у трассы, последовательность которой была той же самой, что и при обучении (табл. 3).

Таблица 3

Равенство такого значения нулю показывает независимость от выбора последовательности для обучения. В среднем у десяти сайтов в эксперименте это значение равно 0,0094%. Таким образом, можно заключить, что доля нетипичных расстояний зависит от действий пользователя не более чем на одну тысячную процента.

Заключение

В работе выполнена модификация способа обнаружения эксплойтов, предложенного в [3, 4], а для защищаемой программы FireFox проведено дополнительное экспериментальное исследование этого способа. Эксперименты с симуляцией работы эксплойта показали, что предложенный способ позволяет выявлять нелегитимное исполнение кода с высокой вероятностью: во всех проведенных экспериментах симуляция работы эксплойта была обнаружена. Результаты экспериментов показали также несущественную зависимость вероятности обнаружения от порядка действий пользователя, совершаемых им при работе с защищаемой программой во время обучения. Это, в частности, может позволить автоматизировать процесс обучения путем псевдослучайной симуляции действий пользователя, не привлекая к процессу обучения реальных пользователей. Также оказалось, что для обучения целесообразнее использовать трассы вызовов нескольких коротких запусков, чем трассу от одного долгого запуска, длительность которого сопоставима с суммарной длительностью множество коротких запусков. Стоит отметить, что хотя вероятность ложного обнаружения и имеет тенденцию к уменьшению с увеличением длительности периода обучения (увеличением множества входных данных), она остается достаточно высокой для применения этого метода на практике. В [4] с целью уменьшения вероятности предлагается использовать расстояния не только между соседними вызовами. Представляется, что разработанное в настоящей работе средство перехвата вызовов позволит исследовать этот подход.

Литература

1. Zetter K. Countdown to Zero Day: Stuxnet and the launch of the world's first digital weapon. - Crown, 2014.

2. Wagner D., Soto P. Mimicry attacks on host-based intrusion detection systems // Proceedings of the 9th ACM Conference on Computer and Communications Security. - Washington. - 2002. - P. 255-264.

3. Косолапов Ю.В. Об обнаружении эксплуатации уязвимостей, приводящей к запуску вредоносного кода // Моделирование и анализ информационных систем. - 2020. - Т. 27, №2. - С. 138-151.

4. Косолапов Ю.В. Об одном способе обнаружения эксплуатации уязвимостей и его параметрах // Системы и средства информатики. - 2021. - Т. 31, №4. - С. 48-60.

5. Forrest S., Hofmeyr S., Somayaji A. The evolution of system-call monitoring // Annual Computer Security Applications Conference Proceedings, IEEE, Piscataway, NJ, USA. - 2008. - P. 418-430.

6. Singh A., Arora R., Pareek H. Malware analysis using multiple API sequence mining CFG

7. Gupta S., Sharma H., Kaur S. Malware characterization using Windows API call sequences // Journal of Cyber Security and Mobility. - 2018. - Vol. 7, Iss. 4. - P. 363-378.

8. Exploit Protection Reference [Электронный ресурс].

Размещено на Allbest.ru