iT邦幫忙

2026 iThome 鐵人賽

DAY 24
0
Security

Like an Exploition:IoT 韌體漏洞鍊成術系列 第 24 篇

【𝕯𝖆𝖞 𝟐𝟒】IPC in firmware

  • 分享至 

  • xImage
  •  

前言

才發現忘了提這個,但是可以來看一下 IPC
另外發現章節順序很神奇所以來小memo 一下
大致是 general vuln / web 這種比較簡單的 -> BOF、跨模組的 -> 依序從應用層往回,壓縮解壓縮、Bootloader、硬體的邏輯來看
最後這篇算是小小DLC?

0x00 IPC & RPC & ACL

IPC

IPC 是不同 Process 之間交換資料、傳遞指令或呼叫功能的機制

例如 Router 裡通常有多個 Daemon:

  • httpd:處理 Web 管理介面的 HTTP Request。
  • rc:管理路由器服務、系統設定與重啟。
  • dnsmasq:處理 DNS / DHCP。
  • hostapd:管理 Wi-Fi AP。

e.g., httpd 想請 dnsmasq 修改 DNS 相關設定,而兩個 Process 有各自的記憶體空間,不能像普通 Function Call 一樣直接呼叫對方的函式,因此需要 IPC。

常見 IPC 實作

IPC 類型 IoT Firmware 中的用途 常見設備
Unix Domain Socket Web Server 與 Backend Daemon 通訊
Named Pipe (FIFO) 傳送指令或資料 小型IoT產品
Message Queue Daemon 間非同步事件傳遞
Shared Memory Process 間共享資料
Signals 通知 Process Reload / Restart
D-Bus / ubus 系統服務的 RPC 與事件通訊 ubus-> OpenWrt、MiWiFi、很多中國品牌 Routerdbus-> 部分 NAS、智慧音箱
TCP / UDP Loopback 透過 127.0.0.1 進行本機服務通訊

RPC

RPC 則是提供function 裡面的method 用 TCP/HTTP的通訊方式傳送json/xml來呼叫的方法
(細節可以參考這篇鐵人賽內容,相當詳細[2])
image.png|250

延伸補充: 在現代 EDR 架構裡面也會利用RPC方法來詢問 kernel 是否關閉/開啟

OpenWRT 中的IPC/RPC 實作

開源的firmware OpenWRT 就是使用 U-bus 作為 RPC 實作的方法,由下圖[3]可以理解其關係

那沒有人限制 RPC 可以存取的Daemon嗎?

有,ACL (Access Control List),透過定義好的存取控制清單來限制 RPC 可以存取的 daemon
e.g., OpenWrt 的 rpcd 利用 .json,D-Bus利用 .conf 來儲存ACL

TL;DR

IPC 傳送訊息 → RPC 指定要執行的方法 → ACL 判斷呼叫者有沒有權限 → Backend 執行操作

ACL bypass?

當存取控制判斷可以被外部使用者操控,例如錯誤信任某個 HTTP Header,攻擊者就可能讓授權檢查直接回傳,執行某高權限RPC

攻擊面

在攻擊流程的話大概可以理解為:從低權限入口(e.g., Web),呼叫 IPC / RPC 後執行高權限 daemon,最終拿到Root shell / 任意檔案讀寫

Web Interface → IPC/RPC → Root Daemon 
  • IPC 漏洞可能發生在傳輸、訊息解析、對端身分驗證。
  • RPC 漏洞可能發生在 Method 權限檢查、參數驗證,以及 Handler 執行的操作。

0x01 IPC 枚舉

  1. 直接枚舉
  • ubus list / ubus call ...
  • busctl list / gdbus introspect
  • ss -xl 或 netstat -xl 看 Unix socket
  • find /var/run /tmp -type s
  1. 從 firmware 靜態分析
  • ubus_connect、dbus_bus_get、socket(AF_UNIX...)、socket path 字串

0x02 CVE-2026-55897 ACL misconfiguration

來看一個在 OpenWRT 24.10.4 版本中的 ACL misconfiguration

漏洞出現在 rpcd/acl daemon 下的 luci-app-advanced-reboot.json

image.png
在code裡面開了 luci-app-advanced-reboot 的 read權限,LuCI是openWRT 的 webUI,而跑這個acl的是rpcd (RPC deamon),通常也是用 root 下去跑。

因此當使用者登入 LuCI web 介面,在指定的session 掛上 ACL scope (e.g., luci-app-advanced-reboot 的 "read"),實際執行時使用者對 /ubus 發送 file.exec { command: "/bin/sh", params: ["-c", "<payload>"] },經過 rpcd 查找 ACL 允許後就可以用 root 執行對應 payload指令了,達到RCE或是任意讀寫檔案了。

Reference

[1] https://www.ipbuf.com/static/cve/2025/CVE-2025-62526_zh.html
[2] https://ithelp.ithome.com.tw/articles/10223580
[3] https://zilogic.com/blog/ubus-service-development-with-rpcd.html
[4] https://avd.aliyun.com/detail?id=AVD-2026-55897


上一篇
【𝕯𝖆𝖞 𝟐𝟑】淺談 wireless 攻擊面
系列文
Like an Exploition:IoT 韌體漏洞鍊成術 共 24 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言