2025 年 10 月，Claroty Team82 發表對 Red Lion（Sixnet）系列遠端端點裝置（SixTRAK、VersaTRAK）之安全研究，揭露兩項嚴重弱點（已編為 CVE-2023-42770 與 CVE-2023-40151），均被評估為 CVSS V3 = 10.0。
攻擊者可利用 Sixnet 專屬協定之實作差異，在未經驗證情況下於 TCP 1594 連接上繞過驗證並執行任意 Linux shell 指令，而該指令以 root 權限執行，形成 pre-auth root RCE（遠端命令執行）。Claroty 與 Red Lion/廠商已發布修補與緩解建議，且 CISA 亦公開了相關公告。資產擁有者應立即評估受影響設備、套用廠商補丁，並在網路端阻斷或隔離危險通道。

利用流程

1. Sixnet Universal 協定概述

2. 驗證繞過（CVE-2023-42770）— TCP 路徑不做驗證

3. 遠端 root RCE（CVE-2023-40151）— 協定內置 shell 執行功能被濫用

漏洞成因

這類「未經驗證的 pre-auth root RCE」漏洞並非單一程式錯誤，而是幾個設計與實作失誤疊加的結果。把技術面原因與流程／管理面根因分開列出，每一項都附上可行的對應緩解建議，方便組織做現場稽核或寫成報告的「原因→對策」段落。

1. 技術／程式實作層面的成因（Why it happened）

1. 協定處理路徑不一致（TCP 與 UDP 使用不同的解析流程）

1. 問題：原本的驗證流程只在 UDP 路徑實作（或使用 get_message_authenticated），而 TCP 路徑調用不同函式並未強制驗證，導致 TCP 成為繞過點。
2. 後果：攻擊者只要透過 TCP 格式化封包即可觸發高權限功能。

2. 存在可由協定下達的高權限命令（內建 shell/command feature）

1. 問題：設備協定包含直接執行系統命令或 shell 腳本的 function code（管理工具/維護功能被內建在協定上）。
2. 後果：一旦繞過驗證，攻擊者即可直接以 root 執行任意指令。

3. 缺乏邊界檢查與輸入驗證（封包內容/長度/欄位未嚴格檢查）

1. 問題：協定解析器接受不完整或預期外的字段，未做嚴格邊界檢查。
2. 後果：有利於構造異常封包造成程序流程跳轉或觸發未預期功能。

4. 預設或弱的預設設定（開放管理埠、預設帳號/功能）

1. 問題：設備預設允許管理通訊埠在未限制網段下可達。
2. 後果：攻擊面被放大，尤其在網路分段不良或遠端存取未控的情況下。

5. 回溯相容 / 遺留程式碼

1. 問題：為保持相容性，保留老舊處理流程或工具（如舊版 Toolkit），導致新安全控制未完整套用。
2. 後果：泛用性越高、老舊代碼越多，漏洞面越大。

2. 流程／組織面（根本原因）

1. 設計階段缺乏威脅建模（Threat Modeling）：未預先分析「管理協定可能被濫用」情境，或未把管理通道視為高風險攻擊面。
2. 不完整的安全開發生命周期（SDL）與測試策略：缺乏對協定解析器、邊界條件與傳輸層一致性的安全測試（如 fuzzing、協定模糊測試）。
3. 供應商測試與驗證不足：驗證流程依賴工程工具（toolkit）測試正常，但未檢視所有 transport/legacy path。
4. 資安意識與分段策略不足（OT 網路設計）：OT 網路可能未做到嚴格分段或管理通道沒有跳板/多因子驗證等保護。

風險與影響評估（對 OT/ICS 環境）

1. 可造成即時控制中斷或操作錯誤：若攻擊者以 root 權限改寫輸入/輸出設定、停止或誤導控制邏輯，可能導致生產停擺或物理設備損壞。
2. 橫向移動與供應鏈風險：被入侵之 RTU 若連接 SCADA、PLC 或 HMIs，攻擊者可視情況橫移進一步入侵關鍵資產，或作為內部跳板。
3. 資料完整性／可用性威脅：攻擊者可刪除/竄改紀錄、阻斷通訊、或安裝後門程式，長期影響系統檢測與回復。
4. 法規與合約風險：被入侵導致服務中斷或資安事件，可能帶來監管罰則、合約賠償與聲譽損失。
5. 綜合評估：由於 CVSS 為 10.0 且可取得 root，對工業控制環境屬於「高危且高影響」事件，應列最高優先級處理。

偵測建議（Indicators of Compromise / 偵測策略）

1. 網路層：監控內/外部對 TCP 1594 的連線嘗試（含來自非管理主機的來源），建立警示規則並記錄封包內容長度與頻率。
2. 協定層：若可能，對 Sixnet 流量進行協定解析（辨識 function code 0xd0 0x1e 等用於 shell 執行的指令），偵測可疑執行命令封包。
3. 主機層：發現非排定的 root 指令、異常進程、或新增可疑執行檔時觸發主機告警。
4. 行為指標：異常的裝置回傳（如在非維護時段回傳大量 shell output），或設備參數突變（station number、boot version 變更等）亦應納入偵測規則。

安全為設計核心

避免產品有這類型漏洞的方法之一，是Secure by Design。從 Secure-by-Design（以安全為設計核心） 的全生命週期角度，建立一套可直接套用到 OT/RTU/嵌入式通訊裝置（像 Sixnet 這類產品）上的安全設計方法，內容包含高階原則、具體設計模式、程式/協定、測試/驗證策略。

1. 核心原則（總覽，先背好這幾句話）

1. 最小權限（Least Privilege）——任何功能只給必要權限，尤其是遠端管理操作絕不以 root 預設執行。
2. 防禦深度（Defense in Depth）——多層防護：協定驗證、網路隔離、主機保護、監控皆不可少。
3. 安全預設（Secure Defaults）——出廠設定閉鎖管理埠、禁用高風險功能，啟用需經管理者顯式開啟。
4. 一致性（Fail-safe & Consistency）——不同傳輸層（TCP/UDP/Serial）採用完全一致的驗證與授權邏輯。
5. 可審計（Auditability）——所有高權限操作要可追溯、紀錄與不可否認。
6. 可更新與可恢復（Patchability & Resilience）——韌體簽章、安全更新機制、回滾路徑。

2. 具體設計模式（產品/協定/韌體層面）

1. 協定層：統一且強制的認證與授權

1. 不要在某個 transport（如 UDP）實作驗證，而在另一個（TCP）跳過。所有 transport 入口都呼叫同一個認證中介（auth middleware）。
2. 使用標準安全機制：mutual TLS 優先；若不能（資源受限），至少使用預共享金鑰與 HMAC (e.g., HMAC-SHA256) + nonce + sequence number 防重放。
3. 每一項「可執行命令」功能需有最小授權分級（role-based access）與會話票證（session token），不可透過單一 raw 協定 field 執行任意 shell。

2. 刪除/隔離高權限命令（Design for no remote shell）

1. 不要在協定中提供 raw shell/execution opcode。若確有必要，應僅提供「受限管理 API」：用白名單的操作、參數限制與可審計輸出。
2. 如果要執行系統命令，請在本地以最低權限 proxy，由受控 daemon 以受限權限（capabilities）執行，且紀錄完整輸入、輸出與執行者身份。

3. 權限分離與 Capability Model（嵌入式推薦）

1. 運行時以 Linux capability（例如 drop CAP_SYS_ADMIN）、或使用 sandbox（seccomp）來限制進程能力。
2. 把管理功能與實際 I/O 控制拆成不同 process，使用 local IPC（受控）溝通，避免單一進程被濫用取得 root。

4. 輸入驗證與邊界檢查（Robust Parsing）

3. 協定解析器必須採「白名單解析」而非「黑名單」；檢查所有欄位長度、數值範圍與型別；任何解析錯誤都應安全失敗（fail closed）。
4. 使用自動化模組化解析器（例如使用生成器產生 packet parser，包含 field constraints），並加上單元測試。

5. 預設網路與管理面安全

1. 管理埠（如 TCP/1594）出廠預設為關閉；出廠時強制先進入安全配對流程（local physical button / serial console pairing）才允許開啟遠端管理。
2. 強制管理通道經由跳板（jump host / bastion）或 mutual-TLS VPN 存取，並採用 MFA。
3. 支援網路分段：RTU 僅能接收來自 SCADA/DMZ 管理網段的流量。

6. 韌體安全：簽章、加密、更新流程

1. 所有韌體映像簽章（vendor key），設備在更新時檢查簽章與版本號，拒絕未簽章或回溯版本（版本回滾策略）。
2. 強制加密更新通道，並提供回滾保護與驗證。
3. 公布安全更新 SLO 與 EOL 政策，且提供供應商安全聯絡窗口。

3. 開發流程與 SDLC 控制（組織/流程）

1. 在需求階段做 Threat Modeling（STRIDE/Dataflow），列出管理協定、傳輸層、指令集等攻擊面；標註高風險功能（如 remote exec）。
2. SDL Gates：在 CI/CD 內加入 SAST、依賴性掃描（SBOM）、秘密檢測、以及合格的 fuzzing/DAST 入口；任何高風險變更需安全審核門（security approval）。
3. 代碼審查：對所有處理 network input 的代碼做強制 code review，並使用安全 checklists（例如檢查所有 parser 是否做邊界檢查、是否有使用非安全函式等）。
4. 第三方評估：發布前做第三方滲透測試或紅隊（包含協定層 fuzzing、TCP/UDP 差異路徑測試）。
5. 安全回報機制（Vulnerability Disclosure Program）與賞金（若可行），快速回應通報。

4. 測試與驗證策略（如何驗證沒有像 Sixnet 的錯誤）

1. 協定一致性測試：自動化測試用例覆蓋所有 transport（UDP、TCP、Serial），確保同一消息在不同 transport 的處理結果一致（包括驗證/授權步驟）。
2. 模糊測試（Fuzzing）：針對協定解析器做深度 fuzz（可用 AFL、libFuzzer 或專用協定 fuzzers），包含變異、邊界、亂序、分片。建立 corpus 包括正確封包與已知邊界情形。
3. 功能最小化測試：驗證「不存在遠端 shell」——嘗試通過協定觸發系統命令且檢查是否被拒絕。
4. 安全回歸測試：每次修改協定處理或更新函式時，執行自動化安全回歸（包含快速模糊用例）。
5. 威脅導向測試劇本：建立攻擊劇本（e.g., unauth TCP path, replay, forged sequence），並定期在測試床上演練（CI 中自動化測試）。

5. 偵測/監控/應變（Design for Detection）

1. 設計協定時加入可審計欄位（request id、caller id、rolling nonce），讓所有管理請求被記錄與關聯。
2. 在設備端與上位監控端均保留：連線來源、session id、請求類型、高權限操作執行紀錄（stdout/stderr 摘要），保留期限視法規/合規要求。
3. 針對協定封包行為建立 IDS 規則（例如識別帶有 command opcode 的封包從非管理 IP 來源來）。
4. 準備 Incident Response playbook：若偵測到可疑 shell exec，應自動隔離該裝置、啟動採證流程並通知供應商。

威脅建模 (Threat Modeling)

以下是是參考Sixnet RTU 或同類嵌入式控制設備，適用於 OT／ICS 類產品的 Threat Modeling 範例，以 STRIDE 方法與 Data Flow Diagram (DFD) 進行設計：

1. 基本資料

欄位	說明
系統名稱	例：Sixnet-type RTU 通信模組
建模日期	YYYY-MM-DD
版本／韌體	v X.X.X
建模範圍	協定層（TCP/UDP 1594）、管理介面、韌體更新模組、SCADA 通訊 I/O
負責單位	系統設計 / 安全架構 / 測試 / 供應商

2. 系統資料流圖（DFD）

元件編號	元件名稱	描述	安全邊界
P1	工程師工作站	執行設定與監控軟體 (IO Tool Kit)	企業 IT 網段
P2	RTU 裝置	接收管理命令、執行 I/O 控制 / 韌體更新	OT 網段
P3	SCADA 伺服器	收集 RTU 資料、下發控制指令	DMZ / OT 邊界
D1	本地設定檔	儲存裝置組態、金鑰、密碼	需加密保護
F1	TCP 1594 通訊通道	專有協定通訊路徑 (TCP/UDP)	邊界跨越點

3. 威脅分類 (STRIDE)

威脅編號	威脅類型	威脅描述	影響	目前控制	建議補強
T-01	Spoofing	攻擊者偽造 合法 IO Tool Kit 封包	執行未授權命令	僅 UDP 驗證	統一 TCP/UDP 驗證、HMAC 挑戰機制
T-02	Tampering	封包內容 被竄改	指令誤執行	無 完整性檢查	加簽 封包 HMAC
T-03	Repudiation	操作者 否認 遠端操作	追蹤困難	未記錄 來源	建立 審計 日誌 + 請求 ID
T-04	Information Disclosure	未加密 通訊	洩露 帳密	明文 協定	TLS 或 VPN 隧道
T-05	Denial of Service	大量 1594 封包 癱瘓 RTU	服務中斷	無 速率限制	封包 速率 控制、資源 隔離
T-06	Elevation of Privilege	利用 TCP 繞過 驗證 直達 root	完全 掌控 系統	權限 未分離	權限 分離 、 sandbox 、 強制 授權

4. 資產與風險分析

資產類別	範例資產	保護目標(C/I/A)	威脅影響 (高/中/低)	緩解策略
通信通道	TCP/UDP 1594 協定	I、C	高	統一 驗證 、 加密
控制邏輯	I/O 控制指令	I、A	高	授權 分層 、 白名單
韌體	系統 映像檔	I、A	高	簽章 驗證 、 安全 更新
認證資料	使用者 帳密、金鑰	C	高	加密 儲存 、 MFA
日誌	審計 與 追蹤 紀錄	I	中	防竄改 、 集中 SIEM

類似產品／已發現漏洞實例

參考Claroty Team82的研究，以下是幾個具體裝置／產品，具備可能與 Sixnet RTU 漏洞相似的特徵，或已被發現有遠端程式執行／命令注入風險。雖然不一定完全相同機制，但在風險評估時應列為高度關注對象。

1. INEA ME RTU

1. 根據報導，INEA ME RTU　韌體版本 3.36 之前存在「作業系統指令注入（OS Command Injection）」漏洞，可讓攻擊者遠端執行任意程式碼。
2. 此漏洞特徵與 Sixnet 的「預授權命令執行」相似（雖然可能仍需某些前置條件），提醒我們「RTU／邊遠終端設備 + 通信模組 +遠端存取／無強認證」為高風險組合。

2. Martem Telem-GW6／GWM 系列 RTU

1. 在歐洲能源分布網路中，一款 RTU 裝置被發現可任意指令執行或造成服務中斷（Arbitrary Code Execution／DoS）等高危漏洞。
2. 雖然未必報導為 root 權限 RCE，但具有類似「遠端控制終端設備」的攻擊面。

3. 各主要 ICS／DCS／RTU 供應商產品中普遍存在的設計弱點

1. 論文指出：在檢視 45 個部署於關鍵基礎設施中的 OT 產品族群後，它們「至少一項容易的漏洞」存在，尤其是授權控管、協定處理、命令執行、網路攻擊面。
2. 也就是說，不只是特定品牌，而整體產業有「類似型攻擊面」潛在風險。

為什麼「可能存在相同漏洞」的條件

基於上述與 Sixnet 案件特點，我們可以歸納出若干「高風險條件」／「漏洞可能性指標」，在顧問評估時可用於篩查：

1. 裝置為 RTU／Telemetry Terminal Unit／邊遠 I/O 模組，特別用在 OT／SCADA 環境。
2. 裝置使用專有通訊協定（或變種）／或混用 UDP／TCP、未充分驗證通道。
3. 裝置預設遠端管理或配置功能強，並可能包含可執行命令、shell 或腳本操作功能。
4. 裝置內部有「management protocol」或「I/O tool kit」連線通道，可能被誤配置／暴露。
5. 裝置韌體更新難、停機成本高、分布於廣泛 OT 網絡中，容易被忽視安全加固。
6. 既往有供應商公告其 RTU、PLC、IED 等設備發生遠端程式執行／命令注入問題。
7. 如果一款裝置符合以上一或多項條件，那麼就應被納入「潛在存在類似驗證繞過 + RCE」的風險清單。

建議納入檢查的「其他品牌／產品範疇」
在組織進行風險分析／控管清單設計時，建議將以下產品範疇列為檢查重點，並視情況深入調查其是否有類似漏洞：

1. 各品牌 RTU／RTU 系列（如 Schneider Electric、ABB、Siemens、Hitachi Energy、Honeywell、Schweitzer/SEL 等），例如：

1. Hitachi Energy RTU500 系列於 IEC 61850 協定實作中發生漏洞。
2. Schneider Electric 公告中亦涵蓋其 RTU/SCADA 裝置曾受「遠端程式執行」／「針對通訊協定缺陷」影響。

2. 邊遠 I/O 模組／資料集中器（Data Concentrator）裝置，常見於電力、水處理、交通系統，Martem RTU 即屬此類型。
3. 支援遠端通訊（4G/Cellular、VPN、LTE/IoT 網路）裝置，例如 INEA RTU 包含 4G LTE 連線模組。
4. 裝置韌體/固件更新機制弱、或已停產／支援有限之產品，容易成為「零補丁」狀態。
5. 使用專有通訊協定、管理工具或配置工具，該工具可能具有「遠端命令執行」功能（相當於六網 RTU 的 shell 功能）。

日常工作及稽核視角下的建議措施

基於上述，建議在組織的日常工作或稽核流程中，納入以下流程以檢查「類似 Sixnet RTU 漏洞群」的風險：

1. 資產清單擴展：除了 Sixnet RTU，將所有 RTU／邊遠 I/O 裝置納入清單，記錄型號、通訊協定、管理通道、遠端接口。
2. 通訊端口與協定檢查：查核裝置是否在常見管理或配置端口（如 TCP/1594 、UDP/1594 或專有協定埠）開放，並檢視是否支援 TCP 且未強制驗證。
3. 驗證與命令執行檢查：審查裝置管理協定是否存在「無驗證路徑」或「shell／命令執行功能」可被濫用。
4. 韌體版本與補丁狀態：查核供應商是否已公告漏洞、是否提供修補，裝置是否為最新版本。
5. 隔離與最小權限設計：對疑似高風險裝置進行網路分段、限制對外 TCP/UDP 埠存取、強化跳板主機或管理 VLAN。
6. 監控與偵測：建立對管理協定流量（如 RTU 專有協定）與非典型流量（如 TCP 管理埠、來自非管理 IP 來源）之監控、日誌與告警。
7. 供應鏈與持續風險評估：評估裝置供應商是否具備安全設計流程、是否支持長期 EoL／固件更新、是否公開安全公告。
8. 事件應變機制：對於可疑活動（如非管理通道的連線、異常命令執行）建立快速隔離與採證流程。

供 OT/ICS 團隊執行參考的具體檢查清單

1. 盤點：列出所有 Red Lion SixTRAK/VersaTRAK 裝置及其 IP、韌體版本。
2. 封鎖：在邊界防火牆與內網 ACL 中封鎖 TCP/1594（非維護/管理網段）。
3. 補丁：確認是否已依廠商或 CISA 指示套用修補或廠商緩解步驟。
4. 日誌：開啟並保留 RTU 及周邊設備的連線/系統日誌，至少保存 90 天以利事後分析。
5. 偵測：在 NIDS/IDS 中新增規則，識別 Sixnet shell 執行指令及非典型 TCP 1594 流量。
6. 主機掃描：對裝置執行完整性檢查、檔案比對、啟動項與 crontab 檢查。
7. 事件通報：若發現可疑活動，依公司事件通報流程通報資安小組與廠商支援。

優先處理建議

Claroty Team82 之研究顯示：Red Lion Sixnet RTU 的設計實作在協定處理路徑上存在致命差異，攻擊者可藉由 TCP 路徑繞過驗證、並利用協定內建之 shell 執行功能以 root 權限執行任意指令（兩項 CVE 均評等為 10.0）。對工業控制系統（尤其直接關聯關鍵基礎設施流程者）而言，此類漏洞屬高風險且需立即處理。建議資安與 OT 管理階層將此事件列為最高優先級：立即封鎖 TCP/1594 可疑連線，立即確認並套用 Red Lion 官方補丁，並同步強化監控與分段隔離措施，完成後進行全面盤點與長期治理改善（包含供應商協議與遠端存取管控）。
 
參考資料：https://claroty.com/team82/research/roaring-access-exploiting-a-pre-auth-root-rce-on-sixnet-rtus