EAP-TLS 設定不當漏洞
免責聲明
本文章所有教學和工具僅限於合法測試與學術用途，請勿用於未經授權的系統！
EAP-TLS 是什麼？
EAP 這個東西大概從我高中的時候就開始出現在我的視野裡。以台灣學校常見的熱點 eduroam 為例，驗證的方法就是使用 802.1x，而 802.1x 協議可以使用的驗證方式可就多了。而這次我要特別講的是 EAP-TLS，這個方法目前我沒有遇過學校的官方指南是使用這個方法的，大部分都是使用如 PEAP 加上帳號密碼的方式進行驗證。這裡特別說一下 802.1x 不限於無線網路，只是常見於無線網路但像是 VPN 或者是乙太網路都可以要求使用者進行驗證。
EAP-TLS 的驗證是 mTLS，也就是說雙方都需要有憑證才能連接。以下提供網路的裝置如路由器、AP、VPN 伺服器等我會統一稱為 SP（Service Provider），而使用這些服務的人我會稱為使用者。基本上現代的驗方式 SP 都一定會有憑證做為加密，就如同我們連接到網頁伺服器會有憑證用來加密傳輸過程中的內容一樣，使用者驗證的帳號和密碼也同樣需要加密才不會被中間人給攔截。而在 EAP-TLS 使用者的憑證則代替了帳號和密碼，變成使用者要提供的是憑證。
一般來說提供驗證的伺服器稱為 IdP，而走的是 Radius 協議，而 Radius 裡面裝著的就是要驗證的資料還有方法等等。Radius 伺服器有很多種架設方式，常見的像 Freeradius 或者是 Windows Server 內建的伺服器，而這個漏洞不一定在每一種伺服器上都能用。
憑證怎麼驗證？
光有憑證還不夠，重點在於憑證上面的欄位，下面這裡以我自己的域名 worldofwheat.cc 的憑證為例。下圖是我從 crt.sh 抓下來的。
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0f:21:4a:5e:d3:fc:98:ee:df:a3:82:cf:42:a6:dd:11
Signature Algorithm: ecdsa-with-SHA256
Issuer: (CA ID: 204407)
commonName = Sectigo Public Server Authentication CA DV E36
organizationName = Sectigo Limited
countryName = GB
Validity
Not Before: Jul 30 00:00:00 2025 GMT
Not After : Oct 28 16:23:47 2025 GMT
Subject:
commonName = worldofwheat.cc
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:61:af:b1:c2:10:55:14:b6:69:97:40:bd:ab:0a:
93:e3:c2:42:c0:fb:a9:05:b1:19:d4:a5:13:7a:b5:
5f:f3:3d:54:cf:4e:73:4b:35:8f:a0:07:c1:e0:8e:
eb:b2:2f:ae:28:fe:26:b9:fd:2d:15:51:b0:6e:af:
97:18:72:4d:3f
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:17:99:A8:04:C1:6F:E4:2D:70:A8:0A:10:3D:03:D3:E9:1A:B8:26:63
X509v3 Subject Key Identifier:
10:5E:89:1D:12:E6:37:25:22:9B:F5:A0:0D:A4:55:CB:E1:F8:E5:E8
X509v3 Key Usage: critical
Digital Signature
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.2.7
CPS: https://sectigo.com/CPS
Policy: 2.23.140.1.2.1
Authority Information Access:
CA Issuers - URI:http://crt.sectigo.com/SectigoPublicServerAuthenticationCADVE36.crt
OCSP - URI:http://ocsp.sectigo.com
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log Name : Google Xenon 2025h2
Log ID : DD:DC:CA:34:95:D7:E1:16:05:E7:95:32:FA:C7:9F:F8:
3D:1C:50:DF:DB:00:3A:14:12:76:0A:2C:AC:BB:C8:2A
Timestamp : Jul 30 17:27:48.910 2025 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:DC:DC:48:8A:2F:AF:11:CA:F3:E3:02:
99:C7:74:10:0F:57:25:E0:7C:EA:7A:07:25:89:12:E6:
5D:33:D8:3D:F5:02:21:00:93:B2:FA:6C:5A:69:21:94:
B2:C0:CA:A6:66:70:B0:79:33:E4:AB:CF:24:AF:BE:88:
18:A0:53:C1:23:06:63:13
Signed Certificate Timestamp:
Version : v1 (0x0)
Log Name : Let's Encrypt Oak 2025h2
Log ID : 0D:E1:F2:30:2B:D3:0D:C1:40:62:12:09:EA:55:2E:FC:
47:74:7C:B1:D7:E9:30:EF:0E:42:1E:B4:7E:4E:AA:34
Timestamp : Jul 30 17:27:48.810 2025 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:85:0D:EA:BE:80:09:3D:A3:D0:A7:33:
E4:D5:C2:C8:B5:AA:88:AE:EC:67:81:FB:DD:64:FF:40:
3F:DB:35:AB:67:02:21:00:E3:0E:3D:7A:4E:5A:B9:6B:
BD:5D:BC:5E:E6:31:D0:31:66:16:3E:75:52:0C:E3:3D:
0A:C2:84:51:B0:0A:D8:80
X509v3 Subject Alternative Name:
DNS:worldofwheat.cc
DNS:*.worldofwheat.cc
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:21:78:e4:0f:2a:87:e6:41:ef:31:a8:17:e7:6b:
cd:a3:e7:45:65:e2:1f:53:59:d8:58:56:77:19:fc:8d:cb:a4:
02:20:32:ab:2b:52:de:43:1e:74:2d:2a:8c:08:aa:e6:f0:41:
3f:fb:e2:1b:46:e7:54:28:17:72:61:1f:e5:58:3e:38
其實使用者和 SP 會互相驗證的地方差不多，但使用者會再多驗證 SP 的 commonName（CN），要確保域名是正確沒有問題的，值得注意的是這裡的域名是會因為不同的連接方式而有差異。例如使用 WPA-Enterprise 連接的話則要自己輸入域名，不輸入的話隨便一張憑證都能騙過去。
但這個漏洞的問題不是出在 CN，而是出在 Issuer，可能會覺得有點奇怪，明明只是簽的人有什麼問題嗎？確實如果把這張憑證放在 SP 或者是網頁伺服器沒什麼問題，但如果使用者拿著這張憑證做為 EAP-TLS 的憑證給 SP 那就漏洞就出現了。
信任鏈
下面這裡以 Let's Encrypt 的憑證為例，可以發現到根憑證有兩張，而下面又分了好幾張的中間憑證。而這裡會發生的問題就是如果 Radius 伺服器所信任的憑證是某一張根憑證或者中間憑證，而被其所簽發的子憑證都可以被信任。
換句話說如果 Radius 憑證伺服器信任了 ISRG Root X1 這張憑證，那只要隨便拿一張根憑證是 ISRG Root X1 的就都可以順利驗證。
模擬環境
我自己使用了 strongSwan 結合 Freeradius 來模擬這個漏洞，因為這樣方便架設也方便測試。
這裡使用的 strongSwan 做為 SP，提供的是 IKEv2/IPsec 服務，也就是 VPN。而 Freeradius 做為驗證伺服器，走的就是 Radius 協議。
快失效了
在寫這篇文章的時候其實這個洞也快要被修好了，可以注意到這篇在 Let's Encrypt blog 的文章，細看就會發現到有一個用途稱為「TLS Client Authentication」會被刪掉，我個人推測應該就是為了處理這個漏洞，但不同的 Radius 伺服器會不會驗證這個特性就有待考查。