Jarvis Network プロジェクトがフラッシュローン再入攻撃を受けた分析

データによると、2023年1月15日17:43:37 UTCに、Jarvis_Networkプロジェクトが攻撃を受け、663,101のMATICが失われました。

取引のコールスタックを分析したところ、流動性を削除する過程で再入ロジックが存在することがわかりました。再入前後で同じコントラクトの同じ関数を呼び出し、渡すパラメータは同じですが、返り値には大きな差異があります：

• 再入国前:1,002,157,321,772,769,944
• 再エントリシティ後:10,091,002,696,492,234,934

! ジャービスネットワークフラッシュローン再入攻撃インシデント分析

再入はremove_liquidity関数で発生します。この関数は流動性を削除する際に、ユーザーが追加したトークンを返します。PolygonとEVMは同型チェーンであるため、MATICがコントラクトに送信されると、コントラクトの再入がトリガーされます。

詳細な分析により、問題はgetUnderlyingPrice関数の実装にあることが判明しました。この関数は、一連の内部計算と外部呼び出しに関与しており、その中で重要なのはget_virtual_price関数の返り値です。

! ジャービスネットワークフラッシュローン再入攻撃インシデント分析

get_virtual_price 関数の戻り値は self によって管理されます。 D 変数。 remove_liquidity機能では、self. Dの更新は、トークンの転送後に行われます。 攻撃者が流動性を削除すると、MATICは攻撃コントラクトに移行し、フォールバックが呼び出されたときに最初にトークン価格が照会されます。 自己による。 D が更新されていないため、価格フェッチ エラーが発生しました。

! ジャービスネットワークフラッシュローン再入攻撃インシデント分析

remove_liquidity機能フロー:

1. ユーザーLPを焼却する
2. ユーザーのステーキング資金を送信 3.自己を更新します。 D

攻撃者は2ステップ目で再入を行い、更新されていないself.D値を利用して借り入れを行い、通常価格の10倍の資金を取得しました。

! ジャービスネットワークフラッシュローン再入攻撃インシデント分析

remove_liquidity関数は@nonreentrant('lock')を使用して再入を防止していますが、攻撃者はクロスコントラクトの再入を通じてこの保護メカニズムを回避しました。

! ジャービスネットワークフラッシュローン再入攻撃インシデント分析

今回の攻撃は、いくつかの重要な問題を浮き彫りにしました：

1. 外部呼び出し後の変数変更ロジックにより、価格取得異常が発生しました。
2. クロスコントラクト再入によって再入ロックが無効になる
3. "チェック-エフェクト-インタラクション"（Checks-Effects-Interactions）パターンに従っていない

! ジャービスネットワークフラッシュローン再入攻撃インシデント分析

安全性を高めるために、プロジェクトチームは次のことを行うべきです：

• 厳格なセキュリティ監査を行う
• 変数の変更を外部呼び出しの前に置く
• 複数のデータソースを使用して価格を取得する
• "先に判断し、次に変数に書き込み、外部呼び出しを行う"というコーディング規範に従う

! ジャービスネットワークフラッシュローン再入攻撃インシデント分析

これらの対策により、プロジェクトの安全性と安定性を大幅に向上させ、同様の攻撃を効果的に防ぐことができます。

! ジャービスネットワークフラッシュローン再入攻撃インシデント分析

! ジャービスネットワークフラッシュローン再入攻撃インシデント分析

! ジャービスネットワークフラッシュローンリエントランシー攻撃インシデント分析

! ジャービスネットワークフラッシュローン再入攻撃インシデント分析

! ジャービスネットワークフラッシュローン再入攻撃インシデント分析