經銷商專區｜登入
〔最新消息〕2020-11-24
Facebook修補了Messenger音訊窺探的BUG--馬上更新!
現代電話充滿了不合時宜的東西。
例如，我們仍然在 "撥號 "打電話，許多電話應用在等待另一端的人接電話時仍然會顯示 "撥號 "一詞。
但你最後一次看到，更不用說使用，真正有鍵盤的手機是什麼時候？
而且我們還在用 "掛斷電話"這樣的成語來形容我們似乎從未停止過接聽電話的日子，儘管家用電話從1912年起就沒有真正意義上的掛鉤，你可能要去博物館才能看到。
當然，鉤子並不是早期電話系統的必要組成部分--在交換機中，電話是通過插孔插頭進行切換的--但當更換或取下接收器時，一個重力操作的開關就會啟動，這是一個聰明的使用者介面選擇。
當你在通話結束後不再使用時，你需要一個地方來存放接收機，所以提供一個地方把它掛起來，同時把接收機與電路斷開，是一個聰明的設計決定--掛在鉤子上就意味著自動脫離電路。
|
在不使用時，實際上將接收器與電路斷開是很重要的。在單線連接中，讓接收機斷線，可防止其他任何人使用該電路，因此會佔用交換機中的一條線路。在單線連接中，如果有幾戶人家的電話同時處於斷線狀態（即電路中），那麼共用電路上的額外電力負荷將使每個人的振鈴器無法工作，交換機將無法將電話接通給任何人。 |
誰在聽 ？
你可能知道，行動語音訊息不再依靠這種 "電路切換 "的方式了。
例如，當你撥打Messenger電話時，你設備上的應用--可能是手機、筆記型電腦，甚至是智慧電視之類的東西--會要求Messenger雲端定位收件人的設備，兩端的應用開始協商建立通話。
一旦通話被收件人接受--通常是在應用播放了鈴聲、彈出了資訊或兩者都有之後，收件人選擇了通話--然後應用開始交換音訊資料的網路資料包。
每一端的應用都會從自己的麥克風中採樣音訊資料，並分塊發送給另一端；同時，它將從另一端接收到的音訊塊，重新拼接起來，並從自己的耳機或揚聲器中播放出來。
如果網路速度很慢或者不可靠，應用一般不會放棄通話，但會盡最大努力還是進行下去，要麼在音訊中留下無聲的空隙，要麼在短暫中斷的情況下進行猜測（這就是典型的網路語音通話中聽到聲音rrrrrepe-ee-ee-e-e不自然的情況），要麼回落到較低的、發擦刮聲的品質。
換句話說，在兩部互聯網電話之間沒有實際的電路被打開或關閉，就像連接到同一交換器的兩部老式固定電話之間一樣。
同樣，如果應用程式有一個靜音按鈕，它不會通過斷開設備中的麥克風電連接來工作。
兩端的應用程式根據網路上分塊發送和接收的資料，決定什麼時候發起連接，以期建立通話；什麼時候響起鈴聲，發出來電信號；什麼時候可以開始錄音和轉播聲音；什麼時候靜音；什麼時候停止交換資料，從而 "掛斷 "通話，斷開虛擬語音回路。
你可能可以想像，這裡有很多可能出錯的地方。
例如，一個惡意的語音應用可能會故意錄製和傳輸聲音，同時故意假裝沒有聲音，比如在等待你開始撥號的時候。
或者一個合法但有漏洞的應用程式可能會在你預期之前就開始傳輸聲音，雖然無辜但也不至於漏網之魚。
畢竟，沒有任何接收器可以掛斷，也沒有物理開關，從字面上將你接入連接到另一端的專用電路中。
事實上，當通話鈴聲響起的時候，兩端的應用已經在相互通信，所以從技術上講，它們此時是可以交換語音資料的。
你只是假設在兩端都沒有交換和確認控制資訊，確認每一方同意通話之前，兩端都不會開始傳輸。
通常情況下，主叫方首先通過 "撥號 "來默示和主動地同意通話；而接收方則通過點擊[接聽]（或點擊一個圖示，顯示一個假想的接收器被從假想的鉤子上吊起）來明確和反應地同意通話。
在這之前，雙方都要假設兩端的應用處於 "還沒有相互呼叫同意 "的模式，因此既不收集也不傳輸任何音訊資料。
如果有bug怎麼辦 ？
但如果有BUG呢？
如果一個語音通話應用過早地假設兩端同意怎麼辦？
不幸的是，Facebook剛剛在其Android上的Messenger應用中修復了一個這樣的bug。這個bug是在一個月前發現的，並由穀歌的Project Zero負責任地披露。在Facebook修復並更新了該漏洞後，Google在本周披露了該漏洞。
非常明確的是：沒有任何跡象表明這是一個軟體漏洞以外的東西；似乎這個漏洞在修復的時候只有Google和Facebook知道；也沒有證據表明這個漏洞曾經被利用過，甚至在現實生活中被攻擊者知道。
換句話說，這並不是一個零日漏洞，是駭客先發現的，所以如果你確保你的安卓系統上已經有了最新版本的Messenger，那麼您應該領先於那些可能成為網絡犯罪分子的地方爭先恐後找出錯誤。
我們不知道哪些舊版本的應用存在漏洞，但Google向公眾開放其錯誤報告的日期與最新版本的發佈日期相吻合[在2020-11-20T15:00Z]，該版本似乎編號為291.0.0.20.114，於2020-11-17發佈。
Google最初的bug報告中包含了PoC（概念證明）代碼，以證明該bug可以被利用，Google表示該bug工作在284.0.0.16.119版本的應用上。
錯誤的工作方式
大大簡化了，這個bug涉及到攻擊者在你的電話還在響起的時候，偷偷向你手機上的應用程式發送一個意外的、額外的控制資訊。
這條控制資訊基本上是說 "用戶已經同意通話"，從而欺騙你手機上的應用，讓它以為你在接聽電話之前就已經接聽了（或者即使你沒有接聽）。
換句話說，這個bug有效地讓來電者假裝你已經點擊接受了電話，而你的手機顯示幕還在詢問你是否要接受電話。
所以，在那決定性的幾秒鐘裡，當你看著你的手機，決定是否接受這個電話的時候--誰沒有在和可怕的姑姑說話或者與前任男女朋友面對面之前，放出一些選擇的話語來支撐自己呢？- 您可能已經在另一端大聲疾呼了。
好消息，據我們從Google的報告中可以看出的是。
● 這個錯誤不能被觸發 隱形或任意。攻擊者必須嘗試給你打電話，並且只會在電話在你那頭響起的時候，得到你可能說的話的 "偷偷預覽"。所以我們認為這個技巧不容易被用於長期監控或竊聽。
● PoC漏洞要求你在應用宣佈來電的同時，在流覽器中登錄Facebook。如果你有在不使用帳戶時在瀏覽器中登出的習慣，或者如果你只在手機上使用Facebook，聽起來這個bug很難或不可能用來對付你。
然而...
…儘早修補，經常修補，是嗎？
(如果有疑問，不要說出來！)
原文網址
