THE DAOに対する攻撃手法を技術的な観点から分析する

この記事の内容はオリジナルではなく、以下の 2 つのブログ投稿の翻訳と解釈に基づいています。

ブログ 1: http://vessenes.com/more-ethereum-attacks-race-to-empty-is-the-real-deal/
ブログ 2: http://vessenes.com/deconstructing-thedao-attack-a-brief-code-tour/

1. 攻撃手法の解読

攻撃者は childDAO を作成し、そこに継続的に Ether を転送しているため、これが現在 Ether を抽出する唯一の実行可能なメカニズムであり、焦点は splitDAO 関数から始まります。

splitDAO は、childDAO (存在しない場合) を作成し、スプリッターが所有する Ether を childDAO に転送し、生成された報酬 (現在は 0 である必要があります) を支払ってから戻ります。

ホワイトペーパーの設計によれば、splitDAO は、投票において不利な立場にある少数派を保護し、投票を通じて多数派から合法的に搾取されることを防ぐことを目的としています。より小規模な DAO を分割することで、分割前に行われた外部資金からの潜在的な利益を確実に獲得しながら、自らの足で投票するメカニズムが与えられます。

しかし、地獄への道は花で舗装されている。

BLOG 2 によると、DAO.sol の splitDAO 関数には次の行があります。

コントラクトでは、msg.sender に記録された DAO 通貨の残高がゼロにリセットされ、DAO 通貨の合計金額 totalSupply が差し引かれるなど、これらはすべて msg.sender に送り返された後に発生します。これは、ブログ 1 のブロガーが指摘した典型的な「アンチパターン」です。

次に、withdrawRewardFor 関数を見てみましょう。現在 GitHub で確認できる最新のコードは、Ethereum ライブネットにデプロイされたコードではありません。ブロガーによると、問題のあるコードは以下のとおりです。

paidOut[_account] += reward は元のコードでは payOut 関数呼び出しの後に配置されていましたが、最新の github コードでは payOut の前に移動されました。
payOut 関数の呼び出しをもう一度見てみましょう。 rewardAccount のタイプは ManagedAccount であり、ManagedAccount.sol で確認できます。

深さでマークされた行に注意してください。_recipient に _amount Wei を転送するための呼び出しが行われます。デフォルトでは、呼び出しにより残りのガスがすべて使用されます。呼び出しによって実行されるコード ステップの数は大きくなる可能性があり、基本的には攻撃者が送信したメッセージの利用可能なガスによってのみ制限されます。
これらをまとめると、ハッカーの攻撃方法が浮かび上がります。
1) 準備

ハッカーは、匿名のフォールバック機能を備えた独自のハッカー契約 HC を作成します。 Solidity 仕様によれば、HC が Ether (データなし) を受信すると、フォールバック機能が自動的に実行されます。このフォールバック関数は、再帰を通じて THE DAO の splitDAO 関数への複数の呼び出しをトリガーします (ただし、ガス不足を避けるためにあまり多くは行いません)。プロセスは、スタックの使用を制御するために、現在の呼び出しの深さも記録する必要があります。

2) 攻撃を開始<br/>ハッカーは THE DAO に分割提案を複数回提出し、各提案の受信者アドレスを HC アドレスに設定し、適切な gasLimit を設定しました。呼び出しスタックは次のようになります。

分割提案を提出する
—> splitDAO関数（その1）
—> withdrawRewardFor 関数 (その 1、この時点ではハッカーの DAO 残高と DAO 合計額は変更されていません!)
—> papOut関数（その1、初めてHCにイーサを送信）
—> HCフォールバック機能（その1）
—->再帰が設定された深さに達しない場合: 分割DAO関数を呼び出す（その2）
—> withdrawRewardFor 関数 (その 2、ハッカー DAO の残高は変わりません!)
—> payOut関数（その2、2回目にHCにイーサを送信する）
—> HCフォールバック機能（その2）
—> (再帰を続ける)

3) 送金して退出する<br/>childDAOに送金されたお金は、当初の契約に従って一定期間後に引き出すことができます。ハッカーが利益を得る時期が来た。

2. 予防と思考

コードから判断すると、この攻撃が成功した要因は 2 つあります。1 つは、DAO 残高の減額と Ether 転送の 2 つの手順の順序が間違っていること、もう 1 つは、未知のコードが制限なく実行されたことです。

アプリケーションコードシーケンスの観点から、DAO 残高チェックは Ether 転送の前提条件であり、DAO 残高ステータスは最新のステータスをタイムリーに反映できる必要があるため、Ether 転送前に DAO 残高を差し引く必要があります。問題のあるコード実装では、最も深い再帰が戻ってハッカーの DAO 残高を正常に差し引くものの、その上の再帰呼び出しでの残高チェックがすべて正常に終了しており、最新の残高を判別する機会がないため、この時点ではハッカーの DAO 残高の差し引きは無意味です。

未知のコードの無制限実行に関しては、現在ハッカーはSolidityが提供する匿名フォールバック機能を使用していますが、コントラクト間のメッセージの受け渡しはオブジェクト指向プログラム開発におけるメソッド呼び出しと完全に類似しており、コールバックを待機するためのインターフェースを提供することはデザインパターンにおける一般的な手法であるため、未知の通常の関数を実行することは完全に可能であるため、この未知のコード実行は原理的にはより多くのシナリオで発生する可能性があります。

同様のハッキング事件はイーサリアムに限らず、将来的にはRootstockなどのプラットフォームでも再び発生する可能性があります。これは、脆弱性がアプリケーション レベルにあり、Ethereum 自体の問題ではないためであり、この攻撃はチューリング完全でないプラットフォームでも機能するため、「チューリング完全性」に起因するものでもないためです。一般的に、アプリケーションが複雑になるほど、アプリケーション内でセキュリティの問題が発生する可能性が高くなります。

このハッキング事件は、私たちに多くのことを考えさせます。TRUST MACHINE 上の未知のコードを信頼すべきでしょうか?分散型システムには、「一時停止」に備えて設計の初期段階で緊急介入コードを含める必要がありますか?問題が発生した場合に世論の統制や情報開示を行うための緊急時対応計画は用意しておくべきでしょうか?プロジェクトは、公開前にコミュニティによるより長いレビューとテストを受ける必要がありますか?

このハッキング事件は、イーサリアム、分散化、ブロックチェーンの終焉を意味するものではありません。この教訓は深いものですが、もし学ぶことができれば、THE DAO と Ethereum だけでなく、ブロックチェーン コミュニティ全体にも利益をもたらすでしょう。