怎么利用Jira的郵件服務器連通測試功能發現其CSRF漏洞

本篇文章給大家分享的是有關怎么利用Jira的郵件服務器連通測試功能發現其CSRF漏洞，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

去年10月，Tenable研究員發現Jira v8.4.1版本存在一個跨站請求偽造漏洞（CSRF）-CVE-2019-20099，籍此可以讓目標Jira服務去連接任意內部主機，Atlassian Jira受該漏洞影響的版本范圍為8.7.0到8.2.4之間的Jira Server 和 Data Center。以下即是具體發現CVE-2019-20099漏洞的過程。

Jira部署的防CSRF策略

跨站請求偽造（CSRF）攻擊可以無需他人授權，假冒他人身份發起惡意操作。為了防止此類攻擊行為，Jira在客戶端某HttpOnly Cookie中部署了CSRF token，因此，對于執行狀態更改的操作請求，Jira服務端會檢查其中的token是否與CSRF Cookie和CSRF參數中的token匹配，這樣一來，攻擊者就很難重用cookie發起CSRF攻擊。并且，其中的Referer header頭信息還可驗證與Jira服務端的域名和端口一致性，防止同源策略繞過操作。

下圖就是我對Jira服務端發起的POST示例請求，也就是從該請求中我發現了漏洞所在。其中 CSRF cookie 和CSRF 參數分別是Atlassian.xsrf.token和atl_token，還包括了與Jira服務端IP和端口匹配的Referer header頭信息。經過多次測試，我發現Jira服務端并不總是會去校驗上述這些驗證性信息的值。

漏洞問題

這里我們以內網中Jira架構郵件服務為例進行測試。在Jira中部署POP3郵件服務時需要管理員提交完整的郵件服務配置信息，如服務器名稱、主機地址、端口號、用戶憑據等等，在底部有兩個按鈕，一個是新建郵服請求，一個是測試當前建立郵服的連通性。注意，由于這里是內網，所以這里的郵件服務器主機地址就是內網地址。

郵服連通性測試操作會讓Jira服務端去連接給定的POP3郵件服務器地址，該過程中會涉及到一個密碼交換過程。當我測試該測試請求時發現，其中的Referer header頭信息和CSRF參數校驗都未執行，所以，這樣一來，如果要對該請求實施CSRF攻擊，那么唯一需要的僅只是重用當前已登錄Jira系統的管理員Cookie。

為了測試該請求，我特意設置了一個內網的POP3郵件服務器以便接收來自Jira服務端的驗證連接，另外我還架設了一個內網Web服務器用來托管與CSRF腳本相關的網頁。目的在于模擬Jira系統管理員點擊了某個惡意鏈接后，被進行會話Cookie重用，請求Jira服務端發起針對我設置的郵件服務器的連通測試。以下是觸發Jira服務端發起測試郵服連通請求的CSRF腳本:

以下就是該CSRF腳本運行后，執行的對預定郵服172.16.68.229的連通性測試Wireshark包圖：

這樣，當受害者172.16.68.1對Jira服務端172.16.68.248發送了一個POST請求后，接著，會起發針對預設郵件服務器172.16.68.229:110的連通測試，這是一個密碼憑據交換驗證過程，如果密碼憑據驗證不通過，則連接終止。不過，利用該腳本，我可以讓Jira服務端去連接我自己設定的主機和端口。

POP3郵服的連接驗證請求需要在POST請求的參數中設置用戶名和密碼信息，當請求實現成功握手后，這些參數會被發送到指定的主機和端口，這也就提供了一種機制，攻擊者可以通過這種渠道向郵服主機發送消息或命令實現主機監聽。

利用漏洞執行內網主機探測發現

XMLHttpRequest對象存在一個readyState屬性，它和onreadystatechange事件一起使用，readyState屬性包含了0到4之間的不同狀態表示值，如下：

readyState屬性值每次發生變化時，都會調用onreadystatechange事件進行處理，為此我在上述腳本中對XMLHttpRequest的state屬性變化加入了alert方法，以便每次狀態改變時能有所提醒。目的在于觀察請求去連接不同主機和端口號時的狀態變化差異。我在上述腳本中加入了以下state狀態轉化跟蹤代碼：

當Jira服務端試圖去連接一個內網不存在的IP地址時，其XMLHttpRequest請求的state屬性會從1到4變化，從而去調用onreadystatechange事件，而只有當連接終止結束后，原始的POST請求才會得到相應的響應，這個過程會花費3秒左右（約3000多毫秒）的時間完成。

PoC

最終我寫了一段PoC腳本來讓Jira服務端以測試郵件服務器連通性的CSRF操作去執行內網主機探測，當然，我把其中的郵件服務器地址設置為了一段內網IP地址，請求端口為110。運行PoC腳本后可以發現，那些花費3000多毫秒的主機IP是不存在的內網IP地址，只有少量耗時的IP才是存在IP，如下：

為了驗證上述發現結果，我又用nmap進行了掃描，果然發現結果相同：

在以下我用Wireshark抓包的圖片中可以發現，PoC腳本會讓Jira服務端去連接指定的IP主機端口，而且，還可以在之前用來進行憑據交換的用戶字段中填入任意消息，發送給連接的指定IP主機。

這是Jira服務端連接郵件服務器功能的一個CSRF漏洞，我利用它可以執行內網主機和端口的掃描探測。可利用場景是，針對Jira管理員構造惡意鏈接迷惑其點擊執行，實現針對其內網的主機端口枚舉探測。

以上就是怎么利用Jira的郵件服務器連通測試功能發現其CSRF漏洞，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。