import sys
import ctypes
import windows.rpc
import windows.generated_def as gdef
from windows.rpc import ndr

StorSvc_UUID =  r"BE7F785E-0E3A-4AB7-91DE-7E46E443BE29"
		
class SvcSetStorageSettingsParameters(ndr.NdrParameters):
	MEMBERS = [ndr.NdrShort, ndr.NdrLong, ndr.NdrShort, ndr.NdrLong]
									
def SvcSetStorageSettings():
	print "[+] Connecting...."
	client = windows.rpc.find_alpc_endpoint_and_connect(StorSvc_UUID, (0,0))
	print "[+] Binding...."
	iid = client.bind(StorSvc_UUID, (0,0))
	params = SvcSetStorageSettingsParameters.pack([0, 1, 2, 0x77])
	print "[+] Calling SvcSetStorageSettings"
	result = client.call(iid, 0xb, params)
	if len(str(result)) > 0:
		print "   [*] Call executed successfully!"
		stream = ndr.NdrStream(result)
		res = ndr.NdrLong.unpack(stream)
		if res == 0:
			print "   [*] Success"
		else:
			print "   [*] Failed"
		
if __name__ == "__main__":
	SvcSetStorageSettings()

代码列表1: 使用PythonForWindows的RPC客户端SvcSetStorageSettings

RPC_STATUS CreateBindingHandle(RPC_BINDING_HANDLE *binding_handle)
{
    RPC_STATUS status;
    RPC_BINDING_HANDLE v5;
    RPC_SECURITY_QOS SecurityQOS = {};
    RPC_WSTR StringBinding = nullptr;
    RPC_BINDING_HANDLE Binding;

    StringBinding = 0;
    Binding = 0;
    status = RpcStringBindingComposeW(L"BE7F785E-0E3A-4AB7-91DE-7E46E443BE29", L"ncalrpc", nullptr, nullptr, nullptr, &StringBinding);
    if (status == RPC_S_OK)
    {
        status = RpcBindingFromStringBindingW(StringBinding, &Binding);
        RpcStringFreeW(&StringBinding);
        if (!status)
        {
            SecurityQOS.Version = 1;
            SecurityQOS.ImpersonationType = RPC_C_IMP_LEVEL_IMPERSONATE;
            SecurityQOS.Capabilities = RPC_C_QOS_CAPABILITIES_DEFAULT;
            SecurityQOS.IdentityTracking = RPC_C_QOS_IDENTITY_STATIC;

            status = RpcBindingSetAuthInfoExW(Binding, 0, 6u, 0xAu, 0, 0, (RPC_SECURITY_QOS*)&SecurityQOS);
            if (!status)
            {
                v5 = Binding;
                Binding = 0;
                *binding_handle = v5;
            }
        }
    }

    if (Binding)
        RpcBindingFree(&Binding);
    return status;
}

VOID RpcSetStorageSettings()
{
    RPC_BINDING_HANDLE handle;
    RPC_STATUS status = CreateBindingHandle(&handle);

    if (status != RPC_S_OK)
    {
        _tprintf(TEXT("[-] Error creating handle %d\n"), status);
        return;
    }

    RpcTryExcept
    {
	if (!SUCCEEDED(SvcSetStorageSettings(0, 1, 2, 0x77))
{
           _tprintf(TEXT("[-] Error calling RPC API\n"));
           return;
        }

    }
    RpcExcept(1)
    {
        
        RpcStringFree(&instanceid);

    }
    RpcEndExcept
}

代码列表2: 使用C++的RPC客户端SvcSetStorageSettings

        RPC客户端成功执行相应的RPC API后，我们使用Process Monitor监控它们行为。Process Monitor对动态分析很有帮助，它提供了基于事件的API运行时信息。需要提一下，Process Monitor有一个很少被人知道的功能，调用栈信息，如图2所示，使用它可以追踪事件的API调用信息。

图2：Process Monitor 的API 调用栈

        例如，在使用类似IDA的反汇编工具进行静态分析时，可以使用这里的地址和路径信息来精确定位对应的模块和函数。这样进行研究很有用，因为有时只使用Process Monitor的输出信息无法确定潜在的符号链接攻击模式。这是基于反汇编的静态分析能帮助我们发现条件竞争问题的原因，在本文第二部分会讨论这个问题。

微软Universal Telemetry Client（UTC）学习

        你听说过微软在Windows10中搜集客户信息、数据和文件访问详细信息么？你有考虑过这是如何实现的么？如果你感兴趣，可以读读这篇关于UTC背后机制的文章。

        开始下一阶段的分析前，我们先从RpcView GUI将所有RPC接口导出到一个文本文件。这个文件中包含所有可以从RPC服务器调用的RPC API。在输出的文件中，我们寻找可以接受宽字符作为输入的API，最终我们在diagtrack.dll中遇到了一个有趣的RPC接口。随后我们从RpcView GUI显示的描述信息中确定了，这个DLL组件负责实现UTC功能，特别是从名称Microsoft Windows Diagnostic Tracking中判断。

图3：RpcView揭示了UTC的DLL组件，并且其中的一个RPC接口接受宽字符作为输入

struct _RPC_SERVER_INTERFACE
{
    unsigned int Length;
    RPC_SYNTAX_IDENTIFIER InterfaceId;
    RPC_SYNTAX_IDENTIFIER TransferSyntax;
    PRPC_DISPATCH_TABLE DispatchTable;
    unsigned int RpcProtseqEndpointCount;
    PRPC_PROTSEQ_ENDPOINT RpcProtseqEndpoint;
    void *DefaultManagerEpv;
    const void *InterpreterInfo;
    unsigned int Flags;
};

PS C:\Users\researcher> Get-AppxPackage | Select-String -pattern "Feedback"
Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe
PS C:\Users\researcher> cd "c:\Program Files\Windows Kits\10\Debuggers\x86"
PS C:\Program Files\Windows Kits\10\Debuggers\x86>
PS C:\Program Files\Windows Kits\10\Debuggers\x86> .\plmdebug.exe /query 
Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe
Package full name is Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe.
Package state: Unknown
SUCCEEDED
PS C:\Program Files\Windows Kits\10\Debuggers\x86>

        获得完整包名后，我们再次使用PLMDebug开启Feedback Hub的UWP调试：

c:\Program Files\Windows Kits\10\Debuggers\x86>plmdebug.exe /enabledebug Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe "c:\program files\windows kits\10\Debuggers\x86\windbg.exe"
Package full name is Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe.
Enable debug mode
SUCCEEDED

HKEY_LOCAL_MACHINE\Software\Microsoft\Diagnostics\DiagTaskTestHooks\Volatile
“NoForceCopyOutputDirAcl” = 1

        梳理一下，如果注册表键不存在，diagtracktempdir将被强制执行一个固定的安全描述符，否则将对目录使用默认的DACL并引起潜在的安全问题，并且创建目录时没有使用模拟令牌。也就是，如果你有一个任意注册表写脆弱性，你就可以跳过对该目录设置固定安全描述符。但这不是我们期望的，所以只好再看看Process Monitor：

图7：设置DACL并重命名diagtracktempdir目录

bQueryTokenSuccessful = UMgrQueryUserToken(hContext, v81, &hToken);
if ( hToken && hToken != -1 )
{
//这里将给当前登录用户授权对指定句柄所代表目录的访问
bResultCopyDir = Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile(&hToken, hDir, Sid, GRANT_ACCESS)
	if ( !ImpersonateLoggedOnUser(hToken) ) 
	{
		bResultCopyDir = 0x80070542;
	}
}
//重命名diagtracktempdir到GUID格式的文件名
bResultCopyDir = Microsoft::Diagnostics::Utils::FileSystem::MoveFileByHandle(SecurityDescriptor, v65, Length);
if ( bResultCopyDir >= 0 )
{
boolRenamedSuccessful = 1;
//这里撤销当前登录用户授权对指定句柄所代表目录的访问
bSetAclSucessful = Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile(&hToken, hDir, Sid, REVOKE_ACCESS)	if (bSetAclSucessful)
{
    //清理并恢复原样
	return;
}
}
else
{
lambda_efc665df8d0c0615e3786b44aaeabc48_::operator_RevertToSelf(&hTokenUser);
//删除diagtracktempdir目录和内容
lambda_8963aeee26028500c2a1af61363095b9_::operator_RecursiveDelete(&v83);
}

代码列表3：授权然后收回对diagtracktempdir的访问权限

        从代码列表3中，我们能够知道什么情况下文件重命名操作会失败。如果bResultCopyDir小于0，将调用函数RecursiveDelete。还需要注意代码在调用RecursiveDelete之前调用RevertToSelf函数来停止令牌模拟，这意味着参数指定的目标目录和内容将被本地system权限删除，如果我们使用符号链接重定向diagtracktempdir到任意目录将能够进行任意文件删除。幸运的是，微软已经修复了这个潜在的重解析点删除问题。RecursiveDelete函数现在已经修复为明确跳过有FILE_ATTRIBUTE_REPARSE_POINT标志的目录或文件，这个标志是专门为连接点目录设置的。所以我们可以确认这个递归删除过程没有任何安全风险。

        由于我们无法在这里进行任意文件删除，我们决定展示如何写任意文件到diagtracktempdir目录。通过看代码，我们发现在递归删除过程完成后，UTC服务没有收回当前登录用户对diagtracktempdir的安全描述符。这是故意的，因为你不需要为一个将被删除的目录设置一个新的DACL，这是愚蠢的工作。但这也为攻击者留下了一个竞争条件机会，可以通过创建一个在同一目录的文件并占有句柄来阻止删除特权目录diagtracktempdir。RecursiveDelete函数在尝试打开和删除被占有句柄的文件时将遇到共享冲突并退出操作。最终，攻击者能够通过获得权限的diagtracktetempdir目录实现在一个权限受限目录释放并执行文件，如C:\WINDOWS\System32。

        那么下一个问题是，我们如何使得文件重命名操作失败？看看Microsoft::Diagnostics::Utils::FileSystem::MoveFileByHandle的内部实现，它基本就是对SetFileInformationByHandle的封装。这表示这个API调用的底层内核函数将以写权限持有父目录的文件句柄。例如，如果当前句柄引用到目录c:\blah\abc，那么将尝试以写权限获取c:\blah的文件句柄。然而，如果我们指定一个当前登录用户没有写权限的目录，Microsoft::Diagnostics::Utils::FileSystem::MoveFileByHandle将失败。下面的路径是很好地选择，他们是众所周知的特权目录，不准许普通用户创建目录：

• C:\WINDOWS\System32

• C:\WINDOWS\tasks

        当一些特权请求涉及写一些日志文件到我们控制的diagtracktempdir并且删除这些日志文件需要耗费一些时间时，赢得条件竞争的胜利应该没有问题。所以，只要我们成功创建一个目标目录内的句柄被占有的文件，就能够在现代系统和多核处理器下赢得竞争。

        接下来，我们需要找到方法通过编程使用UtcApi需要的正确参数来触发代码路径。由于能够调试并在RPC函数设置断点，Feedback Hub里的NdrClientCall使得工作变得简单了。调试器揭露了我们需要发送给UtcApi的scenario ID和提权路径。这种情况下，我们使用scenario ID {1881A45E-01FD-4452-ACE4-4A23666E66E3}，它在任何UtcApi_EscalateScenarioAsync函数被触发的时候都出现，并且它导致了RPC服务中我们期望的代码路径。注意，可以通过特权路径参数控制在哪里创建diagtracktempdir。

Breakpoint 0 hit
eax=0c2fe7b8 ebx=032ae620 ecx=0e8be030 edx=00000277 esi=0c2fe780 edi=0c2fe744
eip=66887154 esp=0c2fe728 ebp=0c2fe768 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
Helper+0x37154:
66887154 ff15a8f08866    call    dword ptr [Helper!DllGetActivationFactory+0x6d31 (6688f0a8)] ds:0023:6688f0a8={RPCRT4!NdrClientCall4 (76a74940)}
0:027> dds esp l9
0c2fe728  66892398 Helper!DllGetActivationFactory+0xa021
0c2fe72c  66891dca Helper!DllGetActivationFactory+0x9a53
0c2fe730  0e8be030
0c2fe734  1881a45e // Scenario ID
0c2fe738  445201fd
0c2fe73c  234ae4ac
0c2fe740  e3666e66
0c2fe744  00000000
0c2fe748  032ae620 // Escalation path
0:027> du 032ae620
032ae620  "E:\researcher\Documents\Feedback"
032ae660  "Hub\{e04b7a09-02bd-42e8-a5a8-666"
032ae6a0  "b5102f5de}\{e04b7a09-02bd-42e8-a"
032ae6e0  "5a8-666b5102f5de}"

long  UtcApi_EscalateScenarioAsync (
		[in] GUID SecnarioID, 
		[in] int16 unknown, 
		[in] wchar_t* wszEscalationPath
		[in] long unknown2, 
		[in] long unknown3, 
		[in] long num_of_keyval_pairs, 
		[in] wchar_t **keys, 
		[in] wchar_t **values) 

         POC的运行结果说明能够利用UTC服务在特权目录创建任意文件和目录到固定目录。

图8：POC准许在diagtracktempdir内创建任意文件

         重申一下，如MSRC所说，在不能同时控制或重命名diagtracktempdir目录时POC不会对Windows操作系统造成安全风险。然而，恶意软件作者通常利用不同的技术如UAC绕过来在系统目录下写文件来绕过启发式检测。事实上，当探索POC中使用的文件路径的其它选择，我们发现普通用户账户对C:\WINDOWS\SYSTEM32\Tasks有写和执行权限。但没有读权限---所以这个目录有常被恶意软件作者用来存储恶意文件的恶名。