用 try 來看檔案系統的改變

Hacker News Daily 上看到這則:「Try: run a command and inspect its effects before changing your live system (github.com/binpash)」,這是一個 GitHub 專案:「binpash/try」。

整包軟體意外的簡單,是一隻 shell script,透過 OverlayFS 取得改變的部分:

try lets you run a command and inspect its effects before changing your live system. try uses Linux's namespaces (via unshare) and the overlayfs union filesystem.

記得 OverlayFS 在 Docker 用的很多,所以穩定性應該是沒什麼問題,不過專案開頭也有提到,這只是把 filesystem 層拆出來,不是很嚴謹的 sandbox 環境,像是 /dev 這邊的東西還是有穿透性,不要跑不信任的程式:

Please note that try is a prototype and not a full sandbox, and should not be used to execute commands that you don't already trust on your system, (i.e. devices in /dev are mounted in the sandbox, and network calls are all allowed.) Please do not attempt any commands that will remove everything in /dev or write zeros to your disks.

我覺得這個很適合拿來跑各種 install.sh 這種東西?有些 install.sh 不知道塞了多少垃圾 (像是 .bashrc 或是 .profile 都有可能會被動),可以知道有哪些檔案要清會比較好。

把裡面的 try 這個檔案丟到自己的可執行目錄就裝好了,像是 ~/.local/bin 或是 ~/bin 之類的地方,看你的 $PATH 設定決定。

另外也可以從 subcommands 裡面的指令看到你可以用 try explore 啟動 shell 跑進去看:

Subcommands:
  try summary DIR   show the summary for the overlay in DIR
  try commit DIR    commit the overlay in DIR
  try explore DIR   start a shell inside the overlay in DIR

GitHub 上面的範例是用 pip 示範,同樣道理應該也可以看 npm 與其他套件。

SHA-256 的 Length extension attack

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

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

拿 MD5 為例子,在維基百科上面可以看到 MD5 演算法對應的 pseudo code,最後輸出的部分可以看到是把 a0a1a2a3 這四個 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.

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

Tailscale 放鬆免費版的使用限制,以及商業版的計算方式

昨天在 Hacker News 上注意到的:「Changes to Tailscale Pricing and Plans (tailscale.com)」,Tailscale 宣佈了新的免費與收費方式 (直接叫做 Pricing v3):「Pricing v3, plans, packages, and debugging」。

這次有許多改變,首先是免費版本來只能一個使用者使用,現在變成三個使用者可以在同一個 tailnet 裡面,這對於超級早期的 startup 方便不少,另外家庭用戶也可以受益。

另外一個是擴大「免費」的定義,本來的「免費」只有在完全免費的方案裡面用,一個人是免費,但五個人會收五個人的費用;現在變成「既然在 Pricing v3 我說三個人以下免費,那五個人的方案裡面還是有三個免費的名額,我就只收額外的兩個人的費用」,而且只有 active user 才會收:

That is, if you have a 5-person team at work, the first three are still free. You’d pay for only the 2 additional users (and only if they’re active, more on that below).

然後是拔掉限制 (包括「No more limits on subnet routers」與「No more limits on admin accounts」),以及放鬆限制 (包括「More free nodes, and twice as many nodes per user」)。

所以看起來 Tailscale 現在的策略是成長,趁這波調價時做了一波 PR...

測試 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...