以下講述了作者在參與美國國防部（DoD） Hack the Pentagon 漏洞眾測專案中，利用JIRA漏洞CVE-2017-9506建構了SSRF攻擊面，實現了對美軍非保密因特網協定路由器網（NIPRnet）的訪問，並且結合其它漏洞技巧，獲取到DoD內網系統的一系列敏感資訊。由於測試過程和內容的涉密性，該篇文章僅點到為止，未對過多技術細節和詳細場景作出披露，僅當學習分享，還望讀者多多包涵。
JIRA 是澳洲 Atlassian 公司開發的一款優秀的問題追蹤管理軟體工具，可以對各種類型的問題進行追蹤管理，包括缺陷、任務、需求、改進等。許多知名公司和開源軟體組織都在使用 JIRA，因其採用J2EE技術，並且能夠進行跨平台部署。
在參與美國國防部（DoD）的漏洞眾測專案時，我發現其中有兩個特別的網站部署了專案跟踪管理工具JIRA，經過初步分析後，我認為不存在可利用的漏洞，所以就直接沒繼續深挖了。
後來，我從Twitter中發現了一則利用JIRA漏洞實作SSRF攻擊的貼文：
小心了，JIRA用戶！攻擊者可以利用JIRA漏洞CVE-2017-9506來竊取你的內部網路資料。這是一種開放重定向漏洞，但在某些情況下，它可被利用重定向到內部JIRA系統的本地連結位址中，從而導致如AWS金鑰等某些內部資源資訊外洩。JIRA漏洞CVE-2017-9506說明
https://�sepath%/plugins/servlet/oauth/users/icon-uri?consumerUri=https://google .com把basepath換成JIRA系統網站鏈接，訪問上述頁面之後，如果正常出現google.com頁面，則證明JIRA系統存在該漏洞；如果訪問出現404頁面，則漏洞不存在。請注意，在consumerUri的末尾添加要測試的網站的請求！ ！ ！ 測試DoD的JIRA應用網站漏洞
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://google.com
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254. 169.254/latest/meta-data/local-hostname/
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http:/ /169.254.169.254/latest/meta-data/iam/security-credential但好像不行。經過仔細閱讀AWS官方文件後，我重新使用了以下連結來取得實例ID、私人IP位址等資訊：
https://website.mil/plugins/servlet/oauth/users/ icon-uri?consumerUri=http://169.254.169.254/latest/dynamic/instance-identity/document很好，竟然都能成功回應取得！
到了這一步，我想應該能說明問題了，所以沒再深入測試就簡單寫了份漏洞報告進行提交，但之後，DoD的項目分類人員把該漏洞定級為中危漏洞，但我認為這絕對是嚴重的高危險漏洞。我與國防部進行了交流後，申請了深入測試的授權，以便測試該漏洞的最終影響。
#首先，我從基本的端口探測開始，發現目標系統開啟了21、22、80、443、8080端口，有了這些端口信息之後，我就能測試各種錯誤信息的返回，通過這些信息判斷目標系統中的伺服器與網路部署情況，如下對目標系統8080埠發起請求後的回應資訊：
#其次，我對gopher檔案目錄檢視協定、DICT字典伺服器協定、FTP協定、LDAP輕量級目錄存取協定等其它協定作了一遍請求測試。如係統回傳了以下不支援LDAP的回應：
在記錄下這些資訊時，我又想到了PortSwigger首席研究員James Kettle的在USA 2017黑帽大會的研究分享《Cracking the Lens: Targeting HTTP's Hidden Attack-Surface》，James Kettle透過構造惡意的HTTP請求和Header頭訊息，側面勾勒出目標系統中HTTP服務的隱藏攻擊面，最終，他利用了這種技術，'偽裝'成美國國防部內部IP身份，成功入侵訪問到了DoD受限的內部網路系統和相關資源。我記得在Kettle的分享中，他還展示了兩個他曾用來作入侵測試的DoD內部網站：（網站資訊出處defensivecarry.com）
https://safe.amrdec .army.mil/safe/
https://dots.dodiis.mil/
結合這兩個James Kettle提到的DoD內部網站，用我發現的DoD的兩個JIRA網站來向它們發起請求，目的就是測試能否以這種途徑實現對James Kettle提到的兩個DoD內部網站的訪問。最終，我用其中一個JIRA網站向James Kettle提到的兩個DoD內部網站發起請求後，其中一個顯示請求超時：
另一個返回了US Goverment （USG）的政府警告訊息，如下：
在此測試過程中，我還發現了其它的DoD內部web服務，透過該內部web服務，我竟然能成功存取到美軍的非保密協定路由網（NIPRnet），此網路系統被DoD內部用來處理比機密級較低的敏感級資訊。由於保密原則，在此我就不詳細揭露具體方法和途徑。
我用第二個JIRA網站向James Kettle提到的兩個DoD內部網站發起請求後，傳回的回應資訊基本沒什麼可用之處。
經過測試，最終我發現可以根據回應時間來評估DoD內部系統連接埠的開放情況。就例如，當向內部系統請求22埠時候，其回應用時1000毫秒，而請求21埠時回應用時將近10000毫秒，從這種時間差上可對一些埠情況作出猜測判斷。另外，由於缺少詳細的錯誤訊息回應返回，我無法對系統中的具體協定作出判斷，但我要著重強調本文的重點是：透過該內部的web服務端，我可以存取到DoD的非保密協定路由網（NIPRnet）！我還使用了Burp的Collaborator外掛程式探測了對該web服務端請求發起後，服務端和請求端資料交換時存在的資訊外洩。
例如從請求頭中的'X-Forwarded-For'可以獲取到內部IP，我用Burp的Collaborator插件查詢了所有可交互的內部IP，雖然最終能查詢到內部IP和相關的網路服務訊息，但卻無法在該web服務端上實作AWS元資料檢索。
最終，我向DoD提交了涉及的兩個漏洞之後，兩個漏洞都被評級為高危（Critical），由此，我聯想到我今年年初向DoD上報的兩個SSRF漏洞，想看看上述漏洞能否用這種SSRF方式有所深入利用。
我年初上報的兩個SSRF漏洞是，用某個web應用過濾器可以對特定的IP位址發起HTTP連接請求，例如能以提交CONNECT IP 請求方式，枚舉出目標系統內的應用服務；另外也能透過更改主機頭資訊對目標系統內部IP或外部IP發起經過驗證的請求信息，如militarywebsite.mil@internal_IP。當我在這兩個JIRA網站上用這種SSRF方式進行測試時發現，之前提示超時、SSL錯誤和其它響應的請求環境中，竟然也能用Blind SSRF方法實現對內部IP和網絡服務進行枚舉探測。所以，這個點的SSRF漏洞利用最終也被DoD評級為中危險。
在我對以上漏洞的綜合測試過程中，我發現在某些情況下，會莫名其妙地發生堆疊錯誤並洩露各種敏感信息，例如，用不完整的HTTP頭資訊http://或http://[::]，這種堆疊錯誤時洩漏的敏感資訊包括資料庫IP、資料庫版本、應用程式插件、作業系統架構和其它系統：
發生堆疊錯誤時，仍然可以繼續對目標網站進行深入的資訊獲取利用，比如，我發現有時目標網站會指向其它Altassian實例，如某次測試中，我發現目標網站某子網域中部署有Altassian的confluence實例，經過測試證明，這些實例同樣會受到資訊外洩漏洞的影響。
作者描述了參與美國國防部漏洞眾測計畫時發現的JIRA漏洞，並概要性地介紹了整個漏洞利用的測試過程，我們一起來梳理下：
1 其中兩個部署有JIRA實例的DoD網站存在授權插件漏洞CVE-2017-9506，攻擊者利用該漏洞可獲取目標網站系統內部資源信息，並能形成SSRF攻擊面；
2 結合CVE-2017-9506利用方法，我從有漏洞的DoD網站中取得了JIRA實例ID、私有IP位址、一系列錯誤回應等資訊；
3 綜合PortSwigger首席研究員James Kettle分享提到的兩個DoD網站，利用CVE-2017-9506請求方法，發現請求的DoD網站返回了有效USG（政府警告）信息；
#4 在第3步過程中，我透過發現的某個內部web服務，結合CVE-2017-9506利用方法，實現了對DoD非保密協定路由網（NIPRnet）的存取；
5 結合CVE-2017-9506利用方法，在有漏洞的DoD網站上復現了SSRF攻擊，實現了內部IP和網路服務枚舉，以及後續堆疊錯誤時的敏感資訊獲取。
以上是利用JIRA漏洞存取美軍非保密網際網路協定路由器網的範例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！
