您好,登錄后才能下訂單哦!
Jira服務工作臺路徑遍歷導致的敏感信息泄露漏洞是怎樣的,針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
作者通過對JIRA Servcie Desk應用下普通用戶和管理員賬戶的權限測試,發現可以普通用戶身份訪問獲取到管理員賬戶關鍵路徑下的一些敏感信息,這些信息會對協同團隊項目造成嚴重安全影響(CVE-2019-14994)。以下是作者對該漏洞的簡單復現和分享。
JIRA Servcie Desk是Atlassian旗下JIRA類應用的核心產品,它是一款服務臺管理軟件,專門用于接受和處理來自于團隊或用戶的問題或請求它還有其他類似于服務中心的附屬功能包括處理服務協議、報告、隊列,通過網站入口或者郵件等形式接收來自外部的問題及反饋。JIRA Servcie Desk是專門為終端用戶提交工單到客戶支持團隊而設計的,它也可適用于開發團隊,可與JIRA Software等同類產品配合使用。
JIRA Servcie Desk主要有兩個管理門戶:
用戶門戶(Customer portal):主要通過/servicedesk/ 目錄來實現訪問
管理員門戶(Administrative portal):主要通過/secure/目錄來實現訪問
該漏洞原理在于,如果攻擊者是可以訪問用戶門戶(Customer portal)的普通用戶,那么,他就能遍歷管理員門戶(Administrative portal)中JIRA項目提交的所有實例問題清單,這些項目包括Jira Service Desk自身、Jira Core projects以及Jira Software等。
漏洞可利用的條件為:
1、JIRA Servcie Desk中`anyone can email the service desk or raise a request in the portal` 設置選項開啟(任何人都可以向服務臺發送電子郵件或在門戶網站上提出請求);
2、上述設置開啟后,攻擊者通過身份驗證并能向JIRA Servcie Desk正常提交工單(Support Ticket)。
漏洞影響版本:
All versions before 3.9.16
3.10.x
3.11.x
3.12.x
3.13.x
3.14.x
3.15.x
3.16.x before 3.16.8 (the fixed version for 3.16.x)
4.0.x
4.1.x before 4.1.3 (the fixed version for 4.1.x)
4.2.x before 4.2.5 (the fixed version for 4.2.x)
4.3.x before 4.3.4 (the fixed version for 4.3.x)
4.4.0 before 4.4.1 (the fixed version for 4.4.x)
首先,我們要檢查的是目標JIRA項目實例是否運行有JIRA Servcie Desk服務,可以通過以下鏈接來核實:
https://target.com/servicedesk/
如果目標JIRA項目確實運行有JIRA Servcie Desk服務,那就會返回以下管理登錄界面:
從以上登錄界面中,點擊其中的注冊( “Sign up” )按鈕,完成注冊。注意,如果這里不顯示注冊( “Sign up” )按鈕,那么漏洞就不可利用,除非你有可登錄進入管理界面的項目內部員工賬號。注冊完成后,我們可以來到用戶門戶(Customer portal)頁面:
接下來,我們就以該普通用戶(Customer)的身份,來發起對管理員賬戶(Administrator)下安全目錄/secure/的請求。結合Burp等其它抓包代理,(如果僅只用瀏覽器,由于URL的正常化將不會導致漏洞利用成功),我們構造請求如下:
GET /servicedesk/customer/../../secure/BrowseProjects.jspa HTTP/1.1Host: target.comCookie: [authenticated as a customer]
注意,這里根據不同的JIRA Servcie Desk版本,這里需要用到以下URL符號構造來進行路徑遍歷:
GET /servicedesk/customer/..;/..;/secure/BrowseProjects.jspa HTTP/1.1
最后,如果目標JIRA Servcie Desk存在漏洞,則會返回顯示一個貌似壞頁的項目瀏覽(Browse Projects)頁面:
這也就是說,普通用戶的Customer,可以去訪問到一些管理員門戶下的頁面信息。然而,因為管理員門戶中的大多功能都是通過APIs來實現的,但是其APIs對URL字符處理比較奇怪,存在問題,使得正常的瀏覽存在貌似壞頁的問題。
對該漏洞的進一步利用就是構造請求,結合jqlQuery查詢,導出所有感興趣的組織數據。試試:
GET /servicedesk/customer/../../sr/jira.issueviews:searchrequest-html-all-fields/temp/SearchRequest.html?jqlQuery=text+%7E+%22%22 HTTP/1.1Host: target.comCookie: [authenticated as a customer]
如果目標JIRA Servcie Desk服務端返回 “not found”,那你也可嘗試通過請求以下URL來獲取相關數據。請求會返回所有與查詢相關的數據信息,當然你可以把jqlQuery查詢參數更改成其它。
GET /servicedesk/customer/../../sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=text+%7E+%22%22 HTTP/1.1
如以下查詢返回了HTML的相關組織頁面數據信息:
補充說明
奇怪的是JIRA本身的身份驗證機制,在它的正常情況下,如果普通用戶或內部員工,通過瀏覽器訪問上述我們所提到的管理員目錄/secure/或/sr/,將會被阻止并重定向跳轉到普通用戶門戶頁面。這種簡單的URL匹配重定向跳轉,看似是JIRA自己對管理員門戶的一種安全保護機制。之后,JIRA方給出了以下簡單修復方案:
<rule> <from>^/[^?]*\.\..*$</from> <to type="temporary-redirect">/</to> </rule>
這個修補方案有點可笑,它只聲明了用戶的有限訪問規則,即訪問到什么什么就實行跳轉,要是修復方案實施之后,攻擊者一樣可以通過一些fuzz或編碼技巧訪問到管理員門戶的相關功能。
關于Jira服務工作臺路徑遍歷導致的敏感信息泄露漏洞是怎樣的問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。