TikTok漏洞引發(fā)數(shù)據(jù)和隱私泄露

作者：ang010ela 2021-01-28 11:16:28

Check Point研究人員在TikTok移動客戶端中發(fā)現(xiàn)了一個安全漏洞，攻擊者利用該漏洞可以竊取用戶個人簡介和綁定的手機號，用于下一步的攻擊活動。

Check Point研究人員在TikTok中發(fā)現(xiàn)了一個安全漏洞，攻擊者利用該漏洞可以竊取用戶個人簡介和綁定的手機號，用于下一步的攻擊活動。

1月26日，Check Point研究人員發(fā)布文章稱發(fā)現(xiàn)了TikTok移動客戶端friend finder特征中的一個安全漏洞。攻擊者利用該漏洞可以將個人簡介信息與手機號就行關(guān)聯(lián)，攻擊者成功利用該漏洞可以建立一個用戶與相關(guān)手機號的數(shù)據(jù)庫。漏洞影響綁定了手機號或以手機號登陸的用戶。

[[378970]]

Syncing Contacts聯(lián)系人同步特征

TikTok移動客戶端允許進行聯(lián)系人同步，也就是說用戶可以同步聯(lián)系人到更容易發(fā)現(xiàn)注冊了TikTok的朋友。同步過程有2個請求組成：

上傳聯(lián)系人;
同步聯(lián)系人。

TikTok漏洞引發(fā)數(shù)據(jù)和隱私泄露

對用戶通訊錄中的每個聯(lián)系人，TikTok都會構(gòu)建一個包含以下3個屬性的JSON：

Invited – “False”.
Name – 使用SHA 256算法哈希的值;
Phone number – 使用SHA 256算法哈希的值。

TikTok漏洞引發(fā)數(shù)據(jù)和隱私泄露

將JSON加入列表中，繼續(xù)上傳通訊錄：

TikTok使用到https://api16-normal-c-alisg.tiktokv.com/aweme/v1/upload/hashcontacts 的HTTP請求來上傳聯(lián)系人。聯(lián)系人會以contact 參數(shù)中的JSON 列表發(fā)送。

比如，單個聯(lián)系人如下：

Name: Testing Tester
Phone number: +972555555555

TikTok會發(fā)送以下JSON 列表作為contact參數(shù)的值：

上傳聯(lián)系人到TikTok服務(wù)器的完整HTTP 請求如下所示：

同步聯(lián)系人

上傳聯(lián)系人請求完成后，TikTok移動客戶端就會發(fā)送一個sync 同步請求來提取所有與發(fā)送的手機號關(guān)聯(lián)的個人簡介。

發(fā)送到 https://api16-normal-c-alisg.tiktokv.com/aweme/v1/social/friend 的HTTP請求如下所示：

應(yīng)用服務(wù)器響應(yīng)含有個人簡介列表、哈希的手機號、個人名字、唯一id、個人簡介照片、個人簡介特征等。

限制

上傳和同步聯(lián)系人請求每天、每用戶、每個設(shè)備限制在500個以內(nèi)。

研究問題

單個用戶查詢TikTok數(shù)據(jù)庫是否會引發(fā)隱私問題?

(1) Step 1 – 創(chuàng)建設(shè)備列表(注冊物理設(shè)備)

每次啟動后，TikTok移動客戶端都會執(zhí)行設(shè)備注冊過程來確保用戶沒有在設(shè)備之間進行切換。設(shè)備注冊的過程是用到https://log-va.tiktokv.com/service/2/device_register 的請求來完成的：

根據(jù)HTTP請求中發(fā)送的數(shù)據(jù)，應(yīng)用服務(wù)器會生成一個唯一的device_id token。該token是強制的，并且會應(yīng)用生成的每個API請求一起發(fā)送給應(yīng)用服務(wù)器。

(2) Step 2 – 創(chuàng)建不過期的session token列表

通過SMS登陸只能通過物理設(shè)備來進行，是通過發(fā)送給https://api16-normal-c-alisg.tiktokv.com/passport/mobile/sms_login_only 的HTTP 請求來實現(xiàn)的。請求的body部分包含有手機號和一次性驗證碼編碼的參數(shù)。

TikTok漏洞引發(fā)數(shù)據(jù)和隱私泄露

服務(wù)器會驗證數(shù)據(jù)，并生成唯一的X-Tt-Token token。此外，服務(wù)器還會設(shè)置會話的cookie。

研究人員分析發(fā)現(xiàn)會話cookie和X-Tt-Token 值的過期時間都是60天，也就是說8周內(nèi)使用的cookie都是相同的。

TikTok HTTP消息簽名

研究人員抓取了TikTok的HTTP 請求發(fā)現(xiàn)，TikTok移動客戶端使用了消息簽名機制來語法攻擊者修改消息和請求的body部分。

消息簽名機制要求服務(wù)器驗證的X-Gorgon 和X-Khronos header，否則數(shù)據(jù)不能被請求。

(3) Step 3 – 繞過TikTok HTTP 消息簽名

在擁有了device_id和X-Tt-Token token，以及2個月都不會過期的cookie后，就可以使用虛擬設(shè)備來替代真實的物理設(shè)備了。

研究人員在測試張使用了運行安卓6.0.1的Genymotion 模擬器，并安裝了TikTok移動客戶端。

研究人員進行動態(tài)分析發(fā)現(xiàn)TikTok移動客戶端在后臺會執(zhí)行一個消息簽名的服務(wù)。簽名服務(wù)是com.bytedance.frameworks.baselib.network.http 包的一部分。

簽名過程首先是一個一個方法開始：

攻擊者可以使用Frida這樣的動態(tài)分析框架來hook函數(shù)，修改函數(shù)的參數(shù)數(shù)據(jù)，然后對請求進行重新簽名。因此，攻擊者可以使用該服務(wù)來對修改后的請求進行簽名，創(chuàng)建更新的X-Gorgon和 X-Khronos header值，并發(fā)送修改后的請求到TikTok應(yīng)用服務(wù)器。

PoC

有了以上能力，就可以修改HTTP請求和對請求重新進行簽名。研究人員寫了一個Frida腳本來自動進行消息重新簽名的過程，具體如下：

啟動HTTP 服務(wù)器，監(jiān)聽4000 端口：