M15 · CTF
Network Extension 中間人位置——盤點誰站在你的流量路徑上
一台合成主機上裝了三個 system extension：一個預期內的企業 VPN（packet tunnel）、一個預期內的 EDR content filter、以及一個「未預期」的 content filter（簽章 Team ID 不在白名單、近期才註冊）。 你要從 systemextensionsctl 的盤點結果中，辨認哪個 NE 佔據了「流量必經的中間人位置」且不該存在， 並說明為什麼一個惡意/被濫用的 content filter 能攔截、重導、改寫流量——這是「位置」類別的信任問題， 不是某個 bug。全程唯讀盤點，不安裝/卸載任何 extension。
此關卡對應的模擬器（ne-flow）尚未提供。
過關目標
- 讓 inventory.unexpectedFilter.identified 達到 true
- 讓 inventory.falsePositiveCount 達到 0
- 用自己的話解釋：為什麼一個 content filter（即使本身沒有任何漏洞）一旦站在流量路徑上且不被信任，就構成中間人風險？這屬於「位置/信任路徑」類別還是「程式 bug」類別？你會用哪個唯讀指令把這類非預期中介盤點出來，又該如何把它接回 M14 的「網路 telemetry 可信度」？
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
先看每個 extension 的型別與位置——content filter 與 transparent proxy 站在「每條 flow 的必經之路」上，packet tunnel 則是建隧道。再比對簽章 Team ID 與註冊時間：白名單外、近期才出現的中介就是訊號。
走錯方向時
別只看「它有沒有漏洞」——這題的根因是「位置」。即使 NE 本身沒 bug，只要它站在流量路徑上且你不信任它，它就能做中間人。問題類別是信任路徑上有非預期中介，不是某個程式錯誤。
想更深入
安裝 system extension 需使用者核可 + entitlement + 簽章（接 M03/M04）。攻擊面常在「誰能讓使用者點下核可」——社交工程、MDM 推送、供應鏈。偵測點是 systemextensionsctl list 裡未預期的 content filter/proxy。