赛门铁克(symantec)曝出任意代码执行漏洞，可冒用签名执行，白名单绕过以及提权

　　【小编提醒】本文部分内容来源网络，仅供参考！如需了解“赛门铁克(symantec)曝出任意代码执行漏洞，可冒用签名执行，白名单绕过以及提权”等有关服务器、云主机租用、托管、配置、价格问题，请在线咨询YINGSOO客服，享受1v1贴心服务！

　　【境外主机】加拿大云服务器特价 | 泰国云服务器特价 | 香港物理服务器特价

　　【优质文章】德国服务器好用吗？德国服务器否适合部署欧洲网游

　　赛门铁克(symantec)集团是世界上最大的安全公司，不过近日曝出任意代码执行漏洞，可冒用签名执行，白名单绕过以及提权。

　　#介绍

　　safebreach 实验室发现了赛门铁克终端安全这个漏洞（symantec endpoint protection）（cVe-2019-12758）

　　利用这个漏洞，可以绕过赛门铁克的自我防护机制，还能实现防御规避、维持权限以及提权。方法是通过加载任意未签名的dll到赛门铁克签名运行的进程里面（这个进程是以nt AUtHoRitY\sYstem权限运行）。

　　注：为了利用这个漏洞，攻击者需要有管理员权限。

　　#赛门铁克终端安全（symantec endpoint protection）

　　赛门铁克终端安全是指一组安全软件套件，包括服务器版本以及桌面电脑版本，组成功能模块部分包括反病毒、入侵防护以及防火墙。由赛门铁克公司开发并在终端安全市场中拥有最大的市场份额。

　　这个软件中的很多部分都是以windows服务的形式运行，这些服务以"nt AUtHoRitY\sYstem"权限运行，这给程序提供了非常强力的权限支持。

　　在这篇文章，我们先描述上述的漏洞，然后展示如何利用这个漏洞在赛门铁克服务上下文里，达成执行任意命令的效果，以获得“nt AUtHoRitY\sYstem”最高级别权限的访问权。

　　#漏洞

　　发现

　　在探索中，我们发现赛门铁克终端安全的一个服务（sepmasterservice），是以“nt AUtHoRitY\sYstem”权限启动一个单独的进程，这个进程会尝试加载一个不存在的dll，这个dll的位于：

　　c:\windows\syswow64\wbem\dspARse.dll

　　如果能证明可以让我们的东西被加载进这个进程，我们就可以绕过赛门铁克反病毒程序的自我防护机制。主要是因为赛门铁克终端安全程序所在的目录受mini-filter文件系统驱动程序保护，会严格限制对其写操作，即便是管理员也不例外。

　　这就意味着，即便我们是Administrator，想要简单地植入一个不存在的dll到赛门铁克的进程里面，也是不现实的。

　　poc展示

　　为了测试这个漏洞，我们从dsparse.dll 里编译出一个32位的代理dLL（未签名的，代理dLL的意思是可以加载其它任意dLL）文件，dsparse.dll 实质上是位于syswow64 目录，而不是 syswow64\wbem目录下面。编译出的dll，它功能是把下面的东西写到一个txt文件里面：

　　1.加载这个dll的进程名

　　2.执行这个dll的用户名

　　3.dll的文件名

　　然后我们把这个dll移植到 c:\windows\syswow64\wbem目录，然后重启电脑。

　　此时，我们可以加载进一个任意的代理dLL（代理dLL可以加载其它任意dLL）进来了，然后在一个服务进程里面执行我们的代码，这个服务进程是赛门铁克集团签名的，而且运行权限是nt AUtHoRitY\sYstem，最终的结果是，绕过了赛门铁克的自我保护机制。

　　#根本原因分析

　　有很多模块里的很多文件导致了这个漏洞，在这里就只分析其中的一个，因为问题的根源往往都是雷同的。

　　当 “symantec endpoint protection” 服务器进程(ccsvcHst.exe) 启动的时候，它就会尝试用 iwbemservices com接口的一个函数去执行一个wmi查询。这个com接口名为：

　　(iwbemservices::execnotificationQueryAsync):

　　用oleViewdotnet（https://github.com/tyranid/oleviewdotnet）快速查看一下，可以看到，这个com接口（和它的函数）是被设计用来使用这个com代理dLL中的库“c:\windows\syswow64\wbem\fastprox.dll” （在我们的例子里，它是一个wow64进程）

　　当fastprox.dll库里的execnotificationQueryAsync函数被调用之后，dscrackspnw 函数也会随之被调用。

　　我们可以看到，这个函数正是可以从dsparse.dll导入的，这会导致赛门铁克的那个服务进程尝试加载这个dll。

　　关于这个漏洞，有两个根本原因

　　1.没有针对二进制文件检查其数字签名。这个程序没有验证加载的dLL是否已经签名（这个功能可以用 winVerifytrust函数实现）。因为，它可以加载任意的未签名的dLL。

　　2.fastprox.dll 库尝试从它当前的运行美国服务器目录加载dsparse.dll文件，这就是c:\windows\syswow64\wbem目录，而实质上文件就是存在syswow64 目录。