Способ категоризации сборок и зависимых образов

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

 

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

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

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

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

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

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

- заголовок файла PE (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 код, метаданные типов, манифест и ресурсы) размещаются внутри единственного файла *.ехе или *.dll. На Фиг. 1а показано устройство однофайловой сборки.

Многофайловая сборка состоит из набора модулей .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:

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

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

\GAC_32 - GAC_архитектура процессора;

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

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

KasperskyLab.dll - \имя сборки.расширение.

Исполнение кода сборки, в частном случае, происходит следующим образом. В первую очередь происходит анализ заголовка PE, чтобы узнать какой процесс запустить (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-компилятору известен вызываемый метод и тип, которым определен этот метод. JIT компилятор ищет в метаданных соответствующей сборки - реализацию кода метода (код реализации метода WriteLine (string str)). Затем JIT-компилирует IL в машинный код, сохраняя его в динамической памяти. Далее JIT-компилятор возвращается к внутренней «структуре» данных типа (Console) и заменяет адрес вызываемого метода на адрес блока памяти с машинным кодом. После этого метод Main() обращается к методу WriteLine (string str) повторно. Т.к. код уже скомпилирован, обращение без вызова JIT-компилятора. Выполнив метод WriteLine (string str) управление возвращается методу Main().

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 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 и PE.

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

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

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

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

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

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

г) определяют категорию доверия определенной на этапе ранее родительской сборки;

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

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

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



 

Похожие патенты:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении безопасности передачи данных. Устройство содержит модуль вычислительный (МВ), выполненный из блока выдачи видеоинформации, интерфейса внешних устройств, блока разуплотнения потока данных для передачи во внешние устройства, блока хранения и обмена данными шумовой последовательности, блока формирования и хранения ключей и масок шифрования, контроллера памяти, администратора состояний, блока шифрования, маскирования, демаскирования и дешифрации данных, модуль контроля управления и индикации (МКУИ), выполненный из контроллера состояния батареи питания, блока контроля напряжений питания, блока контроля вскрытия корпуса, блока управления элементами дополнительной индикации, контроллера ввода данных с клавиатуры, модуль интерфейсов (МИ), выполненный из внешних устройств - блока взаимодействия с радиоаппаратурой, контроллера взаимодействия с устройством ввода радиоданных (УВРД), блока взаимодействия с персональной электронно-вычислительной машиной (ПЭВМ), клавиатуру и дисплей. 1 ил.

Изобретение относится к области аутентификации пользователей. Технический результат – эффективное управление безопасностью вычислительных ресурсов. Способ управления доступом к одному или более вычислительным ресурсам провайдера вычислительных ресурсов содержит: под управлением одной или более компьютерных систем, функционирующих на основе выполняемых команд, прием от первого объекта запроса делегирования, выполнение которого включает в себя разрешение второму объекту привилегии доступа к вычислительному ресурсу; генерирование ключа сеанса на основе, по меньшей мере частично, ограничения и секретного сертификата, совместно используемого с первым объектом; предоставление ключа сеанса первому объекту; прием от второго объекта запроса доступа на осуществление доступа к вычислительному ресурсу, причем запрос доступа включает в себя ключ сеанса, предоставленный первому объекту; подтверждение запроса доступа на основе, по меньшей мере частично, ключа сеанса, содержащегося в запросе доступа; и разрешение второму объекту доступа к вычислительному ресурсу. 3 н. и 17 з.п. ф-лы, 24 ил.
Изобретение относится к области защиты информации, хранимой в информационных системах персональных данных (ИСПДн), от несанкционированного доступа (НСД) и может быть использовано на стадиях разработки и оптимизации ИСПДн в защищенном исполнении. Техническим результатом является повышение уровня безопасности ИСПДн. Способ обезличивания персональных данных обеспечивает защиту ИСПДн от НСД на стадиях разработки и оптимизации, оперирует персональными данными субъектов, хранящимися и обрабатываемыми в ИСПДн, и осуществляет хеширование ключевых атрибутов по алгоритму Keccak. При этом на первом этапе экспертным путем определяются ключевые атрибуты. На втором этапе исходное множество данных D(d1, d2, ..., dM), где М - число атрибутов, разбивается на два непересекающихся подмножества данных А1 и А2, относящихся к ключевым и неключевым атрибутам соответственно. На третьем этапе производится хеширование данных из А1 для каждого субъекта и вычисляется значение хеш-функции, которое является одним из атрибутов обоих множеств. 1 з.п. ф-лы.

Изобретение относится к методикам аутентификации, а именно к аутентификации, основанной на использовании персональных биологических данных, таких как конфигурации вен тела человека. Технический результат – обеспечение достоверной аутентификации и портативность устройства. Устройство для биометрической идентификации пользователя содержит блок освещения, выполненный с возможностью испускания по меньшей мере одного первого оптического излучения на тело человека; блок модуляции, выполненный с возможностью модуляции по меньшей мере одного второго оптического излучения, рассеиваемого от тела человека; датчик, выполненный с возможностью регистрации интегральной мощности по меньшей мере одного второго оптического излучения, рассеиваемого от тела человека; блок обработки и хранения, выполненный с возможностью переключения состояний блока модуляции, получения сигнала от датчика таким образом, чтобы каждое показание датчика соответствовало конкретному состоянию блока модуляции, выполнения биометрической аутентификации пользователя. 2 н. и 6 з.п. ф-лы, 11 ил.

Изобретение относится к управлению административной связью между учетной записью и устройством. Технический результат – повышение эффективности установления административной связи между устройством и учетными записями. Способ управления административной связью между учетной записью и целевым интеллектуальным устройством включает прием запроса связывания устройства, переданного из первого терминала, при этом запрос связывания устройства содержит идентификатор целевого интеллектуального устройства, транслируемый из целевого интеллектуального устройства, и первый идентификатор учетной записи, соответствующий учетной записи, для которой выполнена аутентификация в первом терминале, определение второго идентификатора учетной записи, соответствующего главной административной учетной записи, связанной с целевым интеллектуальным устройством, передачу сообщения с запросом связывания во второй терминал, в котором выполнена аутентификация учетной записи, соответствующей второму идентификатору учетной записи, причем сообщение с запросом связывания содержит первый идентификатор учетной записи и идентификатор устройства, и регистрацию учетной записи, соответствующей первому идентификатору учетной записи, в качестве вспомогательной административной учетной записи для целевого интеллектуального устройства, если из второго терминала принято первое сообщение подтверждения, соответствующее сообщению с запросом связывания. 2 н. и 10 з.п. ф-лы, 11 ил.
Наверх