作者：Shubham Shah，澳大利亞安全研究人員，專注於程式開發、滲透測試和黑客技術。2016年初被安全媒體評為10大著名“漏洞賞金獵人”之一。本文原名《高效漏洞挖掘：120天120個漏洞》

2016年初，我就給自己設定了一個目標：在這一年中，平均每天挖掘出一個漏洞。這個決定完全是一種自我挑戰。我想回到過去狀態，當時，我曾經在一個月內每天都發現了一個漏洞，這些漏洞涉及Atlassian公司所有外部程式。

1   挖洞計劃介紹&動機

1月初，我就積極準備進行我的高效漏洞挖掘計劃，剛開始，我曾在一天之內發現了多個漏洞，然而，隨著時間的推進，我覺得在一天之內找到多個漏洞是件非常耗費腦細胞的事，而且在挖洞過程中，我經常感到身心疲憊。

最終，經過120天之後，我結束了這種“日均一洞”的計劃。但是，我對自己在漏洞挖掘方面多少有了些體會：

（1）尋找一些新的意想不到的技術方式去拿下目標

（2）把關注重點放在那些自己感興趣的漏洞上面

（3）通過漏洞獎勵平臺結交從事安全研究的朋友或同齡群體

2   我發現的漏洞

以下就是我在120天之內挖掘的121個漏洞列表一覽：（全部漏洞請參看部落格 Table1 )

3   分析

以下統計表是對我發現的121個漏洞的大致分類，另外，還有一些雜項漏洞沒有包含在內

出於漏洞獎勵平臺的工作機制，很多提交漏洞可能還處於緩解開發或保密階段。待所有漏洞被修復公開之後，我會繼續更新這些資訊。

4   方法論

圍繞資訊系統實體進行漏洞挖掘

“資產”實體可以定義為資訊系統的所有組成項，包括：應用程式、目錄、檔案、資料夾、可執行程式或伺服器。當然，也包含大多數雲平臺服務，如VoIP、檔案共享、網路會議等。

對“資產”實體的資訊收集，是一個非常有趣的過程。例如，當我正對一家公司使用的軟體開發元件進行資訊收集時，碰巧，該公司的某位開發人員在1 小時之前就不小心把這些元件都上傳到網上了，哎呀，對我來說，這是多麼美妙的事情啊！

編寫自己的漏洞挖掘工具

為了保持每天挖掘一個漏洞的節奏，我需要更好的資訊系統識別工具，畢竟，想要在一些漏洞獎勵專案中發現漏洞已經變得越來越難了，想要獲得高額獎勵更是難上加難。

為此，我和朋友Nathan Wakelam就資訊系統的識別方法進行了一些討論。最終，我們一起編寫了三個相關工具：

Altdns: 通過域名字首序列變化和排列發現子域名的工具

Assetnote: 通過監視跟蹤被動API資料發現子域名

目前，Altdns已經獲得了同行的一些認可。

與值得信任的安全研究人員一起工作

我覺得有效的漏洞挖掘還需要一些外部氛圍，如果條件允許，可以與那些值得信任的安全研究人員或漏洞挖掘者一起工作。畢竟，擁有一個同路的夥伴會讓你覺得有動力。我非常有幸加入了一群出色的漏洞挖掘者當中，他們有我的同事和好朋友。當我處於挖洞瓶頸期的時候，我身邊參與漏洞專案的朋友會和我分享他們的新方法和新思路，這能讓我繼續充滿信心。當其它人發現了一些我所不能發現的漏洞，我都把這當成是一種激發自己學習的動力。還有就是，不要把共同參與漏洞獎勵專案的同事和朋友當做競爭對手，否則，你永遠都得不到進步。

提高漏洞發現視角

有時候，應該學著把漏洞發現視角提高到更高、更廣的水平。我知道有一些研究人員就是這樣做的，如@phwd，他甚至通過參加FACEBOOK的產品釋出會，以瞭解更多關於FACEBOOK的資訊。@phwd在參與FACEBOOK漏洞獎勵專案中的成功，是我所不能及的，這也決非偶然。

找到在漏洞挖掘之外可以釋放壓力的方法或愛好

我覺得，應該在資訊保安或漏洞挖掘之外，找到一個可以釋放壓力的方法或愛好。對我自己來說，漏洞挖掘是一個極度深入內心的愛好，每當我忽略了生活中的一些重要部分之後，我就發現自己並不開心。因為熱愛過度，陷入太深，有時候我覺得自己已經走火入魔了，如果能有一些東西能讓我暫時脫離漏洞挖掘工作，即便是一種簡單的愛好或者曾經的美好時光，我也願意。

5   建議

計劃一個切實可行的目標

我是從2016年1月開始我的“高效挖洞計劃”的，在堅持了兩個月左右的“一天一洞”節奏後，我遇到了第一個倦怠期。我犯的最大錯誤是沒有完全理解漏洞發現過程的波動性，從黑盒測試的角度來看，未被發現的漏洞是不可量化的，而我自己也不能很好的判斷髮現漏洞的可能性。在120天的時間裡，我曾三次到達了瓶頸期。我每天如果不能按計劃發現一個漏洞，情況就會變得更糟；如果在10天之內，我還沒有發現一個漏洞，就意味著我必須在一天之內找到10個漏洞。這個計劃讓我放棄的主要原因在於不斷累積的壓力。

我支援你嘗試這樣的高效漏洞挖掘計劃，只是不要和我犯同樣的錯誤–“每天發現一個漏洞”。請你放輕鬆，制訂一個切實可行的目標，而不是陷入惡性迴圈。

保持心態平和

當你在提交了漏洞之後，你就沒有了真正的漏洞處置權。因為，對於漏洞獎勵平臺來說，這就是一個買方市場。如果一個專案沒有達到你所期望的漏洞獎勵，就不要參與這個專案。另外，請記住，沒有什麼神人願意出高價來收買你的漏洞，或者讓你成為黑客新聞頭條，也沒有什麼所謂的“漏洞賞金獵人”聯盟或黑市願意為你的漏洞買單。基本原則是，我們只是付出有效腦力勞動去獲取該得報酬的合同工而已，我們的委託公司客戶可能是偉大牛逼的，也可能是極不友好的，這就是漏洞獎勵平臺和商業市場的本質。

如果在參與漏洞獎勵專案中，你認為沒有得到你該得的報酬，並且和你提交漏洞的公司有一些內部分歧。我建議你看看這兩篇關於漏洞獎勵的博文《我是如何成為一個成功的漏洞賞金獵手》、《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>, <svg> 或<object> 等元素嵌入過動態內容，這些動態內容還是存活狀態嗎？

這裡有一個快速判斷方法：

（1）建立你的目標網站URL列表（保證儘可能的全覆蓋，可以用爬蟲方法遍歷所有子域名）；

（2） 對每個URL發起請求，並尋找<script>, <iframe>, <svg>, <object>等元素，並從中提取link/hostname/URL資訊。

（3） 確保在上面元素標籤中找到的所有連結仍然有效。如果存在任何無效或過期的資源，請嘗試註冊並運用它們。

在另外一個漏洞獎勵專案中，我發現了很多內嵌框架類似<companyname>.wufoo.com/<formid>的頁面，由於這些頁面是3-4年前建立的，而其中的wufoo賬戶好像已經過期。但是，我通過wufoo.com網站註冊聲稱要求重新獲得有效的子域名，通過這個方法，最終我成功劫持了目標網站的子域名。利用這種簡單的方法卻獲得了高額的漏洞獎勵。

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生成，我們可以訪問下面這個連結觀看由使用者自定義字幕的視訊：

上面連結中存在一個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<track>標籤的瀏覽器中都驗證有效（包括過去2-3年中的所有瀏覽器）。

最終，我的高效挖洞計劃算是成功的嗎？我想應該是的，至少我賺了錢，得到了樂趣，提高了技術能力，還加入了優秀的技術團隊。雖然最終我輸給了身心疲憊，但我總算了解了自己的極限。

*本文譯者：clouds，參考來源：shubs.io ，轉載須註明來自FreeBuf.COM