對 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 畢竟是軟體基底的,要支援什麼演算法可以直接加...

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 大概就看看,有個印象就好?

HashiCorp 的 Vault 也有 fork 了:OpenBao

當初 HashiCorp 宣布改 license (可以參考之前寫的「HashiCorp 將放棄 Open Source License,改採用 BSL 1.1」),用的最多的 Terraform 就馬上有人 fork 出來:「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」、「OpenTF (Terraform 的 fork) 改名為 OpenTofu」。

Vault 也受到影響,當時花了一些時間找看看有沒有人 fork,沒找到後就改用 etcd (然後搭配 etcd-adminer 以及 oauth2-proxyGoogle Workspace 的 SSO),後來就沒有追這個問題了...

剛剛才看到 fork 的消息出來了:「OpenBao – FOSS Fork of HashiCorp Vault (github.com/openbao)」,專案在「OpenBao」這邊,要注意目前只有 development branch 有東西,main branch 目前是空的,而且 Hacker News 上討論也有提到現在還在 early stage,很多東西都還在整理。

之後有機會再回來看看...

GitHub 的 API Token 換格式

GitHub 前幾天宣佈更換 API token 的格式:「Authentication token format updates are generally available」,在今年三月初的時候有先公告要換:「Authentication token format updates」。

另外昨天也解釋了換成這樣的優點:「Behind GitHub’s new authentication token formats」。

首先是 token 的字元集合變大了:

The character set changed from [a-f0-9] to [A-Za-z0-9_]

另外是增加了 prefix 直接指出是什麼種類的 token:

The format now includes a prefix for each token type:

  • ghp_ for Personal Access Tokens
  • gho_ for OAuth Access tokens
  • ghu_ for GitHub App user-to-server tokens
  • ghs_ for GitHub App server-to-server tokens
  • ghr_ for GitHub App refresh tokens

另外官方目前先不會改變 token 長度 (透過字元變多增加 entropy),但未來有打算要增加:

The length of our tokens is remaining the same for now. However, GitHub tokens will likely increase in length in future updates, so integrators should plan to support tokens up to 255 characters after June 1, 2021.

看起來當初當作 hex string 而轉成 binary 會有問題,不過就算這樣做應該也是轉的回來的。

回到好處的部份,這個作法跟 SlackStripe 類似,讓開發者或是管理者更容易辨識 token 的類型:

As we see across the industry from companies like Slack and Stripe, token prefixes are a clear way to make tokens identifiable. We are including specific 3 letter prefixes to represent each token, starting with a company signifier, gh, and the first letter of the token type.

另外這也讓 secret scanning 的準確度更高,本來是 40 bytes 的 hex string,有機會撞到程式碼內的 SHA-1 string:

Many of our old authentication token formats are hex-encoded 40 character strings that are indistinguishable from other encoded data like SHA hashes. These have several limitations, such as inefficient or even inaccurate detection of compromised tokens for our secret scanning feature.

另外官方也建議現有的 token 換成新的格式,這樣如果真的發生洩漏,可以透過 secret scanning 偵測並通知:

We strongly encourage you to reset any personal access tokens and OAuth tokens you have. These improvements help secret scanning detection and will help you mitigate any risk to compromised tokens.

Vault 裡 AppRole 的設計,以及怎麼解決 Secret Zero 問題

VaultHashiCorp 拿來管理各種敏感資訊的軟體,像是 API token 或是資料庫的帳號密碼。把這些資訊集中控管後就不需要把這些資訊放進 Git (超爽的?),而是在需要的時候由應用程式呼叫 Vault 取得。

而 Vault 的設計裡面要求應用程式需要「認證」後才能取得,結果這個「認證」又是一組敏感資訊,這就是 Secret Zero 問題,屬於雞蛋問題的一種。

找了一輪發現 HashiCorp 自家的說明解釋的最清楚,不過這篇是放在 blog 上的文章:「Tackling the Vault Secret Zero Problem by AppRole Authentication」。

Vault 在解決 Secret Zero 的方法是使用 AppRole,這邊的認證包括了 role_idsecret_id 的設計。比較特別的是一組 role_id 可以有多組 secret_id 對應。

在 AppRole 這樣的設計下,權限會綁在 role_id 上,而 secret_id 則可以在部屬時動態產生,像是官方提到的 TerraformChef,或是依照組織裡面使用的管理工具:

這樣就可以透過 role_id 管理權限,但不用在 Git 裡面寫死 Secret Zero 資訊,而且每台機器都有自己的 secret_id 可以提供稽核記錄,把幾個比較明顯的問題解了不少...

AWS 推出 AWS Secrets Manager

AWS 推出 AWS Secrets Manager,你可以把各種帳號密碼丟進去讓系統管理,另外內建 rotate 的功能,針對 AWS 支援的服務可以無縫更換密碼 (目前看起來是 RDS),或是透過 Lambda 換:「AWS Secrets Manager: Store, Distribute, and Rotate Credentials Securely」。

是個整合性的服務,之前就可以做 (用 Lambda 定時跑),現在則是包裝起來針對 AWS 自家的服務弄的更簡單。

Cloudflare 推出在 HTTPS 下的壓縮機制

在 TLS (HTTPS) 環境下基本上都不能開壓縮,主要是為了避免 secret token 會因為 dictionary 的可預測性而被取出,像是 CRIMEBREACHTIMEHEIST (沒完結過...),而因為全面關閉壓縮,對於效能的影響很大。

Cloudflare 就試著去找方法,是否可以維持壓縮,但又不會洩漏 secret token 的方式,於是就有了這篇:「A Solution to Compression Oracles on the Web」。

重點在於 Our Solution 這段的開頭:

We decided to use selective compression, compressing only non-secret parts of a page, in order to stop the extraction of secret information from a page.

透過 regex 判斷那些東西屬於 secret token,然後對這些資料例外處理不要壓縮,而其他的部份就可以維持壓縮。這樣傳輸量仍然可以大幅下降,但不透漏 secret token。然後因為這個想法其實很特別,沒有被實證過,所以成立了 Challenge Site 讓大家打:

We have set up the challenge website compression.website with protection, and a clone of the site compression.website/unsafe without it. The page is a simple form with a per-client CSRF designed to emulate common CSRF protection. Using the example attack presented with the library we have shown that we are able to extract the CSRF from the size of request responses in the unprotected variant but we have not been able to extract it on the protected site. We welcome attempts to extract the CSRF without access to the unencrypted response.

這個方向如果可行的話,應該會有人發展一些標準讓 compression algorithm 不用猜哪些是 secret token,這樣一來就更能確保因為漏判而造成的 leaking...

AWS 推出 AWS Secret Region

AWS 推出給情報單位用的 AWS Secret Region:「Announcing the New AWS Secret Region」。

AWS GovCloud (US) 類似的架構,這個雲的範圍再小一些,給情報單位以及有對應授權的單位用的:

The AWS Secret Region is readily available to the U.S. Intelligence Community (IC) through the IC’s Commercial Cloud Services (C2S) contract with AWS.

The AWS Secret Region also will be available to non-IC U.S. Government customers with appropriate Secret-level network access and their own contract vehicles for use of the AWS Secret Region.

俄羅斯政府透過卡巴斯基的漏洞,偷取美國國安局的文件

這下知道為什麼美國政府要直接禁用 Kaspersky 了:「Russian Hackers Stole NSA Data on U.S. Cyber Defense」。如果看不到 WSJ 的文章,可以看「Russia reportedly stole NSA secrets with help of Kaspersky—what we know now」這邊。

最近的事件被發現與 Kaspersky 的漏洞有關:

The hackers appear to have targeted the contractor after identifying the files through the contractor’s use of a popular antivirus software made by Russia-based Kaspersky Lab, these people said.

加上 Kaspersky 有濃厚的俄羅斯官方色彩 (關係良好),以及法令上與技術上都有可能性要求 Kaspersky 協助。雖然這次事件是合約工家裡電腦用 Kaspersky 造成的,但已經有足夠的風險讓美國政府決定開鍘下令完全禁用了:

For years, U.S. national security officials have suspected that Kaspersky Lab, founded by a computer scientist who was trained at a KGB-sponsored technical school, is a proxy of the Russian government, which under Russian law can compel the company’s assistance in intercepting communications as they move through Russian computer networks.