Tag: security

用 VXLAN + WireGuard 保護 L2 流量的方法

在「Defend against vampires with 10 gbps network encryption (synacktiv.com)」這邊看到「Defend against vampires with 10 gbps network encryption」這篇，裡面在講怎麼保護 ethernet packet 的流量...

開頭就有提到各種從物理層面擷取流量的方式，像是現在主流的光纖要怎麼聽的方式，我記得當年 Snowden 揭露 PRISM 的時候蠻多細節被陸陸續續挖出來... 找了一下當年的報導：「NSA secretly taps Google, Yahoo data transmission worldwide」，在裡面提到：

In the case of Google, the most likely scenario is that the agencies have tapped into fibers and cables connecting the company’s privately owned or leased data centers in Chile, Ireland, Finland, Belgium, Taiwan, Hong Kong, Singapore and others.

這也是為什麼需要保護 ethernet packet 的流量，因為很有可能可以從路邊或是水溝邊直接夾光線聽到東西。

裡面有提到可以用 MACsec 保護，很久沒聽到這個技術了，以前有研究看過，不過記得當時覺得不太好用 (主要是設備支援的情況)，作者在文章裡面也有提到這點。

另外作者有提到 MACsec 沒有保護 MAC address，這點會透漏出設備數量以及可能的廠牌資訊，這也是個隱患 (也就是從 MAC address 與 OUI 資訊得知)。

作者後來選擇的方案是用 VXLAN 將 ethernet packet 轉成 UDP packet，然後再用 WireGuard 傳輸，這樣就可以保護 L2 流量，是個還蠻有趣的組合，然後經過測試後確認現有的 server 在經過簡單的調教後就可以跑到接近 wire-speed 的 10Gbps。

印象中當年在處理同個園區跨辦公室的 case，有一段光纖是跑在園區管道間，好像是用 IPsec 的 site-to-site VPN 解，一方面是兩邊的 IP subnet 不同，所以可以用 L3 的方案解決；另外一方面 IPsec 這個方案在一般商用 VPN 硬體還算成熟，不用自己弄一堆東西。

Percona 的 Telemetry Package

Percona 開始搞 Telemetry (收集資料) 了，翻公告才發現已經一陣子了：「Percona Is Introducing Telemetry Mechanisms Into MySQL, PostgreSQL, and MongoDB」。

關掉的方法：

sudo systemctl disable --now percona-telemetry-agent

另外也是可以考慮原版的 MySQL 與 MariaDB。

對 YubiKey 5 的 side-channel attack

在 Hacker News Daily 上看到的「EUCLEAK Side-Channel Attack on the YubiKey 5 Series (ninjalab.io)」，原文在「EUCLEAK」這邊。

對 YubiKey 5 的攻擊，攻擊需要能夠碰到實體的 key，透過 side-channel 取得 ECDSA secret key 進而複製：

The attack requires physical access to the secure element (few local electromagnetic side-channel acquisitions, i.e. few minutes, are enough) in order to extract the ECDSA secret key. In the case of the FIDO protocol, this allows to create a clone of the FIDO device.

新版的 firmware 解掉了這個問題：

The new YubiKey firmware 5.7 update (May 6th, 2024) switches the YubiKeys from Infineon cryptographic library to Yubico new cryptographic library. To our knowledge, this new cryptographic library is not impacted by our work.

但是官方文件上面也有提到 YubiKey 不支援 firmware 升級：「YubiKey Firmware is Not Upgradable」，對於安全性有高要求的人可能要聯絡 Yubico 看能不能換了...

另外手上的 YubiKey 從外觀不太好認，我是用 USB 的 Device ID 認的，發現官方有列出來，在 Linux 下可以用 lsusb 看到，Windows 應該是裝置管理員之類的地方可以看：「YubiKey USB ID Values」。

AWS KMS 支援 ECDH

看到「Announcing AWS KMS Elliptic Curve Diffie-Hellman (ECDH) support」這篇的介紹，AWS KMS 支援 ECDH 了。

從 AWS 的文件「DeriveSharedSecret」這邊可以看到就是在不將 private key 暴露出來的情況下得到 ECDH 產生的 shared secret：

The private key in your KMS key pair never leaves AWS KMS unencrypted. DeriveSharedSecret returns the raw shared secret.

翻了一下其他兩個雲的 Cloud HSM 類服務，好像沒有看到 ECDH 的，不過如果是實際硬體 HSM 的話，Azure Dedicated HSM 似乎有支援，可以在 FAQ 這邊看到：

Dedicated HSM service provisions Thales Luna 7 HSM appliances.

Cryptography (ECDSA, ECDH, Ed25519, ECIES) with named, user-defined, and Brainpool curves, KCDSA

AWS KMS 畢竟是軟體基底的，要支援什麼演算法可以直接加...

Let's Encrypt 想要停掉 OCSP 服務

看到 Let's Encrypt 貼出來的文章，想要停掉 OCSP 服務：「Intent to End OCSP Service」，而打算以 CRLs 為主。

OCSP 是拿來驗證 certificate 是否有效的機制，由 CA 提供服務讓瀏覽器查詢，但這會有效能與 privacy issue。

前者比較容易理解，因為熱門網站所使用的 HTTPS certificate 會導致很多瀏覽器跑去 OCSP 服務查詢；後者則是因為 OCSP 服務就會知道哪個 IP 存取哪個網站。

不過這兩個應該都可以用 OCSP stapling 解決才對，也就是 web server 去 OCSP 服務拿有效的簽名 (證明你手上的是有效的)，然後在瀏覽器連上來的時候一起送出去，這樣瀏覽器就不用跑去煩 OCSP 服務，而且 OCSP 服務也不知道誰看了什麼網站。

不過跟 CRLs 相比還是不小的負擔就是了，尤其像是 Let's Encrypt 這種等級的量，光是 web server 固定時間去要 OCSP stapling 的簽名 (這又是個數位簽章的動作) 不容易 cache；反過來 CRLs 容易 cache 多了？

另外一方面，CA/Browser 在 2023 年的時候已經投票通過，將 OCSP 列為選擇性項目，而 CRLs 則變成必要項目：「Ballot SC-063 v4: Make OCSP Optional, Require CRLs, and Incentivize Automation」

看文章的語氣，應該是先放個風向？尤其故意不提到 OCSP stapling 這點...

Android 的 Linux Kernel 將會有四年的維護期

去年 Linux Kernel 決定將 LTS 從六年縮短為兩年 (參考先前寫到的「Linux Kernel 後續的 LTS 版本將縮短成兩年」)，而 Android 這邊決定後來的 LTS 版本將額外提供兩年支援，變成四年：「Google extends Linux kernel support to keep Android devices secure for longer」，引用的報導在「Google extends Linux kernel support to keep Android devices secure for longer」。

在 Android 的說明文件「Android common kernels」這邊有提到這個時間：

Beginning with kernel 6.6, the support lifetime for the stable kernels is 4 years.

應該是 Android 本身的 support policy 需要這個長度...

透過 eBPF 攔 TLS 連線的明文

在「Capturing Linux SSL/TLS plaintext without a CA certificate using eBPF (github.com/gojue)」這邊看到的工具，可以透過 eBPF 直接攔 TLS 連線的明文，專案在 gojue/ecapture 這邊可以看到。

除了支援 OpenSSL，還支援了 GnuTLS 與 NSS，看起來常見的 library 都有支援。

算是 reverse engineering 的工具，看起來會適合用在應用程式有 pinning 的情況下 (像是 CA pinning，或是 certificate pinning)，有機會省下改 binary 的麻煩。

官方說明中有提到支援 Android + arm64 這點應該也算清楚。

dotenvx

清一清 tab... 兩個禮拜前還在日本時在 Hacker News 的「Show HN: From dotenv to dotenvx – better config management (dotenvx.com)」看到的東西，原文在推廣 dotenvx：「From dotenv to dotenvx: Next Generation Config Management」。

從 GitHub 的文件上可以看到幾個用法，一種是直接用，像是一般的 dotenv 的用法：

// index.js
require('@dotenvx/dotenvx').config()
console.log(`Hello ${process.env.HELLO}`)

另外一個是當 wrapper 用，像是這樣：

$ dotenvx run -- node index.js
Hello World # with dotenvx
> :-D

然後後者可以指定不同的 .env 多環境使用：

$ dotenvx run -f .env.production -- node index.js
[dotenvx][info] loading env (1) from .env.production
Hello production

另外還支援了 encrypt/decrypt 的能力降低 secret 的風險？不過這應該已經不是目前比較安全的方法了，這十年下來已經知道把 secret 放在環境變數裡太容易洩漏。

環境變數在呼叫外部程式時會被繼承，算是常見的 leaking 管道，另外就算不考慮外部程式，也會遇到環境變數算是一種全域變數，在寫測試時也很頭痛。

目前被提出來比較好的方法是把 secret 都放到 vault service 裡面，由 vault service 給一把讀取用的 API key，放進 dotenv 或是其他地方 (被稱為 secret zero)。

這樣這把 API key 去 vault service 抓取真正的 secret 放到程式內的物件取用 (像是資料庫的帳號密碼)，而不是環境變數。

這樣做的 threat model 在 Hacker News 上有對應的討論，另外 AWS 的服務其實也做了類似的事情：「Amazon EC2 的 IMDSv2 計畫」。

所以 dotenvx 大概就看看，有個印象就好？

regreSSHion：OpenSSH RCE

人在機場準備要回台灣，在 Hacker News 上看到「RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (qualys.com)」這個整個被抽醒，Qualys 的 security advisory 在這：「regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (CVE-2024-6387)」。

剛剛看 Ubuntu 套件已經更新了，請儘快更新...

OpenSSH 官方的「release-9.8」內有提到這是 race condition 造成的問題，在 32-bit 的 lab 環境上面大約六到八小時可以打進去，64-bit 環境理論上應該也是可行的，但時間還沒有被驗證：

Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon.

在 security advisory 裡面有提到更細節的部分，解釋了 race condition 的攻擊對象，以及為什麼 OpenBSD 沒中獎：

This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd's privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.

這幾天應該會有更多測試出來，另外 Hacker News 上有人提到上個月 OpenSSH 打算內建阻擋系統的事情，有在猜測跟這個 security advisory 有關？(參考「OpenSSH 要內建阻擋系統了」)...

Anyway，後續可以再研究看看，但現在先趕緊把手上機器更新一輪比較要緊...