Касперский блокирует скрипты powershell
Как это ни странно, я нашёл на Хабре всего одну статью по данной тематике — и ту в песочнице и сильно незаконченную фактически содержащую в себе маленький кусочек чуть переделанной справки по продукту. Да и Google по запросу klakaut молчит.
Я не собираюсь рассказывать, как администрировать иерархию Kaspersky Security Center (далее по тексту KSC) из командной строки — мне это пока не понадобилось ни разу. Просто хочу поделиться некоторыми соображениями по поводу средств автоматизации с теми, кому это может понадобиться, и разберу один кейс, с которым мне пришлось столкнуться. Если тебе, %habrauser%, эта тема будет интересной — добро пожаловать под кат.
Исторически сложилось так, что в качестве средства антивирусной защиты на работе я предпочитаю продукты Лаборатории Касперского (далее ЛК). Причины и прочие священные войны личных мнений, пожалуй, оставим за кадром.
Естественно, хотелось бы централизованно развернуть, защитить, оградить и не пущать рисовать красивые графики, интегрироваться в существующие системы мониторинга и заниматься прочим перекладыванием работы с больной головы на здоровый сервер. И если с развёртыванием и защитой тут всё более или менее в порядке (у ЛК даже есть какие-то онлайн-курсы по продуктам), то с интеграцией уже сильно грустнее: в последней на текущий момент версии KSC 10.2.434 появилась интеграция аж с двумя SIEM: Arcsight и Qradar. На этом всё.
Для интеграции в что-то своё KSC предоставляет аж 2 интерфейса:
-
: в БД KSC есть ряд представлений с именами, начинающимися на «v_akpub_», из которых можно достать какую-то информацию о состоянии антивирусной защиты. : DCOM-объект, позволяющий скриптовать работу с KSC.
Минусы klakdb очевидны: чтобы напрямую обратиться к БД, нужно иметь к этой БД доступ, что приводит к необходимости лишних телодвижений по созданию правил доступа в межсетевых экранах, настройке прав доступа на серверах СУБД и прочему крайне неувлекательному времяпрепровождению. Ну и плюс мониторинг актуальности всех этих правил, естественно. Особенно интересно становится, когда имеется 20+ серверов — и все в разных филиалах, в каждом из которых свои администраторы.
klakaut в этом плане значительно более интересен: подключившись к корневому серверу иерархии, можно средствами самого KSC пройтись по оной иерархии и получить доступ ко всем нужным данным. Например, построить дерево серверов KSC с пометкой, кто из них живой, а кто нет, позапускать задачи, поперемещать компьютеры и вообще дать волю фантазии.
Минусы тоже есть, естественно: долго и сложно. Если нужно собрать какую-то статистику — нужно будет сначала долго писать скрипт, а потом долго ловить баги ждать, когда он отработает.
Естественно, никто не запрещает (по крайней мере, мне про это неизвестно) использовать оба механизма вместе: например, пройтись по иерархии серверов с помощью klakaut, получить полный список серверов KSC с информацией об используемых БД, а потом уже передать эту информацию в более другие средства автоматизации, которые удалят устаревшие правила из сетевых экранов, создадут новые, дадут разрешения на доступ и принесут кофе в постель отредактируют список источников данных в вашей системе мониторинга, которая, в свою очередь, опросит список и, обнаружив какие-нибудь девиации, с помощью klakaut сделает что-нибудь хорошее. Ну, или просто зарегистрирует инцидент в трекере. Тогда что-нибудь хорошее сделают администраторы в ручном режиме.
Воодушевлённый всеми этими соображениями, я написал свой первый скрипт:
И запустил его на сервере:
Открыв консоль KSC, я убедился, что с правами у меня всё в порядке.
К сожалению, KSC не логирует неудачные попытки входа. Переписка с вендором показала, что логирование неудачных попыток входа можно включить (это была отдельная увлекательная история, которая, кстати, ещё не закончилась), однако данная конкретная попытка в логи всё равно попадать отказалась.
Казалось бы, можно сделать вот так:
В этом случае никаких ошибок не будет, но указывать логин с паролем открытым текстом в скрипте мне не показалось замечательной идеей. Новая переписка с техподдержкой ЛК подарила мне следующую рекомендацию:
Необходимо выставить в настройках COM, на вкладке Default Properties:
Default Authentication Level: Packet
Default Impersonation Level: Delegate
Эта инструкция заставила работать исходный скрипт, но показалась мне сомнительной в плане безопасности, поэтому я решил покопать чуть глубже. После некоторого времени поисков нашёлся добрый человек, который подсказал мне, как задать указанные уровни проверки подлинности и олицетворения для конкретного объекта, а не разрешать всем и всё сразу:
Вот так скрипт никаких ошибок выдавать не стал. Первый квест пройден.
Вообще в боевой среде неплохо бы проверять при вызове EnableImpersonation возвращаемое значение на предмет ошибок, а не перенаправлять его в никуда, как это сделал я.
Следующая задача: получить от KSC данные об используемой БД.
А вот тут всё сложно: документация о том, как это сделать, молчит. Исследование класса KlAkProxy ничего интересного не выявило, кроме параметра KLADMSRV_SERVER_HOSTNAME, который оказался идентификатором компьютера, на котором установлен KSC.
Перейдём тогда к компьютеру, для этого есть специальный класс KlAkHosts2. Для сокращения количества кода приведу только содержимое блока try:
Обратите внимание: переменная $Params, которую я использовал при подключении к KSC — экземпляр класса KlAkParams. А переменная $HostParams при, на мой взгляд, аналогичной функциональности, является экземпляром класса KlAkCollection. Почему используются разные классы — боюсь даже представить. Видимо, то, что SetAt принимает первым аргументом только целочисленные значения — очень принципиальный момент.
Данный код вернул значение «KSC», а значит, я на верном пути.
Метод GetHostInfo класса KlAkHosts2 достаточно хорошо задокументирован, но — не содержит нужной мне информации. Увы и ах. Зато есть метод GetHostSettings. Всё описание для которого сводится к следующему:
Давайте, заглянем внутрь:
Пробежавшись глазами по названиям секций, я решил просмотреть 85 и 87, поскольку остальные на нужное мне были не очень похожи.
Секция 85, судя по всему, отвечает за события и ныне нам неинтересна. А вот в 87 есть что-то, на что стоит обратить внимание:
Тут я воспользовался одним из предыдущих кейсов, где упоминалось, что нужные данные следует брать именно из KLSRV_CONNECTION_DATA (тогда я ещё не знал, что это вообще такое, просто отложилось).
Ну, вот, в общем-то, и всё. Данные об используемой БД получены. Квест пройден.
Наверное, ещё неплохо бы набросать скрипт для прохождения по иерархии серверов. Здесь ничего загадочного не оказалось, всё было вполне по документации. Я написал скрипт, который выбирает UID родителя, UID самого сервера, экземпляр СУБД и имя БД и выводит их в stdout через разделитель.
Стенд маленький, поэтому результат оказался не очень впечатляющим:
Естественно, чтобы превратить точку в актуальное имя сервера, придётся поколдовать с KlAkHosts2.GetHostInfo(), но это уже не столь страшно, просто ещё сколько-то кода.
Техподдержка ЛК, естественно, пугала меня тем, что структура SS_SETTINGS в следующих релизах KSC может поменяться, поэтому так лучше не делать. К сожалению, даже мой внутренний перфекционист считает, что скрипт нельзя просто написать и забыть: при смене версии используемого ПО его по-любому придётся тестировать и отлаживать. Так что пока пользуемся тем, что есть, а проблемы будем решать по мере поступления, благо, техника уже отработана.
В ходе выполнения задачи Проверка скриптов Kaspersky Security для Windows Server контролирует выполнение скриптов, созданных по технологиям Microsoft Windows Script Technologies (Active Scripting), например, скриптов VBScript или JScript®. Программа может также обрабатывать скрипты PowerShell™ и скрипты, работающие в программах Microsoft Office в операционных системах с установленным компонентом Antimalware Scan Interface (далее "AMSI"). Можно разрешить или запретить исполнение опасных или предположительно опасных скриптов. Если программа Kaspersky Security для Windows Server признала скрипт предположительно опасным, она выполняет выбранное вами действие: запрещает или разрешает выполнение скрипта. Если выбрано действие Блокировать выполнение , программа разрешает выполнение скрипта, только если этот скрипт считается безопасным.
Начиная с операционной системы Microsoft Windows Server 2016, Kaspersky Security для Windows Server поддерживает технологию AMSI. Технология AMSI позволяет интегрировать программы и службы с любым установленным на устройстве антивирусным программным обеспечением, чтобы это программное обеспечение могло перехватывать и проверять все исполняемые скрипты.
По умолчанию компонент Проверка скриптов не устанавливается на защищаемое устройство в составе программы. Если установлен компонент Проверка скриптов, программа регистрируется как поставщик AMSI-защиты и проверяет исполняемые скрипты.
На устройствах с операционными системами, не поддерживающими технологию AMSI, использование этого компонента может оказаться несовместимым с некоторыми сторонними программами, установленными на защищаемом устройстве. В этом случае проверка сторонних скриптов может приводить к ошибкам в работе этих скриптов. Рекомендуется либо отказаться от использования сторонних программ, либо остановить задачу Проверка скриптов. Если задача остановлена, возрастают риски, связанные с безопасностью выполнения скриптов.
Если вы хотите использовать компонент Проверка скриптов, вам нужно выбрать его в списке устанавливаемых компонентов вручную во время инсталляции Kaspersky Security для Windows Server. По умолчанию, если компонент установлен, задача Проверка скриптов запускается автоматически при запуске Kaspersky Security для Windows Server.
Более подробная информация о технологии AMSI приведена на сайте Microsoft Windows.
Чтобы настроить задачу Проверка скриптов, выполните следующие действия:
- Разверните узел Управляемые устройства в дереве Консоли администрирования Kaspersky Security Center.
- Выберите группу администрирования, для которой требуется настроить параметры программы.
- В панели результатов выбранной группы администрирования выполните одно из следующих действий:
- Чтобы настроить параметры программы для группы защищаемых устройств, выберите закладку Политики и откройте окно Свойства: .
- Чтобы настроить параметры программы для отдельного защищаемого устройства, выберите закладку Устройства и откройте окно Параметры программы .
Если к устройству применяется активная политика Kaspersky Security Center, запрещающая изменение параметров программы, эти параметры недоступны для изменения в окне Параметры программы .
Kaspersky Security для Windows Server разрешает выполнение предположительно опасных скриптов.
Kaspersky Security для Windows Server блокирует выполнение предположительно опасных скриптов.
Этот вариант выбран по умолчанию.
Флажок включает или выключает использование эвристического анализатора при проверке объектов.
Если флажок установлен, эвристический анализатор включен.
Если флажок снят, эвристический анализатор выключен.
По умолчанию флажок установлен.
Уровень эвристического анализа обеспечивает баланс между тщательностью поиска угроз, степенью загрузки ресурсов операционной системы и временем проверки.
Существуют следующие уровни чувствительности проверки:
- Поверхностный . Эвристический анализатор выполняет меньше инструкций, содержащихся в исполняемых файлах. При таком режиме вероятность обнаружить угрозу снижается. Проверка требует меньше ресурсов системы и выполняется быстрее.
- Средний . Эвристический анализатор выполняет то количество инструкций в исполняемом файле, которое рекомендовано специалистами "Лаборатории Касперского".
Этот уровень выбран по умолчанию.
- Глубокий . Эвристический анализатор выполняет больше инструкций, содержащихся в исполняемых файлах. При таком режиме вероятность обнаружить угрозу возрастает. Проверка требует больше ресурсов системы, занимает больше времени, а также возможно увеличение количества ложных срабатываний.
Параметр доступен, если установлен флажок Использовать эвристический анализатор .
Флажок включает или выключает применение доверенной зоны в задаче.
Если флажок установлен, Kaspersky Security для Windows Server будет учитывать исключения, указанные в списке исключений доверенной зоны с помощью местоположения или с помощью имени или маски имени объекта обнаружения.
Если флажок снят, Kaspersky Security для Windows Server не учитывает исключения при выполнении задачи Проверка скриптов.
Компонент Адаптивный контроль аномалий доступен только для продуктов Kaspersky Endpoint Security для бизнеса Расширенный и Kaspersky Total Security для бизнеса (более подробная информация о продуктах Kaspersky Endpoint Security для бизнеса доступна на сайте "Лаборатории Касперского").
Компонент Адаптивный контроль аномалий отслеживает и блокирует подозрительные действия, нехарактерные для компьютеров сети организации. Для отслеживания нехарактерных действий Адаптивный контроль аномалий использует набор правил (например, правило Запуск Windows PowerShell из офисной программы). Правила созданы специалистами "Лаборатории Касперского" на основе типичных сценариев вредоносной активности. Вы можете выбрать поведение Адаптивного контроля аномалий для каждого из правил и, например, разрешить запуск PowerShell-скриптов для автоматизации решения корпоративных задач. Kaspersky Endpoint Security обновляет набор правил с базами программы. Обновление набора правил нужно подтверждать вручную.
Настройка Адаптивного контроля аномалий
Настройка Адаптивного контроля аномалий состоит из следующих этапов:
-
Обучение Адаптивного контроля аномалий.
После включения Адаптивного контроля аномалий правила работают в обучающем режиме. В ходе обучения Адаптивный контроль аномалий отслеживает срабатывание правил и отправляет события срабатывания в Kaspersky Security Center. Каждое правило имеет свой срок действия обучающего режима. Срок действия обучающего режима устанавливают специалисты "Лаборатории Касперского". Обычно срок действия обучающего режима составляет 2 недели.
Если в ходе обучения правило ни разу не сработало, Адаптивный контроль аномалий будет считать действия, связанные с этим правилом, подозрительными. Kaspersky Endpoint Security будет блокировать все действия, связанные с этим правилом.
Если в ходе обучения правило сработало, Kaspersky Endpoint Security регистрирует события в отчете о срабатываниях правил и в хранилище Срабатывание правил в обучающем режиме .
Администратор анализирует отчет о срабатываниях правил или содержание хранилища Срабатывание правил в обучающем режиме . Далее администратор может выбрать поведение Адаптивного контроля аномалий при срабатывании правила: блокировать или разрешить. Также администратор может продолжить отслеживать срабатывание правила и продлить работу программы в обучающем режиме. Если администратор не предпринимает никаких мер, программа также продолжит работать в обучающем режиме. Отcчет срока действия обучающего режима начинается заново.
Настройка Адаптивного контроля аномалий происходит в режиме реального времени. Настройка Адаптивного контроля аномалий осуществляется по следующим каналам:
- Адаптивный контроль аномалий автоматически начинает блокировать действия, связанные с правилами, которые не сработали в течение обучающего режима.
- Kaspersky Endpoint Security добавляет новые правила или удаляет неактуальные.
- Администратор настраивает работу Адаптивного контроля аномалий после анализа отчета о срабатывании правил и содержимого хранилища Срабатывание правил в обучающем режиме . Рекомендуется проверять отчет о срабатывании правил и содержимое хранилища Срабатывание правил в обучающем режиме .
При попытке вредоносной программы выполнить действие, Kaspersky Endpoint Security заблокирует действие и покажет уведомление (см. рис. ниже).
Уведомление Адаптивного контроля аномалий
Алгоритм работы Адаптивного контроля аномалий
Kaspersky Endpoint Security принимает решение о выполнении действия, связанного с правилом, по следующему алгоритму (см. рис. ниже).
Алгоритм работы Адаптивного контроля аномалий
Параметры компонента Адаптивный контроль аномалий
Отчет о состоянии правил
В этом отчете содержится информация о статусе правил обнаружения Адаптивного контроля аномалий (например, статусы Выключено или Блокировать). Отчет формируется для всех групп администрирования.
Отчет о срабатываниях правил
В этом отчете содержится информация о подозрительных действиях, обнаруженных с помощью Адаптивного контроля аномалий.Отчет формируется для всех групп администрирования.
Таблица правил Адаптивного контроля аномалий. Правила созданы специалистами "Лаборатории Касперского" на основе типичных сценариев потенциально вредоносной активности.
Кажется не так давно это было, примерно в 2015 году, мы начали слышать о хакерах, не использовавших вредоносных программ внутри периметра атакуемой цели. А использовали они то, что было под рукой – это были различные инструменты, находившиеся на целевом сайте. Это оказалось идеальным способом, чтобы сделать свое «грязное дело» не поднимая лишнего «шума».
Этот подход в наше время набрал обороты и стал мейнстримом, в первую очередь из-за обилия готовых инструментариев хакеров, таких как PowerShell Empire.
Мы уже писали о том, как PowerShell, когда он дополняется PowerView, становится мощным поставщиком информации для хакеров (вся эта мудрость собрана в нашей подборке, которую вы должны прочитать как можно скорее).
Безусловно, любой инструмент может использоваться как для хорошего так и для плохого, так что я и не думаю тут намекать, что PowerShell был создан, чтобы облегчить жизнь хакерам.
Но так же, как вы бы не оставили сверхмощный болторез рядом с навесным замком, вы, вероятно, не захотите разрешить, или хотя бы сделать это максимально более трудным для хакеров получить в свои руки PowerShell.
Это в свою очередь поднимает большую тему в мире кибербезопасности: ограничение доступа к приложениям, также известную как белые и черные списки доступа. Общая идея в том, чтобы операционная система знала и строго контролировала какие приложения могут быть запущены пользователем, а какие – нет.
Например, будучи homo blogus, мне, как правило, нужны некоторые основные инструменты и приложения (а также теплое местечко, где могу спать ночью), и я прекрасно могу прожить без оболочки PowerShell, netcat, psexec, и всех других команд, о которых я рассказывал в предыдущих постах. То же самое относится к большинству работников в компаниях, и поэтому квалифицированный ИТ-специалист должен быть в состоянии составить список приложений, которые являются безопасными для использования.
В мире Windows, возможно использовать правила на выполнение приложений с помощью специальных ограничивающих политик использования программ, а в последнее время и AppLocker.
Однако, прежде чем мы перейдем к этим передовым идеям, давайте попробуем два очень простых решения, а затем посмотрим, что с ними не так.
ACL и другие упрощения
Мы часто думаем о списках доступа ACL Windows, что они используются для управления доступом к читабельному содержимому. Но они также могут быть применены и к исполняемым файлам — то есть.ехе, .vbs, .ps1 и остальным.
Я вернулся в облако Amazon Web Services, где у меня находится домен Windows для мифической и некогда легендарной компании Acme и там проделал работу с ACL, дабы продемонстрировать некоторые ограничения доступа.
PowerShell .exe, любой системный администратор сможет без труда сказать вам, находится в C:\Windows\System32\WindowsPowerShell\v1.0. Я перешел в эту папку, вызвал ее свойства и моментально ограничил права выполнения PowerShell на 2 основные группы: «Администраторов домена» и «Acme-SnowFlakes”, группы опытных пользователей Acme.
Я перезашел на сервер, как Боб, мой амплуа в компании Acme, и попытался вызвать PowerShell. Результаты ниже.
На практике, вы могли бы, наверняка, придумать скрипт — почему бы не использовать PowerShell чтобы автоматизировать этот процесс настройки ACL для всех ноутбуков и серверов в небольших и средних по размеру компаниях.
Это не плохое решение.
Если вам не нравится идея изменения ACL на исполняемых файлах, PowerShell предлагает свои собственные средства ограничения. Как пользователь с админ-правами, можно использовать, все что угодно, но проще всего встроенный командлет Set-ExecutionPolicy.
Это уже не настолько «топорное» решение, как установка ACL. Например, вы сможете ограничить PowerShell для работы только в интерактивном режиме – с помощью параметра Restricted — так что он не будет выполнять PS-скрипты, которые могут содержать вредоносные программы хакеров.
Однако, это также заблокирует и скрипты PowerShell, запускаемые вашими ИТ-специалистами. Чтобы разрешить одобренные скрипты, но отключить скрипты злобных хакеров, используйте параметр RemoteSigned. Теперь PowerShell будет запускать только подписанные скрипты. Администраторам, конечно, придется создать их собственные сценарии и затем подписать их с использованием проверенных учетных данных.
Я не буду вдаваться в подробности, как это сделать, в основном потому, что это так легко обойти. Кое-кто тут в блоге описал аж 15 способов обхода ограничений безопасности в PowerShell.
Самый простой – это с помощью параметра Bypass в самом PowerShell. Да! (см.ниже).
Похоже на дыру в безопасности, а?
Так что в PowerShell есть несколько основных уязвимостей. Это кстати и понятно, так как это, в конце концов, всего лишь программная оболочка.
Но даже подход ограничений на уровне ACL имеет свои фундаментальные проблемы.
Если хакеры ослабят свою философию, то они смогут запросто скачать, скажем, с помощью трояна удаленного доступа (RAT) — их собственную копию PowerShell.ехе. А затем запустить его напрямую, с легкостью избежав ограничений с разрешениями с локальным PowerShell.
Политики Ограничения Использования Программ
Эти основные дыры в безопасности (как и многие другие) всегда сопровождают потребительский класс операционных систем. Это навело исследователей ОС на мысль придумать безопасную операционную систему, которая бы имела достаточно силы, чтобы контролировать то, что может быть запущено.
В мире Windows, эти силы известны как политики ограничения использования программ (SRP) — для ознакомления, посмотрите это — они настраиваются через редактор Групповых политик.
С их помощью вы сможете контролировать, какие приложения могут быть запущены на основании расширения файла, имен путей, и было ли приложение подписано цифровой подписью.
Самый эффективный, хоть и самый болезненный подход, это запретить все, а потом добавлять туда приложения, которые вам действительно нужны. Это известно как внесение в „белый список“.
Мы разберем это более подробно в следующей части.
В любом случае, вам потребуется запустить редактор политик, gpEdit и перейдите к политике Local Computer Policy>Windows Settings>Security Settings>Software Restriction Polices>Security Levels. Если Вы нажмете на “Запретить (Disallowed)”, то вы можете сделать это политикой безопасности по-умолчанию — не запускать любые исполняемые файлы!
Белый список: запретить по-умолчанию, а затем добавить разрешенные приложения в “Дополнительные правила (Additional Rules)”.
Это больше похоже на тактику выжженной земли. На практике, потребуется ввести “дополнительные правила”, чтобы добавить обратно разрешенные приложения (с указанием их наименования и пути). Если вы выходите из оболочки PowerShell, то вы фактически отключаете этот инструмент на месте.
К сожалению, вы не можете подстроить правила политик ограничения использования программ на основании отдельных групп или пользователей. Блин!
И теперь это логично приводит нас к последнему достижению безопасности Microsoft, известному как AppLocker, который имеет свои уникальные особенности, чтобы разрешить открыть приложение. Поговорим об этом в следующий раз.
Читайте также: