關於燒毀漏洞的事後檢討

這篇文章要來談一個被稱為燒毀(burning)的漏洞。這篇文章的目標是對上述的漏洞提供完整的細節,解釋這是如何被用來攻擊線上服務、商家與交易所,並且 Monero (開發)社群是如何處理這個漏洞。

這個漏洞基本上來自於錢包在接收到被燒毀的交易時不會發出警告。因此,有心的攻擊者可以利用這點,僅是支付網路交易就能燒毀一個服務機構的錢包內資金。經由此漏洞,攻擊者其實沒有直接的獲益,但是仍然可能有間接的獲益。燒毀的概念上是將數筆交易送至相同的隱匿性地址,而這地址是在先前就已經存在的,這概念的例子可以在先前的討論中看到。不幸的是,這問題被利用來攻擊服務機構的可能性並沒有被察覺,直到 Monero 的一位 reddit 社群成員提出了這個攻擊假設。

目前,Monero的隱匿性地址可以用這樣的公式來表示:

P = Hs(rA||i)*G + B

其中

Hs 是一個雜湊至純量的函式(注意這存量的輸出為 reduced modulo l);
r 是交易私鑰,由發送者隨機產生;
A 是查看公鑰,是收款者的錢包地址字串的其中一部分;
i 是交易輸出索引 (每筆交易輸出都有其索引編號,譬如第一筆交易輸出就是索引0);
G 是標準 Ed25519 的基點;
B 是花費公鑰,是收款者的錢包地址字串的其中一部分;

而 Monero 的金鑰映像可由以下公式表示:

I = xHp(P)

其中

x 是一個私鑰/純量(由收款者的花費私鑰與 ECDH 共享金鑰雜湊純量輸出相加而得);
Hp 是雜湊至點函式;
P 是隱匿性地址;

可以從上面的公式看到,將 Monero 發送至相同的隱匿性地址時將會輸出多個重複的金鑰映像,當區塊鏈網路中出現重複的金鑰映像時,網路將會將之捨棄,因為這相當於重複花費的攻擊。因此每一個隱匿性地址都只能有一個交易輸出被花費一次(錢包會自動挑選面額最大的來使用),而其餘的交易輸出將會無法被花費/被燒毀。此外,發送到同一個隱匿性地址的交易之間關係將可以被連結起來。

閱讀更多關於燒毀漏洞的事後檢討

開發者會議記錄 DevMeeting 20180909

    • 由於與表定分叉更新的時間已非常接近(約於20181018),因此下次的版號將直上V0.13.0.0而非原規劃的v0.12.4.0

    • 最新的PoW已更動為CryptoNightv2,需要一些會C++的開發者幫忙審查

    • Kovri 的程式碼已正式從GitHub移至Gitlab,而主要的Monero 程式碼尚未決定是否要移動

      • 很可能以Gitlab為主而Github作為鏡像備份

      • 也可能Monero就直接用Gitlab的軟體自行架站

      • 防彈協定(BulletProofs)與CryptoNightv2程式碼的合併並於testnet上運行預期會在9月10-11號開始

      • 下次開會時間為2018年9月16號

閱讀更多開發者會議記錄 DevMeeting 20180909

關於重複計數漏洞的事後檢討

這篇文章要來談重複計數(multiple counting)的漏洞,其包括了兩個變種。這篇文章的目標是對上述的漏洞提供完整的細節,解釋這是如何被用來攻擊線上服務、商家與交易所,並且 Monero (開發)社群是如何處理這個漏洞。

重複計數漏洞的兩個變種存在於子地址(subaddress)功能中,這功能用了個不同的交易金鑰程式碼架構。第一個漏洞的變種簡單來說就是沒有對重複的公鑰進行檢查,因此攻擊者可以重複將同份交易公鑰包含在交易中,這結果導致了接收者的錢包會回報收到了x倍於其真正收到的的交易數量(x是代表收到幾次交易金鑰的一個整數),所有用來回報收到交易的指令(如show_transfers (CLI), get_transfers (RPC))都被此漏洞影響。但是餘額並沒有受到影響,錢包依舊會回報正常的資金餘額。可惜的是,大多數的交易所都是利用 get_transfers 或 get_payments RPC指令在運作,因此重複的交易公鑰將會導致計算出錯誤的金額。

閱讀更多關於重複計數漏洞的事後檢討