视频会议系统Polycom HDX远程命令执行漏洞分析

本文由 安全客 翻译，转载请注明“转自安全客”，并附上链接。 原文链接：http://staaldraad.github.io/2017/11/12/polycom-hdx-rce/

一、前言

对目标执行外围评估时，你需要花适量的时间，收集目标指纹信息，找到可能存在的攻击路径。如果目标是一个大型企业，你很有可能会找到视频会议端点。本文详细介绍了Polycom HDX系列视频会议系统中存在的一个漏洞。

我在任职于SensePost时发现了这个漏洞，并将其报告给Polycom。Polycom确认了这个漏洞，并通知我们会发布一个补丁来修复这个漏洞。这件事情距今已过去一年多时间，但我还没有看到官方公布安全公告或者漏洞补丁。从这个漏洞被披露起，官方已经修复了HDX系列中存在的一个XSS漏洞，因此可能他们认为这个漏洞的影响没那么大。

二、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可以自动提取出其中的所有组件。

命令如下：

接下来的工作就是深入分析提取出的所有二进制文件，找到那些文件比较重要、与polycom command shell（PSH）有关。在快速查阅Polycom技术文档的同时，我也参考了PSH中help命令提供的信息，综合这些信息，我明确了哪些文件是我们的寻找目标。

我解压了polycom_swupdate目录中所有的.tar.gz文件，然后执行grep命令来搜索包含某个已知命令的文件。

新的目标是avc程序。分析二进制文件最为偷懒的一种方法就是使用strings命令，这也是我所使用的方法。

这条命令的输出结果可以翻页，便于搜索，根据这些结果，我可以窥探二进制文件及其中可能包含的命令。根据grep的搜索结果，这个文件中包含dialchannels命令，这个信息表明其他命令也有可能会以字符串形式硬编码到该文件中。我们需要遍历所有的字符串，这是一个艰辛的过程，不过幸好我们可以走条捷径。这个程序使用c/c++编写，并且代码中到处可见格式化字符串（%s）的身影。我只需要寻找使用格式化字符串（%s）并将字符串传递给已知Linux系统命令的那些命令即可。

其中最有希望的是traceroute命令。原因有两方面，首先，该命令似乎会直接调用Linux命令，并且使用格式化字符串来传递参数；其次，之前曝光的命令注入漏洞存在于ping命令中（这是我们最喜欢的操作系统命令注入点）。此时貌似我们已经可以完成任务，只需要调用traceroute 'sleep 10'命令应该就能得到命令执行效果。但事实证明并非如此。调用traceroute命令后会不断返回错误信息，提示该命令并不存在。看起来我们并不能直接调用traceroute，因此我需要寻找调用traceroute命令的正确方式。为此，我又回到前面的字符串列表中，查找其中是否包含traceroute。

根据搜索结果，我们知道traceroute是lan命令的部分选项，因此我可以尝试注入这条命令。再次回到Polycom Command Shell，经过尝试后，shell提示我们lan命令中并不包含traceroute选项。

但我认为选项中肯定包含traceroute，因为我已经在二进制文件中找到过这条命令的身影。经过艰难的搜索，我在分析bin/psh文件时发现其中包含一条未公开命令。这条命令就是devcmds，看起来非常美好。运行这条命令后，我们就能看到一条非常有趣的欢迎信息。

四、Devcmds模式

一旦进入这个模式，我发现前面可用的某些原始命令不会再起作用，貌似devcmds会激活一个新的代码分支。在这个模式下，再次尝试lan命令，突然间我们就可以使用traceroute了。我们可以使用lan traceroute 127.0.0.1来验证这条命令是否能正常工作。

接下来就是尝试其他命令注入场景。

然而这条命令无法成功执行，结果提示我们输入了无效的参数。

查看输出结果后，我们可以发现echo之后的所有数据会直接被丢弃掉。这是因为其中包含空格符，程序会将空格符解释为一个单独的参数（程序很可能会使用空格符来拆分输入参数）。

${IFS}

幸运的是，Bash/Sh中包含一个非常棒的环境变量，即$IFS（Internal Field Separator，内部字段分隔符）。我可以使用这个环境变量来替代空格符，只需要将命令注入场景中的所有空格符替换为${IFS}即可。

五、利用方法

如果这的确是RCE漏洞，为何我们不获取一个可用的shell？的确应该这么做。继续测试命令注入场景，我们又发现了一些限制条件。貌似程序会过滤掉分号（;），我们并不知道为什么会出现这种情况，可能是之前部分修复ping注入漏洞时的历史遗留问题。另一个问题是，在底层Polycom设备上，我只能使用数量有限的预置程序。也就是说，我无法使用nc命令，也无法使用反弹式bash shell。

幸运的是，我们还可以使用curl，这意味着我们可以把自定义二进制程序下载到设备中，然后再使用这些程序。我们希望能获得netcat反弹式shell，所以我们需要找到能在Polycom设备上运行的nc程序。Polycom运行在powerpc上，也就是说我们需要找到兼容的nc程序，而不能直接把本地系统的nc程序上传到设备上。这并不是一个真正的难题，很容易解决。只需要启动基于powerpc的Debian镜像，就能找到能够适配powerpc的nc程序，并且该程序也包含-e选项。

我们可以使用qemu来运行Debian镜像：

使用root:root凭证登录，然后拷贝/bin/nc.traditional二进制文件即可。

在本地运行如下命令：

在qemu中运行如下命令：

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

获取Shell

我把powerpc版的nc上传到了web服务器上，以便下载到Polycom设备上。然后，运行监听端，接受目标返回的反弹连接。

使用如下命令运行监听端：

我们可以使用如下命令来下载nc，设置可执行权限，然后创建反弹式shell。将这些命令保存为web服务器上的一个载荷文件。

然后，通过命令注入漏洞执行如下命令：

六、总结

现在，我们已经完全掌握底层设备的root访问权限，可以访问内部主机。理想情况下，会议系统会被放置在独立的子网中，并不能访问内部网络。然而，我们知道实际环境中经常可以看到扁平式网络结构以及缺乏隔离机制的网络环境，此时我们就能以此为突破口访问内部网络。