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

Zoom的流行使其成為黑客，攻擊者和安全社區(qū)的重要目標(biāo)。本文的研究重點是識別Zoom中的安全漏洞。研究結(jié)果表明，一些嚴(yán)重的安全漏洞會影響Zoom的運行和開發(fā)基礎(chǔ)架構(gòu)，Zoom Linux應(yīng)用程序以及Zoom的端到端加密實現(xiàn)。

識別出的漏洞列表

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

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

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

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

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

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

漏洞的尋找過程

我于2020年4月在Zoom上開始了第一輪測試，我的目標(biāo)是找到一個影響Zoom結(jié)構(gòu)和用戶的安全漏洞。功夫不負(fù)有心人，我確定了一個內(nèi)存泄漏漏洞，該漏洞會影響屬于Zoom運行基礎(chǔ)結(jié)構(gòu)的API。

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

接下來，我開始對Zoom進行進一步的安全性研究，并發(fā)現(xiàn)了影響其基礎(chǔ)架構(gòu)，Zoom Linux應(yīng)用及其端到端加密實施的新漏洞。

識別攻擊面

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

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

域發(fā)現(xiàn)

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

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

暴露的公共Kerberos身份驗證服務(wù)器

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

(1) 目標(biāo)：ca01.idm.meetzoom.us

我注意到正在運行的Kerberos服務(wù)可以從外部訪問，Kerberos是一種網(wǎng)絡(luò)身份驗證協(xié)議，旨在保護客戶端/服務(wù)器應(yīng)用程序的身份驗證。

目標(biāo)的命名約定表示該目標(biāo)正在運行身份管理解決方案或PKI(公鑰基礎(chǔ)結(jié)構(gòu))，在檢查端口80上正在運行的內(nèi)容時，我發(fā)現(xiàn)主機正在運行FreeIPA3，這是RedHat開發(fā)的開源身份管理解決方案。

另一個選擇是查看Zoom的Kerberos和FreeIPA設(shè)置的實現(xiàn)，我還發(fā)現(xiàn)另一項目標(biāo)可以運行確切的設(shè)置。

(2) 目標(biāo)：va01.idm.meetzoom.us

實際上，一旦我們擁有了經(jīng)過身份驗證的帳戶，Kerberos就可以允許大規(guī)模的攻擊。雖然不在內(nèi)部網(wǎng)絡(luò)內(nèi)，但Kerberos的初始輸入更為困難。

HTTP接口在錯誤消息方面非常冗長，但是，這是FreeIPA中的默認(rèn)響應(yīng)?？梢詮腫/ipa/session/login_password] API枚舉用戶，如下面的截圖所示。

無效賬戶如下所示：

有效賬戶如下所示： 

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

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

攻擊Kerberos

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

建立字詞表

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

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

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

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

在Zoom運營服務(wù)器上發(fā)現(xiàn)內(nèi)存泄漏

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

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

所以我假設(shè)， Zoom將ImageMagick用作服務(wù)器端圖像轉(zhuǎn)換的后端。部署映像轉(zhuǎn)換微服務(wù)的常見模式是，一旦微服務(wù)達到穩(wěn)定狀態(tài)，它們幾乎不會收到所需的更新和安全控制。發(fā)生這種情況的原因是，它對業(yè)務(wù)的重要性不如基礎(chǔ)架構(gòu)中的其他功能強大。

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

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

原始有效載荷

Zoom API被攻擊的結(jié)果如下所示;

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

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

正常視圖如下所示：

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

結(jié)果表明，當(dāng)提供具有相同有效載荷規(guī)格的正常GIF圖像后，只要確認(rèn)存在安全漏洞并發(fā)現(xiàn)ImageMagick設(shè)置上存在攻擊問題的部分位于Zoom時，此圖像就會被攻擊 。

自動化開發(fā)

要計劃在Zoom上自動利用內(nèi)存泄漏，需要：

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

概念驗證

視頻鏈接點這里。

繼續(xù)發(fā)現(xiàn)漏洞

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

Tavis的研究表明，可以在GhostScript上執(zhí)行遠(yuǎn)程命令。這項研究對于這項功能至關(guān)重要，因為如果我們能夠利用ImageMagick上的GhostScript，我們就可以實現(xiàn)遠(yuǎn)程命令執(zhí)行。

我確認(rèn)此漏洞存在于2017年7月被修復(fù)了。在2018年8月，GhostScript和ImageMagick也修補了遠(yuǎn)程命令執(zhí)行漏洞。這意味著，如果Zoom運行中存在內(nèi)存泄漏，那么GhostScript RCE也將出現(xiàn)在Zoom運行中。

基于Zoom的環(huán)境，我在自己的環(huán)境中復(fù)制了這個漏洞。

有效載荷的概念證明

 

 

 

RCE漏洞的本地復(fù)制

 

緩解措施

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

Shadow IT和Zoom

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

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

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

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

適用于Linux的Zoom App

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

Linux上的Zoom TLS / SSL漏洞

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

Zoom中的不受信任的服務(wù)器證書

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

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

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

代碼如下

 

 

 

有關(guān)Zoom Launcher的設(shè)計漏洞

 

啟動Zoom

[/usr/bin/zoom]是[/opt/zoom/ZoomLauncher]的符號鏈接，調(diào)用Zoom時會發(fā)生以下情況：

$Zoom 

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

概念驗證

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

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

zoom本地數(shù)據(jù)庫在Linux上安全實現(xiàn)的漏洞

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

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

Zoom不完全是端到端加密

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

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