Tag: security

Internet Archive 被打

Internet Archive 更新一篇文章，說明前幾天被打掛的事情：「Let us serve you, but don’t bring us down」。

有 64 台機器 (或是 64 個 IP) 從 AWS 打了幾萬 rps 進 Internet Archive：

Tens of thousands of requests per second for our public domain OCR files were launched from 64 virtual hosts on amazon’s AWS services. (Even by web standards,10’s of thousands of requests per second is a lot.)

然後擋掉這些 IP 後恢復正常，但過了幾個小時後又換 IP 被打了：

But, another 64 addresses started the same type of activity a couple of hours later.

找了一下之前有寫過「限制流量的方式 (rate limit)」這篇，裡面提到 Figma 怎麼處理，另外以前自己搞 apache module 後面接 memcached 達到跨機器統計的作法。

就 Internet Archive 的服務來說，是應該要搞個類似的東西來擋，不然可以預期會不斷發生？

SHA-256 的 Length extension attack

在 Hacker News 上看到「Breaking SHA256: length extension attacks in practice (kerkour.com)」，在講不當使用 SHA-256 會導致 Length extension attack 類的安全漏洞，主要是因為 MD5、SHA-1 以及 SHA-2 類的 hash function 最後生出 hash 值時會暴露出 hash function 的內部狀態而導致的問題。

這邊講的不當使用是指你沒有使用標準的 MAC，而是自己用字串組合實作造成的問題，通常是 S = H(secret || message) 這樣的形式，這邊的 || 是指字串相接。

拿 MD5 為例子，在維基百科上面可以看到 MD5 演算法對應的 pseudo code，最後輸出的部分可以看到是把 a0、a1、a2、a3 這四個 32-bit variable 接起來，也就是把內部的狀態丟出來了：

// Process the message in successive 512-bit chunks:
for each 512-bit chunk of padded message do
    // ...

    // Add this chunk's hash to result so far:
    a0 := a0 + A
    b0 := b0 + B
    c0 := c0 + C
    d0 := d0 + D
end for

var char digest[16] := a0 append b0 append c0 append d0 // (Output is in little-endian)

於是你在可以反推 padding 的結構之後 (會需要知道 secret 的長度)，就可以往後接東西繼續算下去，這就是被稱作 length extension attack。

本來只有 S = H(secret || message)，你在不知道 secret 的情況下就可以疊字串到後面而且算出對應的 hash 值，變成 S' = H(secret || message || evildata)。

維基百科給的例子也示範了怎麼「用」，這是原始的資料以及 server 端簽出來的 hash 值：

Original Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo
Original Signature: 6d5f807e23db210bc254a28be2d6759a0f5f5d99

於是我們想要蓋 waffle 參數，就變成：

Desired New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo&waffle=liege

攻擊者則可以不斷的嘗試，去猜測 padding 的結構，把計算出來對應的 hash 值丟到 server 看反應，直到看到 200 OK 的回應：

New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x28&waffle=liege
New Signature: 0e41270260895979317fff3898ab85668953aaa2

如同前面提到的，這是 hash function 在最後把內部狀態直接暴露出來造成的問題，在 MD5、SHA-1、SHA-2 (SHA-256、SHA-384、SHA-512) 都有類似的問題，而比較新的 hash function 在設計時就已經有考慮到了，不會出現這個問題，像是 SHA-3。

另外一方面，不要自己發明演算法，使用標準的 MAC 演算法通常是比較好的選擇。這邊用的比較廣泛的應該就是 HMAC，超過 25 年了。

結論是 SHA-256 還是堪用，儘量拿現成的演算法套，不要自己搞。

用 Atom feed 訂閱 crt.sh 的 Certificate Transparency

本來打算自己寫個程式訂閱 Certificate Transparency 的資料，結果發現 crt.sh 本身就有提供 Atom feed。

舉我的例子「crt.sh | gslin.org」來說，對應的 Atom feed 就在 https://crt.sh/atom?q=gslin.org 這邊。

不過 crt.sh 的速度不快，我在使用 Slack 內建的 /feed add 加了很多次才成功，但設定好之後放著收更新就可以了，看起來還算方便。

官方應該是可以把 feed 的筆數壓低，降低對後端 PostgreSQL 的壓力才對，像是只丟最近 30 天的量就好，現在看起來是所有的 entry 都轉成 Atom feed 丟出來...

Tailscale SSH 可以啟動側錄功能

Tailscale 宣布 Tailscale SSH 可以側錄：「Announcing session recording for Tailscale SSH in beta」，這主要是對於 compliance 需求會有幫助，以前有類似需求的話會透過 jump server 類的方式來側錄...

這次提供的是 asciinema 格式，很容易可以 replay：

When a member of your tailnet initiates a connection over Tailscale SSH, our client on the server records all of the terminal output in asciinema format, and streams it to a dedicated recorder node on your tailnet.

開放給所有使用者，包括免費版本：

Session recording for Tailscale SSH is available in beta on our Free and Enterprise plans.

舊的 SSH session logging 則是宣布在八月會停掉：

This feature replaces a legacy version of local SSH session logging that saves recordings directly to the SSH server’s filesystem. We are deprecating that feature, and anyone using it should migrate to the new SSH session recording feature. The legacy functionality will remain active until at least August 1, 2023.

在 Hacker News 的討論「Session recording for Tailscale SSH in beta (tailscale.com)」裡面有一些有趣的東西，像是 sudo 也有提供類似的功能：「Sudoreplay」。

之前有遇過一些商用方案，有提供類似的功能，像是 CyberArk 的「Configure recordings and audits (PSM for SSH)」。

另外 2016 年時 AWS 的人也有寫過「How to Record SSH Sessions Established Through a Bastion Host」。

算是稽核上常見的需求，先前就有不少方法了，Tailscale 提供的工具等於是簡化了一些步驟。

比利時合法化「道德滲透 (ethical hacking)」法案

在 Hacker News 上看到的「Belgium legalises ethical hacking (law.kuleuven.be)」，原文在「Belgium legalises ethical hacking: a threat or an opportunity for cybersecurity?」，比利時政府官方的荷蘭語與法語的 PDF 檔案在這邊可以取得，但裡面包括了其他法案的資訊，這邊是讀英文版的文章...

標題提到的 ethical hacking 不確定有沒有比較好的中文詞彙，先暫定用這個。

先講結論，看完以後可以感覺到是個很糟的法案，應該會本來灰色地帶的 ethical hacking 全部打進黑色或直接全部放 0-day？

要符合比利時法律裡面的 ethical hacking 有四個條件：

The first condition set by the law is that ethical hackers cannot have the intent to cause harm or to obtain illegitimate benefits with their activities. The law therefore excludes that ethical hackers request payment in order to reveal any potential vulnerabilities that they discovered, unless this has been agreed upon in advance, for example as part of a bug bounty programme or a CVDP. Extorsion is not an activity endorsed by the law.

第一條的限制包括了不得取得利益，除非單位已經有提供 bug bounty program 之類的獎勵。

The second condition mandates that ethical hackers report any uncovered cybersecurity vulnerability as soon as possible to the Centre for Cyber Security Belgium (CCB), which is the national computer security incident response team of Belgium. Ethical hackers also need to report their findings to the organisation they were investigating, the latest at the time they are notifying the CCB over a vulnerability.

第二條是強制要回報給政府單位 (CCB)，加上第一條的限制，所以是要免費提供給政府。

The third condition requires ethical hackers to not go further in their hacking than necessary and proportionate in order to uncover a cybersecurity vulnerability. Ethical hackers have to limit themselves to those activities that are strictly necessary for the objective of notifying a cybersecurity vulnerability. This condition is for example breached if a vulnerability is discoverable with less intrusive means than those chosen by the ethical hacker. Ethical hackers are also required to ensure that their activities do not affect the availability of the services of the organisation under investigation.

第三條限制滲透行為只限於證明弱點或是漏洞。

The final condition is an obligation for ethical hackers to not disclose information about the uncovered vulnerability to a broader public without the consent of the CCB. Ethical hackers can therefore not report on uncovered cybersecurity vulnerabilities in the media, for example by noting it in a blog post, unless they have the authorisation of the CCB.

第四點是政府沒有同意以前不得列漏給其他人。

Hashcat 在 3090 與 4090 上的速度差異

想到的時候查了一下，發現進步頗大的...

可以參考「Hashcat v6.1.1 benchmark on the Nvidia RTX 3090」與「Hashcat v6.2.6 benchmark on the Nvidia RTX 4090」這兩份資料。

已經被打到爛的 $1$ 或是 $apr1$ 就不看了，主要還是看比較有抵抗性的 KDF 的速度。

撞老牌的 bcrypt，在 4090 的速度快要是 3090 的兩倍了：

Hashmode: 3200 - bcrypt $2*$, Blowfish (Unix) (Iterations: 32)
Speed.#1.........:    96662 H/s (36.29ms) @ Accel:8 Loops:16 Thr:11 Vec:1
* Hash-Mode 3200 (bcrypt $2*$, Blowfish (Unix)) [Iterations: 32]
Speed.#1.........:   184.0 kH/s (50.22ms) @ Accel:4 Loops:32 Thr:24 Vec:1

但是在看 scrypt 的時候不知道為什麼 3090 跑的 iterations 是 1，這兩個不對等：

Hashmode: 8900 - scrypt (Iterations: 1)
Speed.#1.........:  2308.2 kH/s (8.64ms) @ Accel:16 Loops:1 Thr:16 Vec:1
* Hash-Mode 8900 (scrypt) [Iterations: 16384]
Speed.#1.........:     7126 H/s (29.16ms) @ Accel:128 Loops:1024 Thr:32 Vec:1

改看 9300 這組的話，iterations 還是 1：

Hashmode: 9300 - Cisco-IOS $9$ (scrypt) (Iterations: 1)
Speed.#1.........:    85331 H/s (122.39ms) @ Accel:16 Loops:1 Thr:8 Vec:1
* Hash-Mode 9300 (Cisco-IOS $9$ (scrypt)) [Iterations: 16384]
Speed.#1.........:    83890 H/s (1.76ms) @ Accel:128 Loops:1024 Thr:32 Vec:1

再來是看 PBKDF2 類的，這邊先抓 9200 這組，可以看到 4090 的速度是 3090 的兩倍多：

Hashmode: 9200 - Cisco-IOS $8$ (PBKDF2-SHA256) (Iterations: 19999)
Speed.#1.........:   187.2 kH/s (91.61ms) @ Accel:16 Loops:256 Thr:1024 Vec:1
* Hash-Mode 9200 (Cisco-IOS $8$ (PBKDF2-SHA256)) [Iterations: 19999]
Speed.#1.........:   430.1 kH/s (60.71ms) @ Accel:16 Loops:512 Thr:512 Vec:1

另外 10900 這組也是兩倍多：

Hashmode: 10900 - PBKDF2-HMAC-SHA256 (Iterations: 999)
Speed.#1.........:  3785.4 kH/s (87.58ms) @ Accel:4 Loops:999 Thr:1024 Vec:1
* Hash-Mode 10900 (PBKDF2-HMAC-SHA256) [Iterations: 999]
Speed.#1.........:  8865.7 kH/s (50.50ms) @ Accel:64 Loops:124 Thr:512 Vec:1

考慮到單位價錢的效能，與單位功率的效能，4090 都是大幅領先的情況 (台積電幫了不少？)。

Google Authenticator 的備份功能不是 E2EE (end-to-end encryption)

前幾天提到了 Google Authenticator 總算是支援備份功能了：「Google Authenticator 支援備份到 Google Account 的功能」，當初操作的時候沒看到自訂密碼之類的功能，就有在猜應該不是 E2EE，直接攔傳輸內容也被證實沒有 E2EE 了，TOTP 的 secret token 都是直接傳輸的：「PSA: Google Authenticator's Cloud-Synced 2FA Codes Aren't End-to-End Encrypted」。

Google 的發言人回應 CNET 的詢問時只說會有計畫做，但沒有給更細的資料：

To ensure that we're offering a full set of options for users, we have also begun rolling out optional E2EE in some of our products, and we plan to offer E2EE for Google Authenticator in the future.

在意的人就還是先不要開...

測試 GitHub 與 AWS 可以多快偵測出外洩的 token

前幾天在 Hacker News 上看到「What happens when you leak AWS credentials and how AWS minimizes the damage (xebia.com)」這篇，原文連結在「What happens when you leak AWS credentials and how AWS minimizes the damage」這邊。原文跟 Hacker News 上的寫到東西都頗有趣的，可以分開來講。

先是原文的部份，他抓了一些時間軸：

12:33:12 – Pushed the credentials to GitHub
12:34:19 – The AWSCompromisedKeyQuarantineV2 policy is attached to the IAM user test-user by AWS
12:34:32 – Various List and Describe calls are made using the leaked credentials
12:35:08 – Received an email from AWS with the subject ‘ACTION REQUIRED: Your AWS Access Key is Exposed for AWS Account 12345678’

可以看到推上 GitHub 後，AWS 在一分七秒後就自動加上 AWSCompromisedKeyQuarantineV2 以減少災害擴大，然後再發信件通知。

這個功能可以參考 GitHub 的文件說明：「About secret scanning - GitHub Docs」。

另外在 Hacker News 上面看到有人直接把 secret scanning 當作 API 串來用 (噗)，把在 PyPI 上面掃到的 AWS secret 丟上 GitHub 觸發後續的機制：

I set up a project[1] to automatically leak AWS secrets published to the Python package index, which then triggers the secret scanning process and quarantines the keys[2]

1. https://github.com/pypi-data/pypi-aws-secrets

2. https://github.com/pypi-data/pypi-aws-secrets/blob/main/keys...

OpenSSH 與 Dropbear 對 Ed25519 的支援

查了一下這兩個 server 端的軟體支援 Ed25519 的時間點。

OpenSSH 是在 2014/01/30 的 6.5 就支援了：

* ssh(1), sshd(8): Add support for Ed25519 as a public key type. Ed25519 is a elliptic curve signature scheme that offers better security than ECDSA and DSA and good performance. It may be used for both user and host keys.

算是相當久以前就支援了。對應到第一個支援的 Debian 版本是 Jessie 使用的 OpenSSH 6.7：「sshd(8) — openssh-server — Debian jessie — Debian Manpages」；第一個支援的 Ubuntu (LTS) 版本是 Trusty (14.04) 用的 OpenSSH 6.6：「openssh source package in Trusty」。

Dropbear 這邊就晚不少，在 2020/06/15 的 2020.79 版本才支援：

- Support ed25519 hostkeys and authorized_keys, many thanks to Vladislav Grishenko. This also replaces curve25519 with a TweetNaCl implementation that reduces code size.

所以對應到第一個支援的 Debian 版本是 Bullseye 的 2020.81：「Debian -- Details of package dropbear in bullseye」；第一個支援 Ubuntu (LTS) 的版本是 Jammy (22.04) 的 2020.81：「Ubuntu – Details of package dropbear in jammy」。

這樣看起來如果就是想要用 Ed25519 的話，變成 server 端的軟體得配合：預設裝的 sshd 應該都是 OpenSSH，如果想要換 Dropbear 的話要看 distribution 內給的版本夠不夠新，或是透過 PPA 之類的方法裝新版。

但大多數採用 BusyBox 的機器應該沒有採用新版 Dropbear (像是 AP 刷機)，這邊還是得使用其他 key format，如果要避開 NIST 有介入的格式，就還是得用 ssh-rsa 了。