在過去一年中，Zoom的用戶量迅速增長，從2019年初的1000萬活躍用戶增長到2020年中期的2億多。

Zoom的流行使其成為黑客，攻擊者和安全社區的重要目標。本文的研究重點是識別Zoom中的安全漏洞。研究結果表明，一些嚴重的安全漏洞會影響Zoom的運行和開發基礎架構，Zoom Linux應用程序以及Zoom的端到端加密實現。

識別出的漏洞列表

(1) 暴露的公共Kerberos身份驗證服務器;

(2) Zoom Production Server上的內存泄漏;

(3) Zoom Production Server上無法利用的RCE;

(4) 可訪問的Zoom服務器上的Shadow IT問題;

(5) 針對Linux的Zoom App的漏洞：

• TLS / SSL的設計漏洞;
• 有關Zoom Launcher的設計漏洞;
• Zoom用戶之間的端到端加密消息以純文本格式存儲在磁盤上;
• 所有本地用戶均可訪問的Zoom Local Database，包括私有的端到端加密消息(以純文本存儲)和訪問令牌。

漏洞的尋找過程

我于2020年4月在Zoom上開始了第一輪測試，我的目標是找到一個影響Zoom結構和用戶的安全漏洞。功夫不負有心人，我確定了一個內存泄漏漏洞，該漏洞會影響屬于Zoom運行基礎結構的API。

確認存在此漏洞后，我會根據其安全頁面zoom.us/security將其直接報告給security@zoom.us。

接下來，我開始對Zoom進行進一步的安全性研究，并發現了影響其基礎架構，Zoom Linux應用及其端到端加密實施的新漏洞。

識別攻擊面

在目標上進行測試時，我的第一步是攻擊面識別。這是我進行偵察階段的步驟，以了解正在運行的系統，公開的API，(未維護的)服務以及從對手的角度來看可能有趣的所有內容。

在攻擊Zoom之前，我并不了解攻擊面。

域發現

對我來說幸運的是，我運行了FullHunt.io，這是一個漏洞情報平臺，可幫助攻擊面發現，監控和自動執行安全性。有一個內部FullHunt API，可以查詢組織擁有的域。我運行了一個查詢，該查詢返回了13個以上的域。

我將它們添加到我的FullHunt帳戶中，以自動化發現過程。雖然我收集了大量的數據，但我沒有時間去測試所有的東西。

暴露的公共Kerberos身份驗證服務器

在對不同目標進行端口掃描時，一種目標引起了我的注意。

(1) 目標：ca01.idm.meetzoom.us

我注意到正在運行的Kerberos服務可以從外部訪問，Kerberos是一種網絡身份驗證協議，旨在保護客戶端/服務器應用程序的身份驗證。

目標的命名約定表示該目標正在運行身份管理解決方案或PKI(公鑰基礎結構)，在檢查端口80上正在運行的內容時，我發現主機正在運行FreeIPA3，這是RedHat開發的開源身份管理解決方案。

另一個選擇是查看Zoom的Kerberos和FreeIPA設置的實現，我還發現另一項目標可以運行確切的設置。

(2) 目標：va01.idm.meetzoom.us

實際上，一旦我們擁有了經過身份驗證的帳戶，Kerberos就可以允許大規模的攻擊。雖然不在內部網絡內，但Kerberos的初始輸入更為困難。

HTTP接口在錯誤消息方面非常冗長，但是，這是FreeIPA中的默認響應。可以從[/ipa/session/login_password] API枚舉用戶，如下面的截圖所示。

無效賬戶如下所示：

有效賬戶如下所示： 

但是，HTTP API中有一個鎖定策略，用于鎖定超過無效身份驗證嘗試次數的帳戶。

觸發該政策后，一旦鎖定期超時，我便重新訪問了該目標。最好是從HTTP接口攻擊此功能，我直接將攻擊轉移到Kerberos服務中。

攻擊Kerberos

我嘗試枚舉使用UDP/88上運行的公共Kerberos服務的用戶，在UDP中進行身份驗證的優點之一是能夠處理具有不同源IP的數據包。這有助于在服務級別上避免IP黑名單，我不需要進入這一部分，因為在此服務的測試中沒有觸發任何安全控制，用戶枚舉和用戶密碼強行都沒有被阻止。

建立字詞表

根據我對Zoom的背景知識，我了解到Zoom上的電子郵件和帳戶配置文件模式如下：{firstName}。{lastName}@zoom.us。我們可以從Zoom.us/team頁面開始初始化命名：

我還使用OSINT列舉了電子郵件地址，這將用于枚舉可公開訪問的Kerberos服務上的有效用戶帳戶。

所有生成的名稱都不是Kerberos服務上的有效用戶，也許這兩個目標是Shadow IT目標，它們被Zoom錯誤地公開，用戶枚舉為我提供了一個有效用戶“admin”。

我還強制使用了帳戶密碼，因為沒有針對用戶帳戶的鎖定策略，這似乎是timespan(表示一個時間間隔)的死胡同。

在Zoom運營服務器上發現內存泄漏

Zoom允許在帳戶上上傳個人資料圖片，我一直對圖像解析器很感興趣，因為圖像解析器的攻擊面很寬，并且可以為不同的攻擊媒介打開大門。

• 用戶上傳個人資料圖片;
• 僅允許使用JPEG，GIF和PNG。
• 如果圖像是PNG或GIF，則將其轉換為JPEG。
• 如果圖像為JPEG，則不會觸發圖像轉換。
• 如果圖像包含無效的圖像標頭，則更新配置文件API會中止該過程。
• 檢查驗證的圖像是通過檢查魔術字節4完成的，這意味著我們無法控制文件的第一個字節。

所以我假設， Zoom將ImageMagick用作服務器端圖像轉換的后端。部署映像轉換微服務的常見模式是，一旦微服務達到穩定狀態，它們幾乎不會收到所需的更新和安全控制。發生這種情況的原因是，它對業務的重要性不如基礎架構中的其他功能強大。

ImageMagick的一個常見漏洞是CVE-2016–3714，這是一個遠程執行代碼漏洞。我使用CVE-2016–3714測試了該功能，似乎已對其進行了修補。

ImageMagick另一個較不受歡迎的漏洞是由于ImageMagick的GIF解析器上的存儲空間未初始化而導致的內存泄漏漏洞。因此，可以采用“Heartbleed”方法泄漏部分內存，該漏洞就是CVE-2017-15277。

原始有效載荷

Zoom API被攻擊的結果如下所示;

通過進一步確認，這不是Zoom上ImageMagick實現的攻擊漏洞，這是通過ImageMagick生成具有相同有效載荷規格的典型黑色圖像實現的：

$ convert -size 300x300 xc:black black.gif 

正常視圖如下所示：

如下所示，通過Zoom攻擊正常GIF圖像。

結果表明，當提供具有相同有效載荷規格的正常GIF圖像后，只要確認存在安全漏洞并發現ImageMagick設置上存在攻擊問題的部分位于Zoom時，此圖像就會被攻擊 。

自動化開發

要計劃在Zoom上自動利用內存泄漏，需要：

• 生成新的唯一有效載荷; 
• 將其上傳到Zoom;
• 下載攻擊的文件;
• 從Zoom攻擊的損壞文件中提取數據;
• 重復并存儲泄漏的內存部分。

概念驗證

視頻鏈接點這里。

繼續發現漏洞

在自動執行針對內存泄漏的利用的一周之后，我記得Tavis Ormandy研究了GhostScript引擎6。 GhostScript是PostScript語言的解釋器，還在ImageMagick中被使用。

Tavis的研究表明，可以在GhostScript上執行遠程命令。這項研究對于這項功能至關重要，因為如果我們能夠利用ImageMagick上的GhostScript，我們就可以實現遠程命令執行。

我確認此漏洞存在于2017年7月被修復了。在2018年8月，GhostScript和ImageMagick也修補了遠程命令執行漏洞。這意味著，如果Zoom運行中存在內存泄漏，那么GhostScript RCE也將出現在Zoom運行中。

基于Zoom的環境，我在自己的環境中復制了這個漏洞。

有效載荷的概念證明

 

 

 

RCE漏洞的本地復制

 

緩解措施

在Zoom API [/p/upload]中對上傳圖片的神奇字節進行檢查，否則，該漏洞可能會被充分利用。如果在其他地方調用了微服務，那么它仍然可以在那里被利用。

Shadow IT和Zoom

Shadow IT是Zoom的一種公共服務模式，某些實例不經常更新，可以公開訪問。云為用戶的每一種需求都提供了解決方案。員工可以利用云上的應用程序高效快速的完成自己的工作。Shadow IT就是這些被使用的應用程序沒有被批準或者IT管理員沒有意識到其正在使用。我發現一個開發實例至少有10個月沒有更新，盡管我不確定，但我認為它已被Zoom的用戶廣泛使用了。這意味著，如果在運行中修補了一個漏洞，則在這些Shadow IT實例上可能會利用該漏洞，我確認這一點的方式是因為Zoom在實例上留下了一個版本構建文件。

下圖是在2020年7月4日拍攝的，構建時間是在2019年9月10日。

ShadowIT目標上的Nginx狀態，由于開發實例中的后端配置錯誤，因此啟用了Nginx狀態頁面，這使我可以有把握地猜測該實例的使用率不高，并且與Zoom.us運行型Web應用程序相比，日志觸發器的數量可能更少。

它顯示了該實例上的9個活動連接，非常適合測試，而不會觸發安全警報。

適用于Linux的Zoom App

我還在Linux版Zoom App上進行了測試。在安全性研究方面，安全社區并未將重點放在Linux的Zoom客戶端上。所以，我進行了下面的研究。

Linux上的Zoom TLS / SSL漏洞

每當使用自定義TLS / SSL證書攔截流量時，Zoom都會用以下消息提示用戶：

Zoom中的不受信任的服務器證書

用戶單擊“仍然信任”后，該證書將隨證書的指紋一起添加到本地Zoom數據庫中。當出現下一個請求時，白名單證書如預期的那樣被允許。

問題在于，所有TLS / SSL證書都可以被惡意軟件直接“接受”到本地Zoom數據庫，而無需其他權限。 Zoom證書數據庫的自定義實現不僅僅依賴于系統CA證書數據庫。在正常情況下，系統CA證書數據庫需要root訪問權限才能將新的SSL / TLS證書列入白名單。

我用Golang寫了一個概念證明，將TLS / SSL證書指紋注入到本地Zoom數據庫中。在用戶計算機上執行此代碼后，將接受所有注入的證書，而不會在Zoom上出錯。

代碼如下

 

 

 

有關Zoom Launcher的設計漏洞

 

啟動Zoom

[/usr/bin/zoom]是[/opt/zoom/ZoomLauncher]的符號鏈接，調用Zoom時會發生以下情況：

$Zoom 

啟動Zoom后會發現Zoom正在檢查$PWD目錄中是否有用于Zoom的文件，并執行該文件，否則它將導航到Zoom安裝目錄并執行另一個二進制文件Zoom可執行文件。如果$ PWD目錄上有一個名為“zoom”的可執行文件，它將作為/ usr / bin / zoom的子進程執行。

概念驗證

這破壞了應用程序白名單的所有保護，允許惡意軟件作為可信任供應商(Zoom)的子進程運行，而且無論如何都是一個糟糕的設計或是安全實踐。

我曾想過為什么要這樣設計，但我根本沒有找到很好的理由。

zoom本地數據庫在Linux上安全實現的漏洞

我注意到Zoom本地數據庫實現中的另一個有趣的問題，Zoom本地數據庫允許Zoom存儲自定義配置和用戶數據。假設可以通過任何級別的權限訪問用戶計算機，則任何人都可以讀取和提取Zoom用戶數據和配置。

從Zoomus.db本地數據庫可以看出客戶數據和主要的PII詳細信息被混淆處理了，但是仍然有一些重要的數據被公開。

Zoom不完全是端到端加密

Zoom宣布它現在支持端到端加密，并在20207年5月推出了其他安全更新以保護用戶。為此我還專門測試了Zoom Chat，它是Zoom的一項功能，該功能允許群組聊天。 它允許團隊進行協作，共享文件，當然還可以發送消息。

我注意到，Zoom的聊天記錄以純文本格式存儲在磁盤上。 將此與Linux文件權限的不良做法結合在一起，就意味著任何進程都可以無限制地訪問所有Zoom聊天記錄。視頻請點此。