Система и способ формирования журнала при исполнении файла с уязвимостями в виртуальной машине

Область техники

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

Уровень техники

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

Кроме того, зачастую вредоносное программное обеспечение не проявляет свою вредоносную активность сразу, вместо этого производит множество (порядка миллионов вызовов) вызовов API-функций, огромные циклы (порядка миллиардов итераций), приостанавливает свою работу на некоторое время сразу после запуска (например, на 1 час использованием функции «Sleep()»). Вычислительные устройства пользователя в настоящее время имеют высокую производительность, многоядерные процессоры (есть и многопроцессорные системы), поэтому пользователь может не увидеть или не придать значения загруженности одного из ядер. Кроме того, обычно пользователь пользуется устройством после включения более одного часа. Поэтому вредоносному программному обеспечению, если оно запустилось, нет необходимости сразу проявлять свою активность.

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

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

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

Таким образом, известные системы перехвата и агрегации событий и действий, работают в два шага. На первом шаге информация собирается, на втором она анализируется.

Так, публикация US 8479286B2 описывает систему и способ, в которых файл до исполнения в виртуальной машине подвергается анализу, и для исполнения файла по результатам анализа выбирается окружение, наиболее подходящее для раскрытия поведения файла. Далее файл исполняется, если по результатам исполнения принимается решение об изменении окружения, окружение изменяется, и файл исполняется повторно.

Публикация US 7779472B1 описывает классический способ исполнения файла в виртуальной машине. В процессе исполнения происходит перехват вызовов API-функций и их параметров. Набор вызванных API-функций сравнивается с наборами вызовов, соответствующих вредоносному поведению. В случае соответствия выносится решение о вредоносности файла.

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

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

Сущность изобретения

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

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

Согласно другому частному варианту реализации предлагается способ, в котором событие представляет собой вызов API-функции во время исполнения потока процесса.

Согласно еще одному частному варианту реализации предлагается способ, в котором событие представляет собой возврат из API-функции.

Согласно еще одному частному варианту реализации предлагается способ, в котором событие представляет собой системный вызов.

Согласно еще одному частному варианту реализации предлагается способ, в котором событие представляет собой возврат из системного вызова.

Согласно еще одному частному варианту реализации предлагается способ, в котором событие представляет собой оповещение от операционной системы.

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

Согласно еще одному частному варианту реализации предлагается способ, в котором триггер описывает порождение события исполнением на куче.

Согласно еще одному частному варианту реализации предлагается способ, в котором триггер описывает порождение события исполнением на стеке.

Согласно еще одному частному варианту реализации предлагается способ, в котором триггер описывает смену стека.

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

Согласно еще одному частному варианту реализации предлагается способ, в котором триггер описывает событие, порожденное первым исполнением со страницы памяти.

Согласно еще одному частному варианту реализации предлагается способ, в котором триггер описывает динамическое выделение памяти и размещение объектов в ней.

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

Краткое описание чертежей

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

Фиг. 1 показывает пример анализа файла на вредоносность в виртуальной машине.

Фиг. 2 показывает пример реализации предлагаемой системы формирования журнала при исполнении файла с уязвимостями в виртуальной машине.

Фиг. 3 показывает пример реализации предлагаемого способа формирования журнала при исполнении файла с уязвимостями в виртуальной машине.

Фиг. 4 показывает пример компьютерной системы общего назначения, которая позволяет реализовать настоящее изобретение.

Описание вариантов осуществления изобретения

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

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

Виртуальная машина в виде среды для безопасного исполнения файла - это набор (комплекс) программно-аппаратных средств, который предоставляет ресурсы хостовой операционной системы (ГОСТ 56938-2016) для гостевой операционной системы, при этом гостевая операционная система не имеет связи с хостовой операционной системой.

Под средствами системы анализа файла на вредоносность в виртуальной машине в настоящем изобретении понимаются реальные устройства, системы, компоненты, группы компонентов, реализованные с использованием аппаратных средств, таких как интегральные микросхемы (англ. application-specific integrated circuit, ASIC) или программируемые вентильные матрицы (англ. field-programmable gate array, FPGA) или, например, в виде комбинации программных и аппаратных средств, таких как микропроцессорная система и набор программных инструкций, а также на нейроморфных чипах (англ. neurosynaptic chips) Функциональность указанных средств системы может быть реализована исключительно аппаратными средствами, а также в виде комбинации, где часть функциональности средств системы реализована программными средствами, а часть аппаратными. В некоторых вариантах реализации часть средств, или все средства, могут быть исполнены на процессоре компьютера общего назначения (например, который изображен на Фиг. 4). При этом компоненты (каждое из средств) системы могут быть реализованы в рамках как одного вычислительного устройства, так и разнесены между несколькими, связанными между собой вычислительными устройствами.

Фиг. 1 показывает пример анализа файла на вредоносность в виртуальной машине.

В общем случае для анализа на вредоносность файл 100 открывается в виртуальной машине 120 в виде изолированной среды для исполнения файлов. Средство безопасности 110 передает виртуальной машине 120 файл 100. В одном из вариантов реализации виртуальная машина 120 запускается средством безопасности 110. В другом варианте реализации виртуальная машина 120 выбирается средством безопасности 110 из ранее созданных виртуальных машин.

Стоит отметить, что в рамках настоящего изобретения файлом 100 является:

- исполняемый файл;

- динамическая библиотека;

- сценарий, исполняемый каким-либо интерпретатором (например, файлы Microsoft PowerShell с расширением .psl);

- файлы, содержащие сценарии исполнения (например, файлы форматов Microsoft Office или Adobe Acrobat);

- веб-страница;

- изображение;

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

В одном из вариантов реализации под файлом 100 понимается ссылка (например, URL).

В общем случае анализ файла 100 на вредоносность осуществляется после его открытия в операционной системе виртуальной машины 120. Под открытием файла 100 понимается одно из:

- исполнение файла 100, если файл 100 исполняемый;

- открытие файла 100 приложением, если файл 100 не исполняемый. Результатом открытия файла 100 является создание и запуск на исполнение процесса (англ. process) в виртуальной машине 120. При этом создается по меньшей мере один поток (англ. thread).

В одном из вариантов реализации средство безопасности 110 и монитор виртуальных машин 115 (далее по тексту - гипервизор), под управлением которого работает виртуальная машина 120, исполняются на вычислительном устройстве пользователя. В данном случае средство безопасности 110 является приложением безопасности (например, антивирусным приложением). В другом случае средство безопасности 110 и гипервизор 115 исполняются на удаленном сервере (или на разных серверах) или в качестве облачного сервиса. Средство безопасности 110 в этом случае получает файл 100 от сторонних источников (например, от средств безопасности 110, работающих на вычислительных устройствах пользователя), и передает его виртуальной машине 120, где происходит открытие файла 100.

В общем случае гипервизор 115 содержит средство перехвата 130 (средство перехвата 130 является модулем, компонентом или функциональной частью гипервизора 115). Средство перехвата 130 перехватывает вызовы API-функций потоками процесса, созданного при открытии файла 100 в виртуальной машине 120, считывает контекст процессора, на котором исполняется поток, вызывавший API-функцию. Стоит отметить, что контекст процессора содержит по меньшей мере значения регистров процессора. В одном из вариантов реализации средство 130 перехвата также считывает содержимое стека, используя ранее считанные данные, содержащиеся в регистрах процессора, относящихся к стеку (например, память по адресу из регистров ESP и ЕВР). Кроме того, средство перехвата 130 агрегирует упомянутые данные, сохраняет их (например, в базе данных или в журнале 150) и передает их средству безопасности 110 после исполнения процесса, созданного при открытии файла 100. Средство безопасности 110 в свою очередь выносит на основании данных от средства перехвата 130 вердикт о вредоносности файла 100. В общем случае вердикт выносится после анализа сохраненных данных, например, в зависимости от того, в какой последовательности и с какими параметрами производился вызов API-функций потоками процесса, созданного при открытии файла 100. В одном из вариантов реализации, если вердикт не был вынесен, данные, сохраненные средством перехвата 130, передаются средством безопасности 110 специалисту по информационной безопасности (не отображен на Фиг. 1) на анализ.

Фиг. 2 показывает пример реализации предлагаемой системы формирования журнала при исполнении файла с уязвимостями в виртуальной машине.

Настоящее изобретение отличается тем, что файл 100 является безопасным, а предлагаемая система наряду со средством перехвата 130 содержит также средство анализа 140. В одном из вариантов реализации гипервизор 115 содержит средство анализа 140. В другом варианте реализации средство анализа 140 является компонентом (модулем, функциональной частью) средства безопасности 110.

В общем случае средство перехвата 130 перехватывает события в потоках процесса, созданного при открытии файла 100.

Событиями являются по меньшей мере:

- вызов API-функции при исполнении потока процесса;

- возврат из API-функции;

- системный вызов или, другими словами, обращение потока к ядру операционной системы для исполнения какой-либо операции (англ. system call);

- возврат из системного вызова;

- оповещение (уведомление, нотификация) от операционной системы (например, создание потока, создание процесса, загрузка модуля).

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

- уровне ядра (англ. kernel mode),

- уровне пользователя (англ. user mode).

Исполнение потока приостанавливается путем остановки исполнения инструкций потока.

В общем случае реализации во время исполнения потоков процесса, созданного при открытии файла 100, средство перехвата 130 определяет стандарт кодирования (англ. coding convention) вызываемых потоками API-функций. Это позволяет однозначно определить использование регистров процессора для передачи параметров в вызываемые API-функции. Так, например, параметры вызовов будут находиться в регистрах ЕСХ (первый параметр), EDX (второй параметр), остальные параметры будут в стеке (регистр ESP). Кроме того, стандарт кодирования позволяет однозначно определить возвращаемые значения. Например, если API-функция возвращает значение «0», то делает это в регистре ЕАХ.

Стоит отметить, что вредоносное приложение 190, которое эксплуатирует уязвимости файла 100, может проявлять себя не так, как это было изначально задумано злоумышленником на версиях файла 100, отличных от тех, под которые упомянутый вредоносный код изначально проектировался. Например, вредоносное приложение 190, использующее уязвимости Microsoft Office версии 2013.1 может не проявлять вредоносную активность на версии 2013.2. При этом вредоносное приложение 190 или сам Microsoft Office завершаются с исключением, или же, если вредоносное приложение 190 создано качественно, оно после проверки эксплуатации уязвимости завершает свою работу и не порождает никакой активности (событий). Также вредоносное приложение 190 может успешно работать, но не запускать какой-либо дополнительный процесс, а работать внутри эксплуатируемого приложения (процесса, созданного при открытии файла 100). При этом вычислительное устройство пользователя нельзя признать безопасным даже в случае, если вредоносное приложение 190, способное использовать уязвимости файла 100, не выполнило вредоносных действий. Необходимо выявлять факт того, что действия, производимые вредоносным приложением 190, выполняются из-за наличия уязвимости в файле 100 и ее последующей эксплуатации вне зависимости от результата и успешности действий вредоносного приложения 190. Кроме того, так как настоящее изобретение позволяет перехватывать события на уровне ядра, оно может использоваться для выявления вредоносного приложения 190, эксплуатирующего уязвимости компонентов (файлов) операционной системы.

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

- порождение события из цепочки вызовов, использующей возвратно-ориентированное программирование (англ. return oriented programming, ROP);

- порождение события исполнением кода на куче (англ. heap);

- порождение события исполнением кода на стеке;

- смену стека;

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

- событие, порожденное первым исполнением со страницы памяти;

- динамическое выделение памяти и размещение объектов в ней.

Выявление средством перехвата 130 события, при возникновении которого срабатывает триггер, и выполнения сопутствующих условий триггера не тождественно попытке эксплуатации уязвимости безопасного файла 100 вредоносным приложением 190, однако с высокой долей вероятности свидетельствует о том, что файл 100 имеет уязвимости, и вредоносное приложение 190 пытается использовать имеющиеся уязвимости. Настоящее изобретение позволяет выявить, сработал ли триггер при исполнении легитимного кода (безопасного кода, содержащегося в файле 100 и модулях, которые этот файл использует при исполнении) во время исполнения потоков процесса, созданного при открытии файла 100, или передача управления была произведена другим образом, например, вследствие перезаписи данных, хранящихся на стеке, переполнения кучи (англ. heap overflow) и т.д.

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

Примеры работы настоящей системы описаны ниже.

Пример 1.

Средство перехвата 130 выявило событие: вызвана API-функция, для которой сработал триггер. Средство перехвата 130 проверяет регистр ESP, и проверяет, последовательно выявляя адреса вызовов функций, откуда был совершен вызов API-функции. Если код, вызвавший API-функцию не находится в модуле или динамической библиотеке, которые загружены в адресное пространство процесса, созданного при открытии файла 100 (то есть код расположен по аномальному адресу), то необходимо выполнить вышеописанные действия, а именно: сохранить в журнал 150 информацию о последовательности выявленных вызовов, включая аномальный адрес вызова, а также сохранить в журнале 150 дамп области памяти вокруг аномального адреса.

Пример 2.

Средство перехвата 130 выявило событие: вызвана API-функция для которой сработал триггер. Средство перехвата 130 проверяет регистр ESP, и проверяет наличие ROP-цепочки на стеке. Если цепочка выявлена, то в журнал 150 сохраняется дамп памяти (стека) для дальнейшего анализа.

Пример 3.

Средство перехвата 130 выявило событие: возврат из API-функции для которой сработал триггер. Средство перехвата проверяет адрес возврата API-функции. Если адрес возврата указывает на кучу или стек, адрес возврата и дамп кучи или стека сохраняются в журнал 150.

Пример 4.

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

Пример 5.

Если эксплуатация уязвимости происходит в несколько этапов, то сначала вредоносным приложением 190 будет выделено некоторое количество памяти (например, выделение кучи), в этой памяти будут размещены объекты (например, структуры данных, исполняемый код), затем будет произведена попытка передачи управления на эту память. Средство перехвата 130 выявляет событие: динамическое выделение памяти. И даже в случае, если управление (например, из-за несоответствия версий уязвимого файла 100) не передалось, то средство перехвата 130 снимет дамп выделенной памяти с размещенными объектами и отправит на дальнейший анализ.

Пример 6.

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

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

В общем случае для анализа данных, сохраненных в журнал 150 средством перехвата 130, средство анализа 140 использует известные из уровня техники методы (например, сигнатурный или эвристический анализ).

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

Фиг. 3 показывает пример реализации предлагаемого способа формирования журнала при исполнении файла с уязвимостями в виртуальной машине.

В общем случае для формирования журнала средство безопасности 110 передает безопасной файл 100 виртуальной машине 120. Формирование журнала происходит после открытия файла 100 в операционной системе виртуальной машины 120. Под открытием файла 100 понимается одно из:

- исполнение файла, если файл исполняемый;

- открытие файла приложением, если файл не исполняемый.

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

- вызов API-функции при исполнении потока процесса;

- возврат из API-функции;

- системный вызов или, другими словами, обращение потока к ядру операционной системы для исполнения какой-либо операции;

- возврат из системного вызова;

- оповещение от операционной системы.

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

- порождение события из цепочки вызовов, использующей возвратно-ориентированное программирование (англ.: return oriented programming, ROP);

- порождение события исполнением на куче (англ. heap);

- порождение события исполнением на стеке;

- смену стека;

- изменение структуры данных, описывающей привилегии и права процесса в операционной системе;

- событие, порожденное первым исполнением со страницы памяти;

- динамическое выделение памяти и размещение объектов в ней.

На этапе 320 с помощью средства перехвата 130 анализируют стек процесса, созданного при открытии упомянутого файла, и выявляют последовательность вызовов функций, предшествующих событию, в виде последовательности адресов вызовов и возвратов.

На этапе 330 анализируют с помощью средства перехвата 130 выявленную последовательность вызовов функций на предмет выполнения условий триггера, связанных с попыткой эксплуатации уязвимости.

На этапе 340 с помощью средства перехвата 130 в случае выполнения условий триггера, связанных с попыткой эксплуатации уязвимости файла 110, сохраняют в журнал 150 данные о выявленной последовательности вызовов функций. В одном из вариантов реализации в журнал 150 дополнительно сохраняют дамп области памяти, связанной с выполнением условий триггера.

Фиг. 4 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг. 4. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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