BlockSecの「カウンターエクスプロイト」ジャンプに関する見解:脆弱性は本当に存在するのか?

BlockSecの「カウンターエクスプロイト」ジャンプに関する見解:脆弱性は本当に存在するのか?

最近、OasisマルチシグによるOasisマルチシグを使用したMakerDao Vaultからの資金移動に対する「カウンターエクスプロイト」 に多くの注目が集まっています。その一方で、2月18日にPlatypusを支援するためのカウンターエクスプロイトで2.4Mを救済した ことから、BlockSecがこの操作の背後にある「ホワイトハット」ではないかという問い合わせをいくつか受けています。BlockSecはJumpのケースにおけるいかなる行動にも関与していないことを明確にしたいと考えています。 詳細な分析(Dan SmithによるBlockWorksでの優れた分析に感謝します)の後、Jumpの「カウンターエクスプロイト」への関与方法は、Platypusのケースとは根本的に異なると考えています。

さらに、Oasisの声明によると、カウンターエクスプロイトは管理マルチシグアクセスにおける脆弱性により可能になったものです

Oasisの声明からのスクリーンショット
Oasisの声明からのスクリーンショット

しかし、私たちの分析によると、カウンターエクスプロイトの主要なステップは以下の通りです:

  • 遅延実行を無効にする。これはService RegistryコントラクトのオーナーであるOasis Multisigウォレットによって実行されるように設計されています。
  • AutomationBotコントラクトのAUTOMATION_EXECUTOR、およびCloseCommandコントラクトのMCD_VIEW、MULTIPLY_PROXY_ACTIONSを含む、重要なロールの登録済みコントラクトアドレスを変更する。これにより、Oasis MultisigウォレットはAutomationBotを直接呼び出し、クローズコマンドを実行できるようになります。その実際の実行操作は、ExploiterのVaultをシフトするために新しいものに置き換えられます。

私たちの分析は、これらの主要なステップが、主張されている管理マルチシグアクセスにおける脆弱性によるものではないことを示唆しています。

免責事項:このブログは、オンチェーントランザクションと公開情報に基づいて作成されています。ご質問やコメントがありましたら、[email protected]までお気軽にお問い合わせください。

全体プロセス

この操作には複数のアドレスが関与しました。それらの一部を以下のGoogleドキュメントにリストアップします。

https://docs.google.com/spreadsheets/d/1k0PEci8wQ16X7JT7KRq9SvhaCA2yerJcqLn6EfAoPZs/edit?usp=sharing

具体的には、Jumpのカウンターエクスプロイトのハイレベルなアイデアは次のとおりです。

  1. ExploiterはOasisが提供する自動売買サービスを有効にしているため、ExploiterのMaker VaultはOasis AutomationBotスマートコントラクトによって管理されます。
  2. AutomationBotは、Oasis Service Registryコントラクトの設定で、AUTOMATION_EXECUTORというロールを持つアドレスによってのみ操作できます。このアドレスはOasis Multisigウォレットによって更新できます。しかし、Oasis Service Registryコントラクトの設定の更新には遅延実行メカニズムがあり、これはOasis Multisigウォレットによって無効にすることができます。
  3. AutomationBotによって実行される実際のコントラクトと関数も、Oasis Service Registryで設定可能です。

したがって、Oasis MultisigウォレットはまずOasis Service Registryコントラクトの遅延実行を無効にし、Oasis Service Registryコントラクトの設定を変更してAUTOMATION_EXECUTORロールを自分自身(マルチシグウォレット)に設定します。この変更は即座に有効になります。次に、マルチシグウォレットはAutomationBotを呼び出し、ExploiterのMaker Vaultを乗っ取る(シフトおよび譲渡する)コマンドを実行します。AutomationBotはExploiterのVaultを管理できるため、操作全体は成功します。

このプロセスは、私たちが攻撃者のコントラクトに脆弱性を見つけ、Platypusと共有したPlatypusのケースとは根本的に異なると考えています。その後、Platypusは攻撃者のコントラクトを悪用して、自分たちの資金を移動させました。しかし、Jumpのケースでは、Oasisマルチシグは遅延実行メカニズムを無効にし、コントラクトの動作を完全に変更できる重要な設定を更新し、AutomationBotの管理ロールを利用してExploiterの代わりにMaker Vaultを操作しています。

以下では、Jumpの「カウンターエクスプロイト」の全体像について詳しく説明します。

詳細なステップ

この操作には、Jump、Oasis、Wormhole Exploiter、Makerなど、複数のプロトコルと関係者が関与しています。なお、Makerはこの操作中にいかなる行動も取っていません。

具体的には、ExploiterはMaker Vault (30100 および 30179) を作成し、ETHを担保として使用し、VaultからDAIを借入します。Exploiterはまた、Maker Vaultの担保率を管理するためにOasisが提供する自動売買サービスを利用しました。

Oasisの自動化サービスを利用するために、Oasisが提供するAutomationBotというスマートコントラクトを、Vaultの管理リストに追加する必要があります。これは、AutomationBotがExploiterによって作成されたMaker Vaultを制御できることを意味します。その後、AutomationBotはVaultを操作し、Vaultの担保と負債をJumpが制御する別のVaultに移動させることができます。これが「カウンターエクスプロイト」の基本的なプロセスです。なお、AutomationBotを呼び出すには、ServiceRegistryコントラクトでAUTOMATION_EXECUTORとして登録されているアドレスからトランザクションを呼び出す必要があります。

ステップ1:アドレス04e1をOasisマルチシグウォレットに追加

このトランザクションは、アドレス04e1をOasisマルチシグウォレットに追加します。このウォレットは現在12のアドレスを持ち、4つの署名者の確認が必要です。

Image of Oasis multisig wallet address addition
Image of Oasis multisig wallet address addition

ステップ2:Oasis Service Registryの遅延実行を無効にする

このトランザクションは、changeRequiredDela(0)を呼び出すことにより、Oasis Service Registryの遅延実行を無効にします。なお、Oasis Service Registryは、AutomationBotによって使用される重要な設定情報が格納されているスマートコントラクトです。「カウンターエクスプロイト」で使用されるupdateNamedServiceなどの重要な操作には、通常、遅延実行メカニズムがあります。通常、遅延実行は透明性のためのセキュリティメカニズムであり、重要な情報の更新が即座に有効にならないようにし、他の人が再確認できるようにします。

なお、changeRequiredDelayを呼び出す実行は、(reqDelayへの変更がまだ有効になっていないため)遅延実行によって制限されています。

ServiceRegistry.sol code snippet 1
ServiceRegistry.sol code snippet 1
ServiceRegistry.sol code snippet 2
ServiceRegistry.sol code snippet 2

ステップ3:カウンターエクスプロイトを実行する

このトランザクションは、カウンターエクスプロイトを実行します。BlockSecが開発したトランザクション分析ツールであるPhalconによって出力された実行トレースを見てみましょう。

なお、このトランザクションは04e1アドレスから初期化され、Oasisマルチシグウォレットを通じて実行されるため、操作は少なくとも4つの署名者によって署名されています。

ステップ3.1 遅延実行を無効にする

トレースに示すように、遅延は再度ゼロに設定されます。これは、ステップ2の遅延実行無効化アクションを適用するためです。

Execution trace showing delay set to zero
Execution trace showing delay set to zero

ステップ3.2:2つのコントラクトを作成し、サービスレジストリを更新する

MCD_VIEWおよびMULTIPLY_PROXY_ACTIONSコントラクトとして使用される2つの新しいコントラクトが作成されます。

  • MCD_VIEW: 0xceca8d8410797bc6c575fd8ba957708d1e85ed36
  • MULTIPLY_PROXY_ACTIONS: 0xcaef24016d0fba2c1a9427371e0d79c5781b6ea8

次に、これらの2つのコントラクトがOasisサービスレジストリコントラクトに更新されます。

Execution trace showing contract creation and registry update
Execution trace showing contract creation and registry update

ステップ3.3:Automation Executorを変更する

Execution trace showing Automation Executor change
Execution trace showing Automation Executor change

Oasisマルチシグは、ServiceRegistryコントラクトにAUTOMATION_EXECUTORとして登録されます。これは、このロールを持つ登録済みコントラクトのみがAutomationBotコントラクトを呼び出すことができるため、必要です。

AutomationBot.sol code snippet 1
AutomationBot.sol code snippet 1
AutomationBot.sol code snippet 2
AutomationBot.sol code snippet 2

ステップ3.4:ExploiterのVaultをクローズするようにAutomationBotに依頼する

重要なプロセスは、AutomationBotのexecute関数から始まります。詳細な実行関数は引数として渡されます。

プロセス全体を理解するために、まずこの関数を見てみましょう。

AutomationBot.sol code snippet 3
AutomationBot.sol code snippet 3

ハイレベルなロジックは、ボットがまずVaultからDAIを引き出し(268行目)、次にVault(cdpIdで指定)に対して実行される具体的なコマンドコントラクトを呼び出す(274行目から278行目)というものです。このプロセス中、コマンドアドレスはCloseCommandコントラクトです。その後、isExecutionCorrectのチェックが必要です。

以下はCloseCommandコントラクトのexecute関数の説明です。Service Registryコントラクトから、KEY MULTIPLY_PROXY_ACTIONSを使用して実際のexecutorコントラクトアドレスを取得します。MULTIPLY_PROXY_ACTIONSに対応するコントラクトアドレスは新しいものに更新されていることに注意してください。したがって、CloseCommandの実際の実行は、新しいコントラクトで任意の操作を実行できるように制御可能です。

CloseCommand.sol code snippet 1
CloseCommand.sol code snippet 1
CloseCommand.sol code snippet 2
CloseCommand.sol code snippet 2

isExecutionCorrectがCloseCommandで呼び出され、実行が成功したかどうかを確認すること(AutomationBot.solの278行目)を思い出してください。viewアドレスが更新されているため、check viewerContract.getVaultInfo(cdpId) の戻り値は、24行目(CloseCommand.sol)のチェックを通過できる任意の値を返す可能性があります。

コードを全体的に確認した後、実行トレースを見てみましょう。トレースから、automationBotがCloseCommandコントラクトを呼び出していることがわかります。CloseCommandコントラクトは、置き換えられたMULTIPLY_PROXY_ACTIONSコントラクトを呼び出して新しいVault(30231)を開き、Vault 30100(Exploiterのもの)を30231(新しく作成されたもの)にシフトし、新しいVault 30231をOasis Multisig Walletに譲渡します。Exploiterのもう一方のVault(30179)にも同様の操作が行われます。

Execution trace showing vault shifting and transfer
Execution trace showing vault shifting and transfer

ステップ3.5 状態を復元する

Execution trace showing state restoration
Execution trace showing state restoration

Service Registryの変更されたエントリを復元し、遅延実行を再度有効にします。

ステップ3.6 Vaultをアドレス1536に譲渡する

これで、新しいVault(30231および30232)はOasis Multisig Walletによって制御されます。次に、これらのVaultはこれらのトランザクション [TX1 TX2]で0x15364305a06ba3ac6ba13dfe97ca0bad639adf41に譲渡されます。その後、このアドレスはVaultの借入金を返済し、担保(Ethereum)を引き出すことができます。担保率は高い(Vault 30100で約293%)ため、担保を返済して引き出すことで、Vault 30100の約76Mの借入金を返済するコストで、約120KのEthereumを取り戻すことができます。これらの操作に関する詳細については、Makerプロトコルのドキュメントを参照してください。

Execution trace showing collateral withdrawal
Execution trace showing collateral withdrawal

BlockSecについて

BlockSecは、世界的に著名なセキュリティ専門家グループによって2021年に設立された、先進的なブロックチェーンセキュリティ企業です。当社は、Web3の世界のセキュリティと使いやすさを向上させ、その大規模な採用を促進することに尽力しています。この目的を達成するために、BlockSecはスマートコントラクトおよびEVMチェーンのセキュリティ監査サービス、セキュリティ開発および脅威のプロアクティブなブロックのためのPhalconプラットフォーム、資金追跡および調査のためのMetaSleuthプラットフォーム、そしてWeb3ビルダーが仮想通貨の世界を効率的にサーフィンするためのMetaSuites拡張機能を提供しています。

これまでに、MetaMask、Uniswap Foundation、Compound、Forta、PancakeSwapなど300社以上の著名なクライアントにサービスを提供し、Matrix Partners、Vitalbridge Capital、Fenbushi Capitalなどの有力な投資家から2回の資金調達で数千万米ドルを獲得しています。

公式ウェブサイト:https://blocksec.com/ 公式Twitterアカウント:https://twitter.com/BlockSecTeam

Sign up for the latest updates