對(duì)于短信平臺(tái)呼叫狀態(tài)機(jī)的調(diào)查

這篇文章講述了我對(duì)許多短信平臺(tái)呼叫狀態(tài)機(jī)的調(diào)查，包括Signal、JioChat、Mocha、Google Duo和Facebook Messenger，調(diào)查過(guò)程中發(fā)現(xiàn)了5個(gè)漏洞，這些漏洞可以讓呼叫方設(shè)備強(qiáng)制被叫方設(shè)備傳輸音頻或視頻數(shù)據(jù)，我試圖分析這其中的原因。

2019年1月29日，在FaceTime組中發(fā)現(xiàn)了一個(gè)嚴(yán)重的漏洞，攻擊者可以通過(guò)該漏洞呼叫目標(biāo)，不需要進(jìn)行用戶交互就可以強(qiáng)行連接呼叫，從而允許攻擊者在目標(biāo)不知情或不同意的情況下監(jiān)聽(tīng)目標(biāo)的周?chē)h(huán)境。該bug的影響和機(jī)制上都很出色。在沒(méi)有獲得代碼執(zhí)行情況下，漏洞能夠強(qiáng)制目標(biāo)設(shè)備向攻擊者設(shè)備傳輸音頻是不尋常的、可能前所未有的影響。此外，該漏洞是FaceTime調(diào)用狀態(tài)機(jī)中的一個(gè)邏輯bug，只需使用設(shè)備的用戶界面即可執(zhí)行。雖然這個(gè)bug很快就被修復(fù)，但我從未在任何平臺(tái)上考慮過(guò)由于調(diào)用狀態(tài)機(jī)中的邏輯bug發(fā)生如此嚴(yán)重且容易實(shí)現(xiàn)的漏洞攻擊場(chǎng)景，這一事實(shí)使我懷疑其他狀態(tài)機(jī)是否也存在類似的漏洞。這篇文章描述了我對(duì)許多短信平臺(tái)呼叫狀態(tài)機(jī)的調(diào)查，包括Signal、JioChat、Mocha、Google Duo和Facebook Messenger。 WebRTC和狀態(tài)機(jī) 大多數(shù)視頻會(huì)議應(yīng)用都是使用WebRTC實(shí)現(xiàn)的，這些在過(guò)去幾篇博文中已經(jīng)討論過(guò)。WebRTC是通過(guò)在對(duì)等方之間會(huì)話描述協(xié)議（SDP）中的呼叫設(shè)置信息來(lái)創(chuàng)建連接的，這個(gè)過(guò)程被稱為信令。信令不是由WebRTC實(shí)現(xiàn)的，WebRTC允許對(duì)等體以任何可用安全通信消息交換SDP，通常web applications采用WebSockets，以及消息傳遞應(yīng)用程序的安全消息傳遞。 可以由WebRTC對(duì)等體進(jìn)行交換的有幾種類型的SDP。在一個(gè)典型的連接中，呼叫者首先發(fā)送一個(gè)SDP提議，然后被叫者用SDP應(yīng)答來(lái)響應(yīng)。這些消息包含了傳輸和接收媒體所需的大部分信息，包括編解碼器支持、加密密鑰等。在交換報(bào)價(jià)/應(yīng)答之后，對(duì)等方可以向其他對(duì)等方發(fā)送SDP候選者。候選者是兩個(gè)對(duì)等方可以用來(lái)相互連接的潛在網(wǎng)絡(luò)路徑，SDP候選者包含IP地址和TURN服務(wù)器等信息。對(duì)等方通常向一個(gè)對(duì)等方發(fā)送多個(gè)候選者，候選者可以在連接過(guò)程中的任何時(shí)間發(fā)送。 WebRTC連接維護(hù)著一個(gè)與是否已經(jīng)收到并處理了報(bào)價(jià)或應(yīng)答相關(guān)的內(nèi)部狀態(tài)，然而， 使用WebRTC的應(yīng)用程序通常必須維護(hù)自己的狀態(tài)機(jī)來(lái)管理應(yīng)用程序的用戶狀態(tài)。用戶狀態(tài)如何映射到WebRTC狀態(tài)是由WebRTC集成商做出的設(shè)計(jì)選擇，這對(duì)安全和性能都有影響。例如，有些應(yīng)用在被叫用戶與應(yīng)用交互接聽(tīng)電話之前，不會(huì)交換任何SDP，同時(shí)，有些應(yīng)用建立了對(duì)等連接，在被叫用戶還沒(méi)有接到呼叫通知之前，就開(kāi)始從呼叫者向被叫用戶發(fā)送音頻和視頻。 無(wú)論設(shè)計(jì)如何，從輸入設(shè)備傳輸音頻或視頻都必須由應(yīng)用程序代碼使用WebRTC直接啟用。這通常是通過(guò)一個(gè)叫做軌道的功能來(lái)實(shí)現(xiàn)的。每個(gè)輸入設(shè)備都被認(rèn)為是一個(gè) "軌道"，每個(gè)特定的軌道必須在傳輸音頻或視頻之前通過(guò)調(diào)用addTrack（或等效語(yǔ)言）添加到特定的對(duì)等連接中。音軌也可以被禁用，對(duì)于實(shí)現(xiàn)靜音和相機(jī)關(guān)閉功能非常有用。每個(gè)軌道還有一個(gè)RTPSender屬性，可以用來(lái)微調(diào)傳輸?shù)膶傩?，也可以用?lái)禁用音頻或視頻傳輸。 從理論上講，在音頻或視頻傳輸之前確保被叫方同意是一個(gè)相當(dāng)簡(jiǎn)單的問(wèn)題，即等待用戶接受呼叫后再向?qū)Φ冗B接添加任何軌道。然而，當(dāng)我查看實(shí)際的應(yīng)用程序時(shí)，它們以許多不同的方式啟用傳輸。其中大多數(shù)導(dǎo)致了漏洞，使得呼叫在沒(méi)有被叫者的互動(dòng)情況下被連接。 Signal Messenger 我在2019年9月看了Signal，當(dāng)時(shí)該應(yīng)用的呼叫設(shè)置與WebRTC文檔中推薦的非常相似。

建立對(duì)等連接，然后當(dāng)被叫方通過(guò)與用戶界面交互接受呼叫時(shí)，將被叫方的音軌添加到連接中。然后通過(guò)對(duì)等連接向被叫方發(fā)送消息，告訴被叫方也進(jìn)入連接狀態(tài)并添加音軌。 不幸的是，應(yīng)用程序沒(méi)有檢查接收連接消息的設(shè)備是主叫設(shè)備，所以可以從主叫設(shè)備向被叫設(shè)備發(fā)送連接消息。這就導(dǎo)致了音頻通話的連接使主叫方聽(tīng)到了被叫方的周?chē)h(huán)境。我通過(guò)修改Signal的開(kāi)源代碼來(lái)發(fā)送消息并重新編譯攻擊客戶端來(lái)測(cè)試這個(gè)bug。 這個(gè)漏洞在2019年9月在客戶端被修復(fù)，此后，Signal的信令代碼被使用更保守的狀態(tài)機(jī)的ringrtc項(xiàng)目取代 該bug純屬Signal的代碼，并非由于對(duì)WebRTC功能的誤解。狀態(tài)機(jī)設(shè)計(jì)在很大程度上有效，需要用戶同意才能傳輸音頻，但未執(zhí)行特定檢查 JioChat 與Mocha 2020年7月，我在偶然發(fā)現(xiàn)在JioChat和Mocha messengers中兩個(gè)非常相似的漏洞。他們都有一個(gè)類似的信令設(shè)計(jì)，這是服務(wù)器介導(dǎo)的。

通過(guò)服務(wù)器交換邀約和回答，然后呼叫者和被叫者都將他們的候選人發(fā)送到服務(wù)器。然后服務(wù)器將它們存儲(chǔ)起來(lái)，直到被叫方與其設(shè)備交互并接受呼叫。然后建立對(duì)等連接，當(dāng)WebRTC進(jìn)入內(nèi)部連接狀態(tài)時(shí)，就會(huì)添加軌道，造成音頻和視頻的傳輸。 這種設(shè)計(jì)有一個(gè)根本性的問(wèn)題，因?yàn)榭梢赃x擇將候選人包含在SDP提議或回答中。在這種情況下，對(duì)等連接將立即開(kāi)始，因?yàn)樵谶@個(gè)設(shè)計(jì)中，唯一阻止連接的是缺乏候選人，這將反過(guò)來(lái)導(dǎo)致輸入設(shè)備的傳輸。我通過(guò)使用Frida將候選者添加到每個(gè)應(yīng)用程序創(chuàng)建的提議中進(jìn)行測(cè)試。能夠?qū)е翵ioChat在未經(jīng)用戶同意的情況下發(fā)送音頻，以及Mocha發(fā)送音頻和視頻。這兩個(gè)漏洞在提交后不久就通過(guò)過(guò)濾服務(wù)器上的SDP進(jìn)行了修復(fù)。 這些問(wèn)題是由于對(duì)WebRTC的工作原理的誤解，再加上試圖通過(guò)不尋常的信令設(shè)計(jì)來(lái)提高WebRTC的性能所致。通常情況下，WebRTC集成商必須決定是否要等到被叫方接聽(tīng)電話后再建立點(diǎn)對(duì)點(diǎn)連接。提前設(shè)置連接可以提高性能，避免用戶在接聽(tīng)電話時(shí)需要等待，但也大大增加了WebRTC的遠(yuǎn)程攻擊面。這些應(yīng)用試圖通過(guò)這種設(shè)計(jì)來(lái)提高性能，不需要付出安全成本，但沒(méi)有考慮到WebRTC可以啟動(dòng)對(duì)等連接的所有方式。 一般來(lái)說(shuō)，集成商在任何不添加或啟用軌道的WebRTC功能上控制音頻或視頻傳輸不是一個(gè)好主意。首先，許多WebRTC功能是復(fù)雜的，所以很容易犯錯(cuò)，允許音頻或視頻被傳輸。另外，如果門(mén)控功能不是常用的安全功能，那么將來(lái)可能會(huì)進(jìn)行不良測(cè)試或改變。 Duo 我在2020年9月看了Google Duo。Duo的信令方法與很多信令不同，因?yàn)樗С忠粋€(gè)功能，即在接聽(tīng)之前，被叫方可以預(yù)覽來(lái)電的視頻。所以在接聽(tīng)電話之前需要設(shè)置一個(gè)單向的視頻流。

上圖顯示了單向視頻流的設(shè)置。虛線代表使用Java執(zhí)行器進(jìn)行的異步調(diào)用。從被叫方到呼叫方的傳輸缺失是通過(guò)兩個(gè)方法來(lái)實(shí)現(xiàn)的。首先，SDP要約中包含了視頻的屬性a=sendonly，這使得視頻只能朝一個(gè)方向傳輸。另外，當(dāng)被叫方收到呼叫方的offer時(shí)，它將視頻軌道添加到對(duì)等連接中，但隨后使用軌道的RTPSender屬性將其禁用（音頻軌道在用戶接受呼叫之前不會(huì)被添加或啟用）。 這兩種方法都不能有效地阻止視頻從被叫方傳輸?shù)胶艚蟹?。SDP屬性很容易解決，因?yàn)檎{(diào)用者向被叫者提供SDP，所以很容易被改變。除了異步設(shè)計(jì)外，一處理完offer就停用視頻軌跡應(yīng)該是可以的。正常情況下，setLocalDescription方法（處理SDP offer）會(huì)調(diào)用callbackonSetSuccess，回調(diào)結(jié)束后再設(shè)置對(duì)等連接。但是，如果回調(diào)再進(jìn)行一次異步調(diào)用，那么在連接建立之前，onSetSuccess完成的保證不再成立，因?yàn)閟etLocalDescription方法只等待onSetSuccess線程完成。這就造成了禁用視頻和建立連接之間的競(jìng)爭(zhēng)，所以在某些情況下，被叫者可以在禁用傳輸之前向調(diào)用者傳輸幾個(gè)視頻幀。 我通過(guò)使用Frida來(lái)改變被叫方發(fā)送的SDP來(lái)測(cè)試，然后我嘗試了很多方法來(lái)贏得比賽。結(jié)果發(fā)現(xiàn)贏得比賽相當(dāng)困難，我花了大概兩周的時(shí)間，試圖找出如何減緩視頻禁用呼叫的速度，以便給連接時(shí)間建立起來(lái)。最后，我發(fā)送了多個(gè)offer，并在offer中添加候選人減少連接時(shí)間，因?yàn)榫W(wǎng)絡(luò)連接已經(jīng)建立。然后，我通過(guò)對(duì)等連接的數(shù)據(jù)通道發(fā)送了許多需要長(zhǎng)時(shí)間處理的消息，以減緩視頻軌道的禁用。數(shù)據(jù)消息的處理與禁用視頻軌線程隊(duì)列上是一樣的，所以發(fā)送數(shù)據(jù)消息就把禁用視頻所需要的隊(duì)列和許多其他條目一起填滿了，延遲了視頻軌被禁用的時(shí)間。 這個(gè)bug在2020年12月被修復(fù)，刪除了onSetSuccess中的異步調(diào)用。雖然Duo總體上設(shè)計(jì)的信令能有效防止視頻從被叫方傳輸?shù)胶艚蟹?，但異步?shí)現(xiàn)設(shè)計(jì)引入了問(wèn)題。異步信令的實(shí)現(xiàn)在移動(dòng)應(yīng)用上越來(lái)越常見(jiàn)，因?yàn)橛泻芏嗖豢深A(yù)知的情況下，WebRTC需要在網(wǎng)絡(luò)或?qū)Φ润w上進(jìn)行等待，將函數(shù)調(diào)用分離到不同的線程中，意味著一次調(diào)用的延遲不會(huì)影響到不相關(guān)的功能。然而異步調(diào)用使得對(duì)狀態(tài)機(jī)在所有情況下的表現(xiàn)進(jìn)行建模變得更加困難，因此在WebRTC信令中加入異步調(diào)用是非常重要的。在本例中，禁用視頻軌道的異步調(diào)用在性能方面沒(méi)有增加任何東西，因?yàn)榻密壍赖娜魏握{(diào)用都沒(méi)有理由阻塞，onSetSuccess已經(jīng)在自己的線程中運(yùn)行，可以讓位于更高優(yōu)先級(jí)的線程。平衡異步調(diào)用的風(fēng)險(xiǎn)和收益是很重要的，不要濫竽充數(shù)。 Facebook Messenger 我在2020年10月研究了Facebook Messenger。這是一個(gè)相當(dāng)具有挑戰(zhàn)性的目標(biāo)，需要大量的反向工程。退一步講，WebRTC在幾種編程語(yǔ)言中都有綁定去允許它集成到使用該語(yǔ)言的應(yīng)用程序中。大多數(shù)集成WebRTC的Android應(yīng)用都使用Java綁定。這使得研究信令狀態(tài)機(jī)變得相當(dāng)直接，因?yàn)橹匾腏ava函數(shù)，如setLocalDescription（處理報(bào)價(jià)和應(yīng)答）、addRemoteIceCandidate（處理候選者）和addTrack（將軌道添加到連接中）可以在Frida中掛起，并記錄下來(lái)進(jìn)行分析，可以直接使用這些調(diào)用來(lái)改變攻擊者設(shè)備的行為。 Facebook Messenger并沒(méi)有使用Java綁定來(lái)集成WebRTC，而是使用C++綁定。此外，它靜態(tài)地將WebRTC鏈接到一個(gè)更大的庫(kù)(librtcR20.so，很可能就是本文提到的rsys庫(kù))，所以調(diào)用綁定的符號(hào)會(huì)被剝離，使其難以掛接。此外，F(xiàn)acebook Messenger在傳輸SDP之前會(huì)將SDP序列化成另一種格式，很難通過(guò)監(jiān)控流量來(lái)確定信令的工作情況。 我最終意識(shí)到要想弄清楚Facebook Messenger信令的工作原理，唯一合理的方法就是弄清楚它的網(wǎng)絡(luò)協(xié)議。值得慶幸的是，F(xiàn)acebook已經(jīng)公開(kāi)表示他們使用的是fbthrift，是thrift的一個(gè)分支。我把librtcR20.so庫(kù)加載到IDA中，看看能不能找到它調(diào)用到thrift庫(kù)的地方，但雖然有一些調(diào)用，但看起來(lái)代碼大部分是靜態(tài)鏈接的。最后我想明白是因?yàn)閠hrift每實(shí)現(xiàn)一個(gè)協(xié)議都會(huì)生成序列化代碼，所以大部分序列化和反序列化代碼最后都會(huì)和協(xié)議處理代碼一起編譯。所以我決定編譯fbthrift，做一個(gè)示例序列化器，并在IDA中查看它，這樣我就可以對(duì)編譯后的fbthrift序列化器有一個(gè)印象。我注意到，在序列化過(guò)程中，對(duì)象的成員是通過(guò)調(diào)用一個(gè)叫做writeFieldBegin的方法來(lái)序列化的。當(dāng)這個(gè)方法被調(diào)用時(shí)，字段名是必需的，盡管它通常不包含在序列化輸出中。所以我在librtcR20中尋找了一個(gè)頻繁調(diào)用的函數(shù)，該函數(shù)使用不同的字符串參數(shù)，似乎是合理的字段名。符合這個(gè)標(biāo)準(zhǔn)的函數(shù)并不多，所以我能夠確定writeFieldBegin。

此時(shí)，我可以發(fā)現(xiàn)很多地方的對(duì)象都是序列化的，需要確定哪一個(gè)是用來(lái)設(shè)置WebRTC調(diào)用的消息。 早些時(shí)候，我注意到庫(kù)中有一個(gè)名為P2PCall::OnP2PMessageFromPeer的方法（注意，這個(gè)方法的符號(hào)是被剝離的，但當(dāng)它被調(diào)用時(shí)，方法名會(huì)被記錄下來(lái)）。這似乎是一個(gè)可能會(huì)處理反序列化消息的地方。搜索字符串 "P2PMessage"，我發(fā)現(xiàn)了一個(gè)名為P2PMessageRequest的類型的序列化代碼。我認(rèn)為這就是創(chuàng)建調(diào)用設(shè)置消息的地方。 Thrift序列化代碼是根據(jù)Thrift定義文件中的類定義生成的。根據(jù)傳遞給writeFieldBegin的字段名和類型，可以慢慢地對(duì)這個(gè)類型的完整thrift定義進(jìn)行逆向工程。這是一項(xiàng)繁瑣的工作，因?yàn)槎x相當(dāng)長(zhǎng)，而且代碼被混淆了，使得寄存器的使用不一致，所以我不相信任何自動(dòng)化的方法都是準(zhǔn)確的。 以下是序列化代碼的示例。

需要注意的是它從一個(gè)Extmap類型的對(duì)象中寫(xiě)入了兩個(gè)字段。第一個(gè)字段名為id，是必填字段。寫(xiě)代碼的函數(shù)如下。

寫(xiě)的字段標(biāo)識(shí)符為1，字段類型為8，翻譯成i32（32位整數(shù)）。第二個(gè)字段是可選字段，寫(xiě)它的寄存器在下面的代碼中設(shè)置。

將字段名設(shè)置為uri，字段標(biāo)識(shí)符設(shè)置為2，字段類型設(shè)置為8（也是i32）。所有這些，這段代碼可以用下面的thrift定義來(lái)表示。

struct Extmap{ 1: i32 id 2: optional i32 uri} 在對(duì)P2PMessageRequest類型的每個(gè)字段進(jìn)行類似的逆向工程后，我有了一個(gè)完整的thrift定義，可以在這里找到。 我用這個(gè)thrift定義做了兩件事。首先，我用它來(lái)確定C++中P2PMessageRequest類型的布局。這是極有價(jià)值的，因?yàn)樗试S我將結(jié)構(gòu)定義加載到IDA中，并正確命名每一個(gè)字段。這讓我更容易理解P2PCall::OnP2PMessageFromPeer中如何處理傳入消息。fbthrift可以直接從thrift定義中生成C++頭文件，但這些文件非常長(zhǎng)，包含了很多不必要的定義，無(wú)法被IDA處理。所以我最后把生成的源碼編譯后加載到IDA中，然后導(dǎo)出結(jié)構(gòu)定義，導(dǎo)入到另一個(gè)已經(jīng)加載了librtcR20.so的IDA實(shí)例中。在我的編譯中，有幾個(gè)字段的大小與Facebook的不同，但很接近，可以通過(guò)一些修改讓它工作。 下圖是一個(gè)在IDA中反編譯并導(dǎo)入了thrift定義的代碼例子，讓大家了解一下它對(duì)消息對(duì)象的處理有多容易。

我還能夠解碼并生成通過(guò)網(wǎng)絡(luò)發(fā)送的消息。為了做到這一點(diǎn)，我從Python中的thrift定義中生成了序列化代碼，因?yàn)閠hrift支持多種語(yǔ)言的代碼生成。然后，當(dāng)使用Frida Python在Facebook Messenger中掛鉤函數(shù)時(shí)，我能夠?qū)脒@些代碼 然后我需要找到處理傳入的P2PMessageRequest消息的代碼。因?yàn)檫@些消息是由本地代碼處理的，而大多數(shù)Facebook消息是由Java代碼處理的，所以我找了一個(gè)有合適名字的本地調(diào)用，我找到了com.facebook.webrtc.WebrtcEngine.onThriftMessageFromPeer。并把這個(gè)方法和Frida掛上鉤，在生成的反序列器中輸入它的字節(jié)數(shù)組參數(shù)，它就能對(duì)傳入的消息進(jìn)行解碼。 我發(fā)現(xiàn)了一個(gè)類似的方法，用來(lái)發(fā)送thrift消息，sendThriftToPeer(這個(gè)方法的類名被混淆了，在每個(gè)版本的Facebook Messenger中都會(huì)改變，但可以通過(guò)grepping應(yīng)用程序的smali找到它)。我將這個(gè)方法與Frida連接起來(lái)，并在生成的反序列化器中輸入它的字節(jié)數(shù)組參數(shù)，它對(duì)傳入的消息進(jìn)行解碼。 現(xiàn)下我能夠理解Facebook Messenger的信令狀態(tài)機(jī)。取決于用戶在哪里登錄到Facebook Messenger可以有兩種不同的方式可以發(fā)生信令。如果用戶在多個(gè)設(shè)備或?yàn)g覽器上登錄，那么在被叫人與他們的設(shè)備交互之前，幾乎不會(huì)發(fā)生什么。報(bào)價(jià)、應(yīng)答和候選人被交換，但它們被被叫者設(shè)備存儲(chǔ)，直到被叫者用戶接聽(tīng)電話才會(huì)被處理。因?yàn)榉駝tFacebook Messenger不知道要連接到什么設(shè)備。 如果被叫人只在一個(gè)設(shè)備上登錄，狀態(tài)機(jī)就比較有意思了。

在這種情況下，F(xiàn)acebook Messenger在收到提議時(shí)立即啟用跟蹤，但改變了提議，使所有傳出的流都不活躍。然后，它用用戶與設(shè)備交互時(shí)它們處于活躍狀態(tài)的提議來(lái)替換。 我擔(dān)心可能會(huì)有繞過(guò)改變報(bào)價(jià)的方法，但我看了一下這是如何做到的，雖然我一般不建議使用除了添加或禁用軌道以外的任何東西來(lái)禁用輸入設(shè)備傳輸，但這是相當(dāng)強(qiáng)大的。在SDP解碼成一個(gè)內(nèi)部的WebRTC對(duì)象后，報(bào)價(jià)就被改變了，而且直接對(duì)這個(gè)對(duì)象進(jìn)行修改，這就消除了解析錯(cuò)誤的可能性。 在研究如何處理接收的消息時(shí)，我注意到除了報(bào)價(jià)、回答和候選人之外的許多消息類型在電話被接聽(tīng)之前就被處理了。有一種類型很突出，叫做SdpUpdate。當(dāng)收到SdpUpdate消息時(shí)，通過(guò)調(diào)用setLocalDescription更新本地的offer或應(yīng)答。 這個(gè)消息類型發(fā)送到上面的狀態(tài)機(jī)時(shí)并沒(méi)有任何作用，因?yàn)樗呀?jīng)在存儲(chǔ)SDP并等待調(diào)用setLocalDescription。但在用戶登錄兩個(gè)設(shè)備的情況下，它導(dǎo)致了setLocalDescription被調(diào)用，并啟動(dòng)了音頻連接。 目前還不清楚SdpUpdate消息類型在Facebook Messenger中的用途。在我的測(cè)試設(shè)備上嘗試了許多場(chǎng)景，包括網(wǎng)絡(luò)切換，但無(wú)法在正常使用中生成一個(gè)。無(wú)論如何，很明顯在接聽(tīng)電話之前，并沒(méi)有打算讓這種消息類型被接收。這與上面描述的Signal bug類似，它與應(yīng)用程序使用WebRTC無(wú)關(guān)，而是由于在處理輸入時(shí)遺漏了一個(gè)檢查，會(huì)導(dǎo)致?tīng)顟B(tài)轉(zhuǎn)換。 T該漏洞已于2020年11月通過(guò)服務(wù)器變更修復(fù)，防止在呼叫連接之前發(fā)送該消息類型。 其他應(yīng)用 我還查看了其他一些應(yīng)用程序，它們的狀態(tài)機(jī)沒(méi)有發(fā)現(xiàn)問(wèn)題。我在2020年8月查看了Telegram，就在視頻會(huì)議被添加到應(yīng)用程序之后。沒(méi)有發(fā)現(xiàn)任何問(wèn)題主要是因?yàn)樵搼?yīng)用在被叫人接聽(tīng)電話之前不會(huì)交換報(bào)價(jià)、應(yīng)答或候選人。我在2020年11月研究了Viber，沒(méi)有發(fā)現(xiàn)他們的狀態(tài)機(jī)有任何問(wèn)題，盡管逆向工程應(yīng)用程序的挑戰(zhàn)使這個(gè)分析不像我研究的其他應(yīng)用程序那么嚴(yán)格。 探討 我調(diào)查的大多數(shù)呼叫狀態(tài)機(jī)都存在邏輯漏洞，允許音頻或視頻內(nèi)容在未經(jīng)被叫方同意的情況下從被叫方傳輸給呼叫方。這顯然是在保護(hù)WebRTC應(yīng)用安全時(shí)經(jīng)常被忽視的一個(gè)領(lǐng)域。 大多數(shù)錯(cuò)誤似乎不是由于開(kāi)發(fā)人員對(duì)WebRTC功能的誤解造成的。相反，它們是由于狀態(tài)機(jī)的實(shí)現(xiàn)方式出現(xiàn)了錯(cuò)誤。也就是說(shuō)，對(duì)這些類型的問(wèn)題缺乏認(rèn)識(shí)可能是一個(gè)因素。很少有WebRTC文檔或教程明確討論從用戶的設(shè)備上傳輸音頻或視頻時(shí)需要得到用戶的同意。 許多狀態(tài)機(jī)在如何處理調(diào)用設(shè)置方面都有不必要的復(fù)雜性，這也是一個(gè)因素。不必要的線程處理、對(duì)模糊特性的依賴以及大量的狀態(tài)和輸入類型增加了在信號(hào)狀態(tài)機(jī)中發(fā)生此類漏洞的可能性。 此外，值得注意的是，我沒(méi)有研究這些應(yīng)用程序的任何群組呼叫功能，所有報(bào)告的漏洞都是在對(duì)等呼叫中發(fā)現(xiàn)的。這是今后工作的一個(gè)領(lǐng)域，可能會(huì)發(fā)現(xiàn)更多的問(wèn)題。 結(jié)論 我調(diào)查了7個(gè)視頻會(huì)議應(yīng)用程序的信令狀態(tài)機(jī)，發(fā)現(xiàn)了5個(gè)漏洞，這些漏洞可以讓呼叫方設(shè)備強(qiáng)制被叫方設(shè)備傳輸音頻或視頻數(shù)據(jù)。這些漏洞后來(lái)都被修復(fù)了。目前還不清楚為什么這是一個(gè)如此普遍的問(wèn)題，但缺乏對(duì)這類漏洞的認(rèn)識(shí)以及信令狀態(tài)機(jī)不必要的復(fù)雜性可能是一個(gè)因素。信令狀態(tài)機(jī)是視頻會(huì)議應(yīng)用中一個(gè)令人關(guān)注且未被充分調(diào)查的攻擊面，隨著進(jìn)一步的研究，很可能會(huì)發(fā)現(xiàn)更多的問(wèn)題。

責(zé)任編輯：lq