編集者注: この記事は以下から引用しましたスローミストテクノロジー（ID：SlowMist）スローミストテクノロジー（ID：SlowMist）

序文

副題

序文

Lianwen氏によると、Tokenlonは4月18日、攻撃者がUniswap流動性契約のERC777再入脆弱性を利用してETH-imBTCプールサイクルの裁定を行っていたことが判明したため、imBTC送金の一時停止を発表した。今回の攻撃手法は Uniswap v1 に存在する既知の脆弱性であり、この脆弱性は 2019 年 4 月に Consensys によって初めて発見されました。その後、imBTC が Uniswap 上で開始された後、imBTC は ERC777 に基づいて実装されているため、ERC777 の特性と Uniswap コードの問題を組み合わせることで、攻撃者はリエントランシーの脆弱性を利用してアービトラージを達成できます。今後、このアービ​​トラージの攻撃手法や具体的な内容を分析していきます。

副題

知識の準備

ERC777 プロトコルは、イーサリアムのトークン標準プロトコルです。このプロトコルは、イーサリアムの ERC20 プロトコルの改良版です。主な改良点は次のとおりです。

1. ether を送信してトークンを送信するのと同じ概念を使用します。メソッドは次のとおりです: send(dest, value, data)

2. コントラクトと通常のアドレスは、tokensToSend フック関数を登録することで、どのトークンの送信を拒否するかを制御できます（送信拒否は、フック関数 tokensToSend の revert で実現します）。"4. tokensReceived は、2 つの呼び出し (approve/transferFrom) で完了する必要がある ERC20 とは異なり、フック関数を使用して 1 つのトランザクションでトークンを送信し、トークンを受け入れるようにコントラクトに通知できます。"そして"5. ホルダーは次のことができます。"認可された

そして

取り消す

オペレーター (オペレーター: 保有者に代わってトークンを送信できます) これらのオペレーターは、通常 (分散型) 取引所、小切手処理業者、または自動支払いシステムです。

ここで、2 番目の点、つまり ERC777 標準の tokenToSend 関数に特に注意する必要があります。ERC777 プロトコルの定義によれば、この標準に準拠したトークンは、トークン転送のたびにトークンの呼び出しを試みます。送信側の tokensToSend 関数が発生し、トークン所有者は ERC1820 登録コントラクトに独自のコントラクトを登録し、このフック関数でいくつかの操作を定義して、トークン送信やその他の操作の拒否など、トークン転送プロセスの特定のプロセスを処理できます。

詳細な分析

これらの重要なポイントを理解することは、この攻撃の具体的な攻撃方法を理解するのに役立ちます。ここからは少しスピードを上げて、今回 Uniswap に何が起こったのか見てみましょう。

副題

詳細な分析

Etherscan 0x32c83905db61047834f29385ff8ce8cb6f3d24f97e24e6101d8301619efee96e 経由で攻撃者のトランザクションの 1 つをクエリします。

攻撃者は、imBTC を同じ金額の 0.00823084 で Uniswap コントラクトに 2 回転送し、その後 Uniswap から 2 つの ETH を受け取ったことがわかります。これは 2 つの非常に正常なトランザクションであるように見えましたが、実際には底流やその他の謎がありました。トランザクション全体の詳細をより深く理解するには、bloxy.info を通じてトランザクションの特定の詳細を表示する必要があります。

トランザクションの詳細を問い合わせたところ、攻撃者はまず ethToTokenSwapInput 関数を通じて一部の imBTC を Uniswap に交換し、次に tokenToEthSwapInput 関数を通じて初めて imBTC を ETH に交換し、その後 Uniswap が最初に ETH を攻撃者に転送したことがわかりました。 imBTC は ERC777 標準を実装しているため、imBTC の transferFrom 関数を呼び出すと、imBTC は攻撃者の tokensToSend 関数を呼び出します。次に、攻撃者の tokensToSend 関数で、攻撃者は 2 度目に imBTC を ETH に交換し、プロセスは終了します。

トランザクションの詳細を見ると、ここでは問題がないようです。引き続き UniSwap のコードに従います。

上記のコードは Uniswap の ethToTokenSwapInput 関数のコードです。コード分析によると、Uniswap の ethToTokenSwapInput 関数は ethToTokenInput 関数を呼び出し、まず getInputPrice を通じてトークンと交換できる eth の量を取得し、その後ユーザーに eth を送信します。 send 関数を介して、最後に transferFrom を介してトークンをコントラクトに転送します。 getInputPrice 関数に進みましょう。

getInputPrice 関数を分析すると、取得した ETH の量を計算する式は次のとおりであることがわかります。

この式では、ETH に対する通常の imBTC 交換プロセス中に、分母としての imBTC リザーブは交換後に増加し、対応する ETH リザーブは減少します。

しかし、攻撃者の操作方法を確認すると、攻撃者が初めて imBTC を ETH に送信する際、Uniswap はまず攻撃者に ETH を送信します。このとき、Uniswap 内の ETH リザーブが減少し、その後 Uniswap が transferFrom 関数を呼び出します。この時点では攻撃者の imBTC は差し引かれていません)、攻撃者が transferFrom 関数で 2 回目に ethToTokenSwapInput を呼び出すと、getInputPrice を通じて交換された ETH 金額を取得する式は次のようになります。

• 2 回目の交換計算では、ETH の準備金だけが減少しており、imBTC の準備金は増加していないことに注意してください。これは、ethToTokenSwapInput 関数を単独で呼び出した場合と比較して、攻撃者が imBTC を使用して交換するプロセスで可能であるという事実につながります。 2回目のETHでは計算式の分子は変わりますが、分母は変わりません。攻撃者がリエントリー方式で行う２回目の取引は、通常の取引に比べて利益が小さく、利益が得られます。このプロセスを繰り返すことで、同じ量のimBTCを通じてより多くのETHが得られるようになり、Uniswap事業者の損失が生じます。

• 副題

防御方法

• OpenZeppelin の ReentrancyGuard など、主要なビジネス操作メソッドにロック メカニズムを追加します。

• コントラクトを開発するときは、まずこのコントラクトの変数を変更してから、外部呼び出しを行うという書き方を使用してください。

• プロジェクトがオンラインになる前に、優秀なサードパーティのセキュリティ チームが包括的なセキュリティ監査を実施し、潜在的なセキュリティ問題を可能な限り発見します。

• 複数の契約が連携する場合には、複数者契約のコードセキュリティやビジネスセキュリティも確認し、さまざまなビジネスシナリオを組み合わせた場合のセキュリティ問題を十分に考慮する必要があります。

• 複数の契約が連携する場合には、複数者契約のコードセキュリティやビジネスセキュリティも確認し、さまざまなビジネスシナリオを組み合わせた場合のセキュリティ問題を十分に考慮する必要があります。

• セキュリティは動的であり、各プロジェクト関係者は、自分のプロジェクトに関連する可能性のある脅威インテリジェンスをタイムリーに取得し、潜在的なセキュリティ リスクを迅速に調査する必要もあります。

契約では、「ブラックスワン」イベントが発生した場合に時間損失を検出して停止できるように、可能な限り一時停止スイッチを設定する必要があります。

セキュリティは動的であり、各プロジェクト関係者は、自分のプロジェクトに関連する可能性のある脅威インテリジェンスをタイムリーに取得し、潜在的なセキュリティ リスクを迅速に調査する必要もあります。

副題

最終的な考え