在參與Twitter漏洞賞金項目的過程中，我通過一些安全測試發(fā)現(xiàn)了Twitter存在的重大漏洞：攻擊者不需要獲取他人賬戶權限，就能以任意賬戶發(fā)布推文。我于2017年2月26日發(fā)現(xiàn)了該漏洞，Twitter方面于2017年2月28日及時對其進行了修復（參考Hackerone），并最終向我獎勵了$7560美元漏洞賞金。我們一起來看看該漏洞細節(jié)：
簡介
Twitter Ads最早為向企業(yè)開放的廣告服務平臺，為了擴大自媒體廣告業(yè)務，Twitter Ads于2013年5月1日向所有美國用戶免費開放，用戶可以通過https://ads.twitter.com/注冊個人廣告業(yè)務，實現(xiàn)推文（Tweet）推廣、競價排行、個性化定制等個人廣告宣傳。Twitter Ads服務中包含了一個多媒體庫，注冊用戶可以向該庫上傳個人廣告相關的視頻、圖片、GIF動圖等多媒體文件，另外，用戶在發(fā)布推文之前也能對這些文件進行審核。該多媒體庫存在以下鏈接中：
https://ads.twitter.com/accounts/*id_of_your_account*/media
前期試探
如果你是Twitter Ads注冊用戶，用以上鏈接登入多媒體庫后會發(fā)現(xiàn)其多媒體文件上傳功能：

我們點擊右上角的媒體文件下載按鈕Download media-file（Загрузить медиа-файл），選擇某一上傳圖片文件后，會顯示相應的已經(jīng)上傳的圖片：

點擊該圖片放大，請注意查看上圖中顯示的功能，將出現(xiàn)以下情景：

1、我們可以推送發(fā)布該多媒體文件
2、我們可以與任何用戶分享該多媒體文件
通過BurpSuit抓包具體分析一下該推文布動作的相關功能：

可以發(fā)現(xiàn)網(wǎng)絡請求包中包含以下參數(shù)：
account_id：賬戶ID，為已登錄入庫的賬戶ID；
owner_id：圖片文件所有者ID；
user_id：推文分享用戶的ID；
media_key：媒體文件發(fā)布ID，如下圖的地址欄URL后部分數(shù)字：

接下來，讓我們來定義一些相關的測試標識：
我的第一個測試賬號：account №1
我的第二個測試賬號：account №2
由于我不記得錯誤輸出的確切語句，所以我們暫且把兩個賬號對應的錯誤輸出定義為error №1、error №2。
漏洞發(fā)現(xiàn)
首先，我攔截監(jiān)聽了推文發(fā)布的網(wǎng)絡請求信息，并嘗試進行以下參數(shù)更改：
基于json的GET請求owner_id和user_id，在POST方式下，被設置從account №1發(fā)往對應的account №2處，此時，發(fā)生了錯誤error №1；
之后，我嘗試在POST包中更改owner_id和user_id，又出現(xiàn)了錯誤error №2，我記得當時的錯誤提示是這樣的：
作為替代*的，owner_id為*id的用戶，并不是該多媒體文件的所有者，*這里應該是一個media_key*
我想，既然這樣，那我們作出如下更改：
我使用account №2登錄ads.twitter.com，進入媒體庫，上傳圖片，以提前讓Twitter解析出media_key的值。
舉一反三
我們回到account №1登錄狀態(tài)：
攔截監(jiān)聽推文發(fā)布的網(wǎng)絡請求信息，針對推文接收方account №2，我們對GET方式和POST請求中的owner_id和user_id作出相應更改，同時使用了之前知道的media_key值，之后，將會得到錯誤error №1，盡管如此，但在對owner_id和user_id的更改替換中，僅只出現(xiàn)了一種錯誤error №1；而僅在POST方式中對owner_id和user_id作出更改替換，會出現(xiàn)另一種錯誤error №2。那我們再試試其它的？
終于，在POST請求中對owner_id、user_id和media_key作出一系列更改替換之后，響應信息提示我們嘗試的推文發(fā)布動作成功執(zhí)行！對于account №2賬戶來說，可以發(fā)現(xiàn)盡管該賬戶本身沒有執(zhí)行任何推文發(fā)布動作，但其實以其身份和相應media_key的上傳圖片已被account №1當成推文發(fā)送出去了！
漏洞探索
好了，現(xiàn)在，我們可以以任意用戶賬戶身份發(fā)布推文了，但同時也存在一些可能會消弱漏洞嚴重性的限制條件：我們用來發(fā)布推文的受害者用戶必須具有一個已經(jīng)上傳的多媒體文件，而且，還需要知道這個多媒體文件的media_key，但由于media_key包含18位數(shù)字，一般來說，很難通過暴力猜解或其它方式知曉該數(shù)值，media_key值的獲取存在一定限制性難度。
難道這就歇菜了嗎？就這樣向Twitter上報該漏洞？再想想看！我個人感覺該漏洞可能非常嚴重，想想看，還記得之前可以對任何用戶分享該媒體文件的情況嗎？我想到了一個非常有趣的點子：如果我們向受害者用戶（即用他的賬戶發(fā)送推文）分享我們的多媒體文件，那么此時，該受害者用戶也將被視為是這個多媒體文件的所有者， 錯誤error №2情況也將不會發(fā)生，而以該賬戶身份發(fā)送的推文也能成功發(fā)布！經(jīng)過測試證明，該情景確實能成功實現(xiàn)！
綜合以上場景可知，其實對該漏洞的成功利用并不需要media_key的值，當然，如果我們是多媒體文件的所有者，當然也就知道m(xù)edia_key值了。
最終，可以總結(jié)出以下漏洞利用的實現(xiàn)條件：
1、我們上傳自己的多媒體文件；
2、向受害者用戶（推文發(fā)布用戶）分享該多媒體文件；
3、攔截監(jiān)聽向受害者用戶發(fā)起的推文發(fā)布網(wǎng)絡請求信息，并對owner_id和user_id值進行修改，；
4、之后，就可以接收到以受害者用戶身份成功發(fā)布推文的響應信息。
5、利用該漏洞盡情玩耍吧！
好了，可以安心地向Twitter上報漏洞并等待漏洞賞金了！