С использованием внедрения (инжектирования) кода в процесс

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

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

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

Данный способ внедрения, о чем говорили ранее, основан на том, что при загрузке любого приложения, использующего user32.dll, а таких абсолютное большинство, все DLL, перечисленные в разделе реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs, загружаются в адресное пространство этого приложения. В том числе, это относится и к системным процессам. Легальные системные динамические библиотеки располагаются в системной папке \WINDOWS\System32.

Принципы защиты КСЗИ «Панцирь+» от угроз подобных атак, состоящие в реализации соответствующих разграничений прав доступа механизмами контроля доступа к статичным файловым объектам и к объектам реестра ОС, с целью контроля действий и, при необходимости, в усечении прав системного администратора, были расссмотрены ранее.

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

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

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

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

В общем случае возможны два способа инжектирования кода в процесс:

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

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

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

Существует два типа ловушек - глобальные и локальные. Локальная ловушка отслеживает те события, которые происходят только в одной программе (или потоке), т.е. в нашем случае они не представляют интереса. Глобальная же ловушка отслеживает события во всей системе (во всех потоках). Оба типа ловушек устанавливаются одинаково, однако единственное отличие заключается в том, что локальная ловушка вызывается в пределах приложения, в то время как глобальную ловушку необходимо хранить и вызывать из отдельной DLL.

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

Проведенный анализ возможности КСЗИ «Панцирь+» осуществлять защиту от атак на повышение привилегий с использованием внедрения (инжектирования) кода в процесс.

КСЗИ «Панцирь+» позволяет контролировать и разграничивать права доступа по инжектированию кода в процесс обоими способами.

Контроль инжектирования кода в процесс КСЗИ «Панцирь+» реализуется отдельным механизмом защиты «Управление внедрением кода или данных», который контролирует и предотвращает инжектирование кода в процесс обоими способами. Механизм защиты настраивается из интерфейса, представленного на рис.83.

 

Рис.83. Интерфейс настройки механизма защиты «Управление внедрением кода или данных»

Естественно, в первую очередь, целесообразно запретить инжектирование любым способом кода администратором в системные процессы и в процессы, являющиеся средствами администрирования системы, расположенные в папке %SystemRoot%\System32\*.

Проведенная проверка корректности реализации КСЗИ «Панцирь+» защиты от атак на повышение привилегий с использованием внедрения (инжектирования) кода в процесс.

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

В рамках испытаний были созданы требуемые субъекты, см. рис.84, и правила доступа, см. рис.85.

 

Рис.84. Созданные субъекты доступа

 

 

Рис.85. Созданные правила доступа

 

Далее различными способами был осуществлен инжект кода, с использованием разделяемой памяти, под учетной записью администратора («Татьяна») в различные процессы из папки %SystemRoot%\System32\*, запущенные с системными правами и с правами администратора. Процесс calc.exe был запущен с системными правами с использованием планировщика задач.

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

 

Рис.86. Записи в журнале аудита

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

 

 

Рис.87. Записи в журнале аудита

Вывод. КСЗИ «Панцирь+» корректно реализует защиту от атак на повышение привилегий с использованием внедрения (инжектирования) кода в процесс всеми возможными способами.

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

Для ответа на этот вопрос проведена проверка использования приложениями штатной возможности инжектирования кода в процесс.

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

 

Рис.88. Созданное правило контроля доступа

После этого был запущен браузер Crome. Созданные при этом КСЗИ «Панцирь+» записи аудита приведены на рис.89.

Рис.89. Созданные записи аудита

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

Вывод. Защита от атак на повышение привилегий с использованием внедрения (инжектирования) кода в процесс должна осуществляться, по средством реализации контроля и разграничения прав доступа к реализации инжекта, что и обеспечивает КСЗИ «Панцирь+».

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