Tag: security

FreeBSD 14.0 釋出

FreeBSD 14.0-RELEASE 的公告也出來了：「FreeBSD 14.0-RELEASE Announcement」，比較完整的 release notes 在「FreeBSD 14.0-RELEASE Release Notes」。

先從官方列的 highlight 來看，首先比較重要的是 GENERIC kernel 支援 1024 cores：

FreeBSD supports up to 1024 cores on the amd64 and arm64 platforms.

看了一下 commit log 是從 256 變成 1024。

先就 x86-64 這邊來看，目前「家用」最多的應該是 AMD 的 7995WX (96 cores)，舊版的 256 限制應該也還能撐住，但看 commit log 有提到，主要是預期這幾年應該會有更暴力的機器出現。

另外一塊是伺服器端，Intel 這邊有 8 sockets 的版本 (參考「Intel Xeon Sapphire Rapids to Scale to 4 and 8 Sockets」)，如果都是接 8490H 的話就是 480 cores 了。

ARM 的話好像也可以堆，但不熟...

另外一個提到的重點是 TCP 預設的 congestion control 改成 CUBIC：

The default congestion control mechanism for TCP is now CUBIC.

翻 commit log 可以看到是從 NewReno 換成 CUBIC 的，這樣就跟 Linux kernel 預設值一樣了。

再來比較重要的是在 release notes 裡面提到的，FreeBSD 15.0 將會拔光 32-bit 環境的支援，只留 armv7，這代表 Raspberry Pi 第一代的 armv6 也被淘汰掉了：

FreeBSD 15.0 is not expected to include support for 32-bit platforms other than armv7. The armv6, i386, and powerpc platforms are deprecated and will be removed. 64-bit systems will still be able to run older 32-bit binaries.

然後有些我自己翻覺得還蠻有趣的。

首先是看到 non-root 的 chroot：

The chroot facility supports unprivileged operation, and the chroot(8) program has a -n option to enable its use. a40cf4175c90 (Sponsored by EPSRC)

然後把 OpenSSH 內對 FIDO/U2F 的支援開起來了：

The use of FIDO/U2F hardware authenticators has been enabled in ssh, using the new public key types ecdsa-sk and ed25519-sk, along with corresponding certificate types. FIDO/U2F support is described in https://www.openssh.com/txt/release-8.2. e9a994639b2a (Sponsored by The FreeBSD Foundation)

ASLR 預設開啟：

Address Space Layout Randomization (ASLR) is enabled for 64-bit executables by default. It can be disabled as needed if applications fail unexpectedly, for example with segmentation faults. To disable for a single invocation, use the proccontrol(1) command: proccontrol -m aslr -s disable command. To disable ASLR for all invocations of a binary, use the elfctl(1) command: elfctl -e +noaslr file. Problems should be reported via the problem reporting system, https://bugs.freebsd.org, or posting to the freebsd-stable@FreeBSD.org mailing list. b014e0f15bc7 (Sponsored by Stormshield)

然後先前被罵臭頭的 WireGuard 支援也放回來了：(「FreeBSD & pfSense 上的 WireGuard 問題」)

The kernel wg(4) WireGuard driver has been reintegrated; it provides Virtual Private Network (VPN) interfaces using the WireGuard protocol. 744bfb213144 (Sponsored by Rubicon Communications, LLC ("Netgate") and The FreeBSD Foundation)

然後看到 Netflix 贊助的 kTLS 支援 TLS 1.3：

KTLS (the kernel TLS implementation) has added receive offload support for TLS 1.3. Receive offload is now supported for TLS 1.1 through 1.3; send offload is supported for TLS 1.0 through 1.3. 05a1d0f5d7ac (Sponsored by Netflix)

然後 FreeBSD 長久以來 root 預設用的 /bin/csh 改成 /bin/sh 了：

The default shell for the root user is now sh(1), which has many new features for interactive use. d410b585b6f0

預設的 MTA 變成 dma (Dragonfly Mail Agent)，看名字加上翻了一下 manpage，確認是從 Dragonfly BSD 移植過來的：

The default mail transport agent (MTA) is now the Dragonfly Mail Agent (dma(8)) rather than sendmail(8). Configuration of the MTA is done via mailer.conf(5). sendmail(8) and its configuration remain available. a67b925ff3e5

然後 portsnap 被拔掉了，現在就建議直接用 git 拉了，算是功成身退了：

The portsnap(8) utility has been removed. Users are encouraged to fetch the ports tree by using pkg install git and then git clone https://git.FreeBSD.org/ports.git /usr/ports. df53ae0fdd98

而 mergemaster 也被換成 etcupdate 了：

mergemaster(8) has been deprecated. Its replacement is etcupdate(8). 398b12691b4f (Sponsored by The FreeBSD Foundation)

然後支援 tarfs，而且可以用 zstd：

The tarfs(5) file system has been added, which is backed by POSIX tar archives optionally compressed with zstd(1). 69d94f4c7608 (Sponsored by Juniper Networks, Inc.) (Sponsored by Klara, Inc.)

好久沒看 FreeBSD 的 release notes...

從 e-mail 取得電話號碼

Hacker News 上看到 2019 年的文章：「From email to phone number, a new OSINT approach (2019) (martinvigo.com)」，原文在「From email to phone number, a new OSINT approach」。

用的原理是每一家在 recovery 時都會透漏電話號碼的不同部位，從截圖可以看到像是 PayPal 給的是區碼地一碼加上後三碼：

然後他整理出來：

Leaks first three and last two digits:
eBay

Leaks first and last four digits:
Paypal

Leaks first and last two digits:
Yahoo

Leaks last four digits:
Lastpass

Leaks last two digits:
Google
Facebook
Twitter
Hotmail
Steam

接著文章裡面介紹了其他的方法再縮小可能性，然後再反過來利用電話號碼查 e-mail，像是 Amazon：

後面則是示範了這整套過程可以自動化。

可以確認電話號碼後可以做的事情就很多了，文章裡面提到的也只是一小塊...

歌曲與專輯名稱的各種變化

Hacker News 上看到「Horrible edge cases to consider when dealing with music (2022) (dustri.org)」這篇，講音樂產業各種奇怪種奇怪的 case，2022 年的原文在這邊：「Horrible edge cases to consider when dealing with music」，裡面有蠻大的篇幅都在講名稱的問題...。

這讓我想到這則推：

基本上會遇到各種 escaping 與 UTF-8 的處理，另外文章裡面提到會遇到超長名稱，也就是 VARCHAR(255) 的剋星... 不確定之前在 K 社大量取得授權的時候有沒有遇到這張 1999 年的專輯 (下面這是一張專輯的名字)：

When the Pawn Hits the Conflicts He Thinks Like a King What He Knows Throws the Blows When He Goes to the Fight and He'll Win the Whole Thing 'Fore He Enters the Ring There's No Body to Batter When Your Mind Is Your Might So When You Go Solo, You Hold Your Own Hand and Remember That Depth Is the Greatest of Heights and If You Know Where You Stand, Then You Know Where to Land and If You Fall It Won't Matter, Cuz You'll Know That You're Right.

其他文章裡面提到的應該都算是見怪不怪的情境，像是單曲七個小時... 這種在 server side 還拼的過去，但在行動平台上面比較苦命，直接把整曲都放進 memory 裡面的話有可能會炸。

320kbps 七個小時差不多是 1GB，如果沒注意這點，直接處理 DRM 的話瞬間就會吃到 2GB RAM；如果拉到 CD quality 的資料量就更明顯了。

然後你會發現，把音樂創作人的任何資料都當作 untrusted input 的態度來設計系統 (但你不能 reject)，問題通常就不會太大 XD

Amazon EC2 的 IMDSv2 計畫

2019 的時候 Amazon EC2 推出了 IMDSv2 (Instance Metadata Service)：「Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service」。

舊版 v1 的 IMDS 可以直接拿到很多東西，像是這樣：

curl -v http://169.254.169.254/latest/dynamic/instance-identity/document

對於有使用 IAM Role 授權 EC2 instance 操作的，還可以參考「How to hack AWS instances that have the metadata service (IMDSv1) enabled」這邊的方法取得對應的 AWS credential。

當攻擊者可以「操弄」時 (像是 proxy server 或是 crawler)，就會蠻危險的。

而 IMDSv2 則是多了一個步驟，你要先拿到 token，再把這個 token 帶到之後的 HTTP request header 裡面，而蠻多可以「操弄」的情境下是無法修改 HTTP request header 的：

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl http://169.254.169.254/latest/meta-data/profile -H "X-aws-ec2-metadata-token: ${TOKEN}"

而這次 2023 年則是推出了對應的計畫，將在 2024 年年中把預設值改成只提供 IMDSv2：「Amazon EC2 Instance Metadata Service IMDSv2 by default」。

Effective mid-2024, newly released Amazon EC2 instance types will use only version 2 of the EC2 Instance Metadata Service (IMDSv2). We are also taking a series of steps to make IMDSv2 the default choice for AWS Management Console Quick Starts and other launch pathways.

舊的 IMDSv1 還是可以開，但需要指定才會啟用。

Amazon RDS 的 TLS 連線所使用的 CA 要更新了

Amazon RDS 的 TLS (SSL) 連線所使用的 CA 要更新了：「Rotate Your SSL/TLS Certificates Now – Amazon RDS and Amazon Aurora Expire in 2024」。

如果沒有開 TLS 連線的話是不受影響 (像是內網裸奔)，但如果有在用 TLS 的話就要注意一下了，看起來得手動更新處理。

比較特別的是新的 CA 簽的超長：

Most SSL/TLS certificates (rds-ca-2019) for your DB instances will expire in 2024 after the certificate update in 2020. In December 2022, we released new CA certificates that are valid for 40 years (rds-ca-rsa2048-g1) and 100 years (rds-ca-rsa4096-g1 and rds-ca-ecc384-g1). So, if you rotate your CA certificates, you don’t need to do It again for a long time.

現有的 rds-ca-2019 可以在 https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem 這邊取得，用 openssl x509 -in rds-ca-2019-root.pem -text 可以看到資料。

到 crt.sh 上翻過一些字串，沒看到被簽的記錄，所以看起來無法透過一般 trusted store 裡面的 Root CA 一路信任下來。

新的 key 應該也是 Private Root CA，從名字看起來應該是對應的 key algorithm。其中 RSA 2048 的簽了 40 年，而 RSA 4096 與 ECC 384 的簽了 100 年，雖然說是自家弄的 CA，但目前的 compliance 沒有要求 key rotation 嗎...

Anyway，常用的區域基本上都是 August 22, 2024 這個日期，大約還有九個多月的時間更新，依照 AWS 的慣例，後面應該還會提醒幾次：

話說 2020 年的時候也有更新，當時是 Jeff Barr 出來說明的：「Urgent & Important – Rotate Your Amazon RDS, Aurora, and Amazon DocumentDB (with MongoDB compatibility) Certificates」，現在看起來一些常態性的說明都陸續交棒給 Channy Yun 了...

不過這次這樣搞 40 年 & 100 年，後續要更新應該都是演算法的推進了，比較不會是要到期...

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 的內容 (甚至修改內容)。

這次發生的事情就是在德國的 Linode 與 Hetzner 機房內的服務，俄羅斯最大的 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 上可以查到，在 9997694704 與 9997621208)：

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

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

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

Python 3 的支援週期

印象中之前有找過資料應該有寫過，但搜了一下沒翻到，可能是當初寫一寫刪掉了？

Python 的支援週期在「Status of Python versions」這頁可以看到，只看 Python 3 的部分的話，可以看出來從 3.2 之後的版本都是固定五年：

五年剛好與 Ubuntu 的 LTS 相同，好像有點微妙... 會遇到 Ubuntu 的 LTS 支援快要結束的時候，官方的支援也已經結束了，所以也的確有看到 18.04 (bionic) 後續的更新把 python3-minimal 升級到 3.8 版 (2019/10/14 出)。

看起來 20.04 (focal) 也會遇到類似的問題，目前的 python3-minimal 是 3.8.2-0ubuntu2，到 2024 年十月終止，而 20.04 (focal) 的 LTS 到 2025 年四月，應該也會生個版本？

NIST P-curve 的 Seed Bounty Program

Filippo Valsorda 發起了 seed bounty program，針對 NIST P-curve 裡 seed 的部分尋找 SHA-1 的 pre-image：「Announcing the $12k NIST Elliptic Curves Seeds Bounty」。

先講一下這次的 bounty program，希望找出下面這些 SHA-1 的 pre-image input (也就是找出 input，使得 SHA1(input) 會等於下面的東西)：

3045AE6FC8422F64ED579528D38120EAE12196D5
BD71344799D5C7FCDC45B59FA3B9AB8F6A948BC5
C49D360886E704936A6678E1139D26B7819F7E90
A335926AA319A27A1D00896A6773A4827ACDAC73
D09E8800291CB85396CC6717393284AAA0DA64BA

金額是 US$12288，但是要五個都找到。

話說在寫這篇時，查資料發現 P-384 有獨立條目，但 P-256 與 P-521 都是重導指到 Elliptic-curve cryptography 這個條目，但 P-384 看起來也沒什麼特別的，不知道當初編輯的人是怎麼想的...

回來原來的問題，要從一些背景開始講，橢圓曲線的表示法有多種，像是：

y^2 = x^3 + ax + b (Weierstrass form) y^2 = x^3 + ax^2 + bx (Montgomery form)

而這些常數 a 與 b 的選擇會影響到計算速度，所以通常會挑過，但畢竟是密碼學用的東西，挑的過程如果都不解釋的話，會讓人懷疑是不是挑一個有後門的數字，尤其 NIST (NSA) 後來被證實在 Dual_EC_DRBG 裡面埋後門的醜聞，大家對於 NIST 選擇或是設計的密碼系統都有很多疑慮。

舉個例子來說，2005 年時 djb 發明了 Curve25519 (論文「Curve25519: new Diffie-Hellman speed records」則是記錄 2006)，選擇的橢圓曲線是：

y^2 = x^3 + 486662x^2 + x

他就有提到這邊的 486662 是怎麼來的：他先在前一個段落說明，這邊數字如果挑的不好的話，會有哪些攻擊可以用，接下來把最小的三個值列出來，然後說明原因：

To protect against various attacks discussed in Section 3, I rejected choices of A whose curve and twist orders were not {4 · prime, 8 · prime}; here 4, 8 are minimal since p ∈ 1+4Z. The smallest positive choices for A are 358990, 464586, and 486662. I rejected A = 358990 because one of its primes is slightly smaller than 2^252, raising the question of how standards and implementations should handle the theoretical possibility of a user’s secret key matching the prime; discussing this question is more difficult than switching to another A. I rejected 464586 for the same reason. So I ended up with A = 486662.

而 P-192、P-224、P-256、P-384 與 P-521 的值都很怪，這是十六進位的值，在正式的文件或是正式的說明上都沒有解釋，屬於「magic number」：

3045AE6FC8422F64ED579528D38120EAE12196D5 # NIST P-192, ANSI prime192v1
BD71344799D5C7FCDC45B59FA3B9AB8F6A948BC5 # NIST P-224
C49D360886E704936A6678E1139D26B7819F7E90 # NIST P-256, ANSI prime256v1
A335926AA319A27A1D00896A6773A4827ACDAC73 # NIST P-384
D09E8800291CB85396CC6717393284AAA0DA64BA # NIST P-521

依照 Steve Weis 說，這些值當初是 Jerry Solinas 是隨便抓個字串，再用 SHA-1 生出來的：

Apparently, they were provided by the NSA, and generated by Jerry Solinas in 1997. He allegedly generated them by hashing, presumably with SHA-1, some English sentences that he later forgot.

這是 Steve Weis 的敘述，出自「How were the NIST ECDSA curve parameters generated?」：

[Jerry] told me that he used a seed that was something like:
SEED = SHA1("Jerry deserves a raise.")
After he did the work, his machine was replaced or upgraded, and the actual phrase that he used was lost. When the controversy first came up, Jerry tried every phrase that he could think of that was similar to this, but none matched.

如果可以證實當初的字串，那麼 NIST 在裡面埋後門的疑慮會再降低一些，這就是這次發起 bounty program 的原因。

在 Raspberry Pi (32-bit) 上安裝 Tor

在 Raspbian (bullseye) 裡面的 Tor 版本太舊 (0.4.5.16-1)：

0.4.5.16-1 (/var/lib/apt/lists/raspbian.raspberrypi.org_raspbian_dists_bullseye_main_binary-armhf_Packages)
 Description Language: 
                 File: /var/lib/apt/lists/raspbian.raspberrypi.org_raspbian_dists_bullseye_main_binary-armhf_Packages
                  MD5: 9106e8e4b3843ebd532ba2b89615a92e
 Description Language: 
                 File: /var/lib/dpkg/status
                  MD5: 9106e8e4b3843ebd532ba2b89615a92e

這個版本試著連上線的時候會發生像是這樣的錯誤訊息：

Oct  4 10:55:58 myserver Tor[991]: http status 400 ("Tor version is insecure or unsupported. Please upgrade!") response from dirserver 1.2.3.4:80. Please correct.

本來想說可以裝 Tor 官方的版本 (官方有提供 apt repository)，結果發現官方不支援 Raspberry Pi 一代用的 armhf 了，只好另外找...

然後翻到「http://raspbian.raspberrypi.org/raspbian/pool/main/t/tor/」這邊有看到新版的 deb 檔案，但拉下來後發現 dependency 需要 libssl3，在 bullseye 上面沒辦法跑。

後來在 Reddit 上翻到有人貼出來的 workaround：「How do I update my TOR relay on a 32-bit armhf bullseye system (Raspberry Pi 3) to the latest version?」，方法是去 Debian 那邊挖 bullseye-backport：「Debian -- Package Download Selection -- tor_0.4.7.13-1~bpo11+1_armhf.deb」。

拉下來以後直接 dpkg -i 幹進去，然後重跑 Tor 看 /var/log/syslog 內容，發現就連上了。

不是最新版 0.4.8.x，但至少能用...？