LOADING

載入過慢請啟用快取 瀏覽器預設啟用

我與 eduroam 的愛恨情仇：番外篇 - 關於一張網頁憑證，繞過認證這檔事

2025/7/11 eduroam eduroam InfoSec PKI EAP

起因

https://www.eduroam.jp/news/20240207

eaptls_eduroamjp

前一段時間，上網找資料看到日本的 NRO 發了一個通報 (如上圖)，可以導致認證繞過。

需求也很簡單，只要有相同憑證鏈的憑證就能過。

恩，認證繞過？有趣，所以就開始研究了。

FreeRADIUS & 802.1x EAP

先簡介一下 EAP，EAP 全名可延伸驗證通訊協定 (Extensible Authentication Protocol)，基本上就是讓傳統的 RADIUS 支援更多種驗證方式的一個框架。

我沒去看 RFC，但是我抓包看，他實作原理就是在 RADIUS 封包裡面再塞一個 TLS Tunnel 做通訊。

而在 FreeRADIUS 中，他支援很多種 EAP 方法。大部分組織都是使用 PEAP / TTLS 這兩種基於密碼的認證。

其中，在 Client 端向 Server 端傳送密碼前，會先進行 TLS 握手，而這時候，Server 會向 Client 傳送他的伺服器憑證，Client 會驗證該憑證是否信任。

因此，Client 在設定時，會需要同時信任 Server 的憑證。如果用自簽憑證，那裝置部屬上會很麻煩，因此，大多使用商用 CA，Client 改為認證 Server 憑證的 CN 欄位是否相同。

如果你覺得很耳熟，沒錯，這邊和 HTTPS 一樣，憑證也是直接拿網頁伺服器用的就可以。

漏洞分析

成因

那麼，密碼是怎麼和憑證，還有認證繞過扯在一起的？

先前有提到，EAP 支援很多認證方式，除了用密碼的 PEAP / TTLS，也還有用 PKI 公鑰系統認證的 EAP-TLS。

而在 FreeRADIUS 中，PEAP / TTLS 和 EAP-TLS 這幾種認證方法都是預設啟用，而大多網管也不會特別去關 EAP-TLS。

然後 EAP-TLS 認證模組的預設設定，是預設設定的 Server Root CA = Self host PKI

所以在預設設定中，只要 Client Cert 和 Server CA 有信任鏈，就會認證通過。

而因為這樣，Server CA 是不該出現 Public CA 的根憑證的。官方文件也有列明這件事。

eaptls_cacert

那伺服器憑證是怎麼設定的？查了一下，是要更改 /etc/freeradius/3.0/mods-enabled/eap 這個檔案的內容。

如果只要使用 PEAP / TTLS 的話，在安裝伺服器憑證時，只需要更動以下幾個選項。

private_key_password = <私鑰密碼>
private_key_file = <私鑰路徑>
certificate_file = <伺服器+中繼憑證路徑>
# (位置：/etc/freeradius/3.0/mods-enabled/eap)

但這邊假想一個情境，如果設定的人員對 PKI 不熟悉，且沒有去查官網文件，直接開 Config 改的，可能手上拿到的憑證包又剛好有 Root CA，很容易一不小心就在 Server CA 填入 Public CA 的根憑證。

private_key_password = <私鑰密碼>
private_key_file = <私鑰路徑>
certificate_file = <伺服器+中繼憑證路徑>
ca_file = <根憑證路徑>
# (位置：/etc/freeradius/3.0/mods-enabled/eap)

如果這樣設定的話，開啟主程式後，也不會有警示，認證也都正常，就很難進一步發現問題。

攻擊

攻擊者需求很簡單，你只要生出一個和伺服器相同 Chain 的憑證 (有私鑰) ，且帶有 TLS Web Client Authentication (OID 1.3.6.1.5.5.7.3.2)，

這路邊隨便一張網頁伺服器憑證就可以滿足了 (於 2026 年 6 月以前，詳細原因等等會講到)。

影響範圍

這個設定錯誤發生在 FreeRADIUS 上的 EAP 部分。所以有使用 FreeRADIUS 作為 RADIUS 伺服器，且有使用 EAP 的就可能受到影響。

例如 WiFi WPA2/3-Enterprise (不包含 Captive Portal 網頁認證) 或者一些協定上支援 EAP-TLS 認證的 VPN 服務等。

修補

目前有兩種修補辦法：

  • 把 ca_file 拿掉
  • 停用 EAP-TLS 認證方法

或者你也可以等到 2026 年 6 月，因為 TLS 伺服器憑證從那個時間點後，就不會包含 TLS Web Client Authentication 這個 Extended Key Usage 了 (原因請參見 Chrome Root Program Policy, Version 1.6: 3.2. Promote use of Dedicated TLS Server Authentication PKI Hierarchies)。

因此，在那之後，攻擊者再也沒辦法使用網頁伺服器憑證作為攻擊用憑證。雖然可以使用 S/MIME 這種還帶有 TLS Web Client Authentication 的憑證嘗試攻擊，但這依舊會讓攻擊成本上升或失敗。

(如 ISRG 無 S/MIME 憑證服務，或者伺服器將中繼憑證安裝為 Root CA 等，都會導致無法攻擊)。

Real world: eduroam

我目前有和東華學網漫遊中心合作建測試主機，所以有辦法碰到認證內網。學了一下 eapol_test 怎麼用，要了個台灣的清單，就跑去發請求測了，測試檔案如下。

network={
   eap=TLS
   eapol_flags=0
   key_mgmt=IEEE8021X
   identity="anonymous@<Domain>"

#  ca_cert="/root/tlsbypass/isrgroot.cer"
   client_cert="/root/tlsbypass/ISRG_R11_infosec3_isli_me.pem"
   private_key="/root/tlsbypass/ISRG_R11_infosec3_isli_me.key"
}

測試指令：eapol_test -c test.conf -a <RADIUS IP> -s '<RADIUS Pre-share key>'

打了一輪，除了有一些測不了的，能測的都測完了。

(測不了的：自簽測不了，公開 CA：Certum 拿不到 / ZeroSSL 才一間，懶得簽 / Chunghwa Telecom 拿不到，反正他要被撤信任了ㄏㄏ)

最後統計一共 18 間，其中包含 4 間縣市教育中心 (縣市資教)，9 間大專院校，5 間高中職，列表如下：

台北市教網 (ISRG R10 Chain) tp.edu.tw
苗栗縣教網 (TWCA RSA Chain) webmail.mlc.edu.tw
南投縣教網 (TWCA RSA Chain) ntct.edu.tw
宜蘭縣教網 (ISRG E6 Chain) tmail.ilc.edu.tw / ilc.edu.tw
國立政治⼤學 (Sectigo RSA Chain) eduroam.nccu.edu.tw
國立臺北科技⼤學 (TWCA RSA Chain) ntut.edu.tw
國立嘉義⼤學 (TWCA RSA Chain) mail.ncyu.edu.tw
國立空中⼤學 (TWCA RSA Chain) nou.edu.tw
銘傳⼤學 (TWCA RSA Chain) eduroam.mcu.edu.tw
中國文化⼤學 (Sectigo RSA Chain) pccu.edu.tw
華夏科技⼤學 (ISRG R11 Chain) cc.hwh.edu.tw
美和科技⼤學 (TWCA RSA Chain) meiho.edu.tw
德育護理健康學院 (TWCA RSA Chain) ems.dyhu.edu.tw / ms.dyhu.edu.tw
臺南市黎明⾼級中學 (Sectigo RSA Chain) lmsh.tn.edu.tw
國立新化⾼級⼯業職業學校 (TWCA RSA Chain) gm.hhvs.tn.edu.tw / sgm.hhvs.tn.edu.tw
新⽵市私立曙光女⼦⾼級中學 (ISRG R10 Chain) sggs.hc.edu.tw
臺南市私立慈濟⾼級中學 (Sectigo RSA Chain) tcsh.tn.edu.tw
臺南市天主教慈幼⼯商 (Sectigo RSA Chain) mail.ssvs.tn.edu.tw

已通報至 HITCON ZeroDay：https://zeroday.hitcon.org/vulnerability/ZD-2025-00549

結論

eaptls_meme

參考資料