如何挖掘RPC漏洞(Part 1)

在这个限定前提下,我们选择将已有的DecompileAllInterfaces函数集成到RpcView GUI中

一、媒介

2018年8月下旬,一名钻研职员(SandboxEscaper)公开了一个Windows本地权限提升0day破绽在互联网上公开后不到两周光阴内,该破绽就已经被恶意软件进击者所应用(参考ESET颁发的文章)这件工作在InfoSec社区造成了必然程度的纷乱,也引起了FortiGuard实验室的警醒

FortiGuard实验室觉得,理解这类进击道理异常紧张,可以赞助其他钻研职员掘客出类似SandboxEscaper在Windows义务计划法度榜样(Windows Task Scheduler)中找到的破绽在本文中,我们将与大年夜家分享若何滥用RPC办事器上的符号链接来提升权限

事实证实,Windows Task Scheduler经由过程RPC办事器对外公开的某个RPC(Remote Procedure Call,远程历程调用) API中存在破绽在Windows中,大年夜多半RPC办事器都托管于以本地系统权限运行的系统进程中,低权限的RPC客户端可以与RPC办事器进行交互与其他软件一样,这些RPC办事器也可能存在破绽,如回绝办事、内存毁坏、逻辑差错等等换句话说,进击者可以使用RPC办事器中存在的任何破绽来提议进击

这个0day破绽之以是如斯盛行,此中一个缘故原由在于底层破绽使用起来异常简单这是一个法度榜样逻辑差讹夺洞,只要应用精确的对象及技巧就对照轻易发明进击者平日应用捏造的符号链接(symbolic link)来使用这类权限提升破绽,越权至某些文件或者目录,从而能让通俗用户提升权限假如大年夜家对这方面内容对照感兴趣,来自Google Project Zero的James Forshaw分享了关于符号链接进击的各类资本,大年夜家可以作为参考

二、RPC办事器运行时及静态阐发

进入新的钻研领域后,在自己开拓对象之前,最好先看一下网上是否已经有开源对象幸运的是,微软RPC协议异常出名,在以前十几年里已经有钻研职员在这方面做了许多优秀的逆向阐发事情钻研职员可以应用RpcView这款开源对象,这个对象异常方便,可以识别Windows系统上运行的RPC办事这是我最爱好的RPC对象之一,具有各类强大年夜的功能,如搜索RPC接口的UUID(Universal Unique Identifier)、RPC接口名等等

然而,我们的目的是将所有RPC信息反编译并导出到文本文件中,该对象并不满意我们的要求幸运的是,在涉猎源码后,我们发明对象开拓者已经集成了我们所需的功能,但默认环境下该功能没有启用,只能在调试模式下应用某个敕令行参数触发假如大年夜家也想应用这个功能,可以造访我们的Github页面,下载我们定制的RpcView对象鄙人文中大年夜家就可以看到“反编译所有接口”这个功能的好处

图1. RpcView反编译所有接口

当阐发RPC办事器的行径时,我们老是会经由过程RPC接口调用办事器对外供给的API我们可以经由过程RPC客户端向办事器发送RPC哀求,与RPC交互,然后应用SysInternals中的Process Monitor对象来察看办事器的行径在我看来,最方便的做法是编写脚本,而不是开拓C/C++ RPC客户端,由于前者不必要代码编译历程,对照节省光阴

我们选择应用PythonForWindows这个库这个库能够赞助我们以Python的要领来抽象处置惩罚Windows功能,但必要依附Python的ctypes库这个库中还包孕一些RPC库,这些库供给了一些方便的封装函数,可以节省我们开拓RPC客户真个光阴比如,范例的RPC客户端法度榜样必要定义接口定义说话,并且我们必要手动实现绑定操作,这个历程平日必要涉及到一些C++代码从下面两段代码中,我们可以清晰地看到在实现RPC客户端方面脚本说话和编程说话之间的差别:

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 Client开拓的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);

[1] [2] [3] [4] [5]下一页

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 %dn”), status);

return;

}

RpcTryExcept

{

if (!SUCCEEDED(SvcSetStorageSettings(0, 1, 2, 0x77))

{

_tprintf(TEXT(“[-] Error calling RPC APIn”));

return;

}

}

RpcExcept(1)

{

RpcStringFree(&instanceid);

}

RpcEndExcept

}

代码2. 应用C++ RPC Client开拓的SvcSetStorageSettings

当RPC客户端成功调用响应的RPC API后,我们可以应用Process Monitor来监控法度榜样活动轨迹Process Monitor对动态阐发来说异常有用,可以供给基于事故的API运行时信息值得留意的是,Process Monitor中有个较少应用的功能,可以供给调用栈(call-stack)信息,如图2所示使用这个信息,我们可以跟踪某个事故的API调用历程

图2. Process Monitor API调用栈功能

在应用IDA Pro之类的对象静态阐发时,我们可以根据上图中Address和Path信息正确定位响应的模块及函数例程这一点异常有用,由于有些时刻我们可能无法零丁应用Process Monitor输出信息来发明潜在的符号链接进击特性这时刻反汇编对象的静态阐发功能就能派上用处,可以赞助我们发明竞争前提问题,我们会在Part 2文章中评论争论这方面内容

三、UTC案例阐发

大年夜家是否知道微软会在Windows 10及更高版本系统上网络客户信息、数据以及文件相关信息?有没有想过背后的事情道理?假如大年夜家感兴趣,可以涉猎这篇文章,此中先容了UTC(Universal Telemetry Client,通用遥测客户端)背后的事情机制

为了开启下一阶段阐发历程,我们首先应用RpcView GUI将所有RPC接口导出到文本文件中,结果文件中包孕RPC办事器中可以调用的所有RPC API从输出文件中,我们必要查找可以吸收宽字符串作为输入的RPC API,终极从diagtrack.dll中找到了对照有趣的一个RPC接口随后,我们可以确认这个DLL组件认真UTC功能的的详细实现,比如,我们可以在RpcView GUI中发明这个DLL的描述为Microsoft Windows Diagnostic Tracking

图3. 应用RpcView阐发UTC相关DLL组件,此中某个RPC接口吸收宽字符串作为输入数据

请记着,这里我们的目标是找到某个API,这个API可以接管文件路径作为输入参数,终极可能导致权限提升问题(如Windows Task Scheduler中存在的问题)但在图3中,我们发明有16个API可能满意我们的要求显然,我们必要过滤掉落不相符我们前提的API是以我们应用IDA Pro,开始静态阐发,找到待深入阐发的目标API

我首先找到的是RpcServerRegisterIf这个RPC函数,这个函数平日用来注册RPC办事器上的接口规范(interface specification)接口规范中包孕托管于特定RPC办事器上的RPC接口定义根据MSDN官方文档的描述,接口规范位于函数的第一个参数中,该参数遵照RPC_SERVER_INTERFACE数据布局,布局定义如下:

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;

};

接口规范中的InterpreterInfo是指向MIDL_SERVER_INFO数据布局的一个指针,该布局由DispatchTable指针所组成,指针中保存特定RPC接口所支持的接口API信息这切实着实是我们在探求的字段

typedef struct _MIDL_SERVER_INFO_

{

PMIDL_STUB_DESC pStubDesc;

const SERVER_ROUTINE* DispatchTable;

PFORMAT_STRING ProcString;

const unsigned short* FmtStringOffset;

const STUB_THUNK* ThunkTable;

PRPC_SYNTAX_IDENTIFIER pTransferSyntax;

ULONG_PTR nCount;

PMIDL_SYNTAX_INFO pSyntaxInfo;

} MIDL_SERVER_INFO, *PMIDL_SERVER_INFO;

平日环境下,我们可以应用IDA Pro遍历导入地址表(IAT)来定位DispatchTable,如下图所示:

图4. 应用IDA Pro遍历IAT探求RPC公开的API

定位到UTC的接口API(前缀为UtcApi,如图4所示)后,我们考试测验判断这些接口API中是否涉及到ACL(Access Control List,造访节制列表)相关API,比如SetNamedSecurityInfo以及SetSecurityInfo等之以是对这些ACL API感兴趣,是由于变动工具(包括文件、目录以及注册表等)的DACL(discretionary access control,自立造访节制)安然描述符时会用到这些APIIDA Pro中还有另一个有用的功能,便是Proximity view,可以在一张图中显示出某个函数例程的调用图我们可以应用Proximity view来探求ACL API中引用或者调用的函数例程

图5. IDA的Proximity view可以显示SetSecurityInfo与diagtrack.dll中函数例程的关系

上一页[1] [2] [3] [4] [5]下一页

然而,当我们想去探求SetSecurityInfo与UtcApi之间的关系时,IDA Pro并没有给出任何结果进一步钻研后,我们发明UtcApi会将客户真个RPC哀求放入异步线程事情行列步队中进行处置惩罚如图5所示,当触发Microsoft::Diagnostic::EscalationWorkItem::Execute时,就会履行SetSecurityInfo这是一个回调函数,用来处置惩罚聚积在事情行列步队中、来自RPC客户真个哀求

此时,我们必要澄清若何提交哀求阐发各类利用后,我们找到了Microsoft Feedback Hub,这是一个UWP(Universal Windows Platform,通用Windows平台)利用法度榜样,已在Windows 10默认安装有些环境下,调试UWP利用能够给我供给很多信息不幸的是,我们无法应用WinDbg直接打开或者attach UWP利用然而,我们可以应用Windows 10 SDK中Windows Debugger包孕的PLMDebug对象来启用UWP利用调试功能首先我们可以经由过程Powershell内置cmdlet来确定Feedback Hub的完备包名:

PS C:Usersresearcher> Get-AppxPackage | Select-String -pattern “Feedback”

Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe

PS C:Usersresearcher> cd “c:Program FilesWindows Kits10Debuggersx86”

PS C:Program FilesWindows Kits10Debuggersx86>

PS C:Program FilesWindows Kits10Debuggersx86> .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 FilesWindows Kits10Debuggersx86>

获取完备包名后,我们可以再次应用PLMDebug,启用Feedback Hub的UWP调试功能:

c:Program FilesWindows Kits10Debuggersx86>plmdebug.exe /enabledebug Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe “c:program fileswindows kits10Debuggersx86windbg.exe”

Package full name is Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe.

Enable debug mode

SUCCEEDED

下次启动Feedback Hub时,利用就会自动attach到WinDbg

图6. 根据Process Monitor Event Properties窗口确定API调用的偏移地址

启动Feedback Hub后,我们可以遵照利用在屏幕上给出的提示进行操作,然后就能在Process Monitor中察看各类活动记录这是个好兆头,注解我们的偏向没有问题当我们阐发SetSecurityFile事故的调用栈时,我们发明SetSecurityInfo这个ACL API 的偏移地址为0x15A091(我们可以在Event Properties窗口的Process选项卡中找到diagtrack.dll的基址)这个偏移地址位于Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile例程中,如图6所示,我们也可以在图5的Proximity view中找到这个值这些信息注解我们可以使用Feedback Hub,终极获得我们想要的代码路径

除此之外,从Process Monitor输出信息中,我们还知道这个事故会考试测验设置文件工具的DACL,但假如想经由过程静态代码阐发来找出文件工具的获取要领可能是一件异常耗时的工作幸运的是,我们可以将本地调试器attach到svchost.exe法度榜样上,这是由于该进程不受PPL(Protected Process Light)机制的保护,并且托管了具备治理员权限的UTC办事这样我们就可以机动地动态调试UTC办事,理解文件路径的获取历程

将反馈信息经由过程Feedback Hub提交后,所有的反馈信息和相关附件都邑保存在临时目录中,款式为%DOCUMENTS%\FeedbackHub\\diagtracktempdir此中在diagtracktempdir后的十进制随机数应用BCryptGenRandom API天生,这意味着所天生的随机数基础上无法猜测然而符号链进击中异常紧张的一环便是要猜测文件或者目录的名称,是以随机天生的diagtracktempdir切实着实增添了符号链破绽使用的难度是以,我们必要深入其他例程,探求其他潜在的破绽

当我们考试测验理解若何设置diagtracktempdir安然描述符时,我们发明目标会应用显式安然描述符字符串(即O:BAD:P(A;OICI;GA;;;BA)(A;OICI;GA;;;SY))来创建目录,这意味着工具的DACL只会绑定到Administrator以及本地系统用户然而,假如设置了如下注册表键值,系统就会轻忽显式安然描述符:

HKEY_LOCAL_MACHINE\Software\Microsoft\Diagnostics\DiagTaskTestHooks\Volatile

“NoForceCopyOutputDirAcl” = 1

简而言之,假如不存在如上表项,那么diagtracktempdir就会强制应用显式安然描述符,否则就会在目录上利用默认的DACL这可能会激发一些安然问题,由于文件创建历程中不会应用任何模拟(impersonation)令牌无论若何,假如我们具备注册表随意率性写入破绽,就可以绕过该目录中显式安然描述符的限定但这并不是我们想要的结果,是以我们最好照样回到Process Monitor:

图7. 设置DACL,重命名diagtracktempdir目录

我们可以将图7的操作历程总结如下:

1、以本地系统权限赋予当前登任命户对diagtracktempdir的造访权限;

2、经由过程模拟要领重命名diagtracktempdir目录;

3、经由过程模拟要领撤销当前登任命户对diagtracktempdir的造访权限

图7的操作历程可以经由过程如下代码段来表示:

bQueryTokenSuccessful = UMgrQueryUserToken(hContext, v81, &hToken);

if ( hToken && hToken != -1 )

{

// This will GRANT access of the current logged in user to the directory in the specified handle

bResultCopyDir = Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile(&hToken, hDir, Sid, GRANT_ACCESS)

if ( !ImpersonateLoggedOnUser(hToken) )

上一页[1] [2] [3] [4] [5]下一页

{

bResultCopyDir = 0x80070542;

}

}

// Rename diagtracktempdir to GUID-styled folder name

bResultCopyDir = Microsoft::Diagnostics::Utils::FileSystem::MoveFileByHandle(SecurityDescriptor, v65, Length);

if ( bResultCopyDir >= 0 )

{

boolRenamedSuccessful = 1;

// This will REVOKE access of the current logged in user to the directory in the specified handle

bSetAclSucessful = Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile(&hToken, hDir, Sid, REVOKE_ACCESS)if (bSetAclSucessful)

{

// Cleanup and RevertToSelf

return;

}

}

else

{

lambda_efc665df8d0c0615e3786b44aaeabc48_::operator_RevertToSelf(&hTokenUser);

// Delete diagtracktempdir folder and its contents

lambda_8963aeee26028500c2a1af61363095b9_::operator_RecursiveDelete(&v83);

}

代码3:赋予并取消当前用户对diagtracktempdir的造访权限

从代码3中,我们可知文件重命名操作会在什么环境下掉败假如bResultCopyDir的值小于0,那么履行流程就会调用RecursiveDelete函数此外还必要留意的是,在调用RecursiveDelete函数之前,法度榜样会先调用RevertToSelf函数来竣事模拟,这意味着系统会应用本地系统权限来删除目标目录及目录内容是以,假如我们能应用符号链接来将diagtracktempdir重定向到一个随意率性目录,就可以实现随意率性文件删除目标幸运的是,微软已经打消了这个潜在的问题假如目录设置了FILE_ATTRIBUTE_REPARSE_POINT标志(junction目录平日会设置该标志),那么RecursiveDelete函数就会显式跳过这些目录是以我们可以确定,这个删除操作并不会带来任何安然风险

因为我们无法实现随意率性文件删除,我们抉择分享一下若何将随意率性文件写入diagtracktempdir目录中查看代码,我们发明在递归删除操作完成后,UTC办事并不会撤销当前用户对diagtracktempdir目录的安然描述符这是系统故意为之的行径,由于我们并不必要在一个即将被删除的目录上附加新的DACL,这是多余的操作然而这也为进击者供给了一个潜在的竞争前提时机,进击者可以在同一个目录中创建带有独有文件句柄的文件来避免系统删除diagtracktempdir目录当RecursiveDelete函数考试测验打开和删除带有独有文件句柄的文件时,就会碰着共享冲突,然后正常退出履行终极,进击者可以将文件开释到受限目录(如C:\WINDOWS\System32)的diagtracktetempdir目录中并加以履行

那么下一个问题便是,我们若何让文件重命名操作掉败?查看Microsoft::Diagnostics::Utils::FileSystem::MoveFileByHandle的底层实现后,我们可以看到这本色上是一个封装函数,用来调用SetFileInformationByHandle API我们发明派生自该API的底层内核函数彷佛总会获取到父目录的一个可写权限文件句柄比如,假如文件句柄当前指向的是c:\blah\abc,那么系统就会考试测验获取c:\blah目录具备可写权限的文件句柄然而,假如我们我们指定当前登任命户不具备写入权限的某个目录,那么Microsoft::Diagnostics::Utils::FileSystem::MoveFileByHandle就可能无法正常履行我们可以应用如下目录,由于这些目录不容许通俗用户账户履行目录创建操作

C:\WINDOWS\System32

C:\WINDOWS\tasks

因为哀求历程中必要将大年夜量log文件写入我们可控的diagtracktempdir目录中,这必要必然光阴来处置惩罚,是以我们应该有较大年夜的把握能够在竞争前提中得胜是以,假如我们在目标目录中创建了独有文件句柄,那么大年夜部分光阴内,在搭载多核处置惩罚器的操作系统上我们应该都能完成义务

接下来,我们必要找到法子,以编程要领应用UtcApi所需的精确参数来触发这条代码路径因为我们能够在RPC函数上调试并设置断点,Feedback Hub中的NdrClientCall函数可以让我们的事情加倍轻松从调试器中我们可以知道Scenario ID,也可以知道必要发送给UtcApi的文件路径在本例中,我们筹备应用的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}”

UtcApi_EscalateScenarioAsync的函数原型如下所示:

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代码操作历程可以分为如下几个步骤:

1、创建一个轮回线程,监视我们的目标目录(如C:\WINDOWS\SYSTEM32),以便及时捕捉到diagtracktempdir的目录名;

上一页[1] [2] [3] [4] [5]下一页

2、创建另一个轮回线程,该线程会创建C:\WINDOWS\SYSTEM32\diagtracktempdir{random_decimal}\z的一个独有句柄;

3、调用UtcApi_EscalateScenarioAsync(1881A45E-01FD-4452-ACE4-4A23666E66E3),触发Microsoft::Diagnostic::EscalationWorkItem::Execute;

4、随后,进击者可以向C:\WINDOWS\SYSTEM32\diagtracktempdir{random_decimal}目录中写入并履行随意率性文件,与此同时合法法度榜样会觉得%SYSTEM32%目录中只包孕合法的OS文件

我们的PoC演示了一种潜在使用措施,可以使用UTC办事在受限目录的静态目录中创建随意率性文件及目录

图8. 可以在diagtracktempdi目录中创建随意率性文件的PoC代码

重申一下,如MSRC所述,假如不能节制或者重命名diagtracktempdir目录,这个PoC并不会对Windows系统带来安然风险然而,恶意软件开拓者平日会应用各类不合的技巧(如UAC绕过技巧),将文件写入Windows系统目录中,以便绕过启迪式检测器实际上,在探索PoC中可以应用的潜在文件路径时,我们发明C:\WINDOWS\SYSTEM32\Tasks目录包孕通俗用户账户的写入和履行权限,但没有读取权限,这也是为什么该目录常常会被恶意软件开拓者用来存储恶意文件

四、总结

在本文中,我们与大年夜家分享了若何应用不合的对象和在线资本来探求Windows RPC办事器中的潜在安然风险我们同样演示了逆向阐发RPC办事器所需的一些根基常识我们信托RPC办事器中还有其他潜在的安然风险尚未发掘,是以,我们将进一步加强Windows RPC办事器的安然性鄙人一篇文章中,我们会继承查询造访改进我们的措施,继承发明其他RPC办事器破绽

上一页[1] [2] [3] [4] [5]

赞(0) 打赏
分享到: 更多 (0)
免责申明:本站所有资料均来自于网络,版权归原创者所有!本站不提供任何保证,不保证真实性,并不承担任何法律责任

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

阿里云优惠网 更专业 更优惠

阿里云优惠券阿里云大礼包