Защита от уязвимостей Comodo Internet Security

Проблема уязвимостей Comodo Internet Security разных версий и подходы к ее решению

Проблема уязвимостей Comodo

CIS разных версий, от 5.10 до 8.2, имеет множество багов и недоработок. Исследования Project Zero показали, как недоработки защитного ПО открывают для злоумышленников дополнительный вектор атаки; и благодаря этим исследованиям в Comodo Internet Security 8.2.0.4978 был устранен ряд уязвимостей, превращавших этот продукт чуть ли не в «бэкдор». В данной статье речь пойдет не о столь вопиющих ситуациях, а о возможности вредоносных программ обойти защиту CIS.

В прежних статьях описывались проблемы с доверенными инсталляторами, а также новый баг с подменой файлов в версиях 8.x. Особый вид уязвимостей связан с реализацией анализа командной строки. Часть уязвимостей этого вида устранена в версии 8.2, предыдущие же версии подвержены им в полной мере.

Самый очевидный (но, к сожалению, не единственный) способ эксплуатации уязвимостей CIS — LNK-файлы, т.е. ярлыки. При запуске этих файлов происходит обычный запуск указанной в них программы с заданными аргументами командной строки. Запуск самого ярлыка не контролируется CIS, лишь запускаемая программа. При этом параметры командной строки могут быть заданы так, что CIS неправильно их интерпретирует. Результатом может стать обход всех компонентов защиты CIS. Ситуация усугубляется тем, что ярлыки принимают вид любых значков и часто выдаются за каталоги и другие подобные объекты. Таким образом, ярлыки могут успешно включаться в состав вредоносных программ в качестве их стартеров.

С деталями некоторых уязвимостей можно ознакомиться на официальном форуме (требуется регистрация):

Свой специфичный баг имела версия CIS 7: отсутствие контроля скриптов с длинными путями; в версии CIS 8.0 этот баг устранен.

Для защиты от уязвимостей понадобится принять несколько мер.

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

  • включить Auto-Sandbox с набором правил наподобие предустановленного в конфигурации «Proactive Security»;
  • отключить опцию «Обнаруживать программы, требующие повышенных привилегий» на вкладке «Настройка Sandbox»;
  • отключить опцию «Доверять приложениям, установленным с помощью доверенных инсталляторов» на вкладке «Настройка рейтинга файлов».

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

В-третьих, необходимо защитить параметры CIS от изменения сторонними приложениями.

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

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

Еще одним путем попадания вредоносных файлов в доверенные мог оказаться взлом некриптостойкого хеша, на который ранее опиралась проверка репутации. Эта проблема устранена в версии CIS 8.2.0.5027.

Также необходимо учитывать, что проактивная защита CIS проверяет целостность лишь исполняемых файлов, но не загружаемых ими библиотек. Таким образом, безопасные exe-файлы могут эксплуатироваться для выполнения вредоносного кода из других файлов. Поэтому при запуске приложения из неизвестного каталога или архива следует убедиться в безопасности всех его компонентов. Один из способов это сделать — запустить приложение в песочнице, найти процесс этого приложения в KillSwitch, через контекстное меню открыть окно свойств процесса, перейти на вкладку «Модули» и дождаться, пока каждому модулю не поставится оценка.

CIS контролирует процессы частично путем внедрения в них библиотеки guard(32|64).dll. Существует угроза выхода вредоносных программ из-под такого контроля. От внедрения этой библиотеки зависит наложение ограничений Auto-Sandbox и ряд других функций. Поэтому нельзя полагаться на защиту Auto-Sandbox в режиме ограничений. Вместо этого предпочительно настраивать Auto-Sandbox либо на блокировку запуска неопознанных программ, либо на их виртуализацию. Также нельзя полностью полагаться на защиту COM-интерфейсов и другие функции, зависящие от внедрения указанной библиотеки.

Защита от внедрения shell-кода, якобы имеющаяся в CIS, показывает себя несостоятельной. Поэтому необходимо дополнить CIS специализированным средством защиты от эксплоитов, наподобие EMET. Такое средство снизит и уязвимость самого CIS к эксплоитам. (В версии CIS 7 эта проблема была особенно острой, так как внедряемая в процессы библиотека guard(32|64).dll не имела защиты ASLR; в версии CIS 8 эта защита появилась.)

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

Использование Microsoft EMET совместно с CIS

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

Внимание! Приведенные здесь сведения и рекомендации относятся только к версии EMET 5.2. См. замечание о EMET 5.5.

При установке EMET сразу выберем вариант «Use Recommended Settings» (вместо «Keep Existing Settings»). Затем усилим защиту, открыв главное окно и выбрав в секции «Quick Profile Name» вариант «Maximum security settings».

Включение функции DEP в режиме «Always On» может помешать работе некоторых программ (например, портативных, созданных с помощью VMware ThinApp). Если необходимо использовать такие программы, установим опцию DEP в вариант «Application Opt Out».

Кнопкой «Apps» в главном окне откроем список правил для приложений. Необходимо добавить в этот список основные используемые приложения: браузеры, мессенджеры, офисные приложения и т.д. Также понадобится добавить в список компоненты CIS: исполняемые файлы, расположенные в каталоге «%PROGRAMFILES%\Comodo\COMODO Internet Security».

Если заносить программы в список кнопкой «Add Application», то правило будет основано на полном пути к программе. Кнопкой «Add Wildcard» создаются более универсальные правила, в которых лишь имя файла должно быть точным, а путь может представлять собой шаблон. Например, шаблоны *\firefox.exe и *\plugin-container.exe соответствуют компонентам браузера Firefox, независимо от его местоположения.

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

Особенный конфликт вызывают функции Caller, SimExecFlow и StackPivot: для защищенных ими программ не работает анализ командной строки в CIS. Например, EMET по умолчанию включает данные функции для программы Word, и в результате Word может запустить любой скрипт без контроля со стороны CIS. Поэтому рекомендую отключить опции Caller, SimExecFlow и StackPivot во всех правилах EMET.

Другой вариант — для некоторых программ оставить опции Caller, SimExecFlow и StackPivot включенными, но в CIS полностью запретить этим программам запускать скрипты. Для этого понадобится объединить эти программы в группу «NoScript» и создать группу «InterpretersNames» с именами интерпретаторов (см. ниже), а затем в правилах HIPS запретить группе «NoScript» запускать программы из группы «InterpretersNames».

Необходимо дать EMET доступ к памяти всех приложений, включая CIS. Самый простой способ сделать это — добавить компоненты EMET в группу «Системные приложения» на вкладке «Группы файлов».

Для использования версии EMET 5.5 рекомендации будут другими. Эта версия также конфликтует с анализом командной строки, причем здесь уже не помогает отключение никаких функций: если какая-либо программа присутствует в списке правил EMET, то CIS не сможет проконтролировать, какие скрипты она запускает. Таким образом, для каждой программы придется выбирать: либо исключить ее из правил EMET, либо полностью запретить ей запускать скрипты, либо смириться с запуском неизвестных скриптов. Отключать же опции Caller, SimExecFlow и StackPivot теперь нет смысла. Также нет смысла отключать опцию EAF, так как конфликты с ней исчезли в версии EMET 5.5.

Блокировка ярлыков средствами CIS

Необходимость блокировать сторонние ярлыки средствами CIS возникает, как правило, если в установленной версии Windows недоступны политики ограниченного использования программ. Если они доступны, рекомендую использовать другой метод блокировки ярлыков.

Занесение ярлыков в список «Заблокированных файлов»

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

  • открыть вкладку «HIPS» > «Защищенные объекты» > «Заблокированные файлы»,
  • добавить в список любой файл и изменить путь на %USERPROFILE%\Desktop\*\*.lnk

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

Аналогичным способом можно запретить ярлыки в других нежелательных местах, например, на диске D:.

Однако данный метод не пригоден для блокировки ярлыков на съемных носителях, т.е. как раз на типичных источниках заражения. Очевидно, из-за этого смысл его применения теряется.

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

Запрет запуска приложений со съемных носителей

В CIS 8 появился своеобразный контроль съемных носителей: можно задавать отдельные правила Auto-Sandbox для программ, расположенных на таких дисках. Например, можно создать правило, чтобы расположенные на съемных носителях программы всегда блокировались или запускались виртуально, независимо от своего рейтинга:

  • на вкладке «Auto-Sandbox» включить использование этого компонента;
  • добавить новое правило Auto-Sandbox:
    • действие: «Блокировать» или «Запустить виртуально»;
    • цель: группа «Все приложения»;
    • на вкладке «Происхождение» добавить группу «Все приложения»;
    • в поле «Расположение» выбрать «Съемный диск»;
    • остальные опции не задавать;
  • расположить это правило вверху списка.

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

Запрет запуска командного интерпретатора

Наконец, можно предложить блокировку запуска командного интерпретатора из проводника и других файловых менеджеров. Это крайняя мера, которая сделает невозможным непосредственный запуск bat-файлов и затруднит использование интерпретатора командной строки. Но, если пользователю заведомо не нужны данные средства, можно пойти на этот шаг:

  • открыть вкладку «Правила HIPS»;
  • изменить правила для программы %windir%\explorer.exe:
    • выбрать вариант «Использовать собственный набор правил»;
    • скопировать набор правил «Разрешенное приложение»;
    • в пункте «Запуск приложения» нажать «Изменить»;
    • в открывшемся окне на вкладку «Заблокированные файлы» добавить любые два файла и изменить их пути на следующие:
      • %windir%\System32\cmd.exe
      • %windir%\SysWOW64\cmd.exe
  • аналогично запретить запуск cmd.exe другим файловым менеджерам.

Блокировка ярлыков системными политиками ограниченного использования программ

Можно блокировать ярлыки встроенным средством Windows: политиками ограниченного использования программ. Этот вариант имеет несколько преимуществ перед блокировкой ярлыков посредством CIS:

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

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

Рекомендую следующий порядок настройки:

  • нажать Win+R, набрать secpol.msc и запустить;
  • вызвать контекстное меню на пункте «Политики ограниченного использования программ» и выбрать «Создать политику ограниченного использования программ»;
  • открыть раздел «Дополнительные правила»;
  • через контекстное меню создать «правило для пути»:
    • путь: *.lnk
    • уровень безопасности: «Запрещено»;
  • аналогично создать запрещающие правила для следующих путей:
    • %USERPROFILE%\Desktop\*\*.lnk
    • %USERPROFILE%\Desktop\*\*\*.lnk
    • %USERPROFILE%\Desktop\*\*\*\*.lnk
    • %USERPROFILE%\Desktop\*\*\*\*\*.lnk
    • %USERPROFILE%\Desktop\*\*\*\*\*\*.lnk
    • %USERPROFILE%\Desktop\*\*\*\*\*\*\*.lnk
    • %USERPROFILE%\Desktop\*\*\*\*\*\*\*\*.lnk
    • %USERPROFILE%\Desktop\*\*\*\*\*\*\*\*\*.lnk
  • для следующих путей создать правила с уровнем безопасности «Неограниченный»:
    • %HOMEDRIVE%\*\*\*\*\*\*\*\*\*\*\*\*.lnk
    • %HOMEDRIVE%\*\*\*\*\*\*\*\*\*\*\*.lnk
    • %HOMEDRIVE%\*\*\*\*\*\*\*\*\*\*.lnk
    • %HOMEDRIVE%\*\*\*\*\*\*\*\*\*.lnk
    • %HOMEDRIVE%\*\*\*\*\*\*\*\*.lnk
    • %HOMEDRIVE%\*\*\*\*\*\*\*.lnk
    • %HOMEDRIVE%\*\*\*\*\*\*.lnk
    • %HOMEDRIVE%\*\*\*\*\*.lnk
    • %HOMEDRIVE%\*\*\*\*.lnk
    • %HOMEDRIVE%\*\*\*.lnk
    • %HOMEDRIVE%\*\*.lnk

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

Блокировка ярлыков политиками ограниченного использования программ

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

Защита параметров Comodo Internet Security

Защита базы данных CIS

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

Эта проблема была особенно острой для версий CIS ниже 8.2.0.5005, так как они позволяли модифицировать базу даже без прав администратора. Например, от имени ограниченного пользователя можно было занести вредоносный файл в список доверенных или просто повредить базу и тем самым вывести CIS из строя. Если учесть, что возможен запуск неопознанного приложения (например, скрипта) с правами доверенного, имелась серьезная уязвимость.

В версии CIS 8.2.0.5005 ограниченным пользователям запрещено непосредственное изменение базы, но оно все еще возможно от имени администратора.

Данную уязвимость легко устранить:

  • открыть вкладку «Правила HIPS»;
  • изменить правила для группы «Все приложения»:
    • в пункте «Защищенные файлы и папки» нажать «Изменить»;
    • в открывшемся окне на вкладке «Заблокированные файлы» добавить предустановленную группу «Файлы и папки COMODO».

Предполагается, что группа «Файлы и папки COMODO» содержит строку наподобие C:\ProgramData\Comodo*, как и положено по умолчанию.

Защита конфигурации CIS

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

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

  • на вкладке «Группы HIPS» > «Группы реестра» развернуть группу «Ключи реестра COMODO» и заменить входящие в нее шаблоны следующими:
    • HKEY_LOCAL_MACHINE\SOFTWARE\COMODO\CIS*
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CmdAgent\Mode*
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CmdAgent\CisConfigs*
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CmdAgent\PendingOperations*
    • HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CIS*
    • HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Cav*
    • *\SOFTWARE\Comodo*
  • на вкладке «Правила HIPS» изменить правила для группы «Все приложения»:
    • в пункте «Защищенные ключи реестра» нажать «Изменить»;
    • в открывшемся окне на вкладке «Заблокированные ключи реестра» добавить группу «Ключи реестра COMODO».

Защита от ложных интерпретаторов

Защита от ложных интерпретаторов в CIS 8.2

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

В версии CIS 8.2 эта уязвимость частично устранена. По крайней мере, теперь подобный «обман» трудно осуществить в реальной среде. Кроме того, выдать стороннюю программу можно лишь за приложения определенного вида: скрипты, jar-файлы, dll-файлы и т.д. Как правило, программу не удается выдать за какой-либо exe-файл (версия CIS 8.2.0.4508 еще могла принять стороннюю программу за системный файл smss.exe или csrss.exe; в версии CIS 8.2.0.4591 эта брешь закрыта).

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

Таким образом, в разрешающих правилах фаервола следует всегда указывать расширение файлов. Например, чтобы разрешить интернет всем программам в каталоге %COMMONPROGRAMFILES%\Java, понадобится использовать шаблон %COMMONPROGRAMFILES%\Java\*.exe, а не %COMMONPROGRAMFILES%\Java\*.

Более жесткие меры, как правило, не требуются для версии CIS 8.2.0.4591 и выше. Использование ложных интерпретаторов для обхода защиты стало неудобным, ненадежным и потому маловероятным. Оставшаяся часть статьи адресуется только пользователям более старых версий CIS, от 5.10 до 8.1.

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

Блокировка ложных интерпретаторов средствами CIS

Средствами CIS можно частично решить проблему ложных интерпретаторов:

  • открыть вкладку «Рейтинг файлов» > «Группы файлов»;
  • создать группу «InterpretersPaths» и добавить в нее следующие строки:
    • %PROGRAMFILES%\Java\*\java.exe
    • %PROGRAMFILES(x86)%\Java\*\java.exe
    • %ProgramW6432%\Java\*\java.exe
    • %PROGRAMFILES%\Java\*\javaw.exe
    • %PROGRAMFILES(x86)%\Java\*\javaw.exe
    • %ProgramW6432%\Java\*\javaw.exe
    • %windir%\hh.exe
    • %windir%\System32\hh.exe
    • %windir%\SysWOW64\hh.exe
    • %windir%\winhlp32.exe
    • %windir%\System32\cmd.exe
    • %windir%\SysWOW64\cmd.exe
    • %windir%\System32\wscript.exe
    • %windir%\SysWOW64\wscript.exe
    • %windir%\System32\cscript.exe
    • %windir%\SysWOW64\cscript.exe
    • %windir%\System32\mshta.exe
    • %windir%\SysWOW64\mshta.exe
    • %windir%\System32\msiexec.exe
    • %windir%\SysWOW64\msiexec.exe
    • %windir%\System32\rundll32.exe
    • %windir%\SysWOW64\rundll32.exe
    • %windir%\System32\regsvr32.exe
    • %windir%\SysWOW64\regsvr32.exe
    (Напомню, что для добавления строки следует добавить любой файл и изменить путь к нему.)
  • создать группу «InterpretersNames» и добавить в нее следующие строки:
    • *\java.exe
    • *\javaw.exe
    • *\hh.exe
    • *\winhlp32.exe
    • *\cmd.exe
    • *\wscript.exe
    • *\cscript.exe
    • *\mshta.exe
    • *\msiexec.exe
    • *\rundll32.exe
    • *\regsvr32.exe
    • *\perl.exe
  • на вкладке «Настройка HIPS» включить использование этого компонента, желательно в «Безопасном режиме»;
  • на вкладке «Правила HIPS» изменить правила для группы «Все приложения»:
    • в пункте «Запуск приложения» нажать «Изменить»;
    • в открывшемся окне на вкладке «Разрешенные файлы» добавить группу «InterpretersPaths»;
    • на вкладке «Заблокированные файлы» добавить группу «InterpretersNames»;

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

Однако данная мера не защищает от виртуальной подмены интерпретатора. Старые версии CIS позволяли подменить интерпретатор в виртуальной среде даже в отсутствие прав администратора (версия CIS 8.2.0.4674 уже требует для этого права администратора). При этом ложный интерпретатор, который, с точки зрения виртуальной среды, находится на месте настоящего, может быть запущен в ней. Несмотря на то, что в действительности он будет находиться в каталоге VTRoot, блокировки запуска не произойдет.

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

Чтобы защититься средствами Comodo от виртуальной подмены интерпретаторов, придется вообще отказаться от виртуализации, т.е. настроить Auto-Sandbox на блокировку неопознанных приложений вместо их запуска в виртуальной среде, а также запретить запуск приложений в виртуальной среде по требованию:

  • в правилах на вкладке «Auto-Sandbox» изменить действие «Запустить виртуально» на «Блокировать»;
  • на вкладке «Правила HIPS» изменить правило для группы «Все приложения»:
    • в пункте «Запуск приложения» нажать «Изменить»;
    • на вкладке «Заблокированные файлы» добавить программу virtkiosk.exe, находящуюся в каталоге CIS.

Приведенная защита от ложных интерпретаторов средствами CIS имеет еще одну проблему: любым программам разрешается запускать настоящие интерпретаторы. Если Auto-Sandbox настроен на изоляцию любых неопознанных программы (что и рекомендуется), то эта проблема не представляет угрозы. Но если Auto-Sandbox не используется, то вредоносные программы смогут осуществлять свою деятельность посредством интерпретаторов.

Блокировка ложных интерпретаторов системными политиками ограниченного использования программ

Политики ограниченного использования программ можно применять для блокировки не только ярлыков, но и ложных интерпретаторов.

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

Настройка будет следующей:

  • нажать Win+R, набрать secpol.msc и запустить;
  • вызвать контекстное меню на пункте «Политики ограниченного использования программ» и выбрать «Создать политику ограниченного использования программ»;
  • открыть раздел «Дополнительные правила»;
  • через контекстное меню создать «правило для пути»:
    • путь: cmd.exe
    • уровень безопасности: «Запрещено»;
  • аналогично создать запрещающие правила для следующих имен файлов:
    • java.exe
    • javaw.exe
    • hh.exe
    • winhlp32.exe
    • wscript.exe
    • cscript.exe
    • mshta.exe
    • msiexec.exe
    • rundll32.exe
    • regsvr32.exe
    • perl.exe
  • через контекстное меню создать «правило для хэша»:
    • кнопкой «Обзор» указать файл %windir%\System32\cmd.exe
    • уровень безопасности: «Неограниченный»;
  • в случае 64-битной системы создать также правило для хэша файла %windir%\SysWOW64\cmd.exe с уровнем безопасности «Неограниченный» (так как версии файлов в разных каталогах могут отличаться);
  • аналогично создать разрешающие правила для следующих файлов (при их наличии):
    • %windir%\hh.exe
    • %windir%\System32\hh.exe
    • %windir%\SysWOW64\hh.exe
    • %windir%\winhlp32.exe
    • %windir%\System32\cmd.exe
    • %windir%\SysWOW64\cmd.exe
    • %windir%\System32\wscript.exe
    • %windir%\SysWOW64\wscript.exe
    • %windir%\System32\cscript.exe
    • %windir%\SysWOW64\cscript.exe
    • %windir%\System32\mshta.exe
    • %windir%\SysWOW64\mshta.exe
    • %windir%\System32\msiexec.exe
    • %windir%\SysWOW64\msiexec.exe
    • %windir%\System32\rundll32.exe
    • %windir%\SysWOW64\rundll32.exe
    • %windir%\System32\regsvr32.exe
    • %windir%\SysWOW64\regsvr32.exe
    • java.exe в каталоге %PROGRAMFILES%\Java
    • java.exe в каталоге %PROGRAMFILES(x86)%\Java
    • javaw.exe в каталоге %PROGRAMFILES%\Java
    • javaw.exe в каталоге %PROGRAMFILES(x86)%\Java

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

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

  • нажать Win+R, набрать secpol.msc и запустить;
  • в разделе «Политики ограниченного использования программ» через контекстное меню открыть свойства пункта «Применение»;
  • в секции «Применять политику ограниченного использования программ для...» выбрать вариант «всех пользователей, кроме локальных администраторов» и нажать «Применить»;
  • произвести обновление Windows или Java;
  • в каждом правиле заново указать целевой файл для пересчета его хэша;
  • в секции «Применять политику ограниченного использования программ для...» обратно выбрать вариант «всех пользователей».

Внимание! Приложения, изолированные в Auto-Sandbox с уровнем ограничений «Ограниченное», с виртуализацией или без нее, не подчиняются политикам ограниченного использования программ. При обычной виртуализации без ограничений — подчиняются. Обнаружено в Windows 7 x64 SP1.

Блокировка ложных интерпретаторов системными политиками AppLocker

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

В то же время использование AppLocker имеет следующие препятствия:

  • данная функция доступна не во всех редакциях Windows;
  • при использовании AppLocker отключаются политики ограниченного использования программ (которые могли бы эффективно блокировать ярлыки);
  • в AppLocker отсутствует возможность блокировки ярлыков.

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

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

Последовательность настройки AppLocker для блокировки ложных интерпретаторов следующая:

  • нажать Win+R, набрать secpol.msc и запустить;
  • раскрыть раздел «Политики управления приложениями» > «AppLocker» > «Исполняемые файлы»;
  • через контекстное меню создать новое правило:
    • разрешения: «Разрешить»,
    • условия: «Путь»,
    • путь: *
    • нажать кнопку «Создать»,
    • на предложение создать правила по умолчанию ответить «Нет»;
  • создать точно такие же правила в разделе «Правила установщика Windows» и «Правила сценариев»;
  • в разделе «Исполняемые файлы» создать новое правило:
    • разрешения: «Запретить»,
    • условия: «Путь»,
    • путь: *\cmd.exe
    • исключения:
      • выбрать тип «Издатель»,
      • нажать кнопку «Добавить»,
      • кнопкой «Обзор» и указать файл %windir%\System32\cmd.exe
    • нажать кнопку «Создать»,
  • создать аналогичные правила:
    • запретить путь *\java.exe, исключив по издателю файл java.exe в каталоге %PROGRAMFILES(x86)%\Java
    • запретить путь *\javaw.exe, исключив по издателю файл javaw.exe в каталоге %PROGRAMFILES(x86)%\Java
    • запретить путь *\hh.exe, исключив по издателю файл %windir%\hh.exe
    • запретить путь *\winhlp32.exe, исключив по издателю файл %windir%\winhlp32.exe
    • запретить путь *\wscript.exe, исключив по издателю файл %windir%\System32\wscript.exe
    • запретить путь *\cscript.exe, исключив по издателю файл %windir%\System32\cscript.exe
    • запретить путь *\mshta.exe, исключив по издателю файл %windir%\System32\mshta.exe
    • запретить путь *\msiexec.exe, исключив по издателю файл %windir%\System32\msiexec.exe
    • запретить путь *\rundll32.exe, исключив по издателю файл %windir%\System32\rundll32.exe
    • запретить путь *\regsvr32.exe, исключив по издателю файл %windir%\System32\regsvr32.exe
    • запретить путь *\perl.exe, исключив по издателю оригинальный файл, если он используется;
    (Очевидно, исключения следует добавлять только при наличии данных файлов в системе. Запреты же нужны в любом случае.)
  • нажать Win+R, набрать services.msc и запустить;
  • открыть свойства службы «Удостоверение приложения» (AppIDSvc), установить тип запуска «Автоматически» и нажать «Запустить».

Комментарии и отзывы

Добавляя комментарий, ознакомьтесь с Правилами сообщества