在現代 Web 應用安全攻防中,動態的跨站請求偽造(CSRF)權杖對自動化測試構成挑戰。本文以 Ignition SCADA 為例,闡述一種系統性的分析方法,不僅找出權杖生成端點,更追溯其背後的 OpenID Connect(OIDC)驗證協議。透過 Burp Suite Repeater 的靈活操作,測試者得以逆向工程權杖的生命週期,將隨機防禦機制轉化為可預測的流程,為後續的漏洞利用奠定基礎。
Burp Suite Repeater與Ignition SCADA CSRF Token分析
玄貓認為,在對Web應用進行滲透測試時,理解並繞過安全機制(如CSRF Token)是至關重要的挑戰。本節將引導您使用Burp Suite的Repeater工具,深入分析Ignition SCADA的登入流程,揭示其CSRF Token的生成機制,並探討如何應對這種防禦。
攔截登入請求與Repeater工具:
1. 嘗試登入並攔截POST請求:
- 現在,假設您在滲透測試中發現了Ignition SCADA系統,並嘗試使用
admin:admin憑證登入。 - 您應該會停留在登入畫面,因為憑證不正確。
- 此時,我們回到Burp Suite,查看剛剛攔截到的POST請求。
2. 使用Repeater工具:
- 從這裡,我們將使用Burp Suite內建的一個強大工具——Repeater。它允許我們重複地修改和測試我們的請求,這也是其名稱的由來。
- 為此,右鍵點擊攔截到的POST請求,並從下拉選單中選擇「發送到Repeater」(Send to Repeater)。
- 這將把捕獲到的POST請求發送到Repeater工具。
3. 發送請求並分析回應:
- 在Repeater工具中,點擊「發送」(Send)按鈕將請求發送到伺服器。
- 注意螢幕右側的回應。仔細查看,您會發現訊息是「無效Token」(Invalid token)。
CSRF Token的挑戰:
1. 識別CSRF Token:
- 我們可以看到,剛剛透過Repeater工具提交的請求中,似乎包含了一個跨站請求偽造(Cross-Site Request Forgery, CSRF)Token。
- 這使得暴力破解變得更加困難,因為我們現在必須弄清楚Ignition是如何或使用什麼工具來生成這些Token的。
2. 追溯Token來源:
- 知道我們必須追溯Token的生成來源,這要求我們進行更徹底的檢查。
- 讓我們從Proxy | HTTP歷史記錄開始,選擇GET方法來查看我們請求和回應的詳細資訊。
- 在此會話中,沒有什麼特別引起我們興趣的。
- 點擊GET請求上方的POST方法,檢查這是否揭示了在這次不同請求的交換中,CSRF Token是如何形成和共享的線索。
3. 發現next-challenge Token:
- 從這個回應中,我們可以看到一些非常有希望的線索。在使用者名稱-密碼POST請求中所需的Token,似乎是
next-challengeToken。
4. 測試next-challenge Token:
- 為了嘗試生成
next-challengeToken,右鍵點擊該請求並像之前一樣將其發送到Repeater。 - 回到Repeater頁面後,點擊「發送」以測試POST請求。您應該會得到類似「無效Token」的回應,這表明我們的請求Token已過期。
深入追溯OIDC請求:
1. 回溯HTTP歷史記錄:
- 為了弄清楚我們的
next-challengeToken是如何生成的,我們必須回溯更深。 - 返回Proxy | HTTP歷史記錄,並審查在
next-challengePOST請求之前的請求。 - 我們可以看到在先前的
next-challenge之前有一系列GET查詢。
2. 識別OIDC GET請求:
- 這裡有一個非常有趣的GET請求,其路徑中包含OIDC。
- **OpenID Connect (OIDC)**是一種安全且簡單地驗證嘗試登錄線上應用程式使用者的協議。
- 對於我們的目的,我們只需要知道這很可能是我們Token的起點。
- 當我們點擊這個GET方法時,我們現在會得到以下請求和回應輸出。
3. OIDC 302回應與Token生成:
- 如您所見,我們收到了302回應碼,並且我們可以在其中看到我們的
next-challengeToken。 - 讓我們第三次將請求發送到Repeater工具,並點擊「發送」按鈕。
- 您將得到以下結果。這非常令人鼓舞,因為我們現在可以看到一個新的Token已經生成,並且沒有發送任何失敗通知。
- Repeater工具的優點在於它允許我們更新數據並重新發送,以檢查輸入數據如何影響回傳。如果您多次點擊「發送」,您會看到每次都生成了新的
next-challengeToken。
此圖示:Ignition SCADA登入流程與CSRF Token分析
@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
actor "滲透測試者 (玄貓)" as pentester
rectangle "Kali Linux VM" as kali_vm {
component "Firefox 瀏覽器" as firefox
component "Burp Suite" as burpsuite {
folder "Proxy" as proxy
folder "Repeater" as repeater
}
}
rectangle "Ignition SCADA 系統" as scada_system {
component "Web 登入介面" as login_page
component "認證服務" as auth_service
}
pentester -> firefox : 訪問 SCADA 登入頁面
firefox --> proxy : GET /idp/default/authn/login?... (初始頁面請求)
proxy --> pentester : 攔截初始 GET 請求
pentester -> firefox : 嘗試登入 (admin:admin)
firefox --> proxy : POST /idp/default/authn/login (提交憑證)
proxy --> pentester : 攔截登入 POST 請求
pentester -> proxy : 將 POST 請求發送至 Repeater
proxy --> repeater : 載入 POST 請求
pentester -> repeater : 發送 POST 請求
repeater --> auth_service : 提交憑證與 Token
auth_service --> repeater : 回應 "Invalid token"
pentester -> proxy : 檢查 HTTP 歷史記錄
proxy --> pentester : 分析 GET/POST 請求序列
pentester -> proxy : 發現 OIDC GET 請求 (例如: /idp/oidc/...)
firefox --> proxy : GET /idp/oidc/... (OIDC 請求)
proxy --> auth_service : 請求 OIDC 資源
auth_service --> proxy : 回應 302 重定向 (包含 next-challenge token)
proxy --> pentester : 攔截 OIDC GET 請求與 302 回應
pentester -> proxy : 將 OIDC GET 請求發送至 Repeater
proxy --> repeater : 載入 OIDC GET 請求
pentester -> repeater : 發送 OIDC GET 請求
repeater --> auth_service : 請求 OIDC 資源
auth_service --> repeater : 回應 302 重定向 (**新 next-challenge token**)
repeater --> pentester : 顯示新生成 Token (無失敗通知)
note right of auth_service
OIDC (OpenID Connect) 用於身份驗證
生成 CSRF/next-challenge Token
end note
note right of repeater
重複發送請求,觀察 Token 變化
用於分析 Token 生成機制
end note
@enduml看圖說話:
此圖示詳細呈現了玄貓使用Burp Suite分析Ignition SCADA登入流程中CSRF Token生成機制的過程。首先,玄貓透過Firefox瀏覽器訪問SCADA登入頁面,並在Burp Suite的Proxy模組中攔截到初始的GET請求。接著,玄貓嘗試使用錯誤憑證登入,並攔截到提交憑證的POST請求,隨後將其發送至Repeater工具進行測試。Repeater的回應顯示「Invalid token」,這促使玄貓回溯HTTP歷史記錄,尋找Token的生成來源。玄貓發現了一個關鍵的OIDC GET請求,這個請求的回應中包含了next-challenge Token。透過將這個OIDC GET請求發送到Repeater並重複發送,玄貓成功觀察到每次請求都會生成一個新的、有效的next-challenge Token。這個過程揭示了Ignition SCADA如何利用OIDC協議生成動態Token來防禦CSRF攻擊,並展示了Burp Suite在逆向工程Web安全機制方面的強大功能。
Burp Suite Repeater進階應用與CSRF Token繞過實踐
玄貓認為,在面對複雜的Web應用安全機制時,如CSRF Token,滲透測試者必須具備深入分析其生成與驗證邏輯的能力。本節將透過Burp Suite的Repeater工具,演示如何動態獲取並替換CSRF Token,最終實現對Ignition SCADA登入機制的成功繞過,並探討自動化攻擊的策略。
動態獲取與替換Token:
1. Repeater會話管理:
- 如果您一直跟隨操作,您的Repeater工具現在應該包含三個分頁,每個分頁記錄著我們在不同階段提交的請求。這使得Repeater成為一個測試我們CSRF Token生成理論的絕佳工具。
- 再次點擊「發送」(Send)以生成一個新的OIDC Token。複製這個專用的Token。
2. 替換next-challenge Token:
- 現在,我們選擇標記為數字2的第二個分頁。您會發現我們上次嘗試生成
next-challengeToken失敗了。 - 將「請求」(Request)中的Token替換為我們剛剛生成的新OIDC Token。
- 再次發送請求。如果您正確地完成了這些步驟,您應該會收到一個
200回應,這表示操作成功。
3. 替換最終登入請求的CSRF Token:
- 太棒了!我們現在正朝著正確的方向前進。複製我們剛剛生成的
next-challengeToken。 - 點擊標記為數字1的Repeater分頁。您會注意到我們最初嘗試使用者名稱-密碼挑戰失敗,回應訊息是「Invalid token」。
- 用我們生成的
next-challengeToken替換CSRF Token。 - 再次發送請求。這次,您應該會收到一個
200回應碼,表明我們提交了一個有效的CSRF Token,並返回了一個JSON回應。我們可以看到success為false,這表明我們提供的憑證不正確,這符合我們的預期,同時也返回了一個有效的Response token。
成功繞過CSRF Token與驗證:
1. 使用正確憑證驗證:
- 我們現在希望驗證我們的假設是否正確。由於我們在ICS實驗室中安裝Ignition時使用了
scada:scada憑證,讓我們再次重複我們的流程,以確保一切正常運作。 - 這次,當我們使用
scada:scada憑證並替換正確的Token後,您應該會看到成功的身份驗證輸出。
2. 攻擊自動化考量:
- 至此,我們發現了一種生成獨特CSRF Token並暴力破解Ignition身份驗證的技術。
- 除了戰勝CSRF的喜悅之外,我們知道手動執行此操作將耗費大量時間,而在滲透測試任務中,我們沒有這種奢侈。
- 我們可以使用Burp Suite以多種方式自動化這些任務。如果您使用的是專業版(Pro version),您可以生成CSRF PoC。
- 然而,玄貓使用的是社群版(Community Edition),這意味著可以使用「會話規則」(Session Rules)來執行巨集,或者導入像「自定義參數處理器」(Custom Parameter Handler)這樣的Burp擴展。
- 由於社群版的節流限制,這類攻擊將耗費大量時間——可能不像手動執行攻擊那麼長,但對於我們的需求來說仍然太長。因此,要麼升級到專業版,要麼根據實際情況開發自己的腳本。這將在下一節中討論。
建立SCADA暴力破解攻擊腳本:
1. 程式設計與Bash腳本基礎:
- 玄貓假設您對程式設計和Bash腳本有基本的了解。如果您還不知道如何使用Bash腳本和/或Python,玄貓強烈建議您學習。這些是學習Bash和Python的功能和用途的絕佳資源。最重要的是,您將學會如何在滲透測試活動中應用這些腳本/程式語言。
- 玄貓將盡力使這個過程盡可能簡單。玄貓在前言中提到了這一點,因為玄貓充其量只是一個開發者,而不是一個程式碼編寫者。玄貓之所以引入這種區別,是因為那些希望透過編寫測試驅動應用程式謀生的程式設計師會嘲笑玄貓的程式碼。然而,玄貓可以肯定地說,使用玄貓的程式碼,玄貓可以從A點到達B點,坦率地說,最終結果對玄貓來說才是最重要的。
此圖示:CSRF Token繞過與自動化策略
@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
actor "滲透測試者 (玄貓)" as pentester
rectangle "Kali Linux VM" as kali_vm {
component "Burp Suite" as burpsuite {
folder "Proxy" as proxy
folder "Repeater" as repeater
folder "Intruder" as intruder
folder "Extensions" as extensions
}
component "自定義腳本" as custom_script
}
rectangle "Ignition SCADA 系統" as scada_system {
component "Web 登入介面" as login_page
component "認證服務" as auth_service
}
pentester -> repeater : 發送 OIDC GET 請求 (獲取 next-challenge token)
repeater --> pentester : 提供新 next-challenge token
pentester -> repeater : 替換登入 POST 請求中的 next-challenge token
repeater --> auth_service : 提交帶有新 token 的 POST 請求 (admin:admin)
auth_service --> repeater : 回應 200 (success:false, 有效 token)
repeater --> pentester : 顯示成功繞過 CSRF
pentester -> repeater : 再次替換登入 POST 請求中的 next-challenge token
repeater --> auth_service : 提交帶有新 token 的 POST 請求 (scada:scada)
auth_service --> repeater : 回應 200 (success:true)
repeater --> pentester : 顯示成功身份驗證
pentester -> burpsuite : 考慮自動化策略
alt Burp Suite Pro 版本
pentester -> intruder : 使用 Intruder 模組 (自動化暴力破解)
intruder --> auth_service : 大量憑證嘗試
else Burp Suite Community Edition
pentester -> extensions : 使用 Custom Parameter Handler (巨集)
extensions --> auth_service : 模擬自動化
pentester -> custom_script : 開發自定義 Python/Bash 腳本
custom_script --> auth_service : 實現高效暴力破解
end
note right of auth_service
CSRF Token 有效性驗證
憑證驗證
end note
note right of custom_script
利用程式設計能力
繞過 Burp Community 版限制
實現高效自動化攻擊
end note
@enduml看圖說話:
此圖示詳細闡述了玄貓如何利用Burp Suite的Repeater工具成功繞過Ignition SCADA的CSRF Token驗證機制,並進一步探討了自動化攻擊的策略。玄貓首先透過Repeater工具,動態地獲取了OIDC請求中生成的next-challenge Token。隨後,玄貓將這個新生成的Token替換到登入POST請求中,即使使用錯誤憑證admin:admin,也成功收到了200回應,證明了CSRF Token已被有效繞過。接著,玄貓使用正確的憑證scada:scada結合新Token,最終實現了成功的身份驗證。圖示也展示了玄貓對於攻擊自動化的思考:對於Burp Suite專業版,可以使用Intruder模組進行高效暴力破解;而對於社群版,則需要透過擴展(如Custom Parameter Handler)或開發自定義的Python/Bash腳本來克服其限制,實現自動化攻擊,這突顯了程式設計能力在滲透測試中的重要性。
縱觀現代Web應用滲透測試的多元挑戰,本次Ignition SCADA的CSRF Token分析不僅是一次成功的技術演練,更深刻體現了頂尖安全專家所需具備的核心素養。從使用Repeater手動追溯Token來源,到最終構思自動化腳本,整個過程揭示了從「工具操作者」蛻變為「問題解決者」的關鍵路徑。
此案例的價值在於,它清晰地展示了手動分析與自動化策略之間的權衡與整合。單純依賴自動化掃描器,將在如OIDC這類動態生成的客製化安全機制前束手無策;而僅僅停留在手動重複驗證,則會在實戰中因效率低下而錯失良機。真正的突破點,在於透過細膩的逆向工程建立深刻的理解,再將此洞察轉化為可規模化執行的自動化腳本。這不僅是技術能力的展現,更是分析思維與工程實踐的完美結合。
展望未來2-3年,隨著Web應用框架與認證協議日趨複雜,這種「手動分析建立模型,程式設計實現突破」的能力,將成為區分資深與初階滲透測試者的核心護城河。它代表了一種超越工具限制、直面問題本質的專業精神。
玄貓認為,深入掌握這類手動分析與腳本自動化的整合能力,已是頂尖滲透測試專家不可或缺的標誌。對於追求卓越的技術管理者而言,培養團隊具備這種從根本上解構並繞過防禦機制的能力,其長期價值遠勝於添購任何單一的自動化工具。