最近、クライアントの 1 人と協力しているときに、一部の DeFi プロジェクトの攻撃ベクトルとなる可能性のある興味深いバグを発見しました。このエラーは、特によく知られている ERC777 トークン標準に関連しています。また、これは、有名なハッカーの間でよく見られる単純な再入の問題だけではありません。この記事では、ERC777 について必要な詳細をすべて網羅して包括的に説明します。 ERC777 トークンの詳細を詳しく掘り下げるリソースはほとんどありませんが、この記事は ERC777 トークンについて詳しく知りたい人にとって貴重な詳細ガイドです。記事の最後の部分では、私たちの最近の発見について説明します。## 攻撃ベクトルの簡単な説明この脆弱性はERC777の特性を利用し、Hook受信機能を設定できるものです。ターゲット コントラクトで任意の呼び出しを行う機能を利用することで、悪意のある呼び出し元は ERC777 レジストリ コントラクトを呼び出し、ターゲット コントラクトに特定のフック アドレスを割り当てることができます。したがって、今後ターゲット コントラクトが ERC777 トークンを受け取るたびに、攻撃者のフック コントラクトがトリガーされます。このフックはさまざまな方法で悪用される可能性があります。トークンを盗むための再入攻撃や、単にトランザクションをロールバックして、ターゲットのコントラクトが ERC777 トークンを送受信できないようにすることなどです。## ERC777 とそのフック### ERC777とはERC777 は転送フックを備えたトークン規格の 1 つです。 EIP の説明は次のとおりです。また、ERC777 の実践例は次のとおりです。 [4] 。ERC777 トークンを実装する主な動機は、ネイティブ トークン転送の動作を模倣することです。トークンの受信時にスマート コントラクトをトリガーすることで、開発者は特定のロジックを実行して機能を強化し、より動的なトークン インタラクションを作成できます。ただし、転送プロセス中のこれらの追加の呼び出しにより、ERC777 は ERC20 トークンとは異なります。これらのフックは、トークン転送中に追加の呼び出しを処理するように設計されていないスマート コントラクトに影響を与える可能性のある新しい攻撃ベクトルを導入します。このような予期しない動作は、これらの契約にセキュリティ リスクをもたらします。以下は、イーサリアムメインネット上で流動性のあるいくつかの ERC777 トークンのリストです。**フックが発生したとき**ERC20 トークンは、送金中に残高を更新するだけです。しかし、ERC777 トークンは次のことを行います。1. トークン開始者のアドレスに対してフック呼び出しを実行します。2. 残高を更新する3. トークン受信者のアドレスに対してフック呼び出しを実行します。これは VRA トークンでよくわかります。ソースコード：ここで、これらの呼び出しのコードを調べてみましょう。ご覧のとおり:1. この関数は、_ERC1820_REGISTRY からimplementer と呼ばれるコントラクトを読み取ります。2. 関数がインプリメンタを見つけた場合、そのインプリメンタが呼び出されます。このレジストリを調べて、実装者が何であるかを見てみましょう。### レジストリと実装者すべての ERC777 トークンはレジストリの契約に関連しています。このアドレスは、設定されたフック受信者を保存するために ERC777 トークンによって使用されます。これらのフック受信者は「インターフェイス実装者」と呼ばれます。これは、アリスがインターフェース実装者としてボブを選択できることを意味します。アリスが ERC777 トークンを受信または送信すると、ボブはフックを受信します。アリスはさまざまなタイプのフックを管理できます。したがって、アリスがトークンを送信するときは、インターフェイスの実装者としてボブを選択できますが、アリスがトークンを受信するときのみ、実装者としてトムを選択できます。ほとんどの場合、異なるトークンに対して異なるインターフェイス実装者を選択することもできます。これらの設定は、このマップされたレジストリに保存されます。_interfaceHash は、イベントに対してアリスによって選択されたインターフェイス実装者の ID です。そして、誰でもこの関数を使用して、Alice のインターフェース実装を読み取ることができます。ご覧のとおり、これは VRA コードの前半で見た関数です。変数 _TOKENS_SENDER_INTERFACE_HASH は _interfaceHash として使用され、任意のバイトを指定できます。ただし、VRA トークンは次のバイトを使用してこのタイプのフックを識別します。### レシーブフックフック受信関数を設定するには、アリスはレジストリでこの関数を呼び出し、ボブのアドレスを _implementer パラメータとして入力するだけで済みます。_interfaceHash も指定する必要があります。彼女は VRA トークン コードからこの _TOKENS_SENDER_INTERFACE_HASH を取得します。もう 1 つ重要な詳細があります。上記の VRA のインプリメンタをセットアップした後、アリスは、他の ERC777 トークンが転送された場合でもボブが呼び出しを受信することにも気づきます。 imBTCなど [5] , imBTC は、送信されたトークンに同じ _interfaceHash を持ちます。これは、すべての ERC777 トークンがフック設定を保存するために同じレジストリ コントラクトを共有しているためです。ただし、フックに名前を割り当てるのは ERC777 トークン次第であり、似ている場合もありますが、常にそうとは限りません。### ERC777 トークンを見つける方法レジストリの呼び出しは、すべての ERC777 の機能です。それでは、dune.com を試してみましょう [6] レジストリを呼び出すすべてのスマート コントラクトを呼び出します。この SQL スクリプトを使用できます。実際には、トークン アドレスをさらにフィルタリングする必要がありましたが、少なくとも完璧なスタートを切り、最終的には 78 個のアドレスを得ることができました。> 翻訳者注: 砂丘跡表 [7] トランザクションの内部通話記録を記録します。>>### このレジストリが唯一の可能性ですか?理論的には、何らかのトークンがたまたまこの 0x1820 コントラクトをレジストリとして使用することを保証する人は誰もいません。でも、dune.com は使えます [8] チェックして来てください。これらのアドレスを返します0x1820a4b7618bde71dce8cdc73aab6c95905fad240xc0ce3461c92d95b4e1d3abeb5c9d378b1e4180300x820c4597fc3e4193282576750ea4fcfe34ddf0a7確認したところ、貴重な ERC777 トークンを含むレジストリは 0x1820 だけでした。他のレジストリのトークンはそれほど価値がありません。### Hookable トークンの一般的な状況ERC777 はフックを備えた規格だけではありません。 ERC223、ERC995、またはERC667も。それらはそれほど珍しいことではありません。 ERC667を実装したLINKトークンについて聞いたことがあるはずです。 [9] 。## 任意の呼び出しを使用した攻撃ベクトルこれは、ある顧客に対する最近発見された攻撃ベクトルです。研究者は一般に、ERC777 トークンが発信者と受信者に電話をかけると想定しています。しかし実際には、開始者と受信者はフック受信者として任意の「ボブ」を選択できます。では、任意のデータを含む任意のアドレスに任意の呼び出しを行うコントラクトと組み合わせると何が起こるかを想像してみてください。DEX アグリゲーター、ウォレット、マルチコール コントラクトで広く使用できる任意のコール関数があります。> 翻訳者注: 任意の呼び出し関数とは、コントラクトに次のような関数があることを意味します。>> 関数 ute(アドレスターゲット、uint 値、文字列メモリ署名、バイトメモリデータ、uint eta) public payable;>> 他のメソッドを呼び出すことができます。>>攻撃方法：1. 攻撃者は、任意の関数呼び出しを許可するターゲット コントラクト (Target) を見つけます。2. 攻撃者はターゲットに次の呼び出しを行います。3.registy1820.setInterfaceImplementer(ターゲット、フックハッシュ、攻撃者)4. さて、攻撃者はターゲットの実装者です。5. 攻撃者は、ERC777 トークンで使用されるフックハッシュを使用して呼び出されます。6. ターゲットコントラクト (Target) が ERC777 トークンを受信するたびに、攻撃者はフック呼び出しを受信します。7. 次の攻撃はターゲット コードによって異なります。※一部のユーザーが対象コントラクト内の機能を実行すると、攻撃者は再侵入可能* 攻撃者は直接ロールバックできるため、ユーザーのトランザクションは直接復元されます。DEX アグリゲーターが、ERC777 トークンを使用した DEX 取引ペアを経由するのが最適な変換パスであると計算した場合、問題が発生する可能性があります。＃＃ 守るお客様と何時間も話し合いを重ねた結果、任意の通話を中断しないソリューションを見つけました。プロジェクト側にとって、呼び出しのアドレスとして Registry1820 の使用を制限することが最善です。したがって、攻撃者は任意の呼び出しを悪用してインターフェイス実装者を設定することはできません。## 経験から話すプロジェクトと監査人は、ERC777 で説明されているフックの動作に注意を払う必要があります。これらのトークンは、レシーバーとイニシエーターだけでなく、他のフック レシーバーも呼び出します。この意味で、任意の呼び出しを許可するプロジェクトは特別な注意を払い、ERC777 の別の攻撃ベクトルを考慮する必要があります。
ERC777 および任意の通話契約に関する潜在的なセキュリティ問題
最近、クライアントの 1 人と協力しているときに、一部の DeFi プロジェクトの攻撃ベクトルとなる可能性のある興味深いバグを発見しました。このエラーは、特によく知られている ERC777 トークン標準に関連しています。また、これは、有名なハッカーの間でよく見られる単純な再入の問題だけではありません。
この記事では、ERC777 について必要な詳細をすべて網羅して包括的に説明します。 ERC777 トークンの詳細を詳しく掘り下げるリソースはほとんどありませんが、この記事は ERC777 トークンについて詳しく知りたい人にとって貴重な詳細ガイドです。
記事の最後の部分では、私たちの最近の発見について説明します。
攻撃ベクトルの簡単な説明
この脆弱性はERC777の特性を利用し、Hook受信機能を設定できるものです。ターゲット コントラクトで任意の呼び出しを行う機能を利用することで、悪意のある呼び出し元は ERC777 レジストリ コントラクトを呼び出し、ターゲット コントラクトに特定のフック アドレスを割り当てることができます。したがって、今後ターゲット コントラクトが ERC777 トークンを受け取るたびに、攻撃者のフック コントラクトがトリガーされます。このフックはさまざまな方法で悪用される可能性があります。トークンを盗むための再入攻撃や、単にトランザクションをロールバックして、ターゲットのコントラクトが ERC777 トークンを送受信できないようにすることなどです。
ERC777 とそのフック
ERC777とは
ERC777 は転送フックを備えたトークン規格の 1 つです。 EIP の説明は次のとおりです。また、ERC777 の実践例は次のとおりです。 [4] 。
ERC777 トークンを実装する主な動機は、ネイティブ トークン転送の動作を模倣することです。トークンの受信時にスマート コントラクトをトリガーすることで、開発者は特定のロジックを実行して機能を強化し、より動的なトークン インタラクションを作成できます。
ただし、転送プロセス中のこれらの追加の呼び出しにより、ERC777 は ERC20 トークンとは異なります。これらのフックは、トークン転送中に追加の呼び出しを処理するように設計されていないスマート コントラクトに影響を与える可能性のある新しい攻撃ベクトルを導入します。このような予期しない動作は、これらの契約にセキュリティ リスクをもたらします。
以下は、イーサリアムメインネット上で流動性のあるいくつかの ERC777 トークンのリストです。
フックが発生したとき
ERC20 トークンは、送金中に残高を更新するだけです。しかし、ERC777 トークンは次のことを行います。
トークン開始者のアドレスに対してフック呼び出しを実行します。
残高を更新する
トークン受信者のアドレスに対してフック呼び出しを実行します。
これは VRA トークンでよくわかります。
ソースコード：
ここで、これらの呼び出しのコードを調べてみましょう。
ご覧のとおり:
このレジストリを調べて、実装者が何であるかを見てみましょう。
レジストリと実装者
すべての ERC777 トークンはレジストリの契約に関連しています。
このアドレスは、設定されたフック受信者を保存するために ERC777 トークンによって使用されます。これらのフック受信者は「インターフェイス実装者」と呼ばれます。
これは、アリスがインターフェース実装者としてボブを選択できることを意味します。アリスが ERC777 トークンを受信または送信すると、ボブはフックを受信します。
アリスはさまざまなタイプのフックを管理できます。したがって、アリスがトークンを送信するときは、インターフェイスの実装者としてボブを選択できますが、アリスがトークンを受信するときのみ、実装者としてトムを選択できます。
ほとんどの場合、異なるトークンに対して異なるインターフェイス実装者を選択することもできます。
これらの設定は、このマップされたレジストリに保存されます。
_interfaceHash は、イベントに対してアリスによって選択されたインターフェイス実装者の ID です。
そして、誰でもこの関数を使用して、Alice のインターフェース実装を読み取ることができます。
ご覧のとおり、これは VRA コードの前半で見た関数です。
変数 _TOKENS_SENDER_INTERFACE_HASH は _interfaceHash として使用され、任意のバイトを指定できます。ただし、VRA トークンは次のバイトを使用してこのタイプのフックを識別します。
レシーブフック
フック受信関数を設定するには、アリスはレジストリでこの関数を呼び出し、ボブのアドレスを _implementer パラメータとして入力するだけで済みます。
_interfaceHash も指定する必要があります。彼女は VRA トークン コードからこの _TOKENS_SENDER_INTERFACE_HASH を取得します。
もう 1 つ重要な詳細があります。
上記の VRA のインプリメンタをセットアップした後、アリスは、他の ERC777 トークンが転送された場合でもボブが呼び出しを受信することにも気づきます。 imBTCなど [5] , imBTC は、送信されたトークンに同じ _interfaceHash を持ちます。
これは、すべての ERC777 トークンがフック設定を保存するために同じレジストリ コントラクトを共有しているためです。ただし、フックに名前を割り当てるのは ERC777 トークン次第であり、似ている場合もありますが、常にそうとは限りません。
ERC777 トークンを見つける方法
レジストリの呼び出しは、すべての ERC777 の機能です。それでは、dune.com を試してみましょう [6] レジストリを呼び出すすべてのスマート コントラクトを呼び出します。
この SQL スクリプトを使用できます。実際には、トークン アドレスをさらにフィルタリングする必要がありましたが、少なくとも完璧なスタートを切り、最終的には 78 個のアドレスを得ることができました。
このレジストリが唯一の可能性ですか?
理論的には、何らかのトークンがたまたまこの 0x1820 コントラクトをレジストリとして使用することを保証する人は誰もいません。でも、dune.com は使えます [8] チェックして来てください。
これらのアドレスを返します
0x1820a4b7618bde71dce8cdc73aab6c95905fad24 0xc0ce3461c92d95b4e1d3abeb5c9d378b1e418030 0x820c4597fc3e4193282576750ea4fcfe34ddf0a7
確認したところ、貴重な ERC777 トークンを含むレジストリは 0x1820 だけでした。他のレジストリのトークンはそれほど価値がありません。
Hookable トークンの一般的な状況
ERC777 はフックを備えた規格だけではありません。 ERC223、ERC995、またはERC667も。それらはそれほど珍しいことではありません。 ERC667を実装したLINKトークンについて聞いたことがあるはずです。 [9] 。
任意の呼び出しを使用した攻撃ベクトル
これは、ある顧客に対する最近発見された攻撃ベクトルです。
研究者は一般に、ERC777 トークンが発信者と受信者に電話をかけると想定しています。しかし実際には、開始者と受信者はフック受信者として任意の「ボブ」を選択できます。
では、任意のデータを含む任意のアドレスに任意の呼び出しを行うコントラクトと組み合わせると何が起こるかを想像してみてください。
DEX アグリゲーター、ウォレット、マルチコール コントラクトで広く使用できる任意のコール関数があります。
攻撃方法：
DEX アグリゲーターが、ERC777 トークンを使用した DEX 取引ペアを経由するのが最適な変換パスであると計算した場合、問題が発生する可能性があります。
＃＃ 守る
お客様と何時間も話し合いを重ねた結果、任意の通話を中断しないソリューションを見つけました。
プロジェクト側にとって、呼び出しのアドレスとして Registry1820 の使用を制限することが最善です。したがって、攻撃者は任意の呼び出しを悪用してインターフェイス実装者を設定することはできません。
経験から話す
プロジェクトと監査人は、ERC777 で説明されているフックの動作に注意を払う必要があります。これらのトークンは、レシーバーとイニシエーターだけでなく、他のフック レシーバーも呼び出します。
この意味で、任意の呼び出しを許可するプロジェクトは特別な注意を払い、ERC777 の別の攻撃ベクトルを考慮する必要があります。