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

 

Введение, или как плохо жить без песочницы

Среди профессионалов есть несколько аксиом, о которых они не любят говорить. А что говорить об аксиомах? Они есть и есть. Вроде всем понятно, как дважды два. Например, одна из них — сигнатурные антивирусы не защищают. Ну то есть не защищают, и все тут. Сказано-пересказано об этом масса всего и много-много раз. С примерами, красивыми презентациями, танцами и плясками. Да и эпидемии всякой гадости типа Ransomware служат одним из доказательств неэффективности сигнатурных и эвристических технологий. Всякого рода крипторы и обфускаторы успешно решают задачу защиты уже давно известной малвари от обнаружения, и в течение некоторого времени эта малварь не детектируется антивирусами. Этого времени вполне достаточно, чтобы кому-то стало плохо, а кому-то хорошо.

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

 

Песочницы и особенности их реализации

Итак, антивирусы не спасают, а иногда ломают то, что уже есть. «Давайте подойдем к защите с другой стороны и будем изолировать процессы друг от друга», — сказал кто-то бесконечно умный. Действительно, здорово, когда подозрительные процессы выполняются в некоторой изолированной среде, называемой песочницей. Выполняемая в песочнице малварь не может покинуть ее пределов и навредить всей системе. Этот могло бы быть решением, однако в существующих реализациях песочниц есть нюансы…
Далее мы как раз и будем обсуждать все тонкости построения песочниц, знание которых тебе обязательно пригодится, когда понадобится выбрать средство изоляции процессов или HIPS (Host-based Intrusion Prevention System — система предотвращения вторжений для рабочих станций).

 

Нюанс №1, или одна песочница на всех

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

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

Как проверить, что изоляция устроена именно таким образом? Очень просто! Запусти два приложения в песочнице. Например, notepad.exe и wordpad.exe. Создай с помощью notepad.exe текстовый файл 1.txt.

Рис. 1. Создаем текстовый файл
Рис. 1. Создаем текстовый файл

Разумеется, данный файл будет сохранен не на рабочем столе, а в «виртуальной» директории. Попробуй открыть его Wordpad’ом (рис. 3).

Рис. 2. Похоже, для всех изолированных приложений создана одна изолированная среда
Рис. 2. Похоже, для всех изолированных приложений создана одна изолированная среда
Рис. 3. Файл открывается на чтение
Рис. 3. Файл открывается на чтение

Итак, созданный одним изолированным приложением файл можно открыть с помощью другого изолированного приложения. Скажем прямо, изоляция уже не очень. Но может, по крайней мере от записи будет какая-то защита? Меняем содержимое (рис. 4).

Рис. 4. Изменяем содержимое текстового файла
Рис. 4. Изменяем содержимое текстового файла

И сохраняем. А теперь попробуем открыть файл 1.txt с помощью notepad.exe. Конечно же, запустим notepad.exe в песочнице (рис. 5).

Рис. 5. Модифицированный текстовый файл
Рис. 5. Модифицированный текстовый файл

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

 

Нюанс №2, или недоизоляция

Да, изолируемые процессы не могут достучаться до доверенной части системы… но в большинстве реализаций только на запись. То есть они могут читать отовсюду практически без ограничений и часто имеют доступ к сети. Это сделано, видимо, для большей совместимости, но это нельзя назвать изоляцией.
Попробуй провести простенький опыт с песочницей на свой выбор. Создай директорию на жестком диске. Скажем, такую: E:\Photos. Помести в нее, например, фотографию (рис. 6).

Рис. 6. Приватная фоточка
Рис. 6. Приватная фоточка

Запусти Internet Explorer в песочнице и попробуй отправить данное изображение, скажем, на rghost.

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

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

Виртуализация файловой системы и реестра в большинстве реализаций построена по принципу «копирование по требованию». То есть если файл нужно просто прочитать, то он читается из исходной директории при отсутствии аналога в виртуальной директории. Если такой же файл присутствует в виртуальной директории, то изолируемое приложение будет работать с ним. То же можно сказать про виртуальный реестр. Ну и понятно, что при попытке записать файл по реальному пути он запишется в виртуальную файловую систему. Почти всегда.

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

 

Нюанс №3, или «а давайте сделаем еще один велосипед, это так интересно»

Продолжение статьи доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все статьи на сайте

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

Вариант 2. Купи одну статью

Заинтересовала статья, но нет возможности оплатить подписку? Тогда этот вариант для тебя! Обрати внимание: этот способ покупки доступен только для статей, опубликованных более двух месяцев назад.


Комментарии

Подпишитесь на ][, чтобы участвовать в обсуждении

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

Check Also

Скрытая сила пробела. Эксплуатируем критическую уязвимость в Apache Tomcat

В этой статье мы поговорим о баге в Apache Tomcat, популярнейшем веб-сервере для сайтов на…