2022-10-25 事後分析

背景について

根本的な原因

Clientについて

manager.addStatelessValidatorHook([config](auto& builder) {
        // the following line should have been present but was not
    builder.add(validators::CreateAggregateTransactionsHashValidator()); 

    builder.add(validators::CreateBasicAggregateCosignaturesValidator(
			config.MaxTransactionsPerAggregate,
			config.MaxCosignaturesPerAggregate));
	if (config.EnableStrictCosignatureCheck)
		builder.add(validators::CreateStrictAggregateCosignaturesValidator());
});

SDKについて

hashes.splice(i / 2, 0, this.hash([hashes[i], hashes[i + 1]]));

想定される攻撃方法

攻撃例：アグリゲートコンプリート

1. AliceがBobに10アルパカを送る
2. AliceがCharlie10アルパカを送る
3. CharlieがAliceに100XYM送る

攻撃例：アグリゲートボンデッド

評価について

グループ1

• 73,615 (19.07%)は正しい Merkleハッシュアルゴリズムとともに、パディングされていないハッシュを使用していました。
• 129,987 (33.68%)は正しいMerkleハッシュアルゴリズムとともに、パディングされたトランザクションハッシュを使用していました。これらはTypeScript SDKで開始された可能性が高いです。Merkleハッシュアルゴリズムのバグの仕様上、2つ以下のアグリゲートを含むアグリゲートは、暗号的に検証可能なハッシュを計算します。

グループ2

• 184,471 (47.80%)は、無効なMerkleハッシュアルゴリズムとともに、パディングされたトランザクションハッシュを使用していました。これらはTypeScript SDKで開始された可能性が高いです。 これらのうち:

  • 102,591はキーリンク取引（単一所有アカウントによる発行)
• 514 (0.13%)は、無効なMerkleハッシュアルゴリズムとともに、パディングされていないトランザクションハッシュを使用していました。これらはJava SDKで開始された可能性が高いです
• 20 (0.005%)は破損しており、上記のいずれかの方法でも計算されていませんでした。さらに分析すると、これらはすべて雑多なスクリプトによって開始されたようです。これらのスクリプトを見直すと、それらのいくつかは、アグリゲートトランザクションハッシュを計算した後に、1つまたは複数の組み込みトランザクションの変更をしていましたが、再計算は行っていませんでした。

まとめ

Catapult

• 正しい Merkle Hash アルゴリズムを持つ、パディングされていないトランザクションハッシュ
• 正しい Merkle Hash アルゴリズムを持つ、 パディングされたトランザクションハッシュ（2つ以下のTS SDK埋め込みトランザクション）
• 無効なMerkle Hashアルゴリズムを持つ、パディングされていないトランザクションハッシュ（2つ以上のJava SDK埋め込みトランザクション）
• 無効なMerkle Hashアルゴリズムを持つ、パディングされたトランザクションハッシュ（2つ以上のTS SDK埋め込みトランザクション）
• ハッシュが新しいcorrupt_aggregate_transaction_hashes ネットワーク構成に一致する項目を持つトランザクション（20件）

SDK

前へ向かって