對 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」。

polyfill.io 被放 malicious code 的事件

台灣的圈子蠻多人是從「請儘速遠離 cdn.polyfill.io 之惡意程式碼淺析」這邊看到的,一些 code 相關的分析部分可以移駕過去看。裡面提到的 GitHub 上面 alitonium 所寫的 comment 蠻值得讀一下 (第一次點的時候會出現 GitHub 的警告,再點一次應該就會跳到正確的 comment 上)。

polyfill.js 算是老專案了,從 https://github.com/polyfillpolyfill/polyfill-service/graphs/contributors 這邊可以看到是 2013 年開始有記錄,主要是針對舊的瀏覽器 (像是 IE11),透過 javascript 的方式補上對應的功能。

現在的瀏覽器都是一直在更新,大多數的情況不太需要 polyfill 了,但畢竟很多舊的案子還在用,在這次 domain 被中國公司拿走後,Cloudflare 在今年 2024/2/29 就有先寫一篇算是預警的文章了:「polyfill.io now available on cdnjs: reduce your supply chain risk」,不過這種事情都是還沒發生前大家不會有太多重視,接下來就是 GitHub 上面的討論,然後是真的被動手加 malicious code 進去後,有人發現的討論。

後續大家都被迫要開始處理這件事情,GitHub 的作法看起來沒什麼問題:先標注 malicious repository 但是還是讓人可以進去翻歷史資料與討論。

不過 Cloudflare 這邊動作有點大,直接主動幫 CDN 客戶過濾了:「Automatically replacing polyfill.io links with Cloudflare’s mirror for a safer Internet」,這篇在 Hacker News 上也有討論:「Cloudflare automatically fixes Polyfill.io for free sites (cloudflare.com)」。

這個「越界」有點多,這應該也是直接讓 CEO Matthew Prince 出來掛文章作者的原因。這次 Cloudflare 主動做的事情包括了將免費的客戶預設開啟過濾,而付費的客戶則不會主動開啟,但提供一鍵開關:

Any website on the free plan has this feature automatically activated now. Websites on any paid plan can turn on this feature with a single click.

另外也允許所有客戶關掉這個保護:

All customers can turn off the feature at any time.

所以後續就會有另外一條大支線討論:在使用者沒有事前同意的情況下,以「安全」為名主動更改使用者頁面上的東西,這件事情是不是可以接受?如果以「安全」為名可以接受,為什麼是免費的先動,付費的卻不動?雖然我猜 Cloudflare 會裝死到底就是了...

對戰爭時期警報的再分類

在「How Home Assistant is being used to protect from missile and drone attacks (denysdovhan.com)」這邊看到的,原始文章是「War Safety」。

俄羅斯入侵烏克蘭已經兩年多了,作者提到,如果每次聽到警報都得馬上避難的話,會無法過日子,所以得想個方法針對警報再分類危險性:

We hear the siren a few times a day. Life would completely stop if we went to the shelter every time the siren goes off. So, people adapt.

文章裡面提到四種分類,包括了 MiG-31 戰機的起飛、自殺式無人機的攻擊、彈道飛彈的攻擊,以及巡弋飛彈的攻擊。所以想法是針對這四種攻擊不同的危險程度,決定當下的行為。

這種東西主要就是抓想法,先看別人遇到的時候做過什麼...

LLL lattice basis reduction algorithm

短短幾天內看到兩個不同的地方用到了 1982 年發現的「Lenstra–Lenstra–Lovász lattice basis reduction algorithm」。

第一個是「Randar: A Minecraft exploit that uses LLL lattice reduction to crack server RNG (github.com/spawnmason)」這篇,作者群利用 LLL 去分析 java.util.Random 的內部狀態,進而得到其他玩家的地點資訊:

Every time a block is broken in Minecraft versions Beta 1.8 through 1.12.2, the precise coordinates of the dropped item can reveal another player's location.

"Randar" is an exploit for Minecraft which uses LLL lattice reduction to crack the internal state of an incorrectly reused java.util.Random in the Minecraft server, then works backwards from that to locate other players currently loaded into the world.

另外一個是在 Hacker News 上面的 id=40080651 提到,前幾天 PuTTY 的 p521 問題在底層也用到了 LLL:

LLL lattice reduction is the same algorithm that can be used for cracking PuTTY keys from biased nonces from the CVE a few days ago. 'tptacek explained a bit about the attack (and links to a cryptopals problem for it, which I can almost pretend to understand if I squint) https://news.ycombinator.com/item?id=40045377

從維基百科的內容也可以看出來 application 非常多,不光是密碼學的領域用到,看起來值得花點力氣來了解...

一個害我嗆到的故事... (Netlify 帳單的故事?)

故事本身其實還蠻普通的,只是我的閱讀順序害我嗆到...

首先是在 Hacker Newsbest 頁上看到「Netlify just sent me a $104k bill for a simple static site (reddit.com)」這篇,點進去以後是 Reddit 的「Netlify just sent me a $104K bill for a simple static site」這篇,看了一下作者的敘述,是個用 Netlify 的服務,上面有個 3.44MB 的音檔被針對攻擊,造成 190TB 的流量,以及 $104K 的帳單 (十萬多美金),之後 Netlify 的客服同意這是 DDoS 攻擊,給他 95% discount,也就是還是要付 $5K 左右...

Reddit 下面最高分的回應是:

[–]thankyoufatmember 2262 points 14 hours ago
Don't pay, post the story to Hackernews!

Okay,我想說我就是從 Hacker News 上看到點過來的... 回去看一下好了,結果在 Hacker News 的留言最上方是:

bobfunk 10 hours ago | next [–]

Netlify CEO here.

Our support team has reached out to the user from the thread to let them know they're not getting charged for this.

It's currently our policy to not shut down free sites during traffic spikes that doesn't match attack patterns, but instead forgiving any bills from legitimate mistakes after the fact.

Apologies that this didn't come through in the initial support reply.

然後我剛好在喝茶,就嗆到了...

人家常說 Ptt 的電蝦板 (PC_Shopping) 是全台灣最大的客服中心,遇到各種不公不義的問題貼上去就會解決了... 這點倒是頗像的。

sudo 對 ROWHAMMER 攻擊的 mitigation

看到「Rowhammer Resistant Coding in Sudo (github.com/sudo-project)」這邊的討論,提到了 sudo 專案 (變成 root 那個 sudo 軟體) 怎麼緩解 ROWHAMMER 攻擊的實作,原連結是去年九月時 GitHub 上的 commit:「Try to make sudo less vulnerable to ROWHAMMER attacks.」。

從 commit 裡面可以看到這個:

- #define AUTH_SUCCESS		0
- #define AUTH_FAILURE		1
- #define AUTH_INTR		2
- #define AUTH_ERROR		3
- #define AUTH_NONINTERACTIVE	4
+ #define AUTH_SUCCESS		0x52a2925	/* 0101001010100010100100100101 */
+ #define AUTH_FAILURE		0xad5d6da	/* 1010110101011101011011011010 */
+ #define AUTH_INTR		0x69d61fc8	/* 1101001110101100001111111001000 */
+ #define AUTH_ERROR		0x1629e037	/* 0010110001010011110000000110111 */
+ #define AUTH_NONINTERACTIVE	0x1fc8d3ac	/* 11111110010001101001110101100 */

可以看到想法上是讓要攻擊時需要改變的 bit 數量大幅增加?尤其是對 AUTH_SUCCESShamming distance

另外這段也是類似的設計:

+ /* Allowed by policy (rowhammer resistent). */
+ #undef ALLOW
+ #define ALLOW	 0x52a2925	/* 0101001010100010100100100101 */
+ 
+ /* Denied by policy (rowhammer resistent). */
+ #undef DENY
+ #define DENY	 0xad5d6da	/* 1010110101011101011011011010 */

這邊 ALLOWDENY 這邊也是把 hamming distance 設計到最大,兩個 XOR 後剛好是 0xffffffff

會不會變成安全相關軟體實作上的 practice?

SourceHut 被 DDoS 後的報告

SourceHut 在 DDoS 後發表了報告:「SourceHut network outage post-mortem」。

這次的攻擊在 L3 層,直接塞爆 upstream bandwidth:

At around 06:00 UTC on January 10th, a layer 3 distributed denial-of-service (DDoS) attack began to target SourceHut’s PHL infrastructure.

上游 Cogent 選擇 null route 掉:

In response to the attack, Cogent announced null routes for our downstream AS, causing our PHL network to become unreachable both for SourceHut staff and the general public.

中間有試著問 Cloudflare 以及其他的方案,但依照他們的說法,費用上無法承受:

We initially researched a number of solutions, and spoke to Cloudflare in particular due to their ability to provide a rapid response to ongoing incidents. However, given our complex requirements, Cloudflare quoted us a figure which was not attainable within our financial means as a small company. Other options we researched (though we did not seek additional quotes) had similar economical constraints.

後來的解法是在 OVH 放 proxy server (搭配 OVH 的 DDoS 保護服務),然後導到沒有公開的 subnet:

However, we found that OVH’s anti-DDoS protections were likely suitable: they are effective, and their cost is amortized across all OVH users, and therefore of marginal cost to us. To this end the network solution we deployed involved setting up an OVH box to NAT traffic through OVH’s DDoS-resistant network and direct it to our (secret) production subnet in AMS; this met our needs for end-to-end encryption as well as service over arbitrary TCP protocols.

GitHub 在還沒被 Microsoft 併購前 (2018 年) 也有被打的記錄,2015 年的時候 Google 有放一些資料,當年有寫一篇記錄下來:「Google 對 GitHub 先前遭受 GFW 的 DDoS 攻擊的分析」,不過當年這波是 L7 的。

另外 2016 年的時候 GitHub 也有整理一篇關於 TCP SYN flood 的阻擋方式,這個看起來比較接近這次的攻擊:「GitHub 對抗 TCP SYN Flood 的方式:synsanity」。

microsoft.com 的 DNS 出包

Hacker News Daily 上的「Tell HN: Microsoft.com added 192.168.1.1 to their DNS record」這邊看到的,看起來是某種 misconfiguration 造成 microsoft.comA record 除了給正常的 IPv4 address 外,還給出了 192.168.1.1192.168.1.0 的 IPv4 address。

不過裡面比較有趣的是 id=38704301 這個,提到他反而查不到,看 log 發現被 dnsmasq 認定是 DNS rebinding 的攻擊而擋下來不回應任何 IP address:

I was getting an empty answer for microsoft.com. Turns out my dnsmasq is blocking it:

  $ dig microsoft.com. | grep EDE
  ; EDE: 15 (Blocked)

  resolver.log:Dec 20 00:43:57 router dnsmasq[8172]: possible DNS-rebind attack detected: microsoft.com

翻了 dnsmasq 的 manpage,可以看到這個功能:

--stop-dns-rebind

Reject (and log) addresses from upstream nameservers which are in the private ranges. This blocks an attack where a browser behind a firewall is used to probe machines on the local network. For IPv6, the private range covers the IPv4-mapped addresses in private space plus all link-local (LL) and site-local (ULA) addresses.

id=38704159 這邊也有類似的情況,不過這邊是提到 OpenWrt

microsoft.com is currently IPv6-only on my network, because OpenWrt's DNS rebinding protection filters out the A records:

  $ ping -4 microsoft.com
  ping: microsoft.com: Address family for hostname not supported

  $ ping -6 microsoft.com
  PING microsoft.com(2603:1030:c02:8::14 (2603:1030:c02:8::14)) 56 data bytes
  64 bytes from 2603:1030:c02:8::14 (2603:1030:c02:8::14): icmp_seq=1 ttl=112 time=68.4 ms

ISP 偽造出合法的 SSL certificate,對放在德國的 xmpp.ru 進行 MITM 監聽

標題有點複雜,先講一下 http-01 認證,這是目前 Let's Encrypt 上最常被使用的認證方式,是透過 HTTP 協定完成認證,你只要能回答 http://www.example.com/.well-known/acme-challenge/XXX 的內容就能過。

一般來說,這個 HTTP 位置只有這台伺服器的 owner 才有辦法提供,也就能確保不是任何人都可以申請。

但因為這邊走的是 HTTP,對於 ISP 這種比較特別的身分來說,他可以從中架設 HTTP 的 MITM Proxy 做到這件事情。

而有了合法的 SSL certificate 之後,中間的 MITM Proxy 就不只能聽 HTTP 了,還可以聽 HTTPS 的內容 (甚至修改內容)。

這次發生的事情就是在德國的 LinodeHetzner 機房內的服務,俄羅斯最大的 XMPP 服務 xmpp.ru 被搞出這件事情 (XMPP 是一個開放協定,不熟的話可以想像成類似 Line 或是 Telegram 的服務,但 XMPP 是開放協定,可以用自己喜歡的軟體連上):「Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service」。

他們在 Hetzner 的伺服器上有發現 network offline 的訊號:

[Tue Jul 18 12:58:29 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Down
[Tue Jul 18 12:58:48 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

而在這個 network offline 的時間不久後 Let's Encrypt 發出了 xmpp.ru 與 jabber.ru 的 SSL certificate (crt.sh 上可以查到,在 99976947049997621208):

18 July 2023 issuing time is about the same when Hetzner server has lost network link for several seconds.

這些徵兆符合改接到 MITM Proxy 上的行為。

這次的事情很大條,因為這些伺服器是在德國,不是在俄羅斯... 事情才剛開始被報導出來,後續得繼續追蹤,而且應該也會促成新的機制被引入?

OpenSSH 加入了 noise (keystroke timing obfuscation) 功能

Hacker News 上看到在 OpenSSH 裡加入 keystroke timing obfuscation 的功能:「Keystroke timing obfuscation added to ssh(1) (undeadly.org)」。

如同 commit log 裡面提到的,這個功能會想要故意沒事就送一些沒用的資料 (增加一些噪音),降低從 side channel 被判讀的資訊量:

This attempts to hide inter-keystroke timings by sending interactive traffic at fixed intervals (default: every 20ms) when there is only a small amount of data being sent. It also sends fake "chaff" keystrokes for a random interval after the last real keystroke. These are controlled by a new ssh_config ObscureKeystrokeTiming keyword/

基於 OpenSSH 算是 SSH 這塊的 de-factor standard 了,接下來看其他家像是 Dropbear 會不會也實作?