DAOの脆弱性の分析

皆さんは、再帰的な Ethereum 送信エクスプロイトを使用したハッカーによる DAO からの 1 億 5000 万ドルの盗難に関するニュースを聞いたことがあると思います。

この投稿は、これが何であるかを調査する一連の記事の最初のもので、ブロックチェーンを通じて追跡された攻撃者の行動のタイムラインを提供し、技術的なレベルで何が間違っていたかを解体して説明します。最初の投稿では、攻撃者がどのようにして The DAO からすべての資金を盗んだのかに焦点を当てます。

多段階攻撃

DAO の脆弱性を悪用することは明らかに簡単ではありませんでした。特定のプログラミングパターンにより、DAO の弱点は明らかになっただけでなく、DAO の作成者によってフレームワークのコードに対する初期の計画された更新で修正されました。皮肉なことに、彼らがブログ記事を書いて勝利を祝っている間に、ハッカーたちは彼らが修正したばかりの同じ機能を狙った脆弱性を準備して悪用し、DAO の資金をすべて浪費していました。

攻撃を全体的に見てみましょう。攻撃者は DAO.sol を分析し、「splitDAO」関数が上記のパターンを再帰的に送信できる脆弱性があることに気付きました。この関数は最終的にユーザーの残高と合計を更新するため、splitDAO を呼び出す前にこの関数を呼び出すことができれば、必要な金額を再帰的に転送できます (コードコメントは XXXX でマークされています。表示するには下にスクロールする必要があります)。

基本的な考え方は次のとおりです。分割を提案します。分割して実行します。 DAO が応答を元に戻す直前に、この関数を呼び出して、元に戻す処理が完了する前に分割を実行します。この関数は残高を更新せずに実行され、上で「攻撃者が複数回実行したい」とマークしたコマンドラインは複数回実行されます。それは何をするのでしょうか?ソースコードは TokenCreation.sol にあり、親 DAO から子 DAO にトークンを転送します。基本的に、攻撃者はこれを利用して、本来よりも多くのトークンを子 DAO に転送させました。

DAO は転送するトークンの数をどのように決定したのでしょうか?もちろんバランスのとれた配列を使用します。

p.splitData[0]は攻撃者がこの関数を呼び出すたびに同じであるため（これは提案pのプロパティであり、DAOの一般的な状態ではありません）、また、攻撃者は残高配列が更新される前にwithdraw応答からこの関数を呼び出すことができるため、攻撃者はこのコードを取得して攻撃を何度でも実行でき、毎回同じ金額の資金が転送されることになります。

この脆弱性を悪用するために攻撃者が最初に行う必要があるのは、DAO の withdraw 関数を有効にすることです。この機能は、実際に実行すると、決定論的再帰送信の脆弱性にさらされます。これを実現するためにコードで何を行う必要があるかを見てみましょう (DAO.sol より):

ハッカーが最初の if ステートメントを false と評価することができれば、脆弱であるとマークされたステートメントが実行されます。このステートメントが実行されると、次のコードが呼び出されます。

リンク先のエクスプロイトの説明に記載されているように、マークされたコマンドラインが具体的に脆弱なコードであることに注意してください。

このコマンドラインは、DAO プロトコルからのメッセージを「_recipient」(攻撃者) に送信します。もちろん、「_recipient」には間違った機能が含まれており、攻撃者の最初の呼び出しと同じパラメータを送信して、splitDAO を再度呼び出します。これらすべてが splitDAO の withdrawFor で発生したため、残高を更新する splitDAO のコードは実行されなかったことに注意してください。したがって、Split は子 DAO にさらにトークンを送信し、その後、再度引き出しを要求します。トークンを「_recipient」に再度送信しようとし、残高配列を更新する前に分割 DAO を再度呼び出します。

次のように実行されます:

分割を提案し、直接投票の期限が切れるまで待ちます。 (DAO.sol、createProposal)
分割して実行します。 (DAO.sol、splitDAO)
DAO がトークンの一部を新しい DAO に送信できるようにします (splitDAO -> TokenCreation.sol、createTokenProxy)
(3) の後に残高を更新する前に、DAO が支払いを送信しようとしていることを確認してください。 (splitDAO -> withdrawRewardFor -> ManagedAccount.sol、payOut)
DAOがステップ（4）に達したら、（2）と同じパラメータでsplitDAOを再度実行します。 (payOut -> _recipient.call.value -> _recipient())
その後、DAO は残高を更新する前に、さらにサブトークンを送信し、利益を引き出します。 (DAO.sol、splitDAO)
（５）を返せ！
DAO に残高を更新してもらいます。（7）は（5）に戻るので、これは起こりません。

(補足: Ethereum のガス技術はここでは役に立ちません。Call.value は、send 関数とは異なり、トランザクションに必要なガスをデフォルトで渡します。そのため、攻撃者が支払う限り、コードは実行されます。これは低レベルのエクスプロイトと見なされ、不安定であることを意味します)

上記により、DAO が段階的に空になった経緯を段階的に追跡することができます。

ステップ1: 分割を提案する

最初のステップは、前述したように、単に定期的な分割を行うことです。

このステップの攻撃者は、ブロックチェーン上の DAO に「Lonely, so Lonely」という名前の #59 を提案します。

このコマンドラインは、
彼はその提案が承認されるまで一週間待たなければならなかった。でも大丈夫です、他の分割提案と同じように単純な分割提案です!誰もそれにあまり注意を払わないでしょう？

ステップ2: メリットを得る

この件については slock.it の以前の投稿で詳しく説明されており、DAO では依然として収益分配は行われていません。（収益が発生しなかったため）。

概要で述べたように、この重要なコマンドラインはここで実行する必要があります。

ハッカーが最初のフラグ付きコマンドラインを実行できる場合、2 番目のフラグ付きコマンドラインはハッカーが選択したデフォルト関数を実行します (これは、前述したように、splitDAO を返すことと呼ばれます)。
最初の if ステートメントを分解してみましょう。

残高機能は Token.sol で定義されており、もちろん次のようになります。

rewardAccount.accumulatedInput() コマンドラインは、ManagedAccount.sol のコードから評価されます。

幸いなことに、accumulatedInput の操作は簡単です。収入アカウントのデフォルト機能を使用するだけです。

それだけでなく、accumulatedInput を減算するロジックはどこにも存在しないため (すべてのトランザクションにわたってアカウントの入力に従います)、攻撃者は Wei を収益アカウントに送信するだけで、初期条件が間違っていると評価されるだけでなく、そのコンポーネント値はすべての呼び出しで同じと評価されます。

balanceOf は残高を参照するため、決して更新されず、splitDAO のコードは実際には実行されないため、paidOut と totalSupply は更新されず、攻撃者は問題なく収益のわずかな分け前を請求できることを覚えておいてください。彼らは収益のこの分け前を請求できるため、デフォルトの関数を実行して、それを splitDAO に返すことができます。

しかし、本当に特典を含める必要があるのでしょうか?もう一度このコマンドラインを見てみましょう。

収益口座の残高が 0 になるとどうなりますか?すると次のようになります:

支払われない場合、これはエラーとして評価され続け、止まることはありません。なぜ？元のコマンドラインは同等なので、両辺から paidOut を減算すると、次のようになります。

最初の部分でいくら支払われたか。つまり、小切手は実際には次のようになります。

しかし、amountToBePaid が 0 の場合、DAO はどのような場合でも支払います。これは私にはあまり意味がわかりません。なぜこのようにガスを無駄にするのでしょうか?これが、攻撃者が攻撃を実行するには利益口座残高が必要だと考える人が多い理由だと思いますが、実際にはそれは必要ありません。収益アカウントが空であっても、収益アカウントがいっぱいであっても、攻撃は同じように機能します。

DAO の収益アドレスを見てみましょう。 Slockit ペグの DAO アカウントファイルでは、このアドレスは0xd2e16a20dd7b1ae54fb0312209784478d069c7b0です。このアカウントのトランザクションを調べると、次のパターンがわかります。0xf835a0247b0063c04ef22006ebe57c5f11977cc4 および0xc0ee9db1a9e07ca63e4ff0d5fb6f86bf68d47b89への0xf835a0247b0063c04ef22006ebe57c5f11977cc4イーサのトランザクションが 200 ページあります。これは、攻撃者による悪意のある契約 2 つです (これについては後で説明します)。上で述べたように、このトランザクションの各再帰呼び出しは withdrawRewardFor です。したがって、この攻撃では給付金口座に確かに残高があったのですが、攻撃者はそれを適用しませんでした。

ステップ3: 大きな不足

ソーシャルメディア上では、攻撃前にビットフィネックスのイーサリアムに300万ドルの不足があり、その不足分が100万ドル近くの利益に相当したという、完全に未確認の主張がいくつかあった。

この攻撃を構築し分析した者は誰であれ、DAO の特定の特性 (特に、どの分割でも元の DAO と同じコードを実行する必要がある) により、攻撃者は悪意のある分割からコインを引き出す前に、子 DAO の作成期間 (27 日間) を待つ必要があることを十分に認識していました。これにより、コミュニティは、ソフトフォークを介して攻撃者のアカウントを凍結するか、ハードフォークを介してプロトコル全体をロールバックすることによって、盗難に対応する時間が与えられます。

テストネットの脆弱性を悪用しようとする金銭目的の攻撃者は、潜在的なロールバックであろうと、基礎となるトークンをショートさせるためのフォークであろうと、利益を確保したいと考えるでしょう。悪意のある分割によって起動されたスマートコントラクトにより、数分以内に価格が急落し、絶好の利益獲得の機会が生まれましたが、攻撃者がこの機会を利用したという証拠はありません。少なくとも、この点に関しては彼らは愚かだったと結論づけることができる。

ステップ 3a: 退出を阻止する (抵抗は無効)

攻撃者が考慮しなければならないもう 1 つの可能性は、攻撃者が DAO を枯渇させる前に DAO 分割が発生することです。この方法では、別のユーザーが唯一の管理者として機能するため、攻撃者が DAO の資金にアクセスする可能性はありません。

残念ながら、攻撃者は賢かった。攻撃者の分割提案はすべて彼自身の条件で行われ、DAO 分割の許可を彼が得ていたという証拠がある。この記事の後半で説明しますが、DAO の性質上、ここで説明する DAO 分割は同じ攻撃に対して脆弱です。攻撃者が行う必要があるのは、作成期間後に収益アカウントにいくらかのイーサを送り、新しい DAO からの分割を自ら提案して実行することだけです。新しい DAO 管理者が脆弱性を排除するためにコードを更新する前に彼がこれを実行できれば、彼は自分のものではないイーサを DAO から正常に引き出すことができるでしょう。

ここのタイムラインから、攻撃者が悪意のある分割の開始とほぼ同時にこれらすべてを開始していることがわかります。これは、経済的に実行可能な攻撃というよりも、DAO に対する不必要な屈辱だと私は考えています。DAO を事実上空っぽにした後、テーブルの上に残っているコインを拾い上げようとするこの取り組みは、おそらく、保有者が何もしないように妨害しようとする試みです。多くの人が、そして私も同意見ですが、この攻撃者の動機は利益を得ることではなく、DAO を完全に破壊することだったと結論付けています。真実は誰にも分かりませんが、皆さんもご自身で判断することをお勧めします。

興味深いことに、この攻撃はEmin Gün Sirer氏によって説明された後にブロックチェーン上で発生しましたが、一般の人々はそれ以前には気づいていませんでした。

ステップ4: 分割を実行する

この攻撃の退屈な技術的側面をすべて説明してきたので、次は楽しい部分、つまり悪意のある分割を実行するアクションに移りましょう。分割後に取引を行ったアカウントは0xf35e2cc8e6523d683ed44870f5b7cc785051a77dです。

資金を送った子DAOは0x304a554a310c7e546dfe434669c62820b7d83490です。提案の作成と開始のためのアカウント

それは0xb656b2a9c3b2416437a811e07466ca712f5a5b5aです (ブロックチェーンの履歴で作成された提案への呼び出しを確認できます)。

子 DAO を作成するためにコンストラクタのパラメータを分解すると、マネージャ0xda4a4626d3e16e094de3225a751aab7128e96526に至ります。このスマートコントラクトは通常のマルチ署名ウォレットであり、過去のトランザクションのほとんどは所有者の追加/削除やその他のウォレット管理タスクです。何も面白いことはないよ。

Johannes Pfeffer は、Medium で、子 DAO に関わるトランザクションの優れたブロックチェーンベースの再構築を公開しています。彼は素晴らしい仕事をしてくれたので、ブロックチェーンの分析にあまり時間をかけるつもりはありません。この記事に興味のある方は、最初から読み直すことを強くお勧めします。

このシリーズの次の記事では、プロトコル自体の悪意のあるコード（再帰攻撃におけるエクスプロイトの実際の展開を含む）について説明します。出版目的のため、完全な分析は完了していません。

ステップ4a: 分割を展開する

このステップは最初のアップデートのフォローアップであり、攻撃者がどのようにして 30 倍の増幅攻撃 (イーサリアムスタックは 128 ブロックに制限されているため) をアカウントのほぼ無限の流出に変えることができていたのかを不明瞭にしました。

賢明な読者は、スタックを圧倒し、必要以上に悪意のある分割を実行した後でも、コードによって splitDAO が終了した後、ハッカーの残高にはまだ出力がゼロであることに気づいたかもしれません。

では、攻撃者はどのようにしてこの制限を回避するのでしょうか? DAO トークンには送金機能があるため、攻撃者はこれを行う必要がありません。必要なのは、悪意のある関数内から、スタックの一番上にある DAO のヘルパー関数を呼び出すことだけです。

トークンをプロキシアカウントに転送すると、splitDAO の終了時に元のアカウントの出力がゼロになります (A がすべての資金を B に転送した場合、A のアカウントは splitDAO を通じて出力がゼロになる前に、転送を通じて出力がゼロになることに注意してください)。攻撃者はその後、プロキシアカウントから元のアカウントに資金を戻し、プロセスを最初からやり直すことができます。 splitDAOのtotalSupplyが失われたとしても、支払いの計算にはp.totalSupply[0]が使用されるため、これは元の提案のプロパティであり、攻撃が発生するまで実現できません。したがって、DAO 内のイーサの量は反復ごとに減少します。攻撃の強さは変わらない可能性があります。

ブロックチェーン上に withdrawRewardFor への悪意のあるプロトコル呼び出しが 2 つ存在するということは、攻撃者のプロキシアカウントも、攻撃者の元のアカウントと簡単に交換できる、攻撃に使用できる契約であることを示しています。この最適化により、攻撃サイクルごとに 1 つのトレードが節約されますが、不必要であると思われます。

1.1 は脆弱ですか?

withdrawRewardFor は脆弱であるため、関数が更新された後も DAO1.1 は同じ攻撃に対して脆弱であるかどうかを尋ねる人もいます。答えは「はい」です。
更新された機能 (特にマークされたコマンドライン) を確認してください。

実際の支払いが行われる前に paidOut が更新されることに注意してください。それで、これは私たちのエクスプロイトにどのような影響を与えるのでしょうか? getRewardFor が 2 回目に呼び出されると、次のコマンドラインを使用して、splitDAO への悪意のある 2 回目の呼び出しが行われます。

0 になります。呼び出しコストはcall _recipient.call.value (0)() となり、これがこの関数のデフォルト値なので、呼び出す価値があります。

攻撃者は悪意のある分割トランザクションを送信するときに大量のガスを支払ったため、再帰攻撃が続行されました。
1.1 の後に 1.2 を入手するのに 6 日かかり、安全性が保証されたコードの設計には何年もかかることを認識したことが、DAO の操り人形師が手放したかった理由でしょう。

重要な結論

この攻撃にとって、1.1 の感度は興味深いと思います。withdrawRewardFor 自体は脆弱ではなく、withdrawRewardFor のない splitDAO も脆弱ではありませんが、その組み合わせは致命的です。おそらくこれが、テスト中に多くの人がこの脆弱性を何度も見逃した理由です。テスターは一度に 1 つの関数をテストすることに慣れており、安全なサブルーチンを呼び出すと期待どおりに安全に動作すると想定しています。

Ethereum の場合、資金の送信を含む安全な関数であっても、元の関数が再入に対して脆弱になります。それがデフォルトのソリッドライブラリの関数であるか、自分で頭の中で作り上げた安全関数であるかは関係ありません。状態の更新後に Ethereum コードがすべての機能値が実装されていることを確認するように注意する必要があります。そうでない場合、これらの状態値は再入可能である必要があります。