<li id="fw3su"></li>
  • <li id="fw3su"></li>
  • <div id="fw3su"><tr id="fw3su"></tr></div>
    <dl id="fw3su"></dl>
  • <div id="fw3su"><tr id="fw3su"></tr></div>
  • <sup id="fw3su"></sup>
    <progress id="fw3su"></progress><div id="fw3su"><tr id="fw3su"></tr></div><input id="fw3su"><ins id="fw3su"></ins></input>

    HackerOne | 子域名劫持漏洞的挖掘指南

    在HackerOne實時更新的公開漏洞推送Hacktivity消息中,我們可以發現,其中的子域名劫持漏洞(Subdomain Takeover)占比不少。自從2014年Detectify實驗室發布了 一系列子域名劫持攻擊姿勢 的文章之后,眾測行業出現了大量此類問題相關的上報漏洞。

    子域名劫持漏洞的基本前提可以大致的解釋為,發生了錯誤配置情況,對應主機指向了一個當前未在用的特定服務,這樣一來,攻擊者就能通過在該特定的第三方服務中注冊賬戶,聲明對該子域的接管權限,由此,在該子域上部署網絡服務,實現對該子域有目的的利用。作為一位白帽和安全分析師,我每天都會遇到這類漏洞問題。今天,我就來和大家聊聊子域名錯誤配置導致的子域名劫持漏洞相關的理解、挖掘、利用和上報,文章假設讀者具備了一定的DNS知識和子域名設置基礎。

    子域名劫持漏洞介紹

    如果你此前不了解子域名劫持漏洞,想從基本原理聽起,我這里就設計了一個簡單的實例場景。在該場景中,假設example.com是你在參與漏洞眾測的目標網站,經過對example.com的所有子域名進行枚舉之后,發現了其中一個子域名subdomain.example.com,該子域名錯誤配置指向了一個GitHub頁面。由此,我們可以先來看看該子域名的DNS記錄,在這里假設該子域名所屬的GitHub頁面存在多條指向GitHub特定IP地址的A記錄:

    $ host subdomain.example.com
    subdomain.example.com has address 192.30.252.153
    subdomain.example.com has address 192.30.252.154
    $ whois 192.30.252.153 | grep "OrgName"
    OrgName: GitHub, Inc.

    網頁訪問subdomain.example.com后,我們可以發現以下404響應頁面:

    看到這里,大多數白帽可能會覺得有戲了。這個404頁面表示,在域名對應網站的頂級根目錄下沒被注冊部署任何網頁內容,因此,我們可以嘗試去注冊把該子域名接管為我們個人的GitHub庫所有。但是,請注意,出現這種情況,并不代表所有對應的域名都存在劫持漏洞。因為有一些域名應用可能還需要檢查具體的HTTP和HTTPS響應情況,以此來判斷域名控制權限,而另外有些域名就不存在劫持漏洞。

    這里,假設就存在子域名劫持漏洞吧。當我們把該子域名添加進入個人 GitHub 項目之后,就能把它部署上我們自己的Web內容了,也就是說,我們就能把子域名接管為我們自己所有了。如下可以讓subdomain.example.com指向任何你部署的網頁內容:

    二階子域名劫持漏洞

    這里所說的二階子域名劫持漏洞,有點像過期壞鏈劫持(Broken Link Hijacking),這種情況下的子域名,并不屬于目標網站所有,但卻是用來運行目標網站的網頁內容的。也就是說,如目標網站網頁內容中某個資源需要從外部導入的第三方資源,舉例來說,像js文件一樣,那么,攻擊者就可以通過JavaScript的Blob對象類型進行導入,從而聲明對目標網站相關子域名的控制權限。

    這種在網頁頁面的主機劫持可以導致存儲型跨站漏洞,攻擊者可以針對目標網站頁面,利用這種模式來加載任意的客戶端代碼。我在此提出這種威脅,就是希望我們不要把想像力只限制在子域名身上,還可以延伸到代碼審查和目標網站的主機映射等方面。

    像下圖網站中,存在導入的第三方資源 http://subdomain.example.com/script.js ,那么,能否存在subdomain.example.com可被劫持,從而我可以變換script.js實現對example.com的間接劫持呢?

    當然,也要說明的是,如果你想對某個子網站域名進行劫持,那么可以花點時間,去看看該網站上各個頁面中的第三方導入資源是否能被劫持利用。

    子域名枚舉和探測

    現在,我們對如何在錯誤配置的子域名上部署我們自己的網頁內容有了大致了解,接下來,我就來介紹發現漏洞子域名的各種技術、技巧和工具。

    在深入之前,我們需要區分檢索( Scraping )和暴力猜解(Brute Forcing)的不同,因為這兩種方法都能幫助你發現子域名,但最終結果卻有所不同。檢索是一種被動的偵測方式,它利用DNS Dumpster和VirusTotal等外部服務和資源,來收集屬于某個特定主機的子域名。這種方式能快速檢索出外部服務資源中之前加載過的子域記錄,算是一種不費太多精力的子域名發現方式。如以下 DNS Dumpster 網站中記錄的reddit.com子域名情況:

    檢索( Scraping )方式中不僅中以包含索引頁面,還可以添加進目標網站的GIT庫、內容安全策略頭、源代碼和漏洞跟蹤消息等反饋源,只要你能想得到,檢索列表是非常之多的。我就經常更新我自己的檢索列表資源庫,反正你應用的技術越多越奇特,那么最終你發現的結果也會與眾不同。所以,從這一點來說,在做漏洞眾測時,我們一定要具備創新精神。

    Sublist3r算是檢索( Scraping )方式的一個簡單子域名發現工具了,它利用了輕量級的Python腳本,從各種搜索引擎、SSL證書和DNS記錄網站中來收集目標子域名。具體的安裝和應用如下圖所示:

    $ git clone https://github.com/aboul3la/Sublist3r.git

    $ cd Sublist3r

    $ sudo pip install -r requirements.txt

    暴力猜解子域名時,我們可以依托字典進行迭代請求嘗試,然后根據其響應來判斷子域名的有效性。但請注意,如果目標網站開戶了泛域名(Wildcard)模式,進行子域暴力猜解時,可能會得到很多誤報響應。

    泛域名模式(Wildcard)也就是說,所有的子域名解析都可能會對應到同一IP地址下,如a.example.com和ctk.example.com都會解析到同一個IP地址。使用泛域名,可以讓域名支持無限的子域名,也可以防止用戶輸入錯誤的子域名,而無法訪問網站。所以,這個時候,可以解析一個目標網站不可能使用的子域名,依其響應來判斷是否可以正常解析,如果能正常響應,則證明其開啟了泛域名模式。如下:

    $ host randomifje8z193hf8jafvh7g4q79gh274.example.com

    針對子域名暴力猜解,我個人認為最好的方式就是,根據你平時積累的經驗,或個人感興趣的方式,創建你自己的猜解字典。例如,我經常對 Atlassian Jira 系統和 GIT用例的漏洞挖掘較多,所以我會在子域名猜解字典中添加進 “jira” 和 “git” 等相關關鍵字。

    如果你打算創建個人的子域名猜解字典,我強烈建議你可以參考 Jason Haddix 的字典 ,他花了很多精力,將各種子域名發現工具的不同列表合并成了一個廣泛的字典列表。

    指紋識別(Fingerprinting)

    為了增加你的子域名發現結果,不管是檢索( Scraping )還是暴力猜解(Brute Forcing)方式中,都可以采用一種名為指紋識別(Fingerprinting)的技術,這種技術可以通過對目標網站的通用字典創建,然后以此來顯示出那些,你用普通字典列表無法識別的屬于目標網站的資產。

    一些經典的子域名發現工具

    在這里,我要介紹一些好用的子域名發現工具:

    Altdns

    這是Shubham Shah開發的一個子域名遞歸暴力猜解工具,你先要創建一個目標網站存在的子域名字典 subdomains.txt,這就是你的通用fingerprint字典,然后再創建一個遞歸置換字典 words.txt,然后用Altdns命令:

    ./altdns.py -i subdomains.txt -o data_output -w words.txt -r -s results_output.txt

    進行子域生成發現。我喜歡用 Altdns 來生成字典列表,然后再配合其它工具來運行發現。

    Commonspeak

    Commonspeak 也是Shubham開發的另外一個工具,它通過Google的BigQuery查詢記錄來生成字典列表,其中包含了當前每天更新的各類子域名,非常及時快速。你可以通過查看 這篇文章 ,來了解Commonspeak的字典收集和子域提取機制。

    SubFinder

    這是一個兼具檢索( Scraping )和暴力猜解(Brute Forcing)的子域發現工具,就我個人來說,我用SubFinder比Sublist3r多,SubFinder能從包含API接口在內的各種服務中來發現子域名,最終結果也相對較好。

    Massdns

    Massdns是一個非常快速的子域枚舉工具,其它工具可能用15分鐘才能完成,但用Massdns僅需一分鐘。但如果你想用Massdns,得先指定一個有效的DNS存根解析器( Resolver),如這個 https://public-dns.info/nameservers.txt ,通過其中的host進行域名解析發現。如果你長期不更新這個解析器列表,結果也可能會出現誤報。

    $ ./scripts/subbrute.py lists/names.txt example.com | ./bin/massdns -r lists/resolvers.txt -t A -o S -w results.txt

    流程自動化

    在挖掘子域名劫持漏洞的過程中,自動化非常關鍵。頂級的白帽黑客總會長期關注目標網站的任何變動,或是對目標網站的所屬子域名進行持續的狀態跟蹤。本文中,我們不談具體的跟蹤關注手段,相反,我會介紹一些簡單技巧,以便能節省些許挖掘分析時間,實現一定程度的自動化。

    我喜歡用的第一項自動化任務是從一些主機列表中過濾出實時有效的子域名。因為在子域名檢索方法中,最后的結果可能為有些子域名是過期的,有些則是不可訪問的,因此,我們需要檢測出哪些主機對應的子域名是實時有效的。請記住,正如之后會看到的示例顯示,雖然一些主機不能有效解析,但也存在被劫持可能。這里的自動化,我們就用host命令來實現吧,如果某個子域名不存活為無效,那么就會響應返回一個錯誤消息。

    while read subdomain; do
    if host "$subdomain" > /dev/null; then
    # If host is live, print it into
    # a file called "live.txt".
    echo "$subdomain" >> live.txt
    fi
    done < subdomain-list.txt

    把所有檢測和發現機制抽象化后,可以表示為以下流程:

    接下來需要對子域名有個大致的了解,這里有兩種顯示模式,一種為運行子域名截圖腳本抓取所有子域名網站截圖,另一種為存儲各個子域名網站的顯示內容。做子域名截圖,可以考慮工具 EyeWitness ,它能對目標列表子域名生成一個包含截圖、響應頭和標頭信息的HTML文件。

    $ ./EyeWitness -f live.txt -d out --headless

    可能有時候,你只需要存儲子域名網站的簡單GET請求響應頁面內容時,EyeWitness就顯得有點大材小用了。這個時候,我會用Tom Hudson開發的工具 meg ,它會向目標子域名發送簡單的請求并把響應內容進行存儲為明文,meg相比EyeWitness顯得更輕量級一些。

    $ meg -d 10 -c 200 / live.txt

    特殊情況 

    也存在一種特殊情況需要說明,Frans Rosén大牛曾在他的演講《 DNS hijacking using cloud providers – No verification needed 》中提到,如果你遇到一些dead DNS records(廢棄的DNS記錄),不要就表面性地認為其不存在子域名劫持漏洞。據Frans Rosén的觀點,host命令可能會出錯,但如果用dig命令的話,可能就會發現一些dead records。

    漏洞利用

    現在,假設你可以控制目標網站所屬的某個子域名,那么,接下來該做什么呢?當你想用這個錯誤配置的子域名來實現某些可能的攻擊場景時,最關鍵的是需要去了解這個子域名與目標網站的核心服務存在些什么交互。

    Cookies

    利用子域名劫持漏洞,針對可控制的子域名subdomain.example.com進行web服務部署,可以竊取用戶隸屬于 example.com 的Cookie,以此實現劫持受害者會話的目的。

    利用在線前端編輯網站output.jsbin.com,我們可以對cookie進行編輯設置。如果確定目標網站存在會話ID是確知不變的攻擊風險(Session Fixation) https://en.wikipedia.org/wiki/Session_fixation ,并且使用了HTTPOnly類的cookie,那么你就可以對cookie進行設置,當受害者啟動瀏覽器后,由于cookie的按序排列,你這里的惡意cookie將會優先于對方的新生成的cookie,從而間接實現了對受害者身份的劫持。

    CORS跨域資源共享

    跨域資源共享,Cross-Origin Resource Sharing (CORS), 允許 Web 應用服務器進行跨域的網頁訪問控制。在Web應用創建的某個域中,按照一組規則來允許某些網站可以訪問提取包括認證數據在內的數據信息。以某些子域名是可信域名的前提下,一些Web應用還允許子域名執行跨域的HTTP請求。當你挖掘子域名劫持漏洞時,可以留意一下COSR頭信息,在Burp Suite Pro專業版中就有這個檢測功能,另外可以看看Web應用是否將子域名列入了白名單,這些設置都可能實現對Web授權用戶的數據竊取。

    Oauth 授權白名單化

    與跨域資源共享,Oauth 授權過程同樣具備一個白名單機制,藉此,Web開發者可以指定指定哪個回調URIs是可以接受的。這里的風險在于,當存在劫持漏洞的子域名被列入這個白名單中時,攻擊者可以在Oauth授權過程中把用戶會話重定向到先前那個存在劫持漏洞的子域名中,以此竊取用戶的 Oauth 授權信息。

    內容安全策略(Content-Security Policies)

    可以說,內容安全策略是Web應用信任的另一個主機列表,CSP的目的在于限制哪些主機可以在應用中執行客戶端代碼。如果希望盡量減少跨站腳本的影響,這種方式非常有用。如果你可以劫持控制的子域名包含在白名單中,你就可以繞過CSP限制,在Web應用中執行惡意的客戶端代碼。

    $ curl -sI https://hackerone.com | grep -i "content-security-policy"

    content-security-policy: default-src 'none'; base-uri 'self'; block-all-mixed-content; child-src www.youtube-nocookie.co

    m; connect-src 'self' www.google-analytics.com errors.hackerone.net; font-src 'self'; form-action 'self'; frame-ancestor

    s 'none'; img-src 'self' data: cover-photos.hackerone-user-content.com hackathon-photos.hackerone-user-content.com profi

    le-photos.hackerone-user-content.com hackerone-us-west-2-production-attachments.s3-us-west-2.amazonaws.com; media-src 's

    elf' hackerone-us-west-2-production-attachments.s3-us-west-2.amazonaws.com; script-src 'self' www.google-analytics.com ;

    style-src 'self' 'unsafe-inline'; report-uri https://errors.hackerone.net/api/30/csp-report/?sentry_key=61c1e2f50d21487c

    97a071737701f598

    點擊劫持(ClickJacking)

    像《 Cure53 Browser Security White Paper 》中提到的那樣,在X-Frame-Options標頭中,IE、Edge和Safari都支持ALLOW-FROM uri機制,表示該頁面可以在指定來源的 frame 中展示,也就是說,如果你可劫持控制的子域名在該機制的白名單中,那么就可以在目標網頁應用中構建欺騙頁面,執行點擊劫持(ClickJacking)攻擊。

    密碼管理器的密碼信息泄露

    這一點可以不必在一些漏洞上報中進行考慮,但也是我們值得關注的方面。某些密碼管理器,如LastPass會在一些主網站所屬的子域名網站中執行自動密碼填充功能,這相當于讓網站設置了一個包含明文密碼的非httponly類cookie,可以方便子域名劫持之后的深入利用。

    攔截電子郵件

    安全研究者Rojan Rijal曾發現了Uber基于SendGrid服務的某個可劫持子域名,之后,利用該子域名,他成功攔截了Uber內部的公司電郵通信,獲取了Uber官方$10,000美金的獎勵。(翻墻-點此 查看文字分析 ,點此 觀看PoC視頻

    上報子域名劫持漏洞的注意事項

    在你嘗試上報子域名劫持漏洞之前,應該注意以下事項:

    請確保在你可劫持控制的子域名上部署了屬于你自己的Web內容;

    部署的Web內容盡量簡單干凈,最好是一句話之類的標志,連圖片都不要放;

    最佳方法就是在你部署的Web內容HTML文件注釋中包含了某個隱秘消息即可,在與廠商聯系協調時,這就足以證明漏洞問題;

    如果廠商給你授權,為了說明整體的威脅影響,你可以進一步對這種子域名劫持漏洞做出測試;

    大多數情況下,如果你的漏洞報告中包含了子域名劫持漏洞的利用步驟,廠商都會都會認可這種漏洞

    子域名劫持漏洞屬于高危漏洞,在編寫漏洞報告時,請認真一點,如果漏洞屬實又不屬于重復報,那么恭喜你,最終你可以獲得廠商的大獎。

    最后,感謝我的一眾白帽好友Frans Rosén 、Filedescriptor、Mongo 和 Tom Hudson,是他們的寶貴意見,為我這篇文章奠定了基礎。

    *參考來源: HackerOne ,clouds編譯,轉載請注明來自FreeBuf.COM

    我來評幾句
    登錄后評論

    已發表評論數()

    相關站點

    +訂閱
    熱門文章
    11选五