поиск по сайту
АНАЛИЗ ИЗОЛЯЦИИ ПРОЦЕССОВ В ОС WINDOWS С ПОМОЩЬЮ «ПЕСОЧНИЦЫ»

АНАЛИЗ ИЗОЛЯЦИИ ПРОЦЕССОВ В ОС WINDOWS С ПОМОЩЬЮ «ПЕСОЧНИЦЫ»

 Р.А. КОЗАК, Н.В. МОЗОЛИНА

 Московский физико-технический институт (национальный исследовательский университет), Московская область, г. Долгопрудный, 141701, Российская Федерация.

 

Введение

Количество инцидентов информационной безопасности растет. Согласно аналитике [1] 1 место по численности нарушений безопасности занимает события, связанные с вредоносным ПО (около 39%).

Заражение часто связано с нарушением правил эксплуатации. Использование антивирусов не приносит должного результата [2]. Таким образом, становится ясно, что с помощью только одного антивируса невозможно полностью защититься от вредоносного ПО, а пытаться добиться от персонала непреложного соблюдения правил компьютерной безопасности невозможно. Следовательно, необходимо использовать дополнительный компонент защиты. Одно из перспективных направлений – технология изоляции процессов «песочница» [3].  Она  позволяет  создавать отдельную среду  выполнения  процессов и ограничить область заражения компьютера. Целью данной статьи является анализ изоляции процессов в Windows 10 с помощью песочницы. Windows 10 была выбрана из-за ее популярности [4].

Определение изоляции процессов в терминах Windows 10

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

Такое определение возможно только в абстрактном мире математики и не выдерживает никакой проверки на практике. Два процесса могут влиять друг  на друга косвенным образом и, таким образом, не быть изолированными [5]. Следовательно,  его невозможно использовать при разработке решений изоляции процессов, а это значит, что необходимо дать другое определение.

Далее все понятия будут рассмотрены в рамках ОС Windows 10.

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

Вопросы изоляции процессов, связанные с внутренними структурами

У каждого процесса есть принадлежащая ему структура EProcess [6]. Изменить ее можно только используя соответствующие API, получив дескриптор процесса. Следовательно, необходимо запретить либо получать дескриптор чужого процесса, либо вызывать функции, изменяющие поля структуры других процессов.

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

Еще одной структурой, описывающей процесс, является РЕВ (блок окружения процесса) [7]. Он доступен из контекста процесса-собственника. Нельзя запретить его изменение, поскольку это нарушит работу приложения, однако необходимо запретить получение чужого дескриптора PEB. Т.к процесс может изменить свой контекст на чужой, прочитав его с помощью дескриптора.

Вопросы изоляции процессов, связанные с созданием новых процессов

Необходимо определить, что делать с порожденными процессами. Рассмотрим пример. Допустим, мы пытаемся изолировать два процесса (А и Б),  и первый порождает дочерний процесс (В). Должен ли процесс-ребенок быть изолированным от родителя и процесса Б? Ответ на второй вопрос становится ясным, если разобраться как именно происходит создание процесса.

Во время создания объекта процесса в операционной системе, процесс-ребенок может наследовать много полей [8]. Также процесс получает дескриптор родительского процесса. Таким образом, невозможно соблюсти изоляции процессов между А и Б, не изолируя В (ребенка) от Б.

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

Вопросы изоляции процессов, связанные с завершением процессов

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

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

Вопросы изоляции процессов, связанные с памятью процессов

Один процесс может писать в память, принадлежащую другому процессу [11].

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

  1. API Virtual
  2. API Heap
  3. File Map

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

Необходимо запретить одному  процессу создавать дамп памяти другого  и все связанные с ним функции [12].

Большинство современных приложений поддерживает механизмы DEP (Data Execution Prevention, механизм, который не позволяет выполнить команду, находящуюся на странице памяти, не помеченной  на  выполнение.) [13], ASLR (Address space layout randomization, система рандомизации адресов стека и кучи) [14] и EMET (Enhanced Mitigation Experience Toolkit, механизм централизованного управления средствами снижения риска безопасности) [15]. Следует отключить возможность запуска приложений без этих механизмов и  их отключение.

Вопросы изоляции процессов, связанные с механизмами межпроцессного взаимодействия и объектами синхронизации

Необходимо рассмотреть возможность блокировки каждой системы межпроцессорного взаимодействия [16].

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

COM, Data Copy DDE, Mailslots, Pipes, Windows Sockets, RPC. Многие процессы используют перечисленные механизмы для взаимодействия компонентов приложения, и полностью их отключить нельзя. Однако можно запретить вызов функции поиска COM-интерфейсов, дескрипторов и указателей по отношению к изолированному процессу. Также, доступ к ним можно получить через группы объектов, например, к COM-объекту можно обратиться через CO-классы. Поэтому аналогичные функции поиска следует также запретить.

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

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

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

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

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

Memory resource notification. Механизм позволяет узнавать о событиях физической памяти. Так же как и механизм Change notification, его не обязательно блокировать.

Вопросы изоляции процессов, связанные с изоляцией потоков

Говоря об изоляции процессов, необходимо также обсудить вопросы, связанные с изоляцией потоков. Стоит ли изолировать потоки, созданные одним процессом. Кажется, что этого делать не нужно, но не стоит забывать, что Windows позволяет создавать удаленные потоки [17], способные работать в контексте другого процесса. Поэтому стоит запретить вызов функций, создающих удаленные потоки. А изоляцию между остальными потоками, работающими в контексте одного процесса, делать не стоит, иначе нарушается идея многопоточного выполнения.

Однозначно нужно изолировать потоки изолируемых процессов. У потока есть структуры ETread, KThread и TED, по своему предназначению они аналогичны структурам процесса EProcess Kprocess PED. Естественно, что существуют аналогичные функции для работы с полями структур потока. Кажется логичным сохранить политику по отношению к этим структурам, которую мы применяли к структурам процесса, и запретить соответствующие функции.

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

Вопросы изоляции процессов, связанные с файлами

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

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

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

Приведенные выше выкладки позволяют сформулировать следующие критерии изоляции: процессы А и Б изолированы, если

  1. А не может получить дескриптор процесса Б
  2. А не имеет прямого доступа к внутренним структурам Б
  3. А не может вызывать функции позволяющие прочитать или модифицировать внутренние структуры Б
  4. A не может возможности напрямую изменять перечисленные поля собственной структуры EProcess
  5. А изолирован от детей Б
  6. А не может принудительно завершить процесс Б
  7. А не имеет доступа к любой памяти Б
  8. А не может сделать дамп памяти процесса Б
  9. У процесса включены технологии защиты памяти (DEP, ASLR, EMET)
  10. А не может скопировать данные из буфера обмена, когда его окно не активно
  1. А не использует совместно с Б механизмы COM, Data Copy, DDE, Windows Sockets, Mailslots, Pipes, RPC, Job
  2. А не использует совместно с Б механизмы синхронизации
  3. Если Б - консоль, А не использует Console input
  4. А работает с локальной копией файла
  5. Все изменения в файле сохраняются только после завершения работы А Для процесса Б аналогично.

Анализ работы «Sandboxie»

В работе [18] автор провел сравнительный анализ песочниц и среди всех представленных решений выбрал Sandboxie [19]. Необходимо определить, как работает данное ПО. Во всех изображениях приложение, у которого заголовок окружен ”#” запущен из-под песочницы. При запуске приложения в песочнице, она создает анонимного пользователя с SID 1-5-7-2.

Рис. 1 – SID процесса

То есть приложение запускается с флагом SECURITY_ANONYMOUS_LOGON_RID. У такого пользователя есть только привилегия SeChangeNotifyPrivilege, которая позволяет только перемещаться по каталогам. Еще одна странная особенность – это SID пользователя, который виден из-под песочницы. Ее общий вид такой: S-1-5-21-домен-1001. Sa = 21 означает, что SID был выдан контроллером домена или изолированным компьютером. То есть приложение считает, что оно работает на обычном компьютере.

Это подтверждается именами пользователей на изображениях 2.

Рис. 2 – Образы процесса

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

В этом и заключается особенность песочницы. Она обманывает процесс, предоставляя все ресурсы через свой монитор. Воспользовавшись API-Monitor, можно увидеть, что основной контроль по обработке вызовов делает SbieCtrl.exe. Как это происходит?

Просмотрев все библиотеки Sandboxie, можно найти вызываемые функции в SbieDll.dll. Судя по всему, это основная библиотека, отвечающая за реализацию основных методов, поскольку все импортируемые в нее функции принадлежат либо KERNEL32 или ntdll, а остальные библиотеки подключают ее. Как минимум монитор вызывает ее функции.

Для того чтобы отследить поведение процесса, песочница перехватывает вызов функций dll уровня пользователя и далее обрабатывает согласно своим внутренним правилам. Эти правила нигде не описаны и приходится тестировать самостоятельно. Также неясно, как sandboxie перехватывает вызовы. Из библиотеки SboxHostDll.i64 экспортируются функции InjectDllMain и DllEntryPoint. Как видно из ассемблерного листинга, в InjectDllMain вызывается функция SbieDll_Hook 3.

Рис. 3 – Листинг InjectDllMain

В DllEntryPoint происходит настройка параметров, и вызов функции security_init_cookie. Как видно из листинга, она определяет точку входа DLL 4.

Рис. 4 – Листинг security init cookie

SbieDll_Hook перехватывает определенные в коде функции. Вот типичный пример ее использования:

qword_7D2AC5F8 = S b i e D l l _ H o o k ( ” ExitWindowsEx ” , qword_7D2AC5F8 , sub_7D2474E0 ) ; 

[style=CStyle] Сейчас она перехватывает вызов ExitWindowsEx и, вероятно, ставит на нее обработчик sub_7D2474E0. В функциях вида sub_* описаны правила, которые определяют, может процесс делать то или иное действие. Сама же SbieDll_Hook вызывает внутри себя SbieDll_Hook_0. В ней самое интересное происходит в момент вызова EnterCriticalSection. В критической секции вызывается функция VirtualAlloc.

Тестирование Sandboxie

Необходимо протестировать Sandboxie на соответствие критериям изоляции, приведенным выше, и понять способна ли она обеспечивать изоляцию процессов. В ходе тестирования приложения запускаются внутри SandBoxie (Version 5.30 64-bit) со стандартными настройками в ОС Windows 10 (Версия 1073 Сборка 15063.674). Для тестирования некоторых правил изоляции необходимо получить права SE_DEBUG_NAME, и Sandboxie позволяет получить их. Это уже нарушает изоляцию процессов, но вполне возможно, что правила Sandboxie написаны достаточно грамотно, и мы сможем ослабить наши требования.

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

  • получить дескриптор процесса с правом PROCESS_TERMINATE.
  • воспользоваться функцией CreateRemoteThread и подключиться к процессу
  • создать задание и подключить процесс к ней.
  • создать объект отладки и подключить к нему процесс.
  • воспользоваться VirtualAllocEx и записать что-либо в процесс.
  • воспользоваться VirtualQueryEx с помощью которой изменить страницы памяти процесса и заблокировать их.
  • воспользоваться функцией DuplicateHandle перебираем все дескрипторы блокируем их.
  • Обратиться к потоку процесса и завершить или приостановить его
  • Открыть поток и изменить его контекст

Все эти действия песочница блокирует.

Sandboxie перехватывает системные вызовы. В Windows существует возможность защититься от перехвата вызовов функций Dll. Для этого необходимо:

  • Загрузить оригинальный код функции вызовом функции LoadLibrary
  • Получить указатель на текущую функцию
  • Заменить текущий код функции на загруженный

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

Однако Sandboxie позволяет читать память процесса, находящегося вне песочнице. Так, удалось узнать какие команды были введены в cmd.exe через приложение запущенное в песочнице 5. К сожалению, в документации не написано, как исправить такую ситуацию. Это серьезное нарушение изоляции.

Рис. 5 – Чтение памяти процесса

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

Рис. 6 – Запись в память RuntimeBroker.exe

Заключение

В данной статье определены критерии изоляции в терминах Windows.

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

Литература

  1. Positive Technologies ИНЦИДЕНТЫ В ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ КРУПНЫХ РОССИЙСКИХ КОМПАНИЙ. -2018. [электронный ресурс] URL:https://www.ptsecurity.com/upload/corporate/ru-ru/analytics/Positive-Research-2018-rus.pdf
  2. Вирусы, статистика и немного всего. Автор: teecat [электронный ре-сурс] URL:https://habr.com/ru/post/357426/ (Дата обращения:19.05.2019)
  3. «Песочницы» под микроскопом: обзор Anti-APT ре-шений Автор: Александр Русецкий  [электронный ресурс] URL:http://www.jetinfo.ru/stati/pesochnitsy-pod-mikroskopom-obzor-reshenij-prodolzhenie (Дата обращения:19.05.2019)
  4. Статистика ОС Windows. Автор: Comss.one [электронный ресурс] URL:https://www.comss.ru/page.php?id=5148 (Дата обращения:19.05.2019)
  5. В. А. Конявский, С. В. Лопаткин. Компьютерная преступность. В 2-х томах. Т. 2. – М.: РФК-Имидж Лаб, 2006. – 840 с.
  6. Windows kernel opaque structures Автор: com [электронный ресурс] URL:https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/eprocess (Дата обращения:19.05.2019)
  7. PEB structure Автор: MSDN.com [электронный ресурс] URL:https://docs.microsoft.com/en-us/windows/desktop/api/winternl/ns-winternl-peb (Дата обращения:19.05.2019)
  8. Handle Inheritance Автор: com [электронный ресурс] URL:https://docs.microsoft.com/en-us/windows/desktop/sysinfo/handle- inheritance (Дата обращения:19.05.2019)
  9. TerminateProcess function Автор: MSDN.com [электронный ресурс] URL:https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-terminateprocess (Дата обращения:19.05.2019)
  10. GetExitCodeProcess function Автор: MSDN.com [электронный ресурс] URL:https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-getexitcodeprocess (Дата обращения:19.05.2019)
  11. WriteProcessMemory function Автор: MSDN.com [электронный ре-сурс] URL:https://docs.microsoft.com/en-us/windows/desktop/api/memoryapi/nf-memoryapi-writeprocessmemory (Дата обращения:19.05.2019)
  12. Overview of memory dump file options for Windows Автор: microsoft support [электронный ресурс] URL:https://support.microsoft.com/en-us/help/254649/overview-of-memory-dump-file-options-for-windows (Дата обращения:19.05.2019)
  13. Data Execution Prevention Автор: MSDN.com [электронный ресурс] URL:https://docs.microsoft.com/en-us/windows/desktop/memory/data-execution-prevention (Дата обращения:19.05.2019)
  14. /DYNAMICBASE (Use address space layout randomization) Автор: MSDN.com [электронный ресурс] URL:https://docs.microsoft.com/en-us/cpp/build/reference/dynamicbase-use-address-space-layout-randomization?view=vs-2019 (Дата обращения:19.05.2019)
  15. The Enhanced Mitigation Experience Toolkit Автор: support microsoft [электронный ресурс] URL:https://support.microsoft.com/en-us/help/2458544/the-enhanced-mitigation-experience-toolkit (Дата обращения:19.05.2019)
  16. Interprocess Communications Автор: com [электронный ресурс] URL:https://docs.microsoft.com/en-us/windows/desktop/ipc/interprocess-communications (Дата обращения:19.05.2019)
  17. Thread Class Автор: com [элек-тронный ресурс] URL:https://docs.microsoft.com/en-us/dotnet/api/system.threading.thread?view=netframework-4.8 (Дата обращения:19.05.2019)
  18. Разработка методики изоляции процессов для создания изолирован-ной программной среды в ОС Windows 10 Автор: Жвачкин Ян Дипломная работа 2019 г.
  19. Официальный сайт Sandboxie Holdings [электронный ресурс] URL:https://www.sandboxie.com/ (Дата обращения:19.05.2019)
  20. Официальный сайт Hex-Rays SA [электронный ресурс] URL:https://www.hex-rays.com/products/ida/ (Дата обращения:19.05.2019)
  21. Официальный сайт Rohitab Batra [электронный ресурс] URL:http://www.rohitab.com/apimonitor (Дата обращения:19.05.2019)