Back to Blog

Seal Financeにおけるセキュリティインシデント

Code Auditing
2021年1月3日
5 min read

11月30日、当社のセキュリティインシデント監視システム ThunderForecast は、イーサリアム上の履歴トランザクションをスキャンした結果、Loopringプロトコルへの攻撃を検出しました(ブログ記事:EN, CN)。結論として、この攻撃の根本原因は sellTokenForLRC 関数におけるアクセス制御の欠如です。攻撃者は当時80.97 ETH(48,849.2 USD相当)を不正に取得しました。

2020年12月11日、当社の監視システム ThunderForecast は、異常な取引レートで取引された一連のトランザクションを報告しました。その後、当社の研究チームが開発したEthScopeシステムを使用してこれらのトランザクションを分析し、これがアービトラージ目的でSeal Finance Protocolの脆弱性を悪用した攻撃であることを発見しました。

Sealとは?

Sealのホワイトペーパーで言及されているように、「SEAL - 主要なDeFiプロトコル間の仲介役として機能し、それらの間の流動性を深める実験的なプロトコルです」。現在、Sealを他のさまざまな著名なトークン(UNI、YFI、USDT、SNXなど)と連携させる10以上の流動性プールが存在します。ボーナスを獲得するために、投資家はLPトークンをSEAL報酬コントラクトに預け、Farmコントラクトのbreed()関数をトリガーして新しいSEALトークンを生成する必要があります。Farmコントラクトは各Sealプールにデプロイされ、コントラクト内のbreed()関数は新しいSealトークンを発行するために使用されます。breed()の設定では、追加の1.6%のSealトークンが発行されます。さらに、発行されたSealトークンの0.8%は別のトークンと交換され、残りの0.8%の発行されたSealトークンは流動性としてプールに預けられます。しかし、breed()関数にはアクセス制御が設計されていなかったため、誰でもこの関数をトリガーでき、この基本的な設計が報告された攻撃の根本原因となりました。

以下は、breed()関数の確認されたソースコードです。

function breed() external {
	require(now / 1 days > today);
	today += 1;
 
	uint256 sealPairAmount = seal.balanceOf(address(cSeal));
	uint256 tokenPairAmount = token.balanceOf(address(cSeal));
	uint256 newSeal = sealPairAmount.mul(spawnRate).div(1e18);
	uint256 amount = UniswapV2Library.getAmountOut(newSeal, sealPairAmount, tokenPairAmount);
 
	seal.mint(address(cSeal), newSeal);
	if(address(seal) < address(token))
    	cSeal.swap(0, amount, address(this), "");
	else
    	cSeal.swap(amount, 0, address(this), "");
	token.transfer(address(cSeal), amount);
	seal.mint(address(cSeal), newSeal);
	cSeal.mint(address(this));
}

詳細

攻撃トランザクションの1つ[(https://phalcon.blocksec.com/explorer/tx/eth/0xddcbc6f146ce81dd2c0104d02c24b75605defa0cbbbca9adfcbae038ba61ad5b)]で、攻撃者は利益を最大化するために10のSealプールで攻撃ロジックを繰り返しました。以下の分析では、Seal-SNXプールで実行された攻撃に焦点を当てます。

この攻撃は3つのステップで実行されました。

  • ステップ1:Seal-SNXプールで1,084 Sealを2,787 SNXにスワップします。取引レートは1 Seal = 2.57 SNXでした。
  • ステップ2:Farmコントラクトのbreed()関数をトリガーします。この関数は13.08 Sealを発行し、それを10.20 SNXにスワップします。取引レートは1 SNX = 0.78 Sealになりました。これは、プール内のSNXの大部分がSealにスワップされたため、SNXとSealの量の間に大きな差が生じたためです。次に、Uniswapの価格計算アルゴリズムに基づいて、SNXはプール内で非常に価値のあるものになりました(価格は3倍以上に上昇しました)。
  • ステップ3:Seal-SNXプールで2787 SNXを1100 Sealにスワップします。この取引はSNXの価格をさらに上昇させたため、攻撃者はより多くのSealトークン(追加で16 Seal)をアービトラージしました。

損失をさらに測定および確認するために、当社のシステムEthScopeを使用して、攻撃前のブロック状態でのbreed()関数をリプレイしました。その結果、Farmは通常の呼び出しと比較して18個の追加Sealトークンを発行しました。攻撃者は16 Sealを奪い、プールには2 Sealしか残りませんでした。

利益と損失

このトランザクションで、攻撃者は合計175 Sealの利益を得ました。

攻撃の規模

2020年12月13日現在、オンチェーンで3つの悪意のあるコントラクト(0x49f93e, 0x8b3710, 0x0f20b6)がデプロイされ、22件のトランザクションが成功裏に実行され、4,247 Sealトークンがラップされました。当時の価格に基づくと、攻撃者はSealプロトコルの脆弱性を悪用して約58,467 USDを獲得しました。Sealプロトコルの脆弱性は依然として攻撃の対象となっていることを言及する価値があります!!!

さらに、得られたSealトークンのフローを分析した結果、約900のSealトークンがDEXに預けられ、残りは6つの異なるアドレスに分散されていることがわかりました。以下の図に示すように、これらのアドレスは、Seal FinanceとUniswap V2の流動性プールを除いて、すべてSealトークンのトップホルダーです。

終わりに

EthereumのDeFiエコシステムの発展に伴い、さまざまなセキュリティ問題が徐々に出現しています。実際、2020年12月13日現在、22件のトランザクションを通じてSealに相当な損失(58,467 USD)を引き起こした攻撃の根本原因であるアクセス制御。

更新(2021/01/04)

2020年11月30日の最初の攻撃後、攻撃者は3番目の攻撃コントラクトをデプロイし、5回の攻撃を実行しました。最後の攻撃は2020年12月24日に行われ、取得したSealトークンはこのアドレスに転送されました。このプロセスで、攻撃者は6,021 Sealトークンを取得しました。

タイムライン:

  • 2020/12/11:不審なトランザクションが発見される
  • 2020/12/12:分析完了
  • 2020/12/13:Seal Financeに報告
  • 2021/01/03:詳細が公開される
  • 2021/01/03:CVE-2021–3006が割り当てられる

BlockSecについて

BlockSecは、2021年に世界的に著名なセキュリティ専門家グループによって設立された、先駆的なブロックチェーンセキュリティ企業です。当社は、Web3の普及を促進するために、新興のWeb3の世界のセキュリティと使いやすさの向上に取り組んでいます。この目的のため、BlockSecはスマートコントラクトおよびEVMチェーンのセキュリティ監査サービス、セキュリティ開発と脅威のプロアクティブなブロックのためのPhalconプラットフォーム、資金追跡と調査のためのMetaSleuthプラットフォーム、およびWeb3ビルダーが仮想通貨の世界を効率的にサーフィンするためのMetaSuites拡張機能を提供しています。

現在までに、同社はMetaMask、Uniswap Foundation、Compound、Forta、PancakeSwapなど300社以上の著名なクライアントにサービスを提供しており、Matrix Partners、Vitalbridge Capital、Fenbushi Capitalなどの著名な投資家から2回の資金調達で数千万米ドルを獲得しています。

公式ウェブサイト:https://blocksec.com/

公式Twitterアカウント:https://twitter.com/BlockSecTeam

Sign up for the latest updates
安全な保管を超えて、第2部:ウォレットの暗号技術を安全に実装する
Security Insights

安全な保管を超えて、第2部:ウォレットの暗号技術を安全に実装する

攻撃者は、保護された秘密鍵のコピーを読み取らずに、その秘密鍵を復元できるのでしょうか。『Beyond Secure Storage』の第2部では、乱数の品質不足、エントロピーの損失、署名用ノンスの不備によって鍵の予測や復元が可能になった6件の事例を検証します。そこから鍵生成と署名に関する実装要件を導き出し、決済機関がコードレビューと導入済みシステムのテストを通じて、それらをどう評価できるかを説明します。

安全な保管を超えて、第1部:安全な決済・署名ワークフローの設計
Security Insights

安全な保管を超えて、第1部:安全な決済・署名ワークフローの設計

攻撃者が秘密鍵を盗まずに、認可されていない操作が有効な署名を得ることは、なぜ可能なのでしょうか。「安全な保管の先へ」第1回では、Bitget、Bybit、Binanceなどの事例を通じて、支払い要求、トランザクションの構築、署名、実行、決済の各段階における認可の不備を検討します。そのうえで、認可されていない操作を防ぎ、損失を抑えるための設計原則を導き出し、レビュー、監査、ペネトレーションテスト、演習によって、それらの防御策をどう検証できるかを説明します。

NEAR Intentsの悪用:返金処理の欠陥とセキュリティ上の教訓
Security Insights

NEAR Intentsの悪用:返金処理の欠陥とセキュリティ上の教訓

NEAR Intentsへの攻撃では、過大な払い戻しイベントを利用し、預け入れた資産が返還された後も内部残高を維持しました。本分析では、レシートの処理の流れと、合計3,865,021 USDTに上るBNB Chainでの7件の出金を再構成します。また、これらの資金流出とプロジェクトが報告した全額回収を区別し、NEARスマートコントラクトの開発と監査におけるセキュリティ上の考慮事項を示します。

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit
Seal Financeにおけるセキュリティインシデント