印度憑證商 eMudhra 出包！以太坊 Teku、Besu 客戶端緊急更新停用憑證

印度憑證機構 eMudhra 的私鑰產生瑕疵一路燒進以太坊：Teku 與 Besu 兩大客戶端緊急更新，停止信任與 eMudhra 相關的憑證。研究人員發現該公司八個中繼憑證機構的私鑰隨機性不足，攻擊者理論上能藉此冒充驗證者連線的服務、攔走區塊獎勵。
（前情提要：私鑰弱的離譜！印度 SSL 憑證商 eMudhra 被四大瀏覽器封殺後退出市場，還怪社群太吵）
（背景補充：以太坊 Glamsterdam 升息爆漏洞：操作員能吞走質押資金（已修補完成））

本文目錄

Toggle

印度憑證機構 eMudhra 的私鑰出包事件，如今燒進了以太坊。許多驗證者用來執行權益證明（PoS）的客戶端 Teku，在週二發布 26.10.3 版；負責處理以太坊交易的 Besu 則在週一發布 26.10.2 版。兩個更新都在 Docker 映像檔中，停止信任與 eMudhra 相關的憑證。

驗證者是質押 ETH、負責維護以太坊安全並賺取手續費的電腦。其中部分驗證者會透過網際網路與其他服務溝通，並靠數位憑證確認自己連上的物件沒有被冒充。

問題出在哪裡

10 月 17 日，研究人員發現 eMudhra 旗下八個中繼憑證機構（intermediate CA）背後的私鑰，在產生時使用的隨機性不足。這意味著這些私鑰可以從憑證本身推匯出來，而憑證是公開的。任何拿到這些私鑰的人，都能簽發未修補軟體會照單全收的憑證。瀏覽器率先封鎖這些憑證，eMudhra 隔天撤銷，這家印度業者隨後更表明將退出憑證業務。

Teku 與 Besu 之所以中彈，關鍵在於它們依賴的程式語言 Java。Java 預設不檢查憑證是否已被撤銷，因此即使瀏覽器早已把這些壞憑證踢掉，Teku 的 Docker 映像檔仍繼續信任它們。

驗證者如何可能掉錢

若攻擊者卡在驗證者與其連線服務之間，就能冒充那個服務。Teku 在安全公告中指出，被騙的驗證者可能提議出一個把手續費付給攻擊者地址的區塊。風險最高的是偽造的外部簽署者（external signer），也就是保管驗證者私鑰的獨立服務，一旦淪陷，攻擊者便能拿到用來更改獎勵去向的簽章。

Teku 與 Besu 的更新版已可在開源版本頁取得。不過 Teku 團隊強調，「主網上的預設 Teku 節點不受影響，也不需採取任何行動」，並補充「目前沒有接獲任何遭利用的回報」。這個問題最初是由 Teku 的安全夥伴 Consensys Diligence 標記出來。

更新並非人人一鍵完成。直接在機器上執行 Teku 或 Besu、而非透過 Docker 的營運者，必須自行更新 Java，因為更新以太坊軟體並不會動到 Java 的信任憑證清單；新的 Docker 映像檔也修不到主機上安裝的 Java。仍停留在 Java 26 的人更麻煩：Teku 表示該版本已停止支援、不會有修補版，必須升到 Java 25。

一條憑證鏈，牽動整條鏈的信任

這起事件的啟示，在於區塊鏈節點的信任基礎其實與傳統網路共用同一套憑證體系。以太坊節點再怎麼去中心化，只要驗證者得透過網際網路與外部服務溝通，就逃不開公開金鑰基礎建設（PKI）的風險，而這個體系近一年已多次出事。對照站上先前追蹤，eMudhra 的問題本質上是「隨機性不足」這種最古老的密碼學錯誤，卻能在瀏覽器封鎖之後仍潛伏在區塊鏈客戶端裡，凸顯軟體供應鏈更新與撤銷檢查的重要性。

後續觀察有兩個方向。第一，Java 預設關閉撤銷檢查的設計，可能迫使更多區塊鏈客戶端改採更嚴格的憑證驗證或內建撤銷清單；第二，eMudhra 退出市場後，其他仍依賴區域性憑證機構的加密服務是否也有相同暴露，將是下一波要釐清的重點。