在過(guò)去一年中，Zoom的用戶(hù)量迅速增長(zhǎng)，從2019年初的1000萬(wàn)活躍用戶(hù)增長(zhǎng)到2020年中期的2億多。

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

識(shí)別出的漏洞列表

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

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

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

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

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

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

漏洞的尋找過(guò)程

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

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

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

識(shí)別攻擊面

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

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

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

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

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

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

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

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

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

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

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

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

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

HTTP接口在錯(cuò)誤消息方面非常冗長(zhǎng)，但是，這是FreeIPA中的默認(rèn)響應(yīng)。可以從[/ipa/session/login_password] API枚舉用戶(hù)，如下面的截圖所示。

無(wú)效賬戶(hù)如下所示：

有效賬戶(hù)如下所示： 

但是，HTTP API中有一個(gè)鎖定策略，用于鎖定超過(guò)無(wú)效身份驗(yàn)證嘗試次數(shù)的帳戶(hù)。

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

攻擊Kerberos

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

建立字詞表

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

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

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

我還強(qiáng)制使用了帳戶(hù)密碼，因?yàn)闆](méi)有針對(duì)用戶(hù)帳戶(hù)的鎖定策略，這似乎是timespan(表示一個(gè)時(shí)間間隔)的死胡同。

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

Zoom允許在帳戶(hù)上上傳個(gè)人資料圖片，我一直對(duì)圖像解析器很感興趣，因?yàn)閳D像解析器的攻擊面很寬，并且可以為不同的攻擊媒介打開(kāi)大門(mén)。

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

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

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

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

原始有效載荷

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

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

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

正常視圖如下所示：

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

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

自動(dòng)化開(kāi)發(fā)

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

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

概念驗(yàn)證

視頻鏈接點(diǎn)這里。

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

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

Tavis的研究表明，可以在GhostScript上執(zhí)行遠(yuǎn)程命令。這項(xiàng)研究對(duì)于這項(xiàng)功能至關(guān)重要，因?yàn)槿绻覀兡軌蚶肐mageMagick上的GhostScript，我們就可以實(shí)現(xiàn)遠(yuǎn)程命令執(zhí)行。

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

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

有效載荷的概念證明

 

 

 

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

 

緩解措施

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

Shadow IT和Zoom

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

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

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

它顯示了該實(shí)例上的9個(gè)活動(dòng)連接，非常適合測(cè)試，而不會(huì)觸發(fā)安全警報(bào)。

適用于Linux的Zoom App

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

Linux上的Zoom TLS / SSL漏洞

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

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

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

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

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

代碼如下

 

 

 

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

 

啟動(dòng)Zoom

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

$Zoom 

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

概念驗(yàn)證

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

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

zoom本地?cái)?shù)據(jù)庫(kù)在Linux上安全實(shí)現(xiàn)的漏洞

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

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

Zoom不完全是端到端加密

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

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