Способ обнаружения вредоносных сборок Российский патент 2017 года по МПК G06F9/445 G06F21/56 

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

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

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

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

Подобными файлами являются образы сборок в машинном коде (native image), которые являются частью технологии .NET. Приложения .NET создаются за счет использования вместе некоторого количества сборок (assembly), где сборка является двоичным (бинарным) файлом, обслуживаемым общеязыковой исполняющей средой CLR (Common Language Runtime).

Сборка .NET включает в себя следующие элементы:

- заголовок файла РЕ (portable execution);

- заголовок CLR;

- CIL код (Common Intermediate Language);

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

- манифест сборки;

- дополнительные встроенные ресурсы.

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

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

Каждая сборка содержит CIL код, который является промежуточным кодом, не зависящим от процессора. Во время выполнения CIL-код компилируется в режиме реального времени посредством JIT (just in time, т.е. динамическая компиляция) компилятора в инструкции, соответствующие требованиям конкретного процессора.

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

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

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

Сборка может состоять из нескольких модулей (module). Модуль - часть сборки, логическая коллекция кода или ресурсов. Иерархия используемых в сборке сущностей такова: Сборка->модуль->тип(класс)->метод. Модуль может быть внутренним (внутри файла сборки) или внешним (отдельный файл). Модуль не имеет точки входа и не обладает никаким индивидуальным номером версии и поэтому не может напрямую загружаться CLR средой. Модули могут загружаться только главным модулем сборки, например файлом, в котором содержится манифест сборки. Манифест модуля содержит только перечисление всех внешних сборок. Каждый модуль имеет идентификатор MVID (Module Version Identifier) - уникальный идентификатор, прописанный в каждом модуле сборки, который изменяется при каждой компиляции.

В однофайловых сборках все необходимые элементы (заголовки, CIL код, метаданные типов, манифест и ресурсы) размещаются внутри единственного файла *.exe или *.dll. На Фиг. 1a показано устройство однофайловой сборки.

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

В манифесте главного модуля описаны все остальные связанные модули, от которых зависит работа главного модуля. В частном случае второстепенным модулям в многофайловой сборке назначается расширение *.netmodule (Фиг. 1б); обязательным требованием для CLR среды это не является. Во второстепенных модулях *.netmodule тоже содержится CIL-код и метаданные типов, а также манифест уровня модуля, в котором перечислены внешние сборки, необходимые данному модулю.

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

Для многофайловых сборок технология отличается. Кроме хеша основного файла сборки считаются также хеши внешних модулей, после чего данные записываются в основную сборку. Модули не имеют собственных подписей и имеют отличные от главного модуля MVID. В манифест сборки записывается:

- PublicKey - открытая часть StrongName-подписи

- PublicKeyToken - хеш открытой части ключа StrongName-подписи.

Сборки разделяют на: приватные (private) и публичные (public/shared). Приватные сборки должны всегда размещаться в том же каталоге, что и клиентское приложение, в котором они используются (т.е. в каталоге приложения), или в одном из его подкаталогов.

Публичная сборка одновременно может использоваться в нескольких приложениях на одном и том же устройстве. Публичные сборки не размещаются внутри того же самого каталога, что и приложения, в которых они должны использоваться. Вместо этого они устанавливаются в глобальное хранилище (кэш) сборок (Global Assembly Cache - GAC). GAC располагается сразу в нескольких местах:

Сборка, устанавливаемая в GAC, должна иметь строгое имя (strong name). Строгое имя является современным .NET-эквивалентом глобально уникальных идентификаторов (GUID), которые применялись в COM. В отличие от GUID-значений в COM, которые представляют собой 128-битные числа, строгие имена .NET основаны (отчасти) на двух взаимосвязанных криптографических ключах, называемых открытым (public) и секретным (private) ключом.

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

- имена сборки (которое представляет собой имя сборки без файлового расширения).

- номер версии сборки;

- значение открытого ключа;

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

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

Для создания строгого имени сборки получают открытый и секретный ключи, например генерируют данные открытого и секретного ключей с помощью поставляемой в составе .NET Framework SDK утилиты sn.exe. Эта утилита генерирует файл, который содержит данные для двух разных, но математически связанных ключей - открытого и секретного. После указывают местонахождения этого файла компилятору, который запишет полное значение открытого ключа в манифест сборки.

В частном случае, компилятор генерирует на основе всего содержимого сборки (CIL кода, метаданных и т.д.) соответствующий хеш. Хешем является числовое значение, которое является статистически уникальным для фиксированных входных данных. Следовательно, в случае изменения любых данных сборки .NET (даже одного символа в строковом литерале), компилятор выдает другой хеш. Далее полученный хеш объединяется с содержащимися внутри файла данными секретного ключа для получения цифровой подписи, вставляемой в сборку внутрь данных заголовка CLR. На Фиг. 1в показано, как выглядит процесс создания строгого имени.

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

Путь к сборке в GAC:

C:\Windows\assembly\GAC_32\KasperskyLab\2.0.0.0_b03f5f7f11d50a3a\KasperskyLab.dll, где:

C:\Windows\assembly - путь к GAC;

\GAC_32-ОАС_архитектура процессора;

\KasperskyLab - имя сборки;

\2.0.0.0_b03f5f7f11d50a3a - версия сборки метка публичного ключа KasperskyLab.dll-\имя сборки.расширение.

Исполнение кода сборки, в частном случае, происходит следующим образом. В первую очередь происходит анализ заголовка РЕ, чтобы узнать, какой процесс запустить (32 или 64-разрядный). Затем загружается выбранная версия файла MSCorEE.dll (C:\Windows\System32\MSCorEE.dll для 32-разрядных систем). Пример исходного кода сборки приведен ниже.

Для выполнения метода (для удобства код представлен в исходном виде, а не в скомпилированном в CIL код), например метода System.Console.WriteLine(«Kaspersky»), CIL код JIT-компилятор преобразует в машинные команды (Фиг. 2).

В первую очередь перед выполнением функции Main() среда CLR находит все объявленные типы(классы) (например, тип Console). Затем определяет методы, объединяя их в записи внутри единой «структуры» (по одному методу, определенному в типе Console). Записи содержат адреса, по которым можно найти реализации методов. При первом обращение к методу WriteLine вызывается JIT-компилятор. JIT-компилятору известен вызываемый метод и тип, которым определен этот метод. ЛТ компилятор ищет в метаданных соответствующей сборки - реализацию кода метода (код реализации метода WriteLine(string str)). Затем JIT - компилирует IL в машинный код, сохраняя его в динамической памяти. Далее JIT-компилятор возвращается к внутренней «структуре» данных типа (Console) и заменяет адрес вызываемого метода на адрес блока памяти с машинным кодом. После этого метод Main() обращается к методу WriteLine(string str) повторно. Т.к. код уже скомпилирован, обращение без вызова JIT-компилятора. Выполнив метод WriteLine(string str), управление возвращается методу Main().

Из описания следует, что «медленно» работает функция только в момент первого вызова, когда ЛТ переводит CIL-код в инструкции процессора. Во всех остальных случаях код уже находится в памяти и подставляется как оптимизированный для данного процессора. Однако если будет запущена еще одна программа в другом процессе, то JIT-компилятор будет вызван снова для того же метода.

Образы, о которых упоминалось выше, решают задачу «медленной работы функции в момент первого вызова». При загрузке сборки будет подгружаться образ, из которого будет исполняться машинный код, благодаря этой технологии возможно ускорение загрузки и запуска приложения в силу того, что JIT-компилятору не нужно ничего компилировать, а также каждый раз заново создавать структуры данных (записи), все это берется из образа. Образ можно создать для любой .NET-сборки вне зависимости от того, установлена она в GAC или нет. Для компиляции, в частном случае, используется утилита ngen.exe, располагающаяся по пути При запуске ngen.exe происходит создание машинного кода для IL кода сборки с помощью JIT-компилятора, результат сохраняется на диск в хранилище образов NIC (Native Image Cache). Компиляция производится на локальном устройстве с учетом его программно-аппаратной конфигурации, поэтому образ должен использоваться только в той среде (окружении), под которую компилировался. Цель создания таких образов - повышение эффективности управляемых приложений, то есть вместо JIT-компиляции загружается готовая сборка в машинном коде.

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

Путь к компилируемому образу формируется следующим образом, например:

С:\Windows\assembly\NativeImages_ν4.0.30319_32\Kaspersky\9с87f327866f53aec68d4fee40cde33d\Kaspersky.ni.dll, где

C:\Windows\assembly\NativeImages - путь к хранилищу образов в системе;

v4.0.30319_32 - <версия.NET Framework>_<архитектура процессора (32 или 64)>;

Kaspersky - дружественное имя сборки;

9c87f327866f53aec68d4fee40cde33d - хеш приложения;

Kaspersky.ni.dll - <дружественное имя сборки>.mi.<расширение>.

При создании образа машинного кода сборки ngen.exe для 64-битных приложений сохраняет данные о нем в ветке реестра , для 32-битных приложений в

Если образ устанавливался для сборки, расположенной в GAC, ветка будет называться так:

Если же сборка не была установлена в GAC, то так:

До Windows 8 разработчик всегда должен был сам инициировать создание, обновление и удаление образов сборок, используя ngen.exe (или конфигурируя установщик). Начиная с Windows 8 для некоторых сборок Windows создает образы автоматически.

В частном случае для управления образами используется служба Native Image Service. Она позволяет разработчикам откладывать установку, обновление, удаление образов в машинном коде, выполняя эти процедуры отложено, когда устройство простаивает. Native Image Service запускают программой установки приложения или обновления. Делается это посредством утилиты ngen.exe. Служба работает с очередью запросов, сохраняемой в реестре Windows, каждый из запросов имеет свой приоритет. От установленного приоритета зависит то, когда будет выполняться задача.

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

Среда CLR для поиска сборок для загрузки в момент запуска соответствующей сборки использует модуль связывания сборок (Assemble Binder). CLR использует несколько видов модулей связывания. Для поиска образов используется модуль связывания образов (Native Binder). Поиск нужного образа проводится в два этапа - сначала указанный модуль находит сборку и образ на файловой система, затем проверяет соответствие образа сборке. Алгоритм поиска представлен на Фиг. 3. На этапе 310 модуль связывания сборок ищет сборку, поиск производится в:

- GAC, что подразумевает, что искомая сборка подписана, содержимое сборки не читается;

- каталоге приложения, сборка открывается и читаются метаданные.

Далее на этапе 320 модуль связывания образов ищет образ в NIC, соответствующий найденной сборке. В том случае если образ найден, это проверяется на этапе 330, то модуль связывания образов зачитывает необходимые данные и метаданные из образа на этапе 340 и убеждается, что образ подходящий, для чего проводит тщательную проверку, которая в том числе включает контроль:

- строгого имени;

- времени создания (образ должен быть новее, чем сборка);

- MVID сборки и образа;

- версии .NET Framework;

- архитектуры процессора;

- версии связанных образов (например, образ mscorlib.dll);

- и т.д.

Если сборка, для которой ищется образ, не имеет строгого имени, тогда вместо него для проверки используется MVID. В том случае, если образ не актуален, это проверяется на этапе 350, управление передается JIT-компилятору на этапе 370, иначе загружается код из образа на этапе 360.

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

Раскрытие изобретения

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

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

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

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

В другом частном случае данными, между которыми устанавливается несоответствие, являются по меньшей мере CIL код, машинный код, метаданные типов, манифест, информация в РЕ заголовке, информация в CLR заголовке.

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

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

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

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

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

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

Фиг. 1a показывает пример однофайловой сборки;

Фиг. 1б показывает пример многофайловой сборки;

Фиг. 1в показывает способ формирования строго имени;

Фиг. 2 показывает способ исполнения кода сборки;

Фиг. 3 показывает способ работы модуля связывания;

Фиг. 4 показывает способ определения категории доверия образа;

Фиг. 5 показывает способ создания шаблона;

Фиг. 6 показывает способ установки образов на устройстве;

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

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

Описание изобретения

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

На Фиг. 4 изображен способ категоризации образов. На этапе 400 получают образ. Образ в одном частном случае получают из NIC (например, если образ установлен на устройстве и используется на устройстве по назначению), в другом частном случае из любого другого хранилища образов (например, когда устройство используется в качестве хранилища и образы не используются на этом устройстве по назначению). Далее на этапе 410 определяют категорию доверия образа. В частном случае для определения категории доверия образа осуществляют запрос к базе данных, где для запроса используют, например, контрольную сумму образа, в другом частном случае используют MVID образа. Также для определения категории образа используют шаблоны. Механизм работы с шаблонами приводится ниже. Если образ неизвестен в базе данных, то на этапе 420 определяют родительскую сборку, на основе которой создали образ. Для определения используют по меньшей мере следующие данные, структуры данных и средства:

- MVID;

- реестр;

- модуль связывания

- строгое имя.

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

Определение родительской сборки по записям в реестре используют в том случае, когда при создании образов создается запись в реестре. Пример подобной записи представлен выше.

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

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

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

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

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

Образ, как и сборка, имеют некоторую структуру, например, которая изображена на Фиг. 5. Сборка KasperskyLab.dll и образ KasperskyLab.ni.dll содержат метаданные и код, где сборка содержит исключительно CIL код, а образ, в частном случае, дополнительно машинный код и структуру NativeImageHeader. На основании структуры, метаданных и кода формируется шаблон KasperskyLab.dll.tmpl, о котором уже упоминалось выше, который однозначно соответствует родительской сборке и созданному на ее основе образу. Для связывания структуры, кода и метаданных в шаблон, используют, например, технологию гибкого хеша (англ. intelligent hash, также известный как local sensitive hash). В частном случае шаблон формируют, как показано на Фиг. 5. Из сборки извлекаются данные (манифест, метаданные, CIL код и т.д.). Из образа извлекаются те же данные и дополнительно машинный код. Данные, которые неизменны для каждой из возможных версий образа, созданных от одной родительской сборки, обрабатываются (например, от них рассчитывается контрольная сумма) и формируется хеш, который помещается в шаблон. Данные, которые изменяются от версии к версии образа, например машинный код, также обрабатываются и на основании обработки формируется гибкий хеш. В частном случае, для машинного кода, формируют журнал вызова функций, листинг с дизассемблированным машинным кодом или любую другую сущность, которая отражает логику исполнения указанного машинного кода, из этих сущностей и формируют гибкий хеш, в другом частном случае эти сущности используются в шаблоне непосредственно. Следует отметить, что шаблон формируется таким образом, что однозначно связывает (устанавливает соответствие) родительскую сборку и образ независимо от версий образа, зависящих от программно-аппаратной конфигурации устройства. В том случае, если в машинный код образа вносятся изменения и логика исполнения кода образа перестает соответствовать логике исполнения кода сборки, соответствие между родительской сборкой и образом на основании шаблона не устанавливается, образ признается не соответствующим сборке.

Далее описывается пример определения соответствия при помощи шаблона. Например, существует некоторая родительская сборка Kaspersky.dll, для нее на устройстве создается образ Kaspersky.ni.dll. Формируется шаблон Kaspersky.dll.tmpl, который позволяет установить соответствие между родительской сборкой и образом. Далее на устройстве происходит обновление программно-аппаратной части (обновление операционной системы, .NET Framework, замена процессора) и версия образа Kaspersky.ni.dll становится неактуальной, образ использоваться не может, поэтому инициируют обновление этого образа и создают новый образ Kaspersky.ni.dll, который отличен от образа предыдущей версии. Но при использовании шаблона определяют, что обновленный образ соответствует родительской сборке (логика исполнения машинного кода осталась прежней). Пусть в другом случае на устройство устанавливается вредоносное программное обеспечение, которое модифицирует образ Kaspersky.ni.dll. В данном случае при использовании шаблона, определяют, что образ, модифицированный вредоносным программным обеспечением, не соответствует родительской сборке (логика исполнения машинного кода отличается от логики, заложенной в родительской сборке).

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

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

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

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

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

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

При установке системы защиты на устройство необходимо гарантировать, что хранилище образов не было несанкционированно изменено и изменено не будет, для этого применяется ряд мер. На Фиг. 6 изображены назначения категории образу. На этапе 600 ограничивают доступ к хранилищу образов или, по меньшей мере, одному образу, ограничение в частном случае заключается в том, что модифицировать образ разрешают только доверенным процессам или конечному числу некоторых доверенных процессов, например только процессу ngen.exe, всем остальным процессам разрешен только доступ на чтение. В другом частном случае ограничение заключается в полной блокировке доступа на запись к хранилищу в целом или по меньшей мере к одному образу. На этапе 610 определяют родительскую сборку, на основе которой создали образ, доступ к которому ограничили. На этапе 620 запускают обновление(замену), по меньшей мере, одного образа. В одном частном случае обновление заключается в удалении ранее созданного образа и создание нового средства операционной системы (запуском ngen.exe на родительской сборке или сервисом автоматического создания образов), в другом частном случае изменяют лишь часть данных образа, например машинный код, при этом обновление осуществляется доверенными процессами. В первом случае образ после удаления создают вновь, в одном частном случае немедленно, в другом случае создание откладывают на некоторое время, например до запуска родительской сборки, определенную на этапе 610, образ которой подлежит обновлению. На этапе 630 назначают образу категорию родительской сборки.

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

Фиг. 7 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 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, представленного на Фиг. 7. В вычислительной сети могут присутствовать также и другие устройства, например маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

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

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

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

1. Способ обнаружения вредоносного образа машинного кода, где вредоносным считается образ машинного кода, логика исполнения машинного кода которого отличается от логики исполнения CIL кода родительской сборки, в котором:

а) получают образ машинного кода;

б) определяют родительскую сборку, где родительской сборкой является сборка, на основании которой создан полученный образ;

в) устанавливают несоответствие между логикой исполнения машинного кода полученного образа машинного кода и логикой исполнения CIL кода определенной родительской сборки;

г) признают образ машинного кода вредоносным на основании установленного несоответствия между логикой исполнения машинного кода полученного образа машинного кода и логикой исполнения CIL кода определенной родительской сборки.

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

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

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

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

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