作者：Shubham Shah，澳大利亞安全研究人員，專注于程序開發、滲透測試和黑客技術。2016年初被安全媒體評為10大著名“漏洞賞金獵人”之一。本文原名《高效漏洞挖掘：120天120個漏洞》
2016年初，我就給自己設定了一個目標：在這一年中，平均每天挖掘出一個漏洞。這個決定完全是一種自我挑戰。我想回到過去在Atlassian公司時候的狀態，當時，我曾經在一個月內每天都發現了一個漏洞，這些漏洞涉及Atlassian公司所有外部程序。
1 挖洞計劃介紹&動機
1月初，我就積極準備進行我的高效漏洞挖掘計劃，剛開始，我曾在一天之內發現了多個漏洞，然而，隨著時間的推進，我覺得在一天之內找到多個漏洞是件非常耗費腦細胞的事，而且在挖洞過程中，我經常感到身心疲憊。
最終，經過120天之后，我結束了這種“日均一洞”的計劃。但是，我對自己在漏洞挖掘方面多少有了些體會：
（1）尋找一些新的意想不到的技術方式去拿下目標
（2）把關注重點放在那些自己感興趣的漏洞上面
（3）通過漏洞獎勵平臺結交從事安全研究的朋友或同齡群體
2 我發現的漏洞
以下就是我在120天之內挖掘的121個漏洞列表一覽：（全部漏洞請參看博客 Table1)
3 分析
以下統計表是對我發現的121個漏洞的大致分類，另外，還有一些雜項漏洞沒有包含在內
出于漏洞獎勵平臺的工作機制，很多提交漏洞可能還處于緩解開發或保密階段。待所有漏洞被修復公開之后，我會繼續更新這些信息。
4 方法論
圍繞信息系統實體進行漏洞挖掘
“資產”實體可以定義為信息系統的所有組成項，包括：應用程序、目錄、文件、文件夾、可執行程序或服務器。當然，也包含大多數云平臺服務，如VoIP、文件共享、網絡會議等。
對“資產”實體的信息收集，是一個非常有趣的過程。例如，當我正對一家公司使用的軟件開發組件進行信息收集時，碰巧，該公司的某位開發人員在1 小時之前就不小心把這些組件都上傳到網上了，哎呀，對我來說，這是多么美妙的事情?。?/p>
編寫自己的漏洞挖掘工具
為了保持每天挖掘一個漏洞的節奏，我需要更好的信息系統識別工具，畢竟，想要在一些漏洞獎勵項目中發現漏洞已經變得越來越難了，想要獲得高額獎勵更是難上加難。
為此，我和朋友Nathan Wakelam就信息系統的識別方法進行了一些討論。最終，我們一起編寫了三個相關工具：
Altdns: 通過域名前綴序列變化和排列發現子域名的工具
Assetnote: 通過監視跟蹤被動API數據發現子域名
Bugbounty Dash: 顯示漏洞獎勵項目當前的狀態信息
目前，Altdns已經獲得了同行的一些認可。
與值得信任的安全研究人員一起工作
我覺得有效的漏洞挖掘還需要一些外部氛圍，如果條件允許，可以與那些值得信任的安全研究人員或漏洞挖掘者一起工作。畢竟，擁有一個同路的伙伴會讓你覺得有動力。我非常有幸加入了一群出色的漏洞挖掘者當中，他們有我的同事和好朋友。當我處于挖洞瓶頸期的時候，我身邊參與漏洞項目的朋友會和我分享他們的新方法和新思路，這能讓我繼續充滿信心。當其它人發現了一些我所不能發現的漏洞，我都把這當成是一種激發自己學習的動力。還有就是，不要把共同參與漏洞獎勵項目的同事和朋友當做競爭對手，否則，你永遠都得不到進步。
提高漏洞發現視角
有時候，應該學著把漏洞發現視角提高到更高、更廣的水平。我知道有一些研究人員就是這樣做的，如@phwd，他甚至通過參加FACEBOOK的產品發布會，以了解更多關于FACEBOOK的信息。@phwd在參與FACEBOOK漏洞獎勵項目中的成功，是我所不能及的，這也決非偶然。
找到在漏洞挖掘之外可以釋放壓力的方法或愛好
我覺得，應該在信息安全或漏洞挖掘之外，找到一個可以釋放壓力的方法或愛好。對我自己來說，漏洞挖掘是一個極度深入內心的愛好，每當我忽略了生活中的一些重要部分之后，我就發現自己并不開心。因為熱愛過度，陷入太深，有時候我覺得自己已經走火入魔了，如果能有一些東西能讓我暫時脫離漏洞挖掘工作，即便是一種簡單的愛好或者曾經的美好時光，我也愿意。
5 建議
計劃一個切實可行的目標
我是從2016年1月開始我的“高效挖洞計劃”的，在堅持了兩個月左右的“一天一洞”節奏后，我遇到了第一個倦怠期。我犯的最大錯誤是沒有完全理解漏洞發現過程的波動性，從黑盒測試的角度來看，未被發現的漏洞是不可量化的，而我自己也不能很好的判斷發現漏洞的可能性。在120天的時間里，我曾三次到達了瓶頸期。我每天如果不能按計劃發現一個漏洞，情況就會變得更糟；如果在10天之內，我還沒有發現一個漏洞，就意味著我必須在一天之內找到10個漏洞。這個計劃讓我放棄的主要原因在于不斷累積的壓力。
我支持你嘗試這樣的高效漏洞挖掘計劃，只是不要和我犯同樣的錯誤–“每天發現一個漏洞”。請你放輕松，制訂一個切實可行的目標，而不是陷入惡性循環。
保持心態平和
當你在提交了漏洞之后，你就沒有了真正的漏洞處置權。因為，對于漏洞獎勵平臺來說，這就是一個買方市場。如果一個項目沒有達到你所期望的漏洞獎勵，就不要參與這個項目。另外，請記住，沒有什么神人愿意出高價來收買你的漏洞，或者讓你成為黑客新聞頭條，也沒有什么所謂的“漏洞賞金獵人”聯盟或黑市愿意為你的漏洞買單?；驹瓌t是，我們只是付出有效腦力勞動去獲取該得報酬的合同工而已，我們的委托公司客戶可能是偉大牛逼的，也可能是極不友好的，這就是漏洞獎勵平臺和商業市場的本質。
如果在參與漏洞獎勵項目中，你認為沒有得到你該得的報酬，并且和你提交漏洞的公司有一些內部分歧。我建議你看看這兩篇關于漏洞獎勵的博文《我是如何成為一個成功的漏洞賞金獵手》、《5年漏洞獎勵平臺記錄和感想》，或許你可以從中得到一些新的觀點和想法。
加入那些友好而熱情的漏洞獎勵項目
找到并加入那些對待漏洞研究者非常友好的項目，這些項目把漏洞研究人員當成他們自己安全團隊的一部份。他們給你的回復很及時，報酬很慷慨，并且互相之間很尊重。
以上就是我對自己“高效漏洞挖掘”計劃的一些觀點，很樂意和大家分享，也希望大家提出一些意見或建議。
6 值得關注的漏洞1：二級域名/網頁劫持
根據漏洞獎勵平臺上的一部分漏洞為樣本，我發現子域名接管或劫持漏洞的獎勵范圍比較大，可以從 $100 到 $7,500不等。這雖然不可思議，但可能是一些公司在漏洞嚴重程度上有著很大的不同對比。幸運的是，我曾在一個邀請的漏洞眾測項目發現過子域名劫持漏洞，并且獲得了高達$7,500的獎勵。這個項目為大多數有效漏洞支付了高額的獎金，他們努力修復漏洞并給予子域名漏洞提交者慷慨的獎勵。因此，在六個月之后，想找出其子域名劫持漏洞已經變得很難。這就是漏洞獎勵平臺的作用。
然而，作為一名安全研究者，當你不能找到一種方式來對子域名進行劫持時，你會怎么做？這就是二級子域名劫持該發揮作用的時候了。Web應用程序非常復雜，它可以加載10多個主機發起的應用和不計其數的請求內容。例如，我們可以在wufoo.com類型中嵌入框架或者在Amazon S3 中嵌入JavaScript。有更多關于動態內容通過網頁嵌入第三方源的例子，我的大多數子域名劫持漏洞的成功發現都是與wufoo和S3形式相關。
（Wufoo是一個網站應用程序。Wufoo主要幫助人們創建獨特的在線表格。 在使用這個Wufoo應用程序設計表格的時候，它會自動生成數據庫，后端和腳本，以便用戶收集和輕松地理解數據。）
假想一下導致二級域名被劫持的情況：假如你在X公司工作，這家公司已經成立了10多年，并且最近開始了一項漏洞獎勵項目。隨著X公司各方面不斷的發展壯大，在過去的10多年間，其相關網站的CMS系統也創建了大量網頁。如果這家公司的網站曾經通過第三方URL的 <script> , <iframe>,
這里有一個快速判斷方法：
（1）創建你的目標網站URL列表（保證盡可能的全覆蓋，可以用爬蟲方法遍歷所有子域名）；
（2） 對每個URL發起請求，并尋找<script>, <iframe>,
（3） 確保在上面元素標簽中找到的所有鏈接仍然有效。如果存在任何無效或過期的資源，請嘗試注冊并運用它們。
在另外一個漏洞獎勵項目中，我發現了很多內嵌框架類似
6 值得關注的漏洞2：DOM Based XSS via subtitle tracks
在另外一個邀請的漏洞眾測項目中，其中的一個宣傳功能是允許用戶為一個預先設置好的視頻自行制作字幕。它位于以下鏈接當中
http://subdomain.privatebounty.com/en/event/community.html
當訪問這個鏈接，會顯示很多輸入框。在這些輸入框中，用戶可以插入他們自己的字幕信息。一旦用戶輸入完字幕，點擊執行按鈕，字幕文件就被發送至位于遠端云平臺上的 API中。
由客戶端發起的發送字幕文件到API接口的請求如下：
遠端云平臺API對以上請求的回應如下：
通過流量觀察，我嘗試去發現“”user-generated”視頻請求信息：
后經發現，API對字幕文件的回應是明文信息。雖然不能通過終端獲得持久XSS漏洞，但可以在輸入的字幕文件中插入任意代碼文件。例如，對于下面的URL請求，在返回字幕信息中可以包含任意JavaScript執行代碼：
http://apisubdomain.privatebounty.com/api/v1/usersubs/60d499118de429510449.srt
一旦這個SRT字幕文件已經由API生成，我們可以訪問下面這個鏈接觀看由用戶自定義字幕的視頻：
http://subdomain.privatebounty.com/event/community.html?slug=60d499118de429510449
上面鏈接中存在一個JavaScript腳本：
http://subdomain.privatebounty.com/events/scripts/shared-app.js
它在網頁運行中通過slug ID標識為網頁多媒體播放器獲取并設置字幕文件。負責設置字幕的代碼可以在下面找到：
所以，一旦在字幕文件中插入惡意代碼，通過上面JavaScript腳本的運行，惡意字幕文件就可以從以下鏈接加載并注入到受害者的DOM模型中。
http://apisubdomain.privatebounty.com/api/v1/usersubs/60d499118de429510449.srt
由于字幕文件通過SRT文件格式工作，在將它們添加到DOM之前，多媒體播放器默認情況下不會對它們進行審查。這意味著，每一行字幕文件都可以被添加到DOM中（包括攻擊者腳本）。雖然HTML在此表現出了重要的可用性，但也帶來了安全問題。
當視頻播放時，SRT文件中的JavaScript代碼就會執行：
我認為有兩種方式可以修復這個漏洞：
（1） 審查所有的用戶的字幕文件輸入，不只是API的響應數據；
（2） 確保多媒體播放器不被插入HTML DOM的惡意字幕文件。參照
該漏洞在每個支持HTML5
最終，我的高效挖洞計劃算是成功的嗎？我想應該是的，至少我賺了錢，得到了樂趣，提高了技術能力，還加入了優秀的技術團隊。雖然最終我輸給了身心疲憊，但我總算了解了自己的極限。
*本文譯者：clouds，參考來源：shubs.io ，轉載須注明來自FreeBuf.COM
</script>
京公網安備 11010502049343號