分散型金融 (DeFi) は、ブロックチェーン エコロジーの中で人気のあるプロジェクト形式であるため、そのセキュリティは特に重要です。昨年以来、数十件のセキュリティインシデントが発生しています。
DeFi セキュリティに関する長期的な研究チーム (https://blocksecteam.com) として、BlockSec は独自に多数の DeFi セキュリティ インシデントを発見しており、その研究結果は主要なセキュリティ カンファレンス (USENIX Security、CCS、黒い帽子）。次の期間では、DeFi セキュリティ インシデントを体系的に分析し、セキュリティ インシデントの背後にある根本原因を分析します。
過去のレビュー:
（1）過去のレビュー:
（2）[BlockSec DeFi 攻撃分析シリーズの 1 つ] 私自身の話: ChainSwap 攻撃イベント分析
（3）[BlockSec DeFi 攻撃分析シリーズ 2] すべてを差し出す: Sushiswap 手数料が盗まれる
【BlockSec DeFi攻撃分析シリーズ3】空を盗み、時代を変える：アクロポリス攻撃事件の徹底分析
0xffffffff. 序文
北京時間2021年7月21日03時40分、弊社の攻撃検知システムが異常なトランザクションを検知しました。このトランザクションの詳細な分析により、これは、デフレ トークン (デフレ トークン) KEANU のメカニズムを利用して、三州犬が展開するメメステーク コントラクトの報酬計算メカニズムの脆弱性を攻撃した事件であることが判明しました。個人約56ETH。詳細な分析は次のとおりです。
読書の提案:
DeFi（イーサリアム）が初めての方は最初から読んでも大丈夫ですが、比較的長い記事ですので、読めない場合はご注意ください。
Akropolis などの DeFi アグリゲーター プロジェクトについてよく理解している場合は、「0x2 攻撃分析」から直接開始できます。
0x0. 背景の紹介
今年に入ってから、ドージコイン（DOGE）と柴犬コイン（SHIB）が広く注目を集めると同時に、関連する他のミームコインも人気を博し、多くのプロジェクト関係者が独自のミームを開発するきっかけとなった。三州犬が加盟しているサービス「ミームコイン」を中心にミームコインを提供しています。 Sanshu Inu はミームコイン SANSHU を発行しただけでなく、ミームコインのファーミングプールとしてコントラクト Memestake も作成しました。ユーザーが Memestake にミームコインを誓約している限り、報酬としてトークン Mfund を得ることができます。
一方で、ミームコインの多くはデフレトークン、つまり発行量が徐々に減少していくものです。一部のミームコインのデフレーションは、ユーザーがトランザクション転送（転送）を行うたびに、破棄および再配布のためにコインの一定割合を差し引くことで実現されており、これにより、受信者が実際に受け取るトークンの量が実際の支払いよりも少なくなります。支払者の数量によって。今回KEANUが関与したデフレトークンはこのような実装を採用しています。
攻撃の一般的な原理は、Memestake を制御して複数の KEANU 送金を実行し、報酬計算機能の抜け穴を利用して Memestake に多額の Mfund を送金させることで、保有する KEANU の数を減らすことです。アタッカー。
0x1. コード分析
理解を容易にするために、最初にこの攻撃に関連する 2 つの物理コントラクト、KEANU トークンの KeanuInu コントラクトと Memestake コントラクトを簡単に紹介します。
キアヌイヌとの契約
前述したように、KeanuInu がトークン KEANU の譲渡を実現すると、破壊と再分配のためにコインの一定割合が差し引かれ、破壊の割合は固定値 - 2% に設定されます。図に示すように、KeanuInu の transfer() および transferFrom() 関数が呼び出された場合、関数呼び出しに表示される転送量は、発行イベント ログに記録される転送量と一致しません。http://tx.blocksecteam.com:8080/実際のコード実装呼び出しは複雑であるため、ここでは示しませんが、興味のある友人は、付録に記載されているコントラクト アドレスに従って、etherscan.io でコントラクトの実装を確認できます。さらに、上の 2 つのスクリーンショットは、現在オープン ベータ版である自社開発のトランザクション分析ツールからのものです。クリックへようこそ
試してみる。私たちのツールが関数呼び出しとプロセス中に生成されるイベント ログを組み合わせる方法は、デフレ トークンなどの問題の分析にさらに役立ちます。
ミームステーク契約
下図はMemeStakeの入金機能です。この関数は、まず updatePool を呼び出して資金プールの状態を更新し、次にユーザーのトークンをそれ自体に転送します。受信した _amount が 0 より大きい場合、転送はコードの 1295 行目で実行されます。
ただし、KEANU トークンのデフレ特性により、safeTransferFrom 関数の呼び出し時に渡される金額は _amount ですが、実際に資金プールに送金される金額は _amount よりも少なくなります。そしてコード解析の結果、送金先は自分自身、つまりMemeStakeの場合、ユーザーの特定通貨（KEANUトークンなど）の預金はすべてMemeStakeに属することが分かりました。
送金後の1296行目で、MemeStakeはユーザーの入金を登録しますが、ここでの登録はまだ _amount のまま（実際の送金金額は _amount 未満）なので、ユーザーの実際の入金額は登録されている user.amount よりも小さくなります。
最後に、行 1299 では、user.rewardDebt パラメーターも (実際の値より大きい) user.amount に基づいて計算されていることがわかります。
下図はMemeStakeの引き出し機能です。この関数はまず user.amount に十分な残高があるかどうかをチェックしますが、user.amount 自体が実際の値より大きいため、ここでのチェックは不正確になります。次に、updatePool 関数も呼び出され、ファンド プールのステータスが更新されます。
1321 行目で、withdraw 関数はまず user.amount に登録されている残高を差し引いてから、transfer 関数を呼び出してトークンをユーザーに転送します。こちらもデポジット機能と同様にロジックに問題があり、送金のたびにデフレが発生するため、ユーザーに送金される金額は実際の送金金額よりも少なくなってしまいます。
最後に、MemeStake の updatePool 関数を見てみましょう。まず、1255 行目から、各呼び出しで最後に更新された blockNumber が記録されることがわかります。今回呼び出されたブロックが最後の更新と同じ場合は、直接返されます。つまり、updatePool はそれぞれのブロックを更新するだけです。ブロック ファンドプールのステータス。
pool.accMfundPerShare += mFundReward / token.balanceOf(MemeStake)
次に1259行目で、トークンコントラクト内のMemeStakeそのものの残高を取得します（前述の通り、ユーザーが入金するたびにトークンがMemeStakeに転送されます）。最後に、行 1275 で、この残高を分母として使用して、ファンド プール (つまり、pool.accMfundPerShare パラメーター) の入金および引き出しごとの報酬を計算します。次のように計算されます。
rewardMfund = user.amont * pool.accMfundPerShare / 1e18 - user.rewardDebt。
出金の話に戻って、入出金報酬トークン Mfund がどのように転送されるかを見てみましょう。まず、上図のdraw関数の1325行目で、ユーザーが発行されていない保留中のMfundトークンを持っているかどうかを計算します。計算式は次のとおりです。
user.rewardDebt = user.amount * pool.accMfundPerShare / 1e18
そして、rewardDebt は次のように計算されます (図の 1325 行目)。
したがって、コードから考えられる攻撃を構築することは難しくありません。
まず、トランザクション内で、入金関数と引き出し関数を繰り返し呼び出すことによって、MemeStake の資金プールが空になります。この操作では、次の 3 つのコードの問題が利用されます。
まず第一に、user.amount は実際の金額よりも多く請求されるため、すべての出金は成功します。
第二に、MemeStake のすべてのユーザーの資金は 1 つのプールにあるため、各転送では実際に他のユーザーがプールに預けた KEANU トークンが燃焼されます。
第三に、updatePool は同じブロック内でステータスの更新を実行しないため、pool.accMfundPerShare パラメーターに影響を与えず、Mfund トークン報酬も生成しません。
次に、次のブロックで、withdraw 関数を直接呼び出します。
次に、withdraw 関数の行 1315 で、計算された Mfund 報酬額が非常に大きくなり、結果として莫大な Mfund 報酬が得られます。
0x2. 攻撃分析
0x2. 攻撃分析
脆弱性の原因と脆弱性の悪用方法については上記で紹介しましたが、次に攻撃者が実際にどのように攻撃を行うのかを紹介します。
図に示すように、攻撃は 4 つのステップに分けることができ、そのうちの重要な攻撃ステップはステップ 2 です。ステップ 2 では、デフレトークンの特性を利用して Memestake の報酬計算を操作します。ステップ 1 (準備)、まず攻撃者は 2 つのコントラクトを作成して初期化します。契約1KEANU通常の投資契約を実行するために、攻撃者は契約 1 を通じて約 2,049B を Memestake に入金しました。, 多額の MFUND 報酬を獲得するためのステップ 3 への道を切り開きます。契約2
Memestake報酬計算コントラクトを操作するには、まず該当トークンの承認操作を行います。0x00ed第 2 ステップ (操作) では、攻撃者はまず uniswapV2 から大量の KEANU トークンをフラッシュローンし、次にコントラクト 2 を通じて Memestake に大量の KEANU トークンを入出金し、Memestake に大量の KEANU トークンの取引を強制させます。キアヌ。 KEANU はデフレトークンであるため、各トランザクションは取引額の 2% を消費し、その結果、ユーザーの Memestake への実際の入金は登録された user.amount よりも少なくなり、出金は user.amount に応じてユーザーに送金されます (詳細についてはコード分析を参照してください)、その結果、Memestake プール内の KEANU トークン保有量が継続的に減少し、最終的には 1e-07 となりました。以下の図に示すように、関係するトランザクションは次のとおりです。
、トランザクションのスクリーンショットは完了していません。リンクをクリックしてご自身で表示してください。Mfundステップ 3 (利益)、攻撃者はまずコントラクト 2 を通じて Memestake.updatePool() 関数を呼び出し、KEANU が配置されているプールの accMfundPerShare を変更します。これは、この値がプールに保持されている KEANU トークンの量に依存するためです。これは 2 番目のステップで操作されました (具体的な式については、以下のコード分析を参照してください)。これにより、契約 2 は次の引き出しで通常の価値をはるかに上回る価値を得ることができます。0xa945(約61M) このトークンは報酬として使用されます。ステップ 3 はトランザクション内で発生します
同時に、攻撃者は取得したMFundの一部をWETHなどのトークンと交換し始めました。Tornado.Cashステップ4（終了）、攻撃者は取得したMFund、KEANU、その他のトークンをETHに交換し、通過させます。
転送してください。これまでのところ攻撃は終了しており、攻撃者は 55.9484578158357 ETH (攻撃者の EOA アドレスと展開された攻撃契約にはカウントされていない SANSHU トークンと KEANU トークンがまだあります)、約 100,000 米ドルの利益を得ています。0x0333次の図は攻撃アドレスを示しています
取引のスクリーンショット。取引のスクリーンショットは完了していません。アドレスのリンクをクリックして詳細を表示してください。
攻撃関連
興味深いことに、攻撃のステップ 2 と 3 は両方とも Flashbot のトランザクションに関連しています。0x00edステップ 2 に関係するトランザクション
UniswapV2フラッシュローンの採用により、取引前後ではKEANUの購入に約38ETHを使用したのと同等となり、大きな裁定スペースが生まれます。したがって、トランザクションは別の攻撃者によってサンドイッチされました (サンドイッチ攻撃)、つまり、このイベントの攻撃者は別のサンドイッチ イベントの被害者でもありました。サンドイッチ攻撃者は 3.2769697165652474ETH の利益を得ましたが、マイナーには 2.405295771958891249ETH を与え、純利益は 0.8716739446063562ETH でした。0xa945ステップ 3 の攻撃にトランザクションが関与している間
ユニスワッププールで大量のMFundが売却されたため裁定取引スペースが生じたため、バックランニングとなりフラッシュボット取引となった。探索者は0.13858054192600666ETHの利益を上げ、そのうち0.099085087477094764ETHがマイナーに渡され、純利益は0.03949545444891189ETHでした。フラッシュボットとサンドイッチ攻撃の詳細な紹介は、他の攻撃の紹介にあります。。 UniswapV2 ではフラッシュ ローンの実装が通常のスワップと組み合わされているため、具体的な実装原理と第 2 ステップにアービトラージ スペースがある理由については、論文を参照してください。Towards A First Step to Understand Flash Loan and Its Applications in DeFi Ecosystem (SBC 2021).
0x3. 概要とセキュリティに関する推奨事項
0x3. 概要とセキュリティに関する推奨事項
攻撃者はデフレトークンの特性を利用して、プラットフォームが保有するトークンの数を制御し、報酬トークンの計算と配布に影響を与え、55.9484578158357 ETHの利益を得ました。その理由は、Sanshu Inu プラットフォームにはデフレ トークンを導入する際のセキュリティに関する考慮事項が欠けており、攻撃者が悪用できるためです。
したがって、関連するプロジェクト関係者に対するセキュリティに関する推奨事項は次のとおりです。
プロジェクトを開始する前に、セキュリティ監査を実施する資格のあるセキュリティ会社を見つける必要があります。 defiのマネーレゴ属性により、多くのdefiプロジェクトを自由に組み合わせることができ、相互に影響を及ぼし、これがdefi分野でセキュリティインシデントが多発する理由となっていることがわかります。したがって、プロジェクト関係者が注意を払う必要があるセキュリティ問題は、自分のプロジェクトに限定されるものではなく、他のプロジェクトとのやり取りの過程に存在するセキュリティの脆弱性も考慮する必要があります。
コアセキュリティテクノロジーを推進する BlockSec チームは、プライバシー コンピューティングに基づく DeFi セキュリティ、デジタル通貨のマネーロンダリング防止、デジタル資産保管に長年取り組んでおり、DApp プロジェクト関係者に契約セキュリティとデジタル資産セキュリティ サービスを提供しています。このチームは 20 以上のトップセキュリティ学術論文 (CCS、USENIX Security、S&P) を発表しており、そのパートナーは AMiner の世界で最も影響力のあるセキュリティおよびプライバシー学者の称号を獲得しています (2011 年から 2020 年に世界で 6 位)。研究結果はCCTV、新華社通信、海外メディアの報道で表彰された。数十の DeFi セキュリティの脆弱性と脅威を独自に発見し、2019 年の国立衛生研究所プライバシー コンピューティング コンペティション (SGX トラック) で世界 1 位を獲得しました。テクノロジーを推進するチームは、オープン性とウィンウィンの概念を堅持し、コミュニティパートナーと協力して安全な DeFi エコシステムを構築します。
