最近、Oasisのマルチシグを使用してMakerDao Vaultから資金を移動させる「カウンターエクスプロイト（対抗エクスプロイト）」に多くの注目が集まっています。その中で、2月18日にPlatypusの240万ドルの救済を支援したカウンターエクスプロイトに我々が関与していたことから、この件の背後にいる「ホワイトハット」がBlockSecではないかという問い合わせをいくつかいただいております。BlockSecは、今回のJumpの件におけるいかなるアクションにも関与していないことを明確にしたく存じます。 詳細な分析（BlockWorksでDan Smith氏が公開した優れた分析に敬意を表します）の結果、Jumpの「カウンターエクスプロイト」に関わる手法は、Platypusの事例とは根本的に異なると考えています。
また、Oasisの声明によると、このカウンターエクスプロイトは管理用マルチシグアクセスにおける脆弱性が原因で可能になったとのことです
しかし、我々の分析によると、このカウンターエクスプロイトの主要ステップは以下の通りです：
- 遅延実行（delayed execution）を無効にする。これは、OasisマルチシグウォレットであるService Registryコントラクトのオーナーによって行われるよう設計されています。
- AutomationBotコントラクト用のAUTOMATION_EXECUTORや、CloseCommandコントラクト用のMCD_VIEWおよびMULTIPLY_PROXY_ACTIONSなど、重要な役割を担うコントラクトアドレスを変更する。これにより、OasisマルチシグウォレットはAutomationBotを直接呼び出し、クローズコマンドを実行できるようになります。そこで実際に実行される操作は、攻撃者のVaultを移動させるために新しいものへと置き換えられています。
我々の分析では、これらの主要なステップは、主張されている「管理用マルチシグアクセスの脆弱性」によるものではないことが示唆されています。
免責事項：本ブログは、オンチェーンのトランザクションおよび公開情報に基づいて記述されています。ご質問やご意見がございましたら、[email protected] までお気軽にお問い合わせください。
全体的なプロセス
この操作には複数のアドレスが関与していました。その一部を以下のGoogleドキュメントにリストしています。
https://docs.google.com/spreadsheets/d/1k0PEci8wQ16X7JT7KRq9SvhaCA2yerJcqLn6EfAoPZs/edit?usp=sharing
具体的に、Jumpカウンターエクスプロイトの全体的な構想は以下の通りです。
-
攻撃者のMaker Vaultは、攻撃者がOasisの提供する自動売買サービスを有効にしているため、Oasis AutomationBotスマートコントラクトによって管理が可能でした。
-
AutomationBotは、AUTOMATION_EXECUTORというロールを持つアドレスのみが操作できます。このアドレスはOasis Service Registryコントラクトで設定されており、Oasisマルチシグウォレットによって更新可能です。ただし、Oasis Service Registryコントラクトの設定更新には遅延実行メカニズムがあり、これはOasisマルチシグウォレットによって無効化できます。
-
AutomationBotによって実行される実際のコントラクトや関数も、Oasis Service Registryで設定変更可能です。
そのため、OasisマルチシグウォレットはまずOasis Service Registryコントラクトの遅延実行を無効化し、同コントラクトの設定を変更してAUTOMATION_EXECUTORロールを自身（マルチシグウォレット）に設定します。この変更は直ちに有効となります。その後、マルチシグウォレットがAutomationBotを呼び出し、攻撃者のMaker Vaultを乗っ取る（移動および譲渡する）コマンドを実行します。AutomationBotは攻撃者のVaultを管理できるため、一連の操作が成功します。
このプロセスは、攻撃者のコントラクトに脆弱性を見つけてPlatypusと共有したPlatypusの事例とは根本的に異なると考えます。当時、Platypusは攻撃者のコントラクトをエクスプロイトし、本来の所有者である自身の資金を移動させました。しかし、Jumpのケースでは、Oasisのマルチシグが遅延実行メカニズムを無効化し、コントラクトの動作を完全に入れ替える重要な設定を更新した上で、AutomationBotの管理ロールを悪用して攻撃者に代わってMakerのVaultを操作したという点において異なります。
以下に、Jumpの「カウンターエクスプロイト」の全容を詳しく説明します。
詳細なステップ
この操作には、Jump、Oasis、Wormholeの攻撃者、およびMakerを含む複数のプロトコルと当事者が関与しています。なお、操作中、Makerサイドは何のアクションもとっていません。
具体的には、攻撃者がMaker Vault（30100および30179）を作成し、ETHを担保としてDAIを借り入れています。攻撃者はMaker Vaultの担保比率を管理するために、Oasisが提供する自動売買サービスを利用していました。
Oasisの自動化サービスを利用するには、Oasisが提供するAutomationBotというスマートコントラクトをVaultの管理リストに追加する必要があります。これはつまり、AutomationBotが攻撃者の作成したMaker Vaultを制御下に置くことを意味します。その後、AutomationBotはVaultを操作し、Vaultの担保と負債を別のVault（Jumpが管理するもの）に移 transferencia することができます。これが「カウンターエクスプロイト」の基本的なプロセスです。なお、AutomationBotを呼び出すには、ServiceRegistryコントラクトにAUTOMATION_EXECUTORとして登録されているアドレスからトランザクションを呼び出す必要があります。
ステップ 1: アドレス 04e1 をOasisのマルチシグウォレットに追加
このトランザクションにより、アドレス 04e1 がOasisのマルチシグウォレットに追加されました。このウォレットは現在12のアドレスで構成されており、4人の署名者の承認が必要です。
ステップ 2: Oasis Service Registryの遅延実行を無効化
このトランザクションは、changeRequiredDela(0) を呼び出すことで、Oasis Service Registry の遅延実行を無効にしています。Oasis Service Registryは、AutomationBotで使用される重要な設定情報を保持するスマートコントラクトです。通常、重要な操作（「カウンターエクスプロイト」で使用される updateNamedService など）の設定変更には、遅延実行メカニズムが備わっています。通常、遅延実行は透明性を保つためのセキュリティメカニズムであり、重要な情報の更新が即座に反映されず、他者が再確認できる時間を設けるためのものです。
なお、changeRequiredDelay を呼び出すための実行自体も、まだ遅延実行によって制限されています（reqDelay への変更がまだ有効になっていないため）。
ステップ 3: カウンターエクスプロイトの実行
このトランザクションがカウンターエクスプロイトを実行します。BlockSecが開発したトランザクション解析ツール Phalcon の実行トレース出力を見てみましょう。
なお、このトランザクションは 04e1 アドレスから開始され、Oasisマルチシグウォレットを通じて実行されています。つまり、少なくとも4人の署名者によって署名が行われています。
ステップ 3.1 遅延実行の無効化
トレースに示されているように、遅延は再びゼロに設定されています。これは、ステップ2で行った遅延実行無効化のアクションを適用するためです。
ステップ 3.2: 2つのコントラクトを作成し、Service Registryを更新
MCD_VIEW および MULTIPLY_PROXY_ACTIONS コントラクトとして使用される2つの新しいコントラクトが作成されます。
- MCD_VIEW: 0xceca8d8410797bc6c575fd8ba957708d1e85ed36
- MULTIPLY_PROXY_ACTIONS: 0xcaef24016d0fba2c1a9427371e0d79c5781b6ea8
その後、これら2つのコントラクトがOasis Service Registryコントラクトに更新されます。
ステップ 3.3: Automation Executorの変更
OasisマルチシグがServiceRegistryコントラクトにおいて AUTOMATION_EXECUTOR として登録されました。これが必要である理由は、このロールを登録されたコントラクトのみがAutomationBotコントラクトを呼び出せるからです。
ステップ 3.4: AutomationBotに攻撃者のVaultをクローズするように指示
重要なプロセスは、AutomationBotの execute 関数から始まります。実行される関数の詳細は引数を通じて渡されます。
プロセス全体を理解するために、まずこの関数を見てみましょう。
大まかなロジックは、ボットがまずVaultからDAIを引き出し（268行目）、次に具現化されたコマンドコントラクトを呼び出してVault上で（cdpIdで指定された）実行を行う（274行目から278行目）というものです。この過程で、コマンドアドレスは CloseCommand コントラクトになります。その後、isExecutionCorrect のチェックが必要となります。
以下は、CloseCommand コントラクトの execute 関数です。これは、キー MULTIPLY_PROXY_ACTIONS を使用して、Service Registryコントラクトから実際のエクゼキューターコントラクトアドレスを取得します。なお、MULTIPLY_PROXY_ACTIONS に対応するコントラクトアドレスは新しいものに更新されています。そのため、CloseCommand の実際の実行は、新しいコントラクト内で任意の操作を実行するように制御可能です。
繰り返しになりますが、isExecutionCorrect は CloseCommand 上で呼び出され、実行が成功したかどうかをチェックします（AutomationBot.sol の278行目）。Viewアドレスが更新されているため、viewerContract.getVaultInfo(cdpId) の戻り値は、CloseCommand.sol の24行目のチェックを通過できる任意の値を返す可能性があります。
コードを一通り確認したところで、実行トレースを見てみましょう。トレースから、automationBot が CloseCommand コントラクトを呼び出していることがわかります。CloseCommand コントラクトは置き換えられた MULTIPLY_PROXY_ACTIONS コントラクトを呼び出し、新しいVault（30231）を開き、Vault 30100（攻撃者のもの）を 30231（新しく作成されたもの）に移動させ、新しいVault 30231 をOasisマルチシグウォレットに譲渡することができます。同様の操作が攻撃者のもう一方のVault（30179）にも行われます。
ステップ 3.5 状態の復元
Service Registry内の変更されたエントリを復元し、遅延実行を再度有効にします。
ステップ 3.6 Vaultをアドレス 1536 に譲渡
これで、新しいVault（30231および30232）はOasisマルチシグウォレットによって制御されるようになりました。その後、これらのVaultは [TX1 TX2] のトランザクションにおいて 0x15364305a06ba3ac6ba13dfe97ca0bad639adf41 に譲渡されます。このアドレスはVault内の債務を返済し、担保（イーサリアム）を引き出すことができます。担保比率が高いため（Vault 30100で約293%）、返済と引き出しを行うことで、Vault 30100からの約7600万の債務返済コストを負担しつつ、約12万イーサリアムを取り戻すことができます。これらの操作の詳細については、Makerプロトコルのドキュメントを参照してください。
BlockSecについて
BlockSecは、世界的に著名なセキュリティ専門家グループによって2021年に設立された、先駆的なブロックチェーンセキュリティ企業です。当社は、Web3の普及を促進するために、Web3の世界におけるセキュリティ向上とユーザビリティの確保に尽力しています。そのために、スマートコントラクトおよび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
