這是一個(gè)由三部分組成的系列文章，內(nèi)容涉及：利用WebRTC中的BUG和利用Messenger應(yīng)用程序。本系列文章重點(diǎn)闡述了當(dāng)應(yīng)用程序不能應(yīng)用于WebRTC補(bǔ)丁程序以及通信和安全問題通知中斷時(shí)可能出問題的方面。

文 /Natalie Silvanovich

原文鏈接： https://googleprojectzero.blogspot.com/2020/08/exploiting-android-messengers-part-2.html

Part 3: Which Messengers? 在使用WebRTC開發(fā)Android Messenger：第2部分中，我描述了Android上對WebRTC的一個(gè)應(yīng)用。在本節(jié)中，我將探索它用于哪些應(yīng)用程序。 The exploit 在編寫這個(gè)BUG時(shí)，我最初通過修改WebRTC的源代碼并重新編譯它來修改發(fā)送到目標(biāo)設(shè)備的SCTP數(shù)據(jù)包。這對于攻擊封閉源代碼的應(yīng)用程序是不實(shí)際的，因此我最終改用使用Frida來掛接攻擊設(shè)備的二進(jìn)制文件。 Frida的掛鉤功能允許在調(diào)用特定的本機(jī)函數(shù)之前和之后執(zhí)行代碼，這允許我的BUG改變傳出的SCTP包以及檢查傳入的包。從功能上講，這相當(dāng)于改變攻擊客戶機(jī)的源代碼，但是這些改變不是在編譯時(shí)在源代碼中進(jìn)行的，而是由Frida在運(yùn)行時(shí)動(dòng)態(tài)地進(jìn)行的。 該BUG的源代碼可以在這里找到： https://bugs.chromium.org/p/project-zero/issues/detail?id=2034#c6 攻擊設(shè)備需要掛載7個(gè)函數(shù)，如下所示。

這些函數(shù)可以作為符號(hào)連接，或者作為二進(jìn)制中的偏移量。 目標(biāo)設(shè)備的二進(jìn)制文件還有三個(gè)地址偏移量，這是利用BUG進(jìn)行攻擊所必需的。系統(tǒng)函數(shù)和malloc函數(shù)之間的偏移量，以及上一篇文章中描述的gadget和malloc函數(shù)之間的偏移量就是其中兩個(gè)。這些偏移量在libc中，libc是一個(gè)Android系統(tǒng)庫，因此需要根據(jù)目標(biāo)設(shè)備的Android版本來確定。還需要從cricket:：SctpTransport vtable的位置到全局偏移表中malloc位置的偏移量。這必須由被攻擊應(yīng)用程序中包含WebRTC的二進(jìn)制文件確定。 請注意，所提供的利用BUG腳本有一個(gè)嚴(yán)重的限制：每次讀取內(nèi)存時(shí)，只有在設(shè)置了指針的第31位時(shí)才有效。第2部分解釋了其原因。利用BUG腳本提供了一個(gè)示例，說明如何修復(fù)此問題并使用FWD TSN塊讀取任何指針，但這并不是針對每次讀取都實(shí)現(xiàn)的。出于測試目的，我重置設(shè)備，直到WebRTC庫映射到一個(gè)有利的位置。 Android Applications 通過在googleplay的APK文件中搜索usrsctp中的特定字符串，確定了集成WebRTC的流行Android應(yīng)用程序列表。大約200個(gè)用戶超過500萬的應(yīng)用程序似乎在使用WebRTC。我評估了這些應(yīng)用程序，以確定它們是否可能受到BUG攻擊中的BUG的影響，以及影響會(huì)是什么。 事實(shí)證明，應(yīng)用程序使用WebRTC的方式多種多樣，但可以分為四大類。 l 投影：在用戶同意的情況下，將移動(dòng)應(yīng)用程序的屏幕和控件投影到桌面瀏覽器中，以增強(qiáng)可用性 l 流：音頻和視頻內(nèi)容從一個(gè)用戶發(fā)送到多個(gè)用戶。通常有一個(gè)中間服務(wù)器，因此發(fā)件人不需要管理可能的數(shù)千個(gè)對等方，并且會(huì)記錄內(nèi)容以便以后查看 l 瀏覽器：所有主要的瀏覽器都包含WebRTC以實(shí)現(xiàn)JavaScript WebRTC API l 會(huì)議：兩個(gè)或更多用戶通過音頻或視頻進(jìn)行實(shí)時(shí)通信 對于每種類別，利用BUG的影響是不同的。投影是低風(fēng)險(xiǎn)的，因?yàn)榻ebRTC連接需要大量用戶交互，并且用戶首先可以訪問連接的兩面，因此通過損害另一面幾乎無濟(jì)于事。 流媒體的風(fēng)險(xiǎn)也相當(dāng)?shù)?。盡管某些應(yīng)用程序在流的觀看者數(shù)量較少時(shí)有可能使用對等連接，但它們通常使用中間服務(wù)器，該服務(wù)器終止發(fā)送對等方的WebRTC連接，并開始與接收對等方的新連接。這意味著攻擊者通常無法將格式錯(cuò)誤的數(shù)據(jù)包直接發(fā)送到對等方。即使采用點(diǎn)對點(diǎn)流傳輸?shù)脑O(shè)置，目標(biāo)用戶也需要用戶交互才能查看流，并且通常無法限制誰可以訪問流。因此，RTC應(yīng)用程序可能沒有針對性地使用Web流攻擊。當(dāng)然，這些BUG可能會(huì)影響流服務(wù)使用的服務(wù)器，但是本研究未對此進(jìn)行調(diào)查。 瀏覽器幾乎可以肯定會(huì)受到WebRTC中大多數(shù)錯(cuò)誤的攻擊，因?yàn)樗鼈冊试S對配置方式進(jìn)行大量控制。要利用瀏覽器中的此類錯(cuò)誤，攻擊者需要設(shè)置一個(gè)主機(jī)，該主機(jī)的行為與對等連接中的其他對等主機(jī)相同，并誘使目標(biāo)用戶訪問啟動(dòng)對該主機(jī)的調(diào)用的網(wǎng)頁。在這種情況下，該BUG將與JavaScript中的其他內(nèi)存損壞BUG具有類似的影響。 會(huì)議是WebRTC的最高風(fēng)險(xiǎn)使用方法，但BUG的實(shí)際影響取決于應(yīng)用程序用戶之間的聯(lián)系方式。最高風(fēng)險(xiǎn)的設(shè)計(jì)是一個(gè)應(yīng)用程序，在這個(gè)程序中任何用戶都可以根據(jù)標(biāo)識(shí)符與任何其他用戶聯(lián)系。有些應(yīng)用程序要求被調(diào)用者在進(jìn)行呼叫之前必須以特定的方式與調(diào)用者進(jìn)行交互，這使得用戶很難聯(lián)系到目標(biāo)，并且通常會(huì)降低風(fēng)險(xiǎn)。有些應(yīng)用程序要求用戶輸入代碼或訪問鏈接來啟動(dòng)調(diào)用和發(fā)起呼叫，這也有類似的效果。還有一大堆很難或不可能呼叫特定用戶的應(yīng)用程序，例如聊天輪盤賭應(yīng)用程序，以及具有允許用戶啟動(dòng)呼叫客戶支持功能的功能的應(yīng)用程序。 在這項(xiàng)研究中，我把重點(diǎn)放在允許用戶與特定的其他用戶聯(lián)系的會(huì)議應(yīng)用程序上。這將我的200個(gè)應(yīng)用程序列表減少到14個(gè)應(yīng)用程序，如下所示：

該列表是在2020年6月18日編制的。請注意，一些應(yīng)用被刪除是因?yàn)樗鼈兊姆?wù)器當(dāng)天未運(yùn)行，或者它們很難測試（例如，需要觀看多個(gè)廣告才能進(jìn)行一次呼叫）。 由于在測試過程中發(fā)現(xiàn)了一個(gè)嚴(yán)重的其他BUG，該BUG尚未修復(fù)或未達(dá)到披露的最終期限，因此在此博客文章中將不會(huì)標(biāo)識(shí)已測試的一個(gè)應(yīng)用程序。披露截止日期過去后，將更新此博客文章。 Testing the Exploit 以下部分描述了我針對上述應(yīng)用程序測試BUG利用的嘗試。請注意，由于應(yīng)用程序數(shù)量眾多，每個(gè)應(yīng)用程序花費(fèi)的時(shí)間有限，因此無法保證會(huì)考慮針對WebRTC的每種攻擊。盡管我非常確信可以被利用的應(yīng)用程序確實(shí)可以被利用，但是我對被發(fā)現(xiàn)無法利用的應(yīng)用程序沒有把握。如果出于保護(hù)用戶的目的，您需要了解特定應(yīng)用程序是否易受攻擊，請與供應(yīng)商聯(lián)系，而不是依賴此帖子。 Signal 我從測試Signal開始，因?yàn)樗谴肆斜碇形ㄒ坏拈_源應(yīng)用程序。Signal將WebRTC集成為稱為ringrtc的庫的一部分。我先構(gòu)建了ringrtc，然后構(gòu)建了帶有符號(hào)的Signal，然后將所需的符號(hào)與Frida腳本掛鉤在攻擊者設(shè)備上。我嘗試了該BUG利用，并且大約90％的時(shí)間都有效！ **視頻1：https://youtu.be/YGK_SmVzVkE 此攻擊不需要用戶與目標(biāo)設(shè)備進(jìn)行任何交互，因?yàn)镾ignal在接聽來電之前啟動(dòng)了WebRTC連接，并且該連接可以接受傳入的RTP和SCTP。該BUG在Signal和其他目標(biāo)上并非100％可靠，因?yàn)殄e(cuò)誤376要求將釋放的堆分配替換為該線程執(zhí)行的具有相同大小的下一個(gè)分配，并且有時(shí)另一個(gè)線程會(huì)在該線程中進(jìn)行相同大小的分配。與此同時(shí)。故障會(huì)導(dǎo)致崩潰，這通常對用戶不可見，因?yàn)樵撨^程會(huì)重啟，但會(huì)出現(xiàn)未接來電。 此BUG攻擊是在2020年1月13日發(fā)布的Signal 4.53.6上執(zhí)行的，因?yàn)樵谖彝瓿稍揃UG攻擊時(shí)，Bug 376已經(jīng)在Signal中進(jìn)行了修補(bǔ)。CVE-2020-6514在更高版本中也得到了修復(fù)，并且ASCONF在usrsctp中也已被禁用，因此導(dǎo)致Bug 376的代碼不再可訪問。Signal最近還實(shí)現(xiàn)了一項(xiàng)功能，當(dāng)呼叫者不在被呼叫者的聯(lián)系人中時(shí)，要求用戶進(jìn)行交互才能啟動(dòng)WebRTC連接。Signal也已停止在其Beta版本中使用SCTP，并計(jì)劃在測試該更改后將其添加到發(fā)行客戶端。此BUG的來源可在此處獲得。 Google Duo Duo也是一個(gè)有趣的目標(biāo)，因?yàn)樗杨A(yù)裝在許多Android設(shè)備上。它可以動(dòng)態(tài)鏈接Android WebRTC庫libjingle_peerconnection_so.so，而無需進(jìn)行明顯的修改。我在IDA中對該庫進(jìn)行了反向工程，以查找所有需要掛接的函數(shù)的位置，然后修改Frida腳本以根據(jù)它們與導(dǎo)出符號(hào)的偏移量來掛接它們。我還修改了cricket ::SctpTransport vtable和全局偏移量表之間的偏移量，因?yàn)樗cSignal中的有所不同。該BUG也適用于Duo。DuoBUG利用的源代碼在這里。 **視頻2：https://youtu.be/fBuFFmRg_LA 此BUG不需要任何用戶交互，就像Signal一樣，Duo在應(yīng)答呼叫之前啟動(dòng)WebRTC連接。 該BUG利用程序已于2019年12月15日發(fā)布的68.0.284888502.DR68_RC09版本進(jìn)行了測試。此BUG已得到修復(fù)。同樣，在發(fā)布此應(yīng)用程序時(shí)，Duo可以調(diào)用任何安裝了Google Play服務(wù)的Android設(shè)備，而不管是否已安裝Duo?，F(xiàn)在已經(jīng)不是這樣了。用戶現(xiàn)在需要設(shè)置Duo，并將呼叫者放在他們的聯(lián)系人中，以便接收來電。 Google Hangouts Google Hangouts使用WebRTC時(shí)，它不使用數(shù)據(jù)通道，也不交換SDP來建立呼叫，因此沒有明顯的方法可從對等方啟用它們。因此，該BUG無法在Hangouts中使用。 Facebook Messenger Facebook Messenger是另一個(gè)有趣的目標(biāo)。它擁有大量用戶，根據(jù)其文檔，任何用戶都可以根據(jù)他們的手機(jī)號(hào)碼呼叫任何其他用戶。Facebook Messenger將WebRTC集成到名為librtcR11.so的庫中，該庫從另一個(gè)庫libxplat_third-party_usrsctp_usrsctpAndroid.so動(dòng)態(tài)鏈接到usrsctp。Facebook Messenger會(huì)動(dòng)態(tài)下載這些庫，而不是將它們包含在APK中，因此很難識(shí)別我檢查過的版本，但它是在2020年6月22日下載的。 librtcR11.so庫似乎使用的WebRTC版本大約有六年的歷史，因此早于cricket :: SctpTransport類就已經(jīng)存在。就是說，類似的cricket :: DataMediaChannel類似乎容易受到CVE-2020-6514的攻擊。libxplat_third-party_usrsctp_usrsctpAndroid.so庫似乎更現(xiàn)代，但是包含Bug 376的易受攻擊的代碼。也就是說，似乎不可能從Facebook Messenger獲取此代碼，因?yàn)樗辉O(shè)置為使用RTP數(shù)據(jù)通道而不是SCTP數(shù)據(jù)通道，并且不接受通過會(huì)話描述協(xié)議（SDP）更改信道類型的嘗試。雖然還不清楚這種設(shè)計(jì)背后的動(dòng)機(jī)是否是安全性，但這是一個(gè)很好的例子，說明了限制攻擊者對功能的訪問可以如何減少應(yīng)用程序的BUG。Facebook在啟動(dòng)WebRTC連接之前也會(huì)等待一個(gè)呼叫被應(yīng)答，這進(jìn)一步降低了任何影響它的WebRTCBUG的可利用性。 有趣的是，F(xiàn)acebook Messenger在名為librtcR20.so的庫中還包含WebRTC的更現(xiàn)代版本，但該應(yīng)用程序似乎未使用它。通過在Android上設(shè)置系統(tǒng)屬性，可以使Facebook Messenger使用備用庫，但我找不到攻擊者可以讓設(shè)備切換庫的方法。 Viber 與Facebook Messenger一樣，Viber 13.3.0.5版似乎包含易受攻擊的代碼，但是在創(chuàng)建PeerConnectionFactory時(shí)，該應(yīng)用程序會(huì)禁用SCTP。這意味著攻擊者無法訪問易受攻擊的代碼。 VK VK是Mail.ru發(fā)布的社交網(wǎng)絡(luò)應(yīng)用程序，其中用戶必須明確允許特定的其他用戶與他們聯(lián)系，然后才允許每個(gè)用戶呼叫他們。我針對VK測試了我的BUG，并且需要進(jìn)行一些修改才能起作用。首先，VK不會(huì)將數(shù)據(jù)通道用作其WebRTC連接的一部分，因此我必須啟用它。為此，我編寫了一個(gè)Frida腳本，該腳本將Java中的nativeCreateOffer掛鉤，并在創(chuàng)建要約之前調(diào)用createDataChannel。這足以在兩個(gè)設(shè)備上啟用SCTP，因?yàn)槟繕?biāo)設(shè)備會(huì)根據(jù)攻擊者提供的SDP確定是否啟用SCTP。WebRTC的版本也比我為該BUG編寫的版本要老。WebRTC不包含任何版本信息，因此很難確定，但是根據(jù)日志條目來看，該庫至少已有一年的歷史。這意味著利用BUG利用的“假對象”中的某些偏移量是不同的。進(jìn)行了一些更改，我就可以利用VK。 VK將SDP報(bào)價(jià)發(fā)送到目標(biāo)設(shè)備以啟動(dòng)呼叫，但是目標(biāo)用戶直到用戶接受呼叫后才返回SDP應(yīng)答，這意味著利用此BUG需要目標(biāo)在WebRTC連接啟動(dòng)之前應(yīng)答呼叫。這意味著除非目標(biāo)手動(dòng)應(yīng)答呼叫，否則攻擊不會(huì)起作用。在下面的視頻中，該BUG利用程序/攻擊 在用戶回答后需要相當(dāng)長的時(shí)間才能運(yùn)行。這是由于我設(shè)計(jì)BUG利用程序的方式，而不是由于BUG利用的基本限制。尤其是，利用BUG利用程序會(huì)等待usrsctp生成特定的數(shù)據(jù)包，即使它們可以通過利用BUG腳本更快地生成，也可以使用延遲來避免在可以檢查響應(yīng)時(shí)對數(shù)據(jù)包進(jìn)行重新排序。經(jīng)過充分的努力，此攻擊可能會(huì)在不到五秒鐘的時(shí)間內(nèi)運(yùn)行。還要注意，我更改了BUG利用程序，使其只能處理一個(gè)來電，而不是上述BUG利用中的兩個(gè)來電，因?yàn)槠谕繕?biāo)快速連續(xù)兩次接聽電話是不現(xiàn)實(shí)的。盡管這樣做確實(shí)使BUG利用代碼更加復(fù)雜且難以調(diào)試，但并不需要對BUG利用的工作方式進(jìn)行重大更改。 **視頻3：https://youtu.be/hoigoOeaeYE 不管怎樣，與沒有這些功能的應(yīng)用程序相比，用戶必須選擇接受來自攻擊者的呼叫，然后才能進(jìn)行呼叫，再加上要求用戶應(yīng)答呼叫并保持在線幾秒鐘的要求，這一BUG利用對VK的作用大大降低。 針對VK 6.7（5631）進(jìn)行了測試。像Facebook一樣，VK動(dòng)態(tài)下載其WebRTC版本，因此很難指定其版本，但是測試于2020年7月13日進(jìn)行。VK自此更新了服務(wù)器，以使用戶無法使用包含數(shù)據(jù)通道的SDP發(fā)起呼叫 ，因此該BUG利用不再有效。請注意，VK不會(huì)將WebRTC用于兩方通話，而僅用于群組通話，因此我使用群組通話測試了此BUG利用。該BUG的來源可在此處獲得。 OK and TamTam OK和Tamtam是同一供應(yīng)商（也是Mail.ru）發(fā)布的類似消息傳遞應(yīng)用程序。他們使用動(dòng)態(tài)下載的WebRTC版本，該版本與VK使用的版本相同。由于庫是完全一樣的，因此我的BUG利用也可以正常工作，并且我也不必費(fèi)心測試TamTam，因?yàn)樗侨绱讼嗨啤? **視頻4：https://youtu.be/5ZoYQ9QhUzU 與VK一樣，OK和TamTam在目標(biāo)通過與電話交互應(yīng)答呼叫之前不會(huì)返回SDP應(yīng)答，因此這不是對OK和TamTam的完全遠(yuǎn)程攻擊?！按_定”還要求用戶選擇接受其他用戶的消息，然后該用戶才能呼叫他們。TamTam更為寬松，例如，如果用戶驗(yàn)證了電話號(hào)碼，則擁有其電話號(hào)碼的任何用戶都可以與他們聯(lián)系。 測試于7月13日星期一在OK的20.7.7版本上進(jìn)行。僅SDP測試在TamTam 2.14.0版本上進(jìn)行。從那時(shí)起，這些應(yīng)用程序的服務(wù)器已更新，因此無法使用包含數(shù)據(jù)通道的SDP來發(fā)起呼叫，因此該BUG利用不再起作用。 Discord Discord已徹底記錄了其對WebRTC的使用。應(yīng)用程序?qū)⒅虚g服務(wù)器用于WebRTC連接，這意味著對等方不可能向另一方發(fā)送原始SCTP，而這是利用BUG所必需的。不和諧也需要點(diǎn)擊幾下才能進(jìn)入通話。基于這些原因，不和諧不受本文討論的BUG的影響。 JioChat JioChat是一個(gè)消息傳遞應(yīng)用程序，它允許任何用戶基于電話號(hào)碼呼叫任何其他用戶。分析版本3.2.7.4.0211，它的WebRTC集成似乎同時(shí)包含兩個(gè)BUG，并且應(yīng)用程序在被叫方接受傳入呼叫之前交換SDP提供和應(yīng)答，因此我希望該BUG能夠在沒有用戶交互的情況下起作用。但是，當(dāng)我進(jìn)行測試時(shí)情況并非如此，事實(shí)證明JioChat使用了不同的策略來阻止WebRTC連接開始，直到被叫方接受了呼叫。我能夠輕松繞過該策略，并獲得在JioChat上運(yùn)行的BUG。 **視頻5：https://youtu.be/PC1kIrDeOOA 不幸的是，JioChat的連接延遲策略引入了另一個(gè)BUG，該BUG已得到修復(fù)，但披露期限尚未到期。因此，此博客文章中不會(huì)共享有關(guān)如何繞過它的詳細(xì)信息。沒有此功能的BUG利用源可在此處獲得。JioChat最近更新了其服務(wù)器，因此無法使用包含數(shù)據(jù)通道的SDP來啟動(dòng)呼叫，這意味著該BUG利用不再適用于JioChat。 Slack and ICQ Slack和ICQ相似之處在于它們都集成了WebRTC，但是沒有使用庫的傳輸功能（請注意，Slack并不直接集成WebRTC進(jìn)行音頻呼叫，而是集成了Amazon Chime，后者集成了WebRTC）。他們倆都只使用WebRTC進(jìn)行音頻處理，但實(shí)現(xiàn)了自己的傳輸層，并且不使用WebRTC的RTP和SCTP實(shí)現(xiàn)。因此，他們不容易受到本博客文章中討論的錯(cuò)誤以及許多其他WebRTC錯(cuò)誤的影響。 BOTIM BOTIM具有不尋常的設(shè)計(jì)，可阻止BUG利用。與調(diào)用createOffer和交換SDP不同，每個(gè)對等方基于來自對等方的少量信息生成自己的SDP。默認(rèn)情況下，此應(yīng)用程序不使用SCTP，并且無法使用SDP打開它。因此，不可能使用此BUG。BOTIM看起來確實(shí)有一種模式，它可以與對等方交換SDP，但我不知道如何啟用它。 Other Application 該BUG利用程序在另一個(gè)應(yīng)用程序上以完全遠(yuǎn)程的方式工作，但是對BUG利用程序的設(shè)置顯示該應(yīng)用程序中存在明顯的其他嚴(yán)重BUG。該BUG的披露期限到期后，將釋放該BUG在應(yīng)用程序上的行為的詳細(xì)信息。 DiscussionThe Risk of WebRTC 在分析的14個(gè)應(yīng)用程序中，WebRTC對四個(gè)應(yīng)用程序啟用了完全遠(yuǎn)程利用，而對另外兩個(gè)應(yīng)用程序啟用了一鍵式攻擊。這凸顯了將WebRTC包含在移動(dòng)應(yīng)用程序中的風(fēng)險(xiǎn)。與其他視頻會(huì)議解決方案相比，WebRTC不會(huì)帶來實(shí)質(zhì)性的風(fēng)險(xiǎn)，但在應(yīng)用程序中包含視頻會(huì)議的決定引入了一個(gè)巨大的遠(yuǎn)程攻擊面，否則將不會(huì)出現(xiàn)這種情況。WebRTC是移動(dòng)應(yīng)用程序（通常是Android）中為數(shù)不多的完全遠(yuǎn)程攻擊面之一。在幾乎所有將其用于視頻會(huì)議的應(yīng)用程序中，它可能都是風(fēng)險(xiǎn)最高的組件。 視頻會(huì)議對于某些應(yīng)用程序的功能至關(guān)重要，但在另一些應(yīng)用程序中，它卻是很少使用的“額外功能”。低使用率不會(huì)使視頻會(huì)議對用戶造成任何風(fēng)險(xiǎn)。對于軟件制造商來說，重要的是要考慮視頻會(huì)議是否是其應(yīng)用程序中真正必要的部分，并充分了解視頻會(huì)議給用戶帶來的風(fēng)險(xiǎn)。 WebRTC Patching 這項(xiàng)研究表明，許多應(yīng)用程序在向WebRTC應(yīng)用安全更新方面落后。Bug376在2019年9月被修復(fù)，但在分析的14個(gè)應(yīng)用程序中，只有兩個(gè)修補(bǔ)了它。有幾個(gè)因素導(dǎo)致了這一點(diǎn)。 首先，usrsctp沒有用于識(shí)別和傳達(dá)BUG的正式流程。相反，bug376與其他任何bug一樣已得到修復(fù)，因此該代碼直到2020年3月10日才被引入到WebRTC中。即使在修補(bǔ)之后，這個(gè)bug也沒有在Chrome穩(wěn)定通道的安全提示中被注意到，WebRTC告訴開發(fā)者在這里尋找安全更新。告訴開發(fā)人員尋找安全更新。這意味著，使用舊版本W(wǎng)ebRTC和cherry pick修復(fù)程序的應(yīng)用程序的開發(fā)人員，或者與WebRTC分開包含usrsctp的應(yīng)用程序的開發(fā)人員不會(huì)意識(shí)到需要應(yīng)用此補(bǔ)丁程序。 不過，這還不是全部，因?yàn)樵S多應(yīng)用程序都將WebRTC作為未修改的庫包含在內(nèi)，并且自2020年3月以來，Chrome安全說明中還包含其他WebRTCBUG。另一個(gè)促成因素是，直到2019年，WebRTC都沒有向集成商提供任何安全修補(bǔ)指導(dǎo)，實(shí)際上，他們的網(wǎng)站不準(zhǔn)確地表示，該庫中從未報(bào)告過BUG，這是因?yàn)閃ebRTC安全BUG通常存儲(chǔ)在Chromium錯(cuò)誤跟蹤器中，并且沒有考慮這些BUG對非當(dāng)時(shí)的瀏覽器集成商。我分析的許多應(yīng)用程序都具有早于此的WebRTC版本，因此，此不正確指南的遺留之處很可能仍然導(dǎo)致應(yīng)用程序無法更新WebRTC。盡管WebRTC已經(jīng)做了很多工作，使集成商可以更輕松地修補(bǔ)WebRTC，例如允許大型集成商申請BUG的預(yù)先通知，但集成商仍然有很多人只看到了舊指南。當(dāng)然，如果有更好的指導(dǎo)，也不能保證集成商會(huì)遵循更好的指導(dǎo)，但考慮到長期以來集成商很難知道何時(shí)以及如何更新WebRTC，即使他們愿意，這很可能會(huì)產(chǎn)生影響。 集成商還有責(zé)任使WebRTC保持最新的安全修復(fù)程序，其中許多在此方面都失敗了。令人驚訝的是，看到這么多版本的WebRTC已經(jīng)使用了一年多。開發(fā)人員應(yīng)該監(jiān)視他們集成的每個(gè)庫中的安全更新，并及時(shí)應(yīng)用它們。 Application Design 應(yīng)用程序設(shè)計(jì)會(huì)影響WebRTC帶來的風(fēng)險(xiǎn)，并且對許多研究的應(yīng)用程序進(jìn)行了精心設(shè)計(jì)。限制WebRTC的安全影響的最簡單，最重要的方法是，在被叫方通過與設(shè)備進(jìn)行交互來接受呼叫之前，避免啟動(dòng)WebRTC連接。這會(huì)將可能迅速危害任何用戶的攻擊轉(zhuǎn)化為需要用戶交互的攻擊，并且不會(huì)在每個(gè)目標(biāo)上都成功。這也使得質(zhì)量較低的BUG實(shí)際上不可利用，因?yàn)殡m然完全遠(yuǎn)程攻擊可以多次嘗試而用戶不會(huì)注意到，但需要用戶應(yīng)答呼叫的攻擊需要嘗試少量嘗試。 延遲啟動(dòng)WebRTC連接會(huì)影響性能，并且會(huì)妨礙或排除某些功能，例如為被呼叫者提供呼叫預(yù)覽。該BUG利用的應(yīng)用程序中，有兩個(gè)在沒有用戶交互的情況下啟動(dòng)了連接，還有兩個(gè)需要用戶交互。JioChat和我們尚未確定的應(yīng)用程序試圖使用獨(dú)特的技巧來延遲連接，直到用戶接受呼叫為止，而不會(huì)影響性能，但結(jié)果引入了BUG。開發(fā)人員應(yīng)該知道，延遲WebRTC連接的最佳方法是避免在用戶接受調(diào)用之前調(diào)用setRemoteDescription。其他方法可能實(shí)際上不會(huì)延遲連接，并可能導(dǎo)致其他安全問題。 降低WebRTC安全風(fēng)險(xiǎn)的另一種方法是限制攻擊者可以呼叫的人，例如，要求被呼叫方在其聯(lián)系人列表中包含該用戶，或者只允許同意在應(yīng)用程序中互相發(fā)送消息的用戶之間進(jìn)行呼叫。就像延遲連接一樣，這大大減少了攻擊者不費(fèi)吹灰之力就能到達(dá)的目標(biāo)。 最后，集成商應(yīng)將攻擊者可以使用的WebRTC功能限制為應(yīng)用程序所需的功能。許多應(yīng)用程序不容易受到此特定攻擊的影響，因?yàn)樗鼈円延行Ы昧薙CTP。其他人沒有使用SCTP，但是沒有以阻止攻擊者使用它的方式禁用它，而我能夠啟用它。禁用WebRTC中功能的最好方法是在編譯時(shí)將其刪除，某些編解碼器支持此功能。也可以通過PeerConnection和PeerConnectionFactory禁用某些功能，這也非常有效。特性也可以通過過濾SDP來禁用，但重要的是要確保過濾器是健壯的并經(jīng)過徹底測試。 Conclusion 我為Android的WebRTC編寫了一個(gè)BUG攻擊，涉及usrsctp中的兩個(gè)BUG。這個(gè)BUG在Signal、googleduo、JioChat和另一個(gè)應(yīng)用程序上是完全遠(yuǎn)程的，需要用戶在VK、OK和TamTam上進(jìn)行交互。其他休閑包沒有受到影響，因?yàn)樗麄冇行У亟昧薙CTP。多個(gè)應(yīng)用程序使用的WebRTC版本不包含針對BUG利用的任何BUG的修補(bǔ)程序。一個(gè)仍未修補(bǔ)。補(bǔ)丁程序吸收率低的部分原因是WebRTC歷史上提供的補(bǔ)丁程序指導(dǎo)不力。集成商可以通過要求用戶交互來啟動(dòng)WebRTC連接，限制用戶可以輕松調(diào)用的用戶并禁用未使用的功能來降低WebRTC的風(fēng)險(xiǎn)。他們還應(yīng)該考慮視頻會(huì)議是否是其應(yīng)用程序的重要和必要功能。 Vendor Response 在這篇博客文章中提到的軟件供應(yīng)商在這篇文章公開發(fā)布之前被給予了一個(gè)審閱的機(jī)會(huì)，并提供了一些回復(fù)，如下： WebRTC 修復(fù)了用于繞過ASLR和移動(dòng)指令指針的WebRTC錯(cuò)誤。WebRTC不再直接將SctpTransport指針傳遞到usrsctp，而是使用映射到SctpTransport的不透明標(biāo)識(shí)符，而忽略無效值。我們已經(jīng)識(shí)別并修補(bǔ)了每一個(gè)受影響的Google產(chǎn)品，并使用WebRTC聯(lián)系了50個(gè)應(yīng)用程序和集成商，包括本文分析的所有應(yīng)用程序。對于所有尚未修補(bǔ)該BUG的應(yīng)用程序和集成器，我們建議更新到WebRTC M85分支，或修補(bǔ)以下兩個(gè)問題。 Mail.ru 用戶安全是所有Mail.ru G集團(tuán)的產(chǎn)品（包括VK，OK，TamTam等產(chǎn)品）的最高優(yōu)先事項(xiàng)。根據(jù)我們收到的有關(guān)BUG的信息，我們立即開始將移動(dòng)應(yīng)用程序更新為最新版本的WebRTC的過程。此更新當(dāng)前正在進(jìn)行中。我們還在我們的服務(wù)器上實(shí)現(xiàn)了算法，不再允許在我們的產(chǎn)品中利用此BUG。此操作使我們能夠在收到利用BUG演示的信息后3小時(shí)內(nèi)為所有用戶修復(fù)該問題。 Signal 我們感謝在發(fā)現(xiàn)這些BUG和改進(jìn)WebRTC生態(tài)系統(tǒng)安全性方面所做的努力。Signal在被發(fā)現(xiàn)之前已經(jīng)發(fā)布了一個(gè)防御補(bǔ)丁來保護(hù)用戶免受此攻擊。除了對調(diào)用庫進(jìn)行例行更新外，我們還將繼續(xù)采取主動(dòng)措施，以減輕未來WebRTC錯(cuò)誤的影響。 Slack 我們很高興看到這份報(bào)告得出結(jié)論，Slack不受引用的WebRTC BUG和BUG攻擊的影響。在了解到這一風(fēng)險(xiǎn)后，我們進(jìn)行了額外的調(diào)查，并確認(rèn)我們的整個(gè)呼叫服務(wù)沒有受到此處描述的BUG和調(diào)查結(jié)果的影響。

原文標(biāo)題：使用WebRTC開發(fā)Android Messenger：第3部分

文章出處：【微信公眾號(hào)：LiveVideoStack】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。