HITCON 2026

Posted on | Post modified | In | |

HITCON 2026

事前提醒

不管是哪一個議場，建議一定要提前去佔位子，至少不用找插座或是還需要站著(雖然椅子很矮很難坐😒)，另外， Workshop 的形式一定一定一定要提前 30 分鐘去排隊，通常熱門的只要少於30分鐘，很快就會被搶光，尤其是今年，現場只有30多個位子，也無站位，所以排的數量只要大於30，基本上就可以去別的地方

以下部分內容來自 HITCON 共筆

08/21

  • ❌11:20–12:40 - Look Ma, No Hands! Constructing Autonomous AI Offensive Agents Using MCP and HexStrike-AI - AI,MCP,Pentest

11:20–12:40 - Vulnerability Disclosure in the Age of AI

James Forshaw - author

先講很多和漏洞公開的歷史，包含一些重大資安事件，像是 Morris Worm 等等，導致後續的很多情資平台的建立，例如 Bugtraq, Computer Emergency Response Team Coordination Center (CERT/CC)等等

另外提到很重要的觀念: 漏洞揭露的目的是給 Vendor 告知資安問題以及告知使用者

  • 揭露給廠商: 1999 - Common Vul Enueration List / The MITRE Corp.
  • 揭露給使用者:
    • 200x: vulnerability 開始可商業化
    • 2002 iDefense Vul Contributo Prog.
    • 2007 Start of PWN2OWN
    • 2009 No more free Bugs
    • 2009 Operation Aurora
    • 2014 Proj. Zero Begins
      • Factors Determining Disclosure Policy
        • Knowledge: who know the vulnerability
        • Severity: 漏洞多嚴重
        • Complexity
        • Impact: 影響範圍有多廣
      • Project Zero’s Know. based Discosure Policy

所以 AI 帶了的衝擊有哪些

  • 傳統: reverse engineering / fuzzing (分析) → poc / crash analusis (驗證) → report
  • 現在: 通通丟給 LLM 做
    • exploitbench.ai: 由卡內基梅隆大學（Carnegie Mellon University, CMU）的研究人員與 Bugcrowd 共同開發的專門評估 AI 模型的網路安全基準測試平台。它的主要目的是測試大語言模型（LLM）在真實軟體環境中發現漏洞、理解漏洞並編寫攻擊程式（Exploit）的能力。
    • vulnpocalypse: 由 vulnerability（漏洞）與 apocalypse（末日、災難）結合而成的新字，指的是：AI 工具能以極快速度發現軟體或資訊系統漏洞，但人類與企業修補速度卻跟不上，最終可能導致全球網路攻擊暴增的災難性情境。
      • 2026年7月微軟發布了歷史上規模最大的 Patch Tuesday 例行更新，共修補了 622 個微軟產品漏洞（CVE）。此次更新創下單月修補數量最高紀錄，主要歸功於微軟導入了 AI 漏洞挖掘系統（MDASH） 來加速除錯。
      • Google 在 2026 年 7 月 29 日 對 Chrome 瀏覽器進行了大規模的安全更新，一次修復了高達 370 個安全性漏洞，並將瀏覽器版本推進至 151.0.7922.71
  • How to React as a Researcher?
    • Poor Vendor.
    • Bug is probably a Dupe(謊言).
    • Anyone can find this bug with AI.

  • Existing Assunptions Break Down (既有假設正在瓦解)

    過去漏洞研究圈預設「找洞很難、門檻很高」，但 AI 讓這個假設不再成立，於是要重新拆解「找洞的門檻」到底是由哪些因素組成：

    • Expertise（專業知識）：以前要資深研究員才找得到的洞，現在誰有能力找到？
    • Access（存取權）：靠公開/開源模型就能找到，還是得用特殊、受限的模型或內部工具？
    • Cost（成本）：找到這個洞要花多少運算資源/金錢？
    • Novelty（新奇性）：這種洞是不是任何模型都能找到的「通用款」，還是需要非常規、創新的手法才挖得出來？

    這四個維度共同決定「AI 找洞的可及性」。

  • Multiple Tiers of Vulnerabilities: 依照 AI 能不能找到、以及找到的成本高低，把漏洞分成 A~E 五級：
    • A. 用便宜模型直接找
    • B. 用非公開或是貴的模型找
    • C. 沒辦法直接探索
    • D. 困難，或是天價貴的找
    • E: 現有模型無法找出

    這其實是在說：AI 沒有讓所有漏洞「一視同仁」變得好找，而是重新畫出了一條新的難易度光譜。

What can Project Zero do?

Project Zero 原本的揭露政策是「90 天揭露期限 + 30 天 patch soak(讓廠商更新後，使用者有緩衝期安裝更新才公開細節)」。

  • 90 → 60 + 30：討論把揭露期限從 90 天縮短為 60 天（因為 AI 加速了攻擊者的武器化速度，防守方也該加快步調），後面仍保留 30 天的 patch soak。
  • +30 patch soak → none：更激進的選項是直接取消這 30 天緩衝期。
  • Improve fix verification：加強修補驗證，確保廠商的 patch 真的修好了、沒有留下 variant 或重新開洞（這在 AI 輔助找洞時代更重要，因為 AI 也能快速驗證/繞過不完整的修補）。

廠商能做什麼（What can vendor do to improve）

研究者能做什麼（What can researcher do to help）

Facebook engineering blog 的「Escaping the fork-」，主題應與「如何讓修補更快擴散到各個 fork/衍生版本」有關，暗示研究者可以協助解決修補傳播的碎片化問題。

Slop（AI 垃圾報告問題）

「Slop」是業界對 AI 生成的低品質/幻覺內容 的戲稱。這裡的雜湊值和 gist 連結：

Daniel Stenberg 是 curl 專案的維護者 Daniel Stenberg，他長期公開抱怨/紀錄 curl 收到大量「AI 生成、看似合理但實際是幻覺」的假漏洞報告，浪費維護者時間。這個連結應該是被拿來當作 AI slop 問題的實例佐證。問題在於報告者沒有真正驗證漏洞是否存在

「獎勵那些報告寫得比較好的」：這是對抗 AI slop 的建議之一——賞金/獎勵機制應該偏向獎勵「品質高、經過驗證、寫得清楚」的報告，而不是量多但品質差的 AI 亂槍打鳥式報告，藉此過濾雜訊、鼓勵研究者好好把報告寫完整。

14:00–14:40 - Pwn2OwNothing: When a KVM Full-Chain Escapes to Emptiness - Pwn2Own,RHEL KVM

Bruce Chen、Pan Zhenpeng、Weiming Shi、Jheng Bing Jhong - author

Pwn2Own 項目 - ZDI 舉辦

  • 虛擬機逃逸
    1. KVM - QEMU/KVM

      https://share.google/aimode/a1MMOypKpulReAwJA

    2. VMware - ESXi
    3. 微軟 Hyper-V

    https://share.google/aimode/2SiG9WuZWuwnL9KLF

  • 作業系統提權
  • Browser Full Chain
  • 還有其他

要先了解 QEMU-KVM

1st Attempt - Attack QEMU/KVM

先丟 RHEL(QEMU 套件 Ver. 10.0.0.14) 的 source code 到 LLM(Opus 4.6) → 列舉容易出問題的 Component

  • hw/display/virtio-gpu.c → virtio_gpu_simple_process_cmd(): GPU command 在處理時會有大量可控的輸入，而且處理邏輯也比較複雜(越容易出問題)
  • Bug Hunting: 用 Multi-Agent 以及 subagent 讀 switch case 提升挖掘的速度
  • 漏洞一: calc_image_hostmen integer overflow: 沒有判斷 32 bits sign integer 的 buffer size → BOF → OOB write → CVE-2026-3886(DEVCORE)(是個 N-day) → 還需要一個 Info Leak 的漏洞，找到 memory address
  • 漏洞二: 寫入 _rtld_local → 控制 function pointer → 可以關機 KVM
  • 漏洞三: Info Leak bug in SLIRP(在 QEMU 中用來處理網路封包的 component) → CVE-2026-9539
  • ZDI 回報: 必須使用 VM manager 而不是 custom startup script → 不能使用 SLIRP
  • Cockpit 會啟動 seccomp sandbox 保護 Guest VM
  • SELinux: user:role:type/domain:MCS:level → 使用 rule 和 policies 更加保護傳統的 linux 使用的 RWX 權限控制
    • MCS level: VM 之間不能互相溝通
  • Intel CET(Control-Flow Enforcement Technology): 要看 user/kernel space 有無支援
    • SHSTK (Shadow stack) → 不能 ROP
    • IBT

2nd Attempt

  • 找另外一個 info leak bug → 叫 Opus 利用 OOB Write 找 info leak bug
  • 透過 Bug 1 OOB write → 利用 AI 找 COP/JOP attempt → 因為 glibc 會把 SHSTK 關掉(在 user space) → 可以用 ROP
  • Overwrite /proc/self/mem 讀寫 process 本身的記憶體 → 跳是先寫好的 shellcode
  • 之前以為有 SHSTK 所以 ROP 不能用，但最後 AI 還是找到一個可以用的 ROP Chain ，因為 SHSTK 被 glibc 關掉了，為了程式相容性

提權

  • Use CVE-2026-23394: race condition in unix_gc
  • DirtyMode: Data-Only Exploit Technique
  • Arbitrary Mem. decrement primitive in sk_buff

有四個問題需要解決，但我沒紀錄到

最後一步: Cross Tenant Attack → Pagecache attack

15:10–17:30 - Hands-on IoT firmware extraction and forensics workshop - IoT,Hacking 101

Dennis Giese、Arnold Wey

抱怨環節

真的學不到什麼東西，因為雖然大會給了很多時間，但是現場的器材根本不夠，我覺得他們不太有很多這種現場 demo 的經驗，包含控場、人數以及材料數量等等，都是事前需要規劃，所以到最後我們只有利用 Pre-Heater + heat gun 去除 Amazon Echo Dot 這個 Target 的 memory 晶片，原本預設是大家把晶片去除之後要去讀取裡面的資料，包含 router ip 或是加密演算法等等，再把晶片焊回去並且要是 Target 正常運作，結果由於上述原因，現場大部分的人都在等器材，所以只能把 chip 拿下來而已，整個過程非常沒有效率

在這場，我學到的東西，只有小型英文聽力測驗 + 夢回高中的焊接生活(器材精密很多，市面上也不常見，但基本原理一模一樣) + 充當隔壁兩個高中生弟弟的翻譯?

就算這一場的所有流程都順利走完，也還是有點失望，畢竟和我原先期待能學到的東西有巨大的落差，由於工作需要，未來可能需要做到 IoT 的滲透，所以希望是能夠手把手的教學如何做到這件事，而不只是讀資料而已，畢竟在工作現場也不太會做到這件事

  • 作者的 Blog: https://dontvacuum.me
  • 作者提供的 PPT: https://drive.google.com/drive/folders/1RwwRBHR30_UaBPgl76_RM6ZMFe3OU1v4?usp=sharing
  • 作者的論文 https://dl.acm.org/doi/epdf/10.1145/3448300.3467820 : 有興趣更加了解這一堂課會學到的東西，可以直接看他的論文

目標

  1. 了解 IoT 設備的 Security & Privacy Risk
  2. 了解 IoT 設備的儲存元件
  3. 實際體驗 chip-off 的技巧

如何拿到 firmware 和 data

  • Retrieve OTA(Over-The-Air update), if possible: 設備如果有 OTA 更新機制，透過網路下載更新韌體
  • Root device and extract firmware + data: 如果拿不到 OTA ，就從已經能正常執行的裝置裡面把東西拉出來
  • Extract firmware + data from flash: 最底層的做法，要先
    1. 在 PCB 上找 flash chip: 課程發的 Echo ，背後有 FCC ID ，可以先到 https://fccid.io/ 找該設備的資訊(FCC ID 2AHSE-2045) 
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      FCC ID
↓
產品 / Model
↓
Internal Photos
↓
PCB
├── SoC
├── Flash
├── RAM
├── Wi-Fi / Bluetooth chip
├── antenna
└── test points
    2. 查該 flash chip 的datasheet ，確認型號、容量、電壓以及 pinout 等等，例如此次課程的內部 chip 是 美光的 JHA98 JWB30

Flash 的種類

詳細每一種類型特點，可以繼續看 slide

實際的 Target

目前的這一顆美光記憶體是 eMCP IC，有 eMMC flash 和 DDR3 RAM 和 SoC 溝通，我們有可能可以從這一個元件得到以下資訊

如何拿到資料

  1. 非破壞方式
    1. Shell: 查看哪裡有
      • UART(Universal Asynchronous Receiver/Transmitter，中文通常叫「通用非同步收發器」) 也就是電腦和板子之間的溝通地方，通常是 TX/RX/GND
      • ADB
      • Telnet
    2. JTAG
    3. ISP(In-System-Programming): 不把晶片從電路板上拆下來，直接透過電路板上的介面對晶片進行寫入、更新或重新燒錄。和 UART 不一樣，UART 是一種通訊介面，而ISP 是一種「在裝置仍然裝在系統裡進行程式寫入」的概念／方式。
  2. 破壞性方式: 就是今天的方式
    • 有些情況是已經知道晶片拔下來之後，PCB 對應的端點哪裡可以看資料，那就直接針對該點進行探針讀取，就不需要焊接銅線
    • 有時候要個別走線出來讀取資料

詳細的拆除過程與讀取資料

可以看網路上一些短影片，步驟一模一樣 CHIP OFF - Redmi note 11 “Spes”

然後透過 reader(類似chip off moto g32看到的裝置) 然後開一個特別的軟體就讀到 router IP/加密演算法等資訊

不過由於 demo 當時我在 chip-off 所以沒仔細看到，但根據以下 AI 提供的資訊，我想應該可以概略一二

確認晶片封裝與硬體選擇 (Reader)

晶片拆下後，首先要看它的封裝形式與通訊介面，這決定了你需要購買哪種讀取器和轉接座（Socket）：

  • SPI NOR Flash (常見封裝：SOP8, DIP8, WSON8)
    • 常見晶片：主機板 BIOS、路由器韌體（如 Winbond, Macronix）。
    • 推薦讀取器：
      • 平價首選：CH341A 程式燒錄器（非常便宜，適合新手）。
      • 專業進階：RT809F 或 XTW100。
    • 必備配件：SOP8 轉 DIP8 燒錄座（或是彈簧晶片夾，免焊接直接壓住晶片腳位）。
  • NAND Flash / EMMC (常見封裝：TSOP48, BGA63, BGA153)
    • 常見晶片：隨身碟、SSD、手機記憶體、智慧電視主晶片。
    • 推薦讀取器：
      • 專業維修級：RT809H（支援度極廣，通殺大部份 TSOP48/BGA）。
      • 萬用燒錄器：希爾特 (Xeltek) SuperPro 系列（工業級，價格較高）。
      • 手機/分體救援專用：EasyJTAG Plus 或 Medusa Pro。
    • 必備配件：需要對應封裝的轉接座（例如 TSOP48 翻蓋座，或 BGA 專用定位座）。

搭配使用的軟體 (Software)

硬體讀取器必須搭配專用的電腦軟體才能將資料導出（Dump）為 .bin 或 .hex 的鏡像檔案。

  • 配合 CH341A 燒錄器：
    • AsProgrammer 或 NeoProgrammer：開源且完全免費，支援晶片種類比原廠軟體多，且不會有驅動程式相容性問題。
    • CH341A Programmer：原廠內建軟體，介面簡單。
  • 配合 RT809F / RT809H 燒錄器：
    • RT809 官方控制軟體：買硬體時會附帶，軟體內建龐大的晶片資料庫。只要輸入晶片型號（例如 W25Q64），軟體就會自動設定好電壓與讀取參數。

一些現場的照片

08/22

10:10-10:50 - Out of LINE：一張 QR Code 盜走全球手機 - RCE

Flydragon 林紘騰 - author

這一場有夠靠北，超級臭 Line ，而且感受到怨念超深

Motivation

  • Android App 超多
  • 透過 LLM → Bounty → 發財: 全自動找洞成效有限，但有些需要人工提供思路
  • Line 使用率高、很爛、是 hitcon 贊助商

Phase 1 - Android 101

  • Intent: 執行操作請求
  • one click
  • Deeplink/URL Scheme handler (Line 註冊超級多 Handler)

Phase 2 - 聊天室 DoS

通話: libandromeda.so

  • webrtc
  • memcpy_chk

主要檢查 overflow ，發現 zone_1 使用者可控 → 1 byte overflow → Remote DoS， 不過不合法 zone 沒辦法撥出 → 需要打下 Line SIP server

What is SIP Server: SIP（Session Initiation Protocol）線路 與 SIP 伺服器 的完整介紹。它們是現代網路電話（VoIP）與企業通訊系統的核心技術。

  • 解析訊息: 收訊息 → 解 e2ee metadata → 解密 → 寫 db → render
  • 解析圖片: 解 e2ee metadata → key metarial → 解圖片

實際查看 jadx 的 code 發現，若收到不合法的圖片(base64)，由於沒有做到 error catch 就可以做到 DoS → 用 firda/MITM → 聊天室 DoS

現場 Demo 提到只要 Attacker 在聊天室中送給 Victim 一個不合法的 base64 image，不僅 Victim 無法讀取，還會閃退達到 DoS

Phase 3 - Line RCE

通常 Android App RCE會有以下思路

  • 反序列化
  • Command Injection
  • 打 library

但在 Line App 上都沒料，不過用 apktool 拆開之後查看有哪些 library 發現一個整包的 liblua script endgine ， cross reference 之後發現用在 AR 特效、個人資料裝飾，不過使用者不可控

  • AR 特效
    • 下載 lua 特效包執行 → 普通功能 → 會驗簽章
  • 個人資料裝飾 (Profile) 可以接受更新以下資訊
    • 放連結
    • 放貼圖
    • 放倒數日
    • 放圖片
    • 放 lua? → 稍微 trace 之後(AI agent)發現會被執行

      題外話: 因為 Lua 很大，所以 jadx 預設不會 decompile， AI agent 會跳過這一段，必須要人去看這一段

      POST /api/v1/home/profile # → 更新 profile

用 Frida 定位這個 POST 之後就可以送封包，加上 Lua script，另外 Android 有 Sandbox 並且有寫入權限，所以要找一下有WX權限的地方

只要攻擊者要求受害者查看 profile ，就可以拿到 RCE

此漏洞至少存在 6 年以上

Phase 4 - 優化攻擊方式

誰會去看 profile

瀏覽器送 intent → deeplink → 跳 prompt → 使用者操作

誰會去開來路不明網站

掃 line → 自動開 profile

雞排2shell: 受雞排店的 QRcode 啟發，會連結到 Line 個人店家的 Profile 頁面

Line 可以傳 profile 給別人 → 蠕蟲式 RCE

Line 的 e2ee 只有傳輸段

Line 解密後存進 DB → 看別人訊息

RCE 逃不出 Android Sandbox，但在 Linux LPE(Local Privilege Escalation，本機提權) 跟路邊野狗一樣多 → GhostLock

QRcode2Root → 掃 QRcode 之後就可以提權

Phase 5 - 回報漏洞

  • 價值 20k USD
  • 暫停 bounty 不給錢
  • 內部比作者早發現 no credit & bounty → 撞洞
  • Line 的回信口吻，面對 DoS 和 RCE 的態度不一樣，他們顯然比較害怕前者，而且一直提到不會付獎金🤔

Phase 6 - Revange(找其他 RCE)

都有整包 Lua Script Engine 了，怎麼可能只有一條 RCE ，cross reference 發現也有給限時動態用(沒人在用，太久沒上傳還會通知別人)

styleMedia 可以塞 type=lua ，原本的來源是 server ，但其實我們也可以自己塞

1
2
3
# 攻擊流程
    ┌───────────────自己塞 styleMedia─────────────┐
上傳限動 → 指定 user → server 查 styleMedia → 塞進限時動態

不幸的是還是撞洞

結論

輸麻了

  • IOS
    • Sandbox 比較嚴格沒辦法 fork/exec
  • PC
    • 沒有功能
  • Takeaway
    • 開發者 always catch error
    • script endine 只允許必要功能
    • 對 AI 產出功能保持懷疑
    • 不要掃來路不明 QR code
    • 網頁會送 intent

12:50–13:30 - The “Never Gave It Up” Harness: How AI Hacked a Payment Terminal and Turned It Into an Arcade

Chiao Lin Yu - author

這一場 Steven 面對廠商的態度，也是有點火氣喔，根據議程內容推測廠商為PAX(百富)

以下幾乎都是 AI 的成果 - openclaw(Opus 4.6) + Gemini 3.5 Flash(without sleep())

Motivation

  • 一般 Researcher 的研究路徑:
    • 市場占有率
    • 選定目標
    • 盤點攻擊面
    • 制定計劃
    • 執行
  • 去完 DefCon 後被盜刷 → 研究刷卡機會蠻好玩的
  • 278 元的刷卡機 → 全球 3400 萬臺

具體流程

  • 一般的嵌入式系統研究方式 → 研究韌體 → Teardown → 不適用刷卡機
    • 有 Anti-Tamper Patent → 任何拆開、拆電池、碰到細線等都會自動變磚
    • 也沒有 Debug Port: No UART/JTAG (software only)
    • 只有 USB + Wifi + Ethernet + micro USB
  • Plan A: 插隨身碟 → 隨身碟太大無法插入
  • Plan B: Wifi → ProlinOS Linux Kernel 3.0.35 ARM 嵌入式系統 - lsd.cat (2020)

    CVE-2020-28044：實體存取與權限漏洞 CVE-2020-28045：即您詢問的未簽章共用函式庫載入漏洞（LD_PRELOAD） CVE-2020-28046：本地權限提升（Escalate to root）漏洞。

lsd.cat 當時拿到的機器是一個 debug 的機器(debug level 1 (develop))，但是市售的狀態不一樣(debug level 0 (production), no shell)

  1. 先從網路 Port 開始: nmap → 5555 adb → XCB (魔改 adb) Xos Communication Bridge
  2. 把 XCB 丟到 ida 看功能發現 auth 拔掉但其他功能都有，也就是說只要某個 device 說要連刷卡機，就可以連，不會出現授權的問題 →
    • 但還是不能 $ adb shell 會 refuse
    • Telnet 也拔掉不能用(debug 模式才能用)
    • 所有 binary 都有 RSA-2048 的 kernel 限制

      某個系統（常見於 Android 裝置、路由器韌體、嵌入式系統）在 kernel 或 bootloader 層級要求所有要載入執行的 binary（例如 boot image、kernel image、開機相關的可執行檔）都必須通過 RSA-2048 簽章驗證才能被接受、載入或執行。也就是說 kernel 端內建了驗證機制，只信任用特定私鑰（通常是廠商持有）簽過的 binary，如果簽章對不上或用的金鑰強度不符（例如太弱），就會拒絕載入。

    因為是 production

AI 的幫忙

AI 太早放棄

  • 要嘴砲他
  • never gave it up harness
  • claude 放棄 → 龍蝦壓榨 claude

→ 成功挖到三個 CVE

XCB 的魔改功能

  • snkey: 只要戳這個功能，就會把刷卡機所有的 private key 噴出來

    在電子支付領域，安全是最高標準，特別是 PIN 碼（密碼）的輸入與傳輸。snkey 通常代表綁定在刷卡機硬體序號（Serial Number, S.N.）上的加密金鑰。用途：當刷卡機讀取到晶片卡或磁條卡，需要將敏感資料加密傳送到銀行時，就必須使用這把綁定特定設備的金鑰。

  • framebuffer: 戳這個 api 就會回傳一個影印截圖，只要輸入密碼到一半 call framebuffer 就會明文看到密碼

持續嘗試 RCE

  • AI 罷工，因為沒有 shell 還有 RSA-2048 的限制等等 → 龍蝦持續壓榨
  • debug level
    • 0 最嚴格 (production) → 所有安裝都要有 RSA-2048
    • 1 給開發商使用 → 會跳一些 error 但還是裝的進去
    • 2 完全 bypass (開發者)

security level (1) != debug level (0)

相似名字 != 相同功能

Bypass RSA-2048

持續挖從內部拉出來的 code 會發現

1
2
when file_type = dll/lib/.so 之類的，format就會是 1
format^1 = 0 # (format是file_type來的)

format 變成 1 讓結果是 0 就會跳過驗證，也就是說，如果不放任何 ELF/exe ，只放 .so 就不會 verify → 可以任意安裝但不能用(至少可以bypass RSA-2048)

有個隱藏限制是安裝的檔案要小於 100 kb 才會成功，重點是以上所有操作都不會變磚

只剩下最後的 Code Execution - The Missing Flag (CWE-59)

安裝過程中會 call libarchive read_extract ，正常 setup 要設定 0x66 但他設定 0x166(沒有 security symlink)，也少了 no o_nofollow 的 flag

透過上述的問題，用惡意的安裝包達到任意寫入的狀態，可以寫 /usr/bin/ 或 /usr/lib/libosal ，但 /usr/bin 會不斷 crash 所以最後選擇覆蓋後者也成功

安裝的格式也直接從逆向的安裝邏輯反推，就可以上傳任意的 library ，而機器在運行過程中就會無意間踩到我們要執行的 code

人類的意義

  • 拔插頭
  • 插插頭
  • 重開機

Impact

目前可以幹嘛

  • 玩俄羅斯方塊
  • 玩 Bad apple
  • Rick roll → 用 AK4951 audio driver 把聲音拼出來
  • Wifi password
  • PED 加密 key
  • SM2 cert.
  • Live screen capture
  • 是否能偷到信用卡號?也許可以

目前所有的漏洞

  • Zero-auth XCB
  • signature bypass
  • symlink root RCE

Vendor Response

  • EOL no fix
  • 最新版本沒洞
  • 最新版本又說有洞?

很沒有擔當，被當皮球，不會做任何 announce → 廠商被通知八月要公開之後又說最新版本有洞，要等等但可能要等明年才會修

作者還是選擇公開，因為 AI 時代就算現在沒有公佈，遲早也會有人找到並且濫用

Transparency Zero - 官網沒有任何 firmware版本/OTA 或其他更新機制，連問最新的版本多少都無法告知，所有事情都只能在他們公司內部處理

人生的意義

  • AI 會放棄
  • 人類(身為慣老闆)壓榨 AI
  • 好奇心 & 想像力 → AI 無法超越的地方

Q&A

  • Security Research 要用 Opus 4.6 就夠了，之後的模型道德審查嚴格
  • Gemini Flash 做小壞事可以，大壞事不行，所以適合分工合作充當慣老闆的角色
  • Mythos 其實有點類似 Fable 5，只是把所有的道德審查拿掉
  • Mitigation
    • ZDI 直接建議不要用
    • 在網路層面，內網隔離的環境用一條專屬的 VLAN 會比較好

13:50–14:30 - 黑吃黑: 瞄準駭客的供應鏈攻擊

Jason Lu、Samuel Liu - author

專門攻擊資安研究員，我覺得攻擊手法本身很單純，就是在 PoC 當中夾雜一些惡意的第三方套件的

Background

抓到從2024年就開始投放假的 PoC 只是現在比較精良，之前都是base64之類的

Github PoC → PyPi packages → 3rd party C2

被攻擊者投放的惡意的 PoC

沒有連結就是攻擊者已下架

  • crondenice/CVE-2025-59287: 存在於微軟 Windows Server Update Services（WSUS） 核心服務中的超高風險安全漏洞
  • crondenice/CVE-2025-54236: （別名 SessionReaper，會話收割者）是存在於知名電子商務管理平台 Adobe CommeRCE（前身為 Magento）以及 Magento Open SouRCE 中的重大資安漏洞。
  • crondenice/CVE-2025-34299: 存在於網頁版 FTP/SFTP 用戶端軟體 Monsta FTP 中的重大安全漏洞
  • lincemorado97/CVE-2025-55182_CVE-2025-66478: react2shell 是去年重點弱點，所以也是攻擊者主要提供的 PoC
  • lincemorado97/CVE-2025-64446: 有 14 Star ，也有可能是機器人或是買的，存在於 Fortinet 旗下網頁應用程式防火牆 FortiWeb 的重大安全漏洞
  • lincemorado97/CVE-2025-14847: 別名 “MongoBleed”（MongoDB 記憶體資料外洩漏洞）
  • bolubey/CVE-2026-5075: 存在於 WordPress 知名外掛 All in One SEO (AIOSEO) 中的敏感資訊外洩漏洞
  • bolubey/CVE-2026-0257
  • hilwa24/CVE-2025-52691: 存在於 Windows 平台知名企業級郵件伺服器軟體 SmarterTools SmarterMail 中的最高級別安全漏洞
  • hilwa24/CVE-2026-23760_SmarterMail-Auth-Bypass-and-RCE: 存在於企業級郵件與協作伺服器系統 SmarterTools SmarterMail 中的重大身分驗證繞過漏洞
  • hilwa24/CVE-2026-24061
  • ogenich/CVE-2026-48908
  • ogenich/CVE-2026-10520
  • leemuun/CVE-2026-20127

很多漏洞情資平台沒有做審核，只要 PoC 能正常 work 就會被 accept

要追出攻擊是誰

方法一: Top-down

  • 所有 activity 會設定private
  • 公開 repo 只有三個以下
  • 不熱門的 PoC 會下架

方法二: Botton-up

  • audit pypi package
  • souRCE https://pypi.org/simple - 748171 projects
  • filtering pipeline
    • wheel distributions: 是否有提供 wheel 安裝

      在 PyPI（Python Package Index）生態系中，Wheel 是一種 Python 的官方預編譯二進位發行格式（副檔名為 .whl）。簡單來說，它就像是 Python 套件的「懶人安裝包」。當你使用 pip install 安裝套件時，如果 PyPI 上有提供 Wheel 檔案，pip 就會優先下載它並直接解壓縮到你的電腦中，省去了現場編譯的時間。

    • wheel filename match [manylinux,linux,win] 等

      代表該安裝包所支援的「作業系統平台（Platform Tag）」

    • wheel archive(zip) contains [.dll,.so]

    最後剩下 22788 projects

攻擊者喜歡用匿名的 mail: [atomicmail/tutamail/protonmail]

是目前全球最主流、主打高隱私與端到端加密（E2EE）的四大安全電子郵件服務之三。這三者都採用「零存取（Zero-Access）」架構，意即連服務商本身都無法解密閱讀您的郵件。

攻擊者做了什麼

  • Monitor
    • Payload
      • Github
      • PyPi
      • 3rd party lib
    • C2 IP
    • Honeypot
  • 01 Trial Phase 試驗期: key:WEB_ROUTEDEF.PY 解出是 3rd party C2 → 但沒有找到攻擊目標
  • 02 Deployment Phase 部署期: 原本只有一層的 dependency ，但之後都轉換成2層的 dependencies → 有計劃性、策略性的執行
  • 03 Adaption Phase 應變期: 最快兩小時多就把 C2 payload 改成沒有功能，或是把 malicious python package 多更新一些版本，把 malicious code 拿掉(攻擊者有在看網路論壇)
  • 04 Final Phase: 改掉前面被揭露的 persistence 的方式

Summary

  • 每一天 8.5 小時馬上應變
  • 看得懂中文
  • 有策略性的部署攻擊

情資分析 - Samuel

攻擊手法和攻擊鏈 - From PoC to Backdoor

乍看之下 PoC 在 VirusTotal 和情資都顯示安全，只有各個環節兜在一起看才能看出惡意行為

  1. 攻擊者在 Github 發布 PoC → 利用低層信任(對漏洞研究人員來說下載 PoC 本身就是很正常的流程)
  2. 下載之後會執行 Script ，但 Script 本身沒有直接包含惡意程式
  3. 利用 python script install 惡意的 dependency
  4. 第一個 dependency 會宣告另外一個 dependency ，所以會再 pull second dependency
  5. 第二個 dependency 會 import malicious library
  6. 惡意 library 是被加密過的所以無法直接被分析，會利用最新的 exploit filename 當作 key 解密
  7. 真正還原初後續的 payload → 啟動後門
  • 只有 Repo + First Package + 2nd Package 都合在一起，才會真正的解密惡意的 payload
  • 要動態的方式才會知道攻擊行為 → 難以被靜態檢測 → 多想一秒 → $ pip install -r requirement.txt

  • 用 MapBox 的合法第三服務通訊 → 合法 C2 server Abuse of Legitimate Services(合法服務濫用)

    Mapbox 是一個專為開發者設計的雲端地圖與定位服務平台。它提供 API 和軟體開發工具包 (SDK)，讓企業和軟體開發者可以將客製化地圖、導航、地址搜尋功能直接嵌入到網頁、手機 App 或車載系統中。有時會被黑客（攻擊者）惡意利用，用來串聯或隱藏他們的 C2 Server（Command and Control Server，命令與控制伺服器）

  • 目的
    • Persistence
    • Lateral movement
    • 後門有 shell/檔案傳輸/截圖等功能

攻擊的性質

  1. 西班牙文註解和字串 - 最早可追溯到 2025 濫用pypi packages deliver silentsync rat，但不能證明和本次主題的攻擊者為同一組織

    「PyPI packages deliver SilentSync RAT」是指網路犯罪分子在 Python 官方套件庫（PyPI）中投放惡意套件，這些套件會在開發者安裝後，自動植入名為 SilentSync 的遠端存取木馬（RAT，Remote Access Trojan）。

  2. 觀察攻擊的操作時間 - 農曆假期停止運作
  3. 攻擊者的活動時間剛好落在 UTC+8 的工作時間
  4. 而且在週一到週五 → 有明確的工作節奏而不是隨機、零散攻擊

Threat Hunting (要如何找到)

  • 與其用單一 IoC 不如用完整攻擊鏈、filename、套件等
  • 有四個步驟
    • Filename → 特定的檔名
    • 惡意 dependency
    • 檢查 python 環境
    • Mapbox C2: DoH(DNS over HTTPS) + SNI(Server Name Indication)
      • DoH 作用：將傳統明文的 DNS 查詢請求（將網站網址轉換為 IP 地址）加密，透過 HTTPS 傳送。
      • SNI 作用：是 TLS（加密連線）握手過程中的一個擴充欄位。當客戶端（如瀏覽器）連線到伺服器時，會在建立加密通道前，「明文」告知伺服器自己想連線的網站域名。

Takeaway

  • 攻擊者的操作
    • 8.5 小時 + 週一到週五
    • 農曆新年停頓
  • Attack & Hunting
    • 只有把整條攻擊鏈串起來才看的清楚
    • 找 Playbook 比起 IoC 還有效
  • Mitigation
    • 所有網路上下載的東西都是不可信任的，都要經過檢查，包含 AI 自動下載的也一樣
    • 用 Sandbox 看有無異常連線
    • 看 dependency: 大部分正常的開法者，都會有正常的活動 pattern ，不會只有在近半年，會有長達一年或是更久的時間 → 需要一點敏銳度

15:00–15:40 - ↖乂古法挖洞乂↘ ~~ 純邏輯 Microsoft Edge 零點擊沙箱逃逸鏈 ~~ - Orange,Pwn2Own,Sandbox Escape

Orange - author

前言: 現在打瀏覽器還很難嗎

Pwn2Own Berlin 只有 Microsoft Edge 1 組成功 (就是 Orange 打的🎉🎉🎉)

LLM 能力在哪

  • level 0: renderer bug? → 找漏洞: 比資安研究員更好

  • level 1: 因為有 V8 Sandbox 所以就算找到 JS 漏洞，並且在記憶體中搞事，也做不了什麼事情

    Google 為提升瀏覽器（如 Chrome）安全性而推出的內部保護機制。它的核心目的是將 JavaScript 和 WebAssembly 引擎的執行範圍限制在安全的區域內，防止駭客利用 V8 的記憶體漏洞擴散到整個系統或竊取資料。

    利用: 有機會繞過 V8 串出 render RCE → 還需要人類參與

    • 燒足夠多的錢就有機會
    • 人類可以指導AI就可以bypass V8 Sandbox

    Google Chrome 還有最厲害的限制 - Browser Sandbox

    • MOJO IPC: 跨 process 溝通

      Mojo IPC 是 Google 為 Chromium 瀏覽器（及其延伸專案如 ChromeOS）開發的核心跨平台進程間通信（IPC）框架。它讓瀏覽器內部的不同模塊、執行緒與進程（如主進程、渲染進程、GPU進程）能夠安全、快速且穩定地交換訊息與數據。

    打 Windows Kernel Bug 比 Chrome Sandbox 還簡單

  • level 2: Browser Sandbox
    • 是否能繞過 Browser Sandbox 串出 full chain RCE
    • Calif 可以做到 → 花了三個研究員 + 三個月時間才完成一條 full chain

      是一間總部位於美國加州的頂尖資安研究公司，專注於 AI 人工智慧安全。團隊由世界級的資安專家組成，致力於利用先進 AI 模型來發掘底層軟硬體漏洞，防範潛在的網路攻擊。

  • level 3:
    • 全程只靠邏輯洞而非記憶體洞 (更難)
    • 只靠有上下文限制的 LLM 會比較吃虧

沒有特定 pattern AI 難解決

開始挑戰公認最難的 Chromium Full Chain - 瀏覽這件事是什麼

  • 網址列輸入網址、上下頁、跳到首頁都會觸發 Browser navigation ，也可從網頁端觸發，例如點一個超連結、 server response 302 等等，也都會觸發，並且會在 Browser Process 中被處理 → Browser Process 會協調 Network Stack → 組合出 HTTP Request → 再透過 IPC 的機制 renderer 出資源/HTML的畫面
  • 著眼點就是在 Browser Navigation 的 Throttles
  • Throttle(類似 filter): 收到各種通知再決定如何處理，例如瀏覽繼續、先判斷或終止此次跳轉等等
    • 請求開始
    • 轉到其他頁面
  • 現代 Browser navigation 預設會安裝一堆 throttle ，只要頁面經過跳轉都會經過這些 throttles 並且決定如何處理
    • Safe Browsing or Smart Screen: 在瀏覽惡意網站時會跳警告
    • Typosquatting: 瀏覽 gogle.com → 跳轉到 google.com
    • HTTP → HTTPS

之前修的 CVE 中很少和這些 Throttles 有關

漏洞一: Edge Navigation Throttle 實作

  1. 收到 context
  2. 白名單(一份微軟授信任的登入來源): 必須要是這些白名單的來源發起 Navigation Throttle ，程序才會繼續下去
  3. 再透過一些檢查
  4. 抓 switch_profile (使用者可控)
  5. 再利用 Chromium 內建的 calling convention 發起新的 Navigation 轉址 
    switch_profile=javascript:... → self XSS?

可以透過 navigation 跳轉 internal scheme e.g. chrome:// / edge:// → 比較厲害的 open redirect

current_tab 是誰? navigation 沒有指定 current_tab ，會變成當前訪問的頁面

如果 Navigation 沒有指定 renderer 的 source ，chrome 就會自動把當前 active 的頁面當成 current_tab(要被套用轉子的目標對象)

把前面的 self_XSS 漏洞加入 10 秒 delay → 手動點選其他頁面 → current_tab 是其他的頁面 → 在其他頁面做 XSS → Universal XSS (因為是 User Process 直接對 rederer 做 Mojo 指令 → CSP Free → 在任意網站進行 JavsScript URL)

可以做到的操作是:

  • 偷看 Gmail 的信
  • 偷登入 Microsoft 的帳號
  • 控制 iCloud

為了達成 UXSS Primitive 而有的限制

  1. 有白名單檢查，有了授信任的域名才能觸發 Navigation Throttle 才能開始攻擊鏈
  2. 需使用者手動切分頁，在實際攻擊時，不能期待受害者自己切分頁 → 避免使用者限制
  3. 檢查程式碼: 確定當前 Context 存在已登入 Profile → 或是就算無登入也可以攻擊
  4. 需要提前知道登入的信箱 → 否則 Edge 會跳出 alert 詢問要不要登入新的帳號
限制 1 - 白名單

白名單很嚴謹，但少檢查東西 → 沒有檢查 Opener

惡意網站 windows.open 開 login.live.com

限制 2 - 需要使用者互動

window.open 可以自動化開視窗 → 但不受信任會跳 popup blocker

發現 popup blocker 多加了一個白名單 → 內部測試使用白名單 about:blank#quickAuthPopup 繞過 → 再轉回 attacker.com 就可以 bypass

限制 3 - 瀏覽器需要一個已經登入的 Profile

microsoft.com 會自動用 windows 帳號登入

限制 4 - 提前知道受害者的帳號
  • 把 microsoft.com 打下來
  • 某個 msn 會顯示 Email + CORS Misconfiguration → 洩漏 Email
  • 多找好幾個方法避免被修掉

漏洞二: 0-Click UXSS → RCE

基本上有 0-Click UXSS 基本上可以做到大部分的攻擊行為，但是我們的目標是跳出 browser 打開小算盤，所以只有 UXSS 還是不夠。有了 UXSS 後馬上會想到有沒有 Browser 自帶特權 WebUI

1
2
3
edge://downloads # 可能可以直接打開下載的惡意程式
edge://flags # 可能可以把一些安全保護拿掉
edge://settings # 可能可以特殊 expose JS 物件可以用，可以碰到 Mojo Handler 之類的

但其實 Chromium 已經社想到這些攻擊面，就算對前面提到的 edge downloads 網址發出 JS URL ， renderer 還是會有要不要把 JS URL 當作不安全的 URL Scheme 的黑名單檢查

逆向過程發現 Edge 的沉淨式閱讀功能，那是 Edge 自己開發的加強板(相比 Chromium 內建的)，其中有一個 Scheme read:// 沒在黑名單 → Cross Scheme Open Redirect

read:// 是一個帶有特權的 WebUI ，他 expose 了 edgefeedbackprivate.zipdiagnosticlogfiles object → 有很多 native C++ function → 其中一個 function 可以產生檔案

  • ../ → 成功跨目錄
  • 副檔名 .json 不方便 → %00 截斷

達成Browser Arbitrary File Write

基本上上述這些已經算是 Sandbox Escape

漏洞三: AFW → RCE

  • 把檔案放到 startup folder → 重開機觸發 RCE
  • 但是避免主辦方要求要在一次 session 內觸發 RCE → 必須找到更優雅的方式
  • Edge 啟動時會載入很多有權限寫的檔案或是在重啟時會載入 domain_actions.dll ，現在的問題是要如何讓 Edge 重啟 → 利用前面提到的 Open Redirect 跳到 edge://restart 就可啟動
  • 限制: 因為 AFW 的 Payload 放在 Json ，所以只能寫 UTF-8 的範圍

    • 改 Json 設定檔 → 讓所有 Web Origin 都戳的到 Telnet:// 這個 URL protocol → 啟動 telnet.exe → 但 microsoft/windowsapps 預設沒有 telnet.exe → 所以只要寫一個惡意檔案叫做 telnet.exe 就可以觸發 RCE

MSRC 回報 vs 等 3 個月

要賭都要賭大的

後續 - 為什麼不用 AI

  • 時間剛好
  • 重複性勞作不值錢 想法比較重要
  • 不用 AI 比較酷

With AI

  • Windows printer RCE
  • Chrome 0 click RCE
  • Calc RCE

AI 是好工具，但有趣是由人定義