PowerShell v 5.0 стартует в ограниченном языковом режиме (constrained language mode) при запуске на компьютере, работающем в режиме белого списка (SRP/Bitlocker). Как этого избежать?

Пришла беда откуда не ждали: после установки PowerShell v 5.0. любой запуск PowerShell на моем компьютере стал сопровождаться сообщением об ошибке:

. C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1 : Cannot dot-source this command because it was defferent language mode. To invoke this command without importing its contents, omit the ‘.’ operator.

Из сообщения об ошибке понятно, что PowerShell запустился в режиме ограниченной функциональности (constrained language mode) из-за чего и не  смог выполнить профиль. Погуглив, я обнаружил интересный топик на одном из форумов, автор которого утверждал, что причина такого поведения PowerShell v5.0 – настройка компьютера на функционирование в режиме белого списка запускаемых программ при помощи SRP. Я так же использую настройку запуска программ в режиме белого списка, посему решил проверить эту гипотезу, запуская PowerShell при включенном и выключенном SRP, и она полностью подтвердилась. Я сначала понадеялся, что constrained mode удастся отключить при помощи переменной окружения __PSLockdownPolicy, однако, оказалось, что для PowerShell v5  это не так: ни пользовательская, ни системная переменные окружения не смогли заставить PowerShell запуститься в режиме Full Language mode. Я обратился к Вадимсу Подансу, в надежде, что он в курсе нововведений, произошедших в PowerShell v 5.0. Оказалось, что разработчики PowerShell в v5.0 стали закручивать гайки, и на машинах, работающих в режиме белого списка, PowerShell теперь принудительно запускается в constrained language mode. К сожалению, запуск PowerShell в ограниченном режиме (constrained language mode) влечет за собой следующие очень нехорошие последствия: перестает выполняться профиль пользователя (а, значит, невозможно настроить под себя интерактивный режим работы консоли), не работает отладчик (а это уже совсем печально).

Как же жить с этим дальше? Отключать режим белого списка запускаемых программ для того, чтобы получить возможность работать с полноценным PowerShell – это сродни лечения головной боли посредством усечения головы. Хотелось бы пожертвовать чем-то меньшим, например ногами Подмигивающая рожица. Вадимс предложил включить логирование SRP и посмотреть, что происходит при запуске powershell.exe. Оказалось, что при запуске powershell.exe  в папке %temp% создается пара файлов с произвольным именем и расширениями ps1 и psm1, которые запускаются на исполнение. В лог-файле было видно, что запуск этих файлов был заблокирован при помощи SRP.

powershell.exe (PID = 5140) identified C:\Users\shs\AppData\Local\Temp\halnmb3v.hmg.ps1 as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302} powershell.exe (PID = 5140) identified C:\Users\shs\AppData\Local\Temp\xhltufae.z1d.psm1 as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}

 

Но привычных сообщений в Application-логе о том, что SRP заблокировала запуск файла, при этом сделано не было. Стало понятно, что запуск этих файлов был пробным шаром, целью которого было обнаружение того факта, что система работает в режиме белого списка запускаемых программ. Если запуск этих файлов блокируется, то PowerShell считает, что система работает в режиме белого списка, и принимает решение о необходимости принудительного включения режима ограниченной функциональности (constrained language mode). Как же обойти эту проверку?

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

И так правила пути – это не наш метод. Может быть у этих файлов, которые PoweShell всякий раз создает для тестирования работы “под колпаком”, будет одинаковое содержимое, и тогда можно будет создать правило разрешающее запуск по хэшу? Решили проверить эту гипотезу. Для этого пришлось отнять право на удаление файлов  для всех пользователей в папке %temp%. В результате PowerShell при очередном запуске создал в ней файлы с расширением ps1 и psm1, но был лишен возможности их удалить после того, как использовал. Оказалось, что содержимое файлов ps1 и psm1, при помощи которых PowerShell выполняет проверку, всякий раз одно и то же (это файлы в кодировке ANSI, которые содержат единственный символ: ‘1’). А, значит, можно разрешить такие файлы по правилу хэша, что и было успешно проделано.

PS Вадимс подробно изложил свое видение ситуации с PowerShell v5, белым списком и constrained language mode у себя в бложике:

PowerShell 5.0 and Applocker. When security doesn’t mean security

PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

Обязательно почитайте!

PPS Чуть не забыл обратить ваше внимание на важное замечание: в PowerShell v 5.0 constrained language mode стал единственной защитным механизмом, которым разработчики пытаются защитить систему от использования PowerShell в зловредных целях. К сожалению и моему полному изумлению, ни SRP, ни bitlocker теперь не блокируют выполнение скриптов PowerShell (от слова совсем). Т.е. протестировав, наложена ли блокировка на запуск исполняемых файлов по белому списку при своем запуске, PowerShell в дальнейшем полностью игнорирует отсутствие разрешений (или явный запрет) на запуск сценариев. Вместо того, чтобы запретить запуск файла сценария, PowerShell запускает его в constrained language mode! В результате отключения constrained language mode, мы, как я и говорил выше, отстреливаем себе ноги, снимая единственное ограничение накладываемое на файлы сценариев PowerShell.

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.