Tor 的 Onion 導入防禦機制,在遭受 DoS 的時候要求用戶端執行 PoW 任務

在「Introducing Proof-of-Work Defense for Onion Services」這邊看到 0.4.8 的新機制,當 Onion 服務受到 DoS 時,會需要 client 提供 PoW 證明,有證明的會優先處理:

Tor's PoW defense is a dynamic and reactive mechanism, remaining dormant under normal use conditions to ensure a seamless user experience, but when an onion service is under stress, the mechanism will prompt incoming client connections to perform a number of successively more complex operations. The onion service will then prioritize these connections based on the effort level demonstrated by the client.

主要原因是傳統遇到 DoS 時可以透過 IP address 之類的資訊設計阻擋機制,但在 Onion 服務裡面沒有這個資訊,所以需要其他方式阻擋:

The inherent design of onion services, which prioritizes user privacy by obfuscating IP addresses, has made it vulnerable to DoS attacks and traditional IP-based rate limits have been imperfect protections in these scenarios. In need of alternative solutions, we devised a proof-of-work mechanism involving a client puzzle to thwart DoS attacks without compromising user privacy.

這個 PoW 機制的說明可以在「torspec/proposals/327-pow-over-intro.txt」這邊看到,看起來是三年前 (2020/04/02) 就提出來了,直到 0.4.8 才推出。

裡面有提到 PoW 的演算法是用 Equi-X

For our proof-of-work function we will use the Equi-X scheme by tevador [REF_EQUIX].

看起來是個方法,而且從 cryptocurrency 後大家對 PoW 的用法愈來愈熟悉了,在這邊用還不錯...

透過 mDNS 建立內部網路的 fingerprint

Hacker News 上看到透過 mDNS 建立 fingerprint 的方式,進而定位使用者身分:「Brute-forcing a macOS user’s real name from a browser using mDNS (fingerprint.com)」,原文在「Demo: Brute-forcing a macOS user’s real name from a browser using mDNS」。

利用發 HTTP(s) request 出去時,雖然都是傳回 Failed to fetch 錯誤,但因為 hostname 存在時會是 connection timeout,而不存在時會直接因為 DNS 查不到而很快 failed 掉,這個時間差異產生了 side channel,可以透過時間差異知道某個 hostname 是否存在。

這個技巧配合字典就可以大量掃描 *.local 的 mDNS 網段,進而產生出內部網路的 fingerprint。

這個問題應該是有標準解法 (或是有被提案過的解法),就是不讓 internet domain 存取 local domain 的東西,像是避免 internet 上的網站透過 JavaScript 碰到 http://127.0.0.1:xxx/ 的機制。

應該是把 *.local 用同樣方式對待就能避開這個問題?

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 類的安全漏洞,主要是因為 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 還是堪用,儘量拿現成的演算法套,不要自己搞。

Apple 在 iOS 16、iPadOS 16 與 macOS Ventura 上推出 Lockdown Mode

AppleiOS 16、iPadOS 16 與 macOS Ventura 上推出了 Lockdown Mode:「Apple expands industry-leading commitment to protect users from highly targeted mercenary spyware」。

Lockdown Mode 主要是透過降低被攻擊的面積以提昇安全性,依照 Apple 的預想,主要是針對被政府單位盯上的族群:

Apple is previewing a groundbreaking security capability that offers specialized additional protection to users who may be at risk of highly targeted cyberattacks from private companies developing state-sponsored mercenary spyware.

在 Lockdown Mode 下目前列出來的限制:

  • Messages: Most message attachment types other than images are blocked. Some features, like link previews, are disabled.
  • Web browsing: Certain complex web technologies, like just-in-time (JIT) JavaScript compilation, are disabled unless the user excludes a trusted site from Lockdown Mode.
  • Apple services: Incoming invitations and service requests, including FaceTime calls, are blocked if the user has not previously sent the initiator a call or request.
  • Wired connections with a computer or accessory are blocked when iPhone is locked.
  • Configuration profiles cannot be installed, and the device cannot enroll into mobile device management (MDM), while Lockdown Mode is turned on.

列出來的這些的確都是之前 0-day 常被拿來打的東西,把攻擊面積縮小的確會有不少幫助。

這應該是業界第一個大咖跳進來做這個 (也就兩個大咖?),第一次搞未必會完美,但算是個開始,後面應該會有更多的面積被考慮進去...

Log4j2 的 RCE

昨天爆出來 Log4j2 的 RCE,看了一下 pattern,只要是 Java stack 應該都很容易中獎:「Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package」,Hacker News 上對應的討論在「Log4j RCE Found (lunasec.io)」這邊可以看。

LunaSec 宣稱這是 0-day RCE,不過 Log4j2 的修正版本 2.15.0 在 2021/12/06 出了,而 exploit 被丟出來是 2021/12/09,但不確定在這之前是不是已經有 exploit 在 internet 上飛來飛去了...

丟出來的 exploit sample (CVE-2021-44228-Apache-Log4j-Rce) 是用 LDAP 來打,雖然大多數的 Java 版本不受影響,但還是有其他的面可以攻擊,所以整體上還是很容易打穿,該升級的還是得趕快升級:

Updates (3 hours after posting): According to this blog post (see translation), JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load remote code using LDAP.

However, there are other attack vectors targeting this vulnerability which can result in RCE. An attacker could still leverage existing code on the server to execute a payload. An attack targeting the class org.apache.naming.factory.BeanFactory, present on Apache Tomcat servers, is discussed in this blog post.

週末苦命時間...

對 Tor 網路的攻擊

在「Is “KAX17” performing de-anonymization Attacks against Tor Users?」這邊看到針對 Tor 網路攻擊的一些說明...

BTCMITM20 這組比較好理解,目標也比較明確:

primary motivation: financial profit (by replacing bitcoin addresses in tor exit traffic)

KAX17 這組看起來就比較像是政府單位在後面掛:

motivation: unknown; plausible: Sybil attack; collection of tor client and/or onion service IP addresses; deanonymization of tor users and/or onion services

其中可以看到同時掌握了不少 hop,這樣就很有機會一路串起來:

To provide a worst-case snapshot, on 2020–09–08 KAX17's overall tor network visibility would allow them to de-anonymize tor users with the following probabilities:

  • first hop probability (guard) : 10.34%
  • second hop probability (middle): 24.33%
  • last hop probability (exit): 4.6%

由於 Tor 是匿名網路,目前最好的防禦方式還是讓更多人參與加入節點,降低單一團體可以取得足夠組出的資料... 之後找機會整理一下跑了一年多 exit node 的想法好了。

Google 釋出網頁版的 Spectre 攻擊 PoC,包括 Apple M1 在內

在大約三年前 (2018 年年初) 的時候,在讀完 Spectre 之後寫下了一些記錄:「讀書時間:Spectre 的攻擊方式」,結果在 Bruce Schneier 這邊看到消息,Google 前幾天把把 PoC 放出來了:「Exploiting Spectre Over the Internet」,在 Hacker News 上也有討論:「A Spectre proof-of-concept for a Spectre-proof web (googleblog.com)」。

首先是這個攻擊方法在目前的瀏覽器都還有用,而且包括 Apple M1 上都可以跑:

The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. Note that the code will likely require minor modifications to apply to other CPUs or browser versions; however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.

即使目前的瀏覽器都已經把 performance.now() 改為 1ms 的精度,也還是可以達到 60 bytes/sec 的速度:

While experimenting, we also developed other PoCs with different properties. Some examples include:

  • A PoC which can leak 8kB/s of data at a cost of reduced stability using performance.now() as a timer with 5μs precision.
  • A PoC which leaks data at 60B/s using timers with a precision of 1ms or worse.

比較苦的消息是 Google 已經確認在軟體層沒辦法解乾淨,目前在瀏覽器上只能靠各種 isolation 降低風險,像是將不同站台跑在不同的 process 裡面:

In 2019, the team responsible for V8, Chrome’s JavaScript engine, published a blog post and whitepaper concluding that such attacks can’t be reliably mitigated at the software level. Instead, robust solutions to these issues require security boundaries in applications such as web browsers to be aligned with low-level primitives, for example process-based isolation.

Apple M1 也中這件事情讓人比較意外一點,看起來是當初開發的時候沒評估?目前傳言的 M1x 與 M2 不知道會怎樣...

Visa 網站上面的 Opt-Out 功能被拿來玩 Timing Attack...

Hacker News Daily 上看到「Visa Advertising Solutions (VAS) Opt Out (visa.com)」這篇講 Visa 的 Visa Advertising Solutions (VAS) Opt Out,本來以為是在討論企業賣資料的問題 (下面的討論的確是有在討論這個),但最上面的討論居然是在討論 timing attack,像是這篇:

morpheuskafka 2 days ago [–]

Checked and the Mastercard one someone posted below doesn't seem to be vulnerable to this. My real card number and a dummy mastercard number with valid prefix and check digit both returned a 200 OK in around 1.01s. A random 16digit number without valid check digit returned 400 Bad Request in about 800ms. Decided to check that one since they have a completely useless machine-readable catchpa.

For Visa it was 835ms for valid, 762ms for dummy, prefix and check digit appears to be checked client side.

我印象中這類方式已經發展很久了 (透過網路反應時間的 timing attack),討論裡面有提到「Exploiting remote timing attacks」這篇,也是十多年前的資料了... 不過官方網站玩起來總是有中特別爽的感覺 XDDD

不過 Visa 的這個網站前面用了 Cloudflare,用機器人掃感覺很容易被擋,這又是另外一回事了...

在視訊會議裡面,用肩膀的移動猜測輸入的字串

在「Determining What Video Conference Participants Are Typing from Watching Shoulder Movements」這邊看到的方法,利用視訊會議時肩膀的移動猜測輸入的字串,原始的論文在「Zoom on the Keystrokes: Exploiting Video Calls for Keystroke Inference Attacks」這邊可以看到。

就論文有提到的,單就這個資訊的準確度看起來不高,看起來主要是想驗證這也是一個攻擊手法... 但馬上想到視訊會議裡如果有聲音的話,可以透過分析鍵盤的聲音攻擊,這在 2005 年的時候就有類似的手法了,而且準確率很高,不過不知道過了視訊會議軟體後會差多少:「Snooping on Text by Listening to the Keyboard」。

算是個頗特別的方法就是了...