Home / セキュリティ監査 / BetterBankの報酬ロジック欠陥によるDeFi攻撃の詳細解析

BetterBankの報酬ロジック欠陥によるDeFi攻撃の詳細解析

出典: Securelist – https://securelist.com/betterbank-defi-protocol-esteem-token-bonus-minting/117822/

原題: Deep analysis of the flaw in BetterBank reward logic

BetterBankの報酬ロジック欠陥を突いたDeFi攻撃の詳細解析

2025年8月末、PulseChainネットワーク上のDeFiプロトコルBetterBankが報酬トークンの設計ミスを悪用され、約500万ドル相当の資産が流出しました。本記事では、この攻撃の背景、技術的詳細、影響、そして今後の対策について詳しく解説します。

主要なポイント

  • 攻撃の概要と被害額:2025年8月26日から27日にかけて、BetterBankは流動性操作と報酬トークンの不正発行により約500万ドルの資産を失いましたが、交渉により約270万ドルが返還され、最終的な純損失は約140万ドルに抑えられました。
  • 脆弱性の原因:報酬システムの根本的な設計ミスにより、swapExactTokensForFavorAndTrackBonus関数がスワップ元の流動性プールの正当性を検証していなかったことが攻撃成功の鍵となりました。
  • 技術的な悪用手法:攻撃者は偽の流動性プールを作成し、FAVORトークンのスワップを繰り返すことでESTEEM報酬トークンを無制限にミント。さらに売却税を回避する仕組みも悪用しました。
  • 事前監査の指摘と対応不足:Zokyo社によるセキュリティ監査で同様の脆弱性が指摘されていたものの、コミュニケーション不足やリスク評価の低さから修正が不十分でした。
  • 攻撃後の対応と教訓:攻撃者との交渉による資金返還は異例であり、設計見直しや多層的なセキュリティ強化の必要性が浮き彫りになりました。

技術的な詳細と背景情報

BetterBankはFAVORとESTEEMという二種類のトークンを用いた報酬システムを採用しています。FAVORトークンのスワップに応じてESTEEMトークンが報酬としてミントされる設計ですが、問題はswapExactTokensForFavorAndTrackBonus関数がスワップ元の流動性プールの正当性を検証していなかった点にあります。

攻撃者は偽の流動性プールを作成し、FAVORトークンのスワップを繰り返すことでESTEEMトークンを無制限に発行。ESTEEMはFAVORに変換可能なため、このループにより報酬が際限なく増加しました。さらに、売却時に課されるはずの売却税(sell tax)を回避できる偽の流動性プールを利用し、損失を最小限に抑えました。

また、攻撃はfavorPLS.solのlogBuy関数や税ロジックを含む_transfer関数、そしてuniswapWrapper.solのbuy wrapper関数の脆弱性を悪用。allowedDirectPairマッピングのチェックのみで偽トークンを承認可能だったことも攻撃成功の要因です。フラッシュローンを用いて大量の資金を瞬時に調達し、正規のDAI-PDAIF流動性プールを排出した後、偽の流動性プールを作成して操作を行いました。

影響と重要性

  • ユーザーと流動性提供者への影響:BetterBankの利用者は直接的な資産損失を被り、流動性提供者の信頼も大きく揺らぎました。
  • PulseChainネットワークへの波及:DAI、PLSX、WPLSなど関連資産の価値や取引に影響を与え、ネットワーク全体の健全性に懸念が生じました。
  • DeFiエコシステム全体への教訓:報酬設計の甘さや監査の不徹底が大規模な損失につながることを示し、セキュリティ監査の信頼性向上と設計段階でのリスク評価の重要性を再認識させました。

まとめ

BetterBankの攻撃事件は、DeFiプロトコルにおける報酬ロジックの設計ミスがいかに致命的な脆弱性となりうるかを示す典型例です。事前のセキュリティ監査で指摘された問題が適切に対処されなかったこと、そして偽の流動性プールを用いた巧妙な攻撃手法が被害を拡大させました。

今後は、報酬システムの設計見直しやスワップ元の流動性プールの正当性検証の必須化、ホワイトリスト管理の強化、フラッシュローン攻撃への対策など多層的なセキュリティ対策が求められます。また、攻撃者との交渉による資金返還という異例の対応も注目されており、DeFiコミュニティ全体でのリスク管理と対応体制の強化が急務です。

この事件はトークノミクス設計におけるインセンティブとセキュリティのバランスの重要性を示すケーススタディとして、今後のプロトコル開発における貴重な教訓となるでしょう。

タグ付け処理あり:

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です