這是一個由三部分組成的系列文章，內容涉及：利用WebRTC中的BUG和利用Messenger應用程序。本系列文章重點闡述了當應用程序不能應用于WebRTC補丁程序以及通信和安全問題通知中斷時可能出問題的方面。

文 /Natalie Silvanovich

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

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

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

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

原文標題：使用WebRTC開發Android Messenger：第3部分

文章出處：【微信公眾號：LiveVideoStack】歡迎添加關注！文章轉載請注明出處。