投稿者: yudan@スローフォグセキュリティチーム

副題

攻撃内容の分析

BurgerSwap は Uniswap に似た AMM プロジェクトですが、Uniswap アーキテクチャとは異なります。 BurgerSwap アーキテクチャは一般的に [デリゲート -> lpPlatForm -> ペア] に分かれています。デリゲート層はすべてのペア情報を管理し、lpPlatForm 層の作成を担当します。次に、lpPlatForm レイヤーがダウンして、対応するペア コントラクトを作成します。アーキテクチャ全体を通じて、lpPlatForm 層は Uniswap のルーターとして機能し、計算されたトランザクション データと交換されるトークンをペア コントラクトに転送して交換を完了する役割を果たします。

今回の事件の根源はこの構造の問題にある。攻撃者のトランザクション動作を段階的に分析することで、攻撃プロセス全体の中核を復元します。

この攻撃は Pancake のフラッシュローンから始まり、攻撃者は Pancake から多額の WBNB を借り入れ、BurgerSwap を通じてこれらの WBNB を Burger トークンに変換しました。上記の操作を完了した後、攻撃者は制御するトークン (攻撃コントラクト自体) とバーガー トークンを使用して、デリゲート層を通じてトランザクション ペアを作成し、後続の攻撃に備えるための流動性を追加します。

トークンの作成と準備が完了すると、攻撃者はすぐに PaltForm 層の swapExactTokensForTokens 関数を通じて交換を開始します。交換パスは [攻撃者が制御するトークン -> Burger -> WBNB] になります。

次に最も重要な操作が行われました。

攻撃者はトランザクション ペアの作成時に自分が制御するトークンを使用したため、トークン交換プロセス中に、_innerTransferFrom 関数は攻撃者が制御するトークン コントラクトを呼び出すため、攻撃者は _innerTransferFrom 関数で swapExactTokensForTokens 関数を再入力できます。攻撃者はなぜこのようなことを行うのでしょうか?

PlatForm レイヤーの swapExactTokensForTokens 関数のコードを分析すると、コントラクトが _innerTransferFrom 関数を呼び出すときに最初にユーザーの交換データを計算し、その後、事前に計算されたデータを使用して、呼び出し後に最下位レイヤーに転送していることを見つけるのは難しくありません。 _innerTransferFrom 関数の操作、トークン交換。この関数の観点から見ると、たとえ攻撃者が swapExactTokensForTokens 関数に再度入ったとしても、下層で呼び出されるスワップ関数も独立しており、一見問題はありませんが、チェーン上の動作が注目されています。 SlowMist セキュリティ チーム:

驚いたのは、償還プロセス中にスリッページによる交換回数が減らなかったことです。理由は何ですか？鍵となるのは、根底にあるPair契約の問題だと思われる。最下層によって呼び出されるペア コントラクトをさらに分析しました。コードは次のとおりです。

要約する

要約する

この攻撃は BurgerSwap アーキテクチャの問題であり、Pair 層は PaltForm 層のデータを完全に信頼しており、それ自体で別のチェックを実行しないため、攻撃が発生します。最近、DeFiのセキュリティインシデントが頻繁に発生しており、DApp攻撃が激化していることを考慮し、SlowMistセキュリティチームは、DApp開発者が他のプロトコルからコードを移植する際には、移植プロトコルのアーキテクチャを十分に理解し、移植プロトコルとその移植プロトコルを十分に検討する必要があると推奨しています。互換性があり、経済的損失を防ぐためにオンライン化する前に専門のセキュリティ監査組織の監査に合格する必要があります。

攻撃トランザクション参照:

https://bscscan.com/tx/0xac8a739c1f668b13d065d56a03c37a686e0aa1c9339e79fcbc5a2d0a6311e333