Повысьте безопасность с помощью ограниченного языкового режима PowerShell.
История убедительно продемонстрировала, что кибер-злоумышленники воспользуются любой предполагаемой слабостью системы, чтобы получить к ней доступ. Хотя некоторые недооценивают идею о том, что PowerShell можно использовать в качестве инструмента для атаки на систему, было немало задокументированных случаев, когда злоумышленники делали именно это. Поскольку PowerShell иногда может представлять интерес для тех, у кого плохие намерения, рекомендуется по возможности укреплять PowerShell, чтобы предотвратить его использование. Один из способов сделать это — включить ограниченный языковой режим в сеансах PowerShell.
Что такое ограниченный языковой режим?
Так что же такое ограниченный языковой режим? Проще говоря, режим — это инструмент, который можно использовать для ограничения типов команд, которые могут выполняться в сеансе PowerShell. Позвольте мне привести вам очень простой пример.
Если вы посмотрите на рисунок ниже, то увидите, что я открыл два отдельных окна PowerShell. Верхнее окно совершенно обычное. Как видите, я ввел в это окно математическое выражение. Это выражение запрашивает квадратный корень из 64. PowerShell вернул значение 8, что является правильным ответом. В нижнем окне PowerShell на рисунке включен режим ограниченного языка. Я ввел точно такое же математическое выражение в это окно, но получил сообщение об ошибке, в котором говорилось, что PowerShell не удалось вызвать метод.
Хорошо, так что же здесь происходит на самом деле? Почему в одном окне команда не удалась, а в другом успешно? Простое объяснение заключается в том, что ограниченный языковой режим позволяет продолжать использовать базовые командлеты PowerShell, но блокирует команды, которые можно использовать для взаимодействия с различными API. Причина, по которой математическое выражение, показанное на предыдущем рисунке, вызвало ошибку, заключается в том, что я пытался использовать.NET. Если бы я ввел более простое выражение, такое как 2+2, операция была бы разрешена.
Существует длинный список элементов, которые PowerShell либо ограничивает, либо блокирует, когда включен ограниченный языковой режим. Я не буду утомлять вас полным списком, но некоторые из наиболее примечательных пунктов включают в себя:
• COM-объекты
• Неутвержденные типы.NET
• Рабочие процессы на основе XAML
• Классы PowerShell
Настройка ограниченного языкового режима PowerShell
Если вы хотите определить, какой языковой режим PowerShell использует в данный момент, введите следующую команду:
$ExecutionContext.SessionState.LanguageMode
Как вы можете видеть на снимке экрана ниже, PowerShell настроен на использование полного языкового режима, что означает, что ограниченный языковой режим не включен.
Если вы решите включить ограниченное делегирование, вы можете сделать это с помощью варианта команды, показанной выше. Просто введите команду, как и раньше, но добавьте = «ConstrainedLanguage». Полная команда выглядит так:
$ExecutionContext.SessionState.LanguageMode = "Ограниченный язык"
Вы можете увидеть, как выглядит переключение с полного языка на язык с ограничениями на скриншоте ниже.
Ахиллесова пята PowerShell
Проблема с использованием ограниченного делегирования в качестве функции безопасности заключается в том, что в зависимости от того, как оно реализовано, злоумышленник может относительно легко обойти его. Причина этого в том, что языковой режим PowerShell зависит от сеанса. Позвольте мне показать вам, что я имею в виду.
Если вы посмотрите на скриншот ниже, вы увидите, что у меня открыто два окна PowerShell. Я установил языковой режим окна слева на Constrained Language. Затем я проверил языковой режим, чтобы убедиться, что PowerShell действительно правильно настроен на использование ограниченного языка. Затем я открыл окно справа и проверил языковой режим PowerShell. Сеанс PowerShell, работающий в этом окне, использует полный язык, хотя сеанс в окне слева по-прежнему ограничен использованием ограниченного языка. Другими словами, если злоумышленник хочет получить доступ ко всему языку, ему достаточно открыть еще один сеанс PowerShell.
Две проблемы
Хотя ограниченный языковой режим может повысить безопасность, его использование создает две большие проблемы. Во-первых, как отмечалось ранее, ограниченный языковой режим легко обойти, поскольку он зависит от сеанса. Если злоумышленник хочет избежать ограниченного языкового режима, он может просто запустить новый сеанс PowerShell.
Вторая проблема с использованием ограниченного языкового режима заключается в том, что он может нарушить работу существующих сценариев PowerShell. Ранее я показывал вам пример математического выражения, которое нельзя было вычислить, поскольку для этого требовалось использование.NET. Только представьте, если бы это выражение было частью сценария.
Хитрость в том, чтобы сделать использование языка с ограничениями практичным, состоит в том, чтобы принять идею о том, что режим языка с ограничениями не предназначен для использования сам по себе. Вместо этого ограниченный языковой режим предназначен для использования в сочетании с целостностью кода пользовательского режима Device Guard (UMCI).
Для тех, кто может быть не знаком с UMCI, это инструмент, который позволяет администраторам устанавливать политики, описывающие код, который разрешен для запуска в системе. Поскольку Device Guard работает на уровне всей системы, он идеально подходит для принудительного использования языкового режима с ограничениями. Злоумышленник не сможет обойти ограниченный языковой режим, открыв новый сеанс PowerShell, поскольку политики Device Guard применяются ко всей системе, а не только к текущему сеансу PowerShell.
Мощный инструмент
Ограниченный языковой режим может быть очень мощным инструментом для блокировки PowerShell, чтобы предотвратить его использование в гнусных целях. Тем не менее, сам по себе он совершенно неэффективен, поскольку злоумышленник может обойти его, запустив еще один сеанс PowerShell, или просто отключить его, введя одну команду. Однако, несмотря на свои недостатки, ограниченный языковой режим может значительно повысить безопасность PowerShell, если он используется в сочетании с целостностью кода пользовательского режима Device Guard.