著者: Immunefi編集: Coinitme.com QDD
序章
ブロックチェーン技術を活用したスマートコントラクトは、分散化と自動化を実現することでさまざまな業界に革命をもたらしました。ただし、分散型アプリケーションの運用と設計には、新しいタイプのセキュリティ上の課題も生じます。
この記事では、安全で堅牢なスマート コントラクトを構築するために開発者と監査人が認識する必要がある、最も一般的な 10 個のスマート コントラクトの脆弱性について説明します。
注: Immunefi を通じて送信されたほとんどのプロジェクトとバグは、EVM ベースのブロックチェーンを使用しています。したがって、この記事ではこれらのテクニックに焦点を当てます。ただし、これらの分類は一般的なものであり、あらゆるブロックチェーン テクノロジーに拡張可能です。リストにある脆弱性は、ハッキングと、2023 年第 1 四半期までに Immunefi を通じて提出および支払われた脆弱性を詳述する過去のバグ修正レビュー記事の組み合わせによって特定されました。
抜け穴
V01:2023 不適切な入力検証
概要
不適切な入力検証は、Immunefi を通じて送信される多数の確認された脆弱性レポートや、実際に悪用される主な原因となっています。入力検証は、システムに入力されたデータの整合性、正確性、およびセキュリティを検証する重要なセキュリティ手法です。入力を適切に検証できないと、攻撃者が脆弱性を悪用してシステムの動作を操作する可能性が生じます。
説明する
不適切な入力検証は、スマート コントラクトがユーザー入力を適切に検証およびサニタイズできない場合に発生し、さまざまな種類の攻撃に対して脆弱になります。このような脆弱性を悪用すると、コントラクト ロジックを操作したり、悪意のあるデータを挿入したり、予期しない動作を引き起こしたりする可能性があります。適切な入力検証により、コントラクトが有効かつ期待されるデータのみを処理することが保証され、悪用のリスクが軽減されます。
注意事項
このような脆弱性を防ぐために、開発者は包括的な入力検証ルーチンを実装する必要があります。これには、データ型の検証、境界条件のチェック、予期せぬ事態を防ぐためのユーザー入力のサニタイズが含まれます。堅牢な入力検証を確保するには、エッジ ケースや予期しない入力を含む、考えられるすべての入力ケースを考慮する必要があります。難読化やシンボリック実行などの一部のツールや手法は、開発者がエッジ ケースの見逃しを防ぐのに役立ちます。これらのツールは、開発者がさまざまな入力をテストして、悪意のある入力によってスマート コントラクトの不変条件や実行が破壊されないことを確認するのに役立ちます。
例
Beanstalk ロジック エラーのバグ修正レビューには、入力検証の欠落バグの例が示されています。 Beanstalk トークン ファセット コントラクトには、エクスターナル モード転送中に msg.sender の許可が適切に検証されないという transferTokenFrom() 関数に脆弱性がありました。この脆弱性により、攻撃者は以前に Beanstalk 契約を承認していた被害者のアカウントから資金を送金することができました。
参考文献:
l https://medium.com/immunefi/sovryn-loan-vulnerability-postmortem-ffaf4d1d688f
l https://medium.com/immunefi/zapper-arbitrary-call-data-bug-fix-postmortem-d75a4a076ae9
l https://medium.com/immunefi/cream-finance-insufficient-validation-bug-fix-postmortem-1ec7248e8865
l https://medium.com/immunefi/pancakeswap-logic-error-bug-fix-postmortem-f2d02adb6983
lhttps://medium.com/immunefi/mcdex-insufficient-validation-bug-fix-postmortem-182fc6cab899
l https://medium.com/immunefi/polygon-lack-of-balance-check-bugfix-postmortem-2-2m-bounty-64ec66c24c7d
l https://medium.com/immunefi/notional-double-counting-free-colternate-bugfix-review-28b634903934
l https://medium.com/immunefi/port-finance-logic-error-bugfix-review-29767aced446
l https://medium.com/immunefi/aurora-withdrawal-logic-error-bugfix-review-c5b4e30a9160
lhttps://medium.com/immunefi/aurora-improper-input-sanitization-bugfix-review-a9376dac046f
l https://medium.com/immunefi/mt-pelerin-double-transaction-bugfix-review-503838db3d70
l https://medium.com/immunefi/balancer-logic-error-bugfix-review-74f5edca8b1a
l https://medium.com/immunefi/beanstalk-logic-error-bugfix-review-4fea17478716
l https://medium.com/immunefi/hack-analysis-platypus-finance-february-2023-d11fce37d861
V02:2023間違った計算
概要
Immunefi で確認されたバグ報告では、不正確な計算が僅差で 2 番目に多くなっています。
スマート コントラクトの計算が正しくない、または一貫性がない場合、不正確なトークン残高、不正確な報酬の分配、契約実行中の予期せぬ結果などの予期せぬ結果が生じる可能性があります。不正な計算は悪用されたコード パスと一致することが多く、不正な入力検証の脆弱性と密接に関連しています。ただし、誤った計算に関係する脆弱性は、ユーザーが何らかのアクションを実行できるはずであるにもかかわらず、計算ミスにより、ユーザーがそのアクションから予想よりもはるかに多くの価値を得る可能性があることです。
説明する
スマート コントラクトでは、数学的計算が正しく実行されない場合に計算エラーが発生し、予期しないまたは不正確な結果が生じます。これらの脆弱性は、精度、値の範囲に関する誤った仮定、契約のさまざまな部分の計算の不一致など、さまざまな理由で発生する可能性があります。契約が特殊なケースを考慮していない場合、または特殊なケースを適切に処理していない場合にも、誤った計算が発生する可能性があります。場合によっては、契約が極端な値を考慮していないか、オーバーフローまたはアンダーオーバーフローの処理に失敗し、予期しない動作やセキュリティ リスクにつながる可能性があります。攻撃者はこれらの脆弱性を悪用して、コントラクト内の計算を操作したり、不正な利益を獲得したりする可能性があります。このような脆弱性を防ぐには、適切な数学的精度と特殊なケースを注意深く考慮することが重要です。
注意事項
難読化またはシンボリック実行と組み合わせた単体テストは、見逃したエッジケースがコードベースに侵入するのを防ぐのに役立ちます。さらに、数式の正式な検証は、可能な状態についての保証を提供するのに役立ちます。計算を正確に実行するには、十分にテストされた安全な数学ライブラリまたはブロックチェーン プラットフォームによって提供される組み込み関数を使用します。これらのライブラリには、オーバーフローやアンダーフローなどの一般的な計算エラーに対する保護機能が組み込まれていることがよくあります。
例
例
参考文献:
l https://medium.com/immunefi/armorfi-bug-bounty-postmortem-cf46eb650b38
l https://medium.com/immunefi/vesper-rebase-vulnerability-postmortem-and-bug-bounty-55354a49d184
l https://medium.com/immunefi/pods-finance-bug-fix-postmortem-61a576897ebd
l https://medium.com/immunefi/tidal-finance-logic-error-bug-fix-postmortem-3607d8b7ed1f
l https://medium.com/immunefi/belt-finance-logic-error-bug-fix-postmortem-39308a158291
l https://medium.com/immunefi/cronos-theft-of-transactions-fees-bugfix-postmortem-b33f941b9570
l https://medium.com/immunefi/apwine-incorrect-check-of-delegations-bugfix-review-7e401a49c04f
l https://medium.com/immunefi/polygon-consensus-bypass-bugfix-review-7076ce5047fe
l https://medium.com/immunefi/synthetix-logic-error-bugfix-review-40da0ead5f4f
l https://medium.com/immunefi/building-a -poc-for-the-uranium-heist-ec83fbd83e9f
l https://medium.com/immunefi/hack-analysis-saddle-finance-april-2022-f2bcb119f38
l https://medium.com/immunefi/88mph-theft-of-unclaimed-mph-rewards-bugfix-review-1dec98b9956b
V03:2023 Oracle/価格操作
概要
スマート コントラクトは多くの場合、情報に基づいた意思決定を行うために外部データ ソース (オラクルと呼ばれます) に依存します。これらの法定通貨が侵害されたり操作されたりすると、スワップの価格設定の誤り、報酬の誤計算、担保比率が許容する以上の資産の借入、または金融取引に関連するその他の一般的な問題が発生する可能性があります。これらの外部データ ソースの操作は、オンチェーン DeFi の脆弱性の主な理由の 1 つです。信頼できるオラクルを選択し、安全なデータ検証メカニズムを実装することは、オラクル/価格操作に関連するリスクを軽減するために重要です。
説明する
多くのプロトコルはユーザーのアクションに基づいて資産の価格を更新するため、価格はユーザーの操作に基づいて更新されることが予想されるため、これは明白ですが見落とされやすい脆弱性である可能性があります。ただし、プロトコルがこれらの内部または外部の価格設定メカニズムに依存している場合は、スポット価格が乱用されないように慎重に検討する必要があります。価格操作が効果的に実行できるかどうかは、現在のオンチェーンの状況にも大きく依存します。液体プールが少ない場合、液体プールが多い場合よりも操作されるリスクが高くなります。信頼できるトークンを慎重に選択し、安全なデータ検証メカニズムを実装することが重要です。静的チェック、平均価格設定メカニズム、および読み取り専用の再入保護は、外部価格設定メカニズムの堅牢な統合にとって重要な機能となる可能性があります。データソースの多様化により、単一プロトコルの脆弱性がブロックチェーンエコシステム全体に大混乱をもたらすことも防止されます。
注意事項
オラクル/価格操作の脆弱性を防ぐために、開発者は実績のある信頼できるオラクルを慎重に選択する必要があります。暗号証明やマルチソース集約などの安全なデータ検証メカニズムを実装すると、受信したデータの正確性と整合性を確保できます。オラクルコントラクトとスマートコントラクトとの相互作用を定期的に監査および監視することも、潜在的な脆弱性を発見するのに役立ちます。外部オラクルから返されたデータの正確性について仮定を置くべきではなく、一時的な価格操作や古いデータがプロトコルの動作に影響を与えることを防ぐための安全策を講じる必要があります。
例
BonqDAO は、攻撃者が借りる資格がある (BEUR) よりもはるかに多くのステーブルコインを借りるために、WALBT トークンの価格を一時的につり上げることができる価格オラクル操作攻撃の被害を受けました。その後、攻撃者は再び価格を操作し、担保不足のコイン 30 枚以上を清算するために価格を最低値まで下げました。 BonqDAO の脆弱性は、その価格報告メカニズムが許可を必要としないということではなく、契約契約のスポット価格を最後に報告された値と見なすことです。このため、誰でも瞬時に特定の価格を上げたり下げたりすることができます。
参考文献:
l https://medium.com/immunefi/fei-protocol-vulnerability-postmortem-483f9a7e6ad1
l https://medium.com/immunefi/fei-protocol-flashloan-vulnerability-postmortem-7c5dc001affb
l https://medium.com/immunefi/mushrooms-finance-theft-of-yield-bug-fix-postmortem-16bd6961388f
l https://medium.com/immunefi/enzyme-finance-price-oracle-manipulation-bug-fix-postmortem-4e1f3d4201b5
l https://medium.com/immunefi/hack-analysis-cream-finance-oct-2021-fc222d913fc5
l https://medium.com/immunefi/hack-analysis-bonqdao-february-2023-ef6aab0086d6
V04:2023弱いアクセス制御
概要
アクセス制御メカニズムが弱いため、権限のないユーザーや悪意のある行為者がスマート コントラクト内の重要な機能やデータに権限なくアクセスできるようになります。アクセス制御は、許可されたエンティティのみが特定の機能と対話したり、重要なパラメータを変更したりできるようにするために不可欠です。
説明する
不正アクセスを防ぐには、役割ベースの権限や強力な認証メカニズムなどの適切なアクセス制御手段を実装する必要があります。これらの制約とシステム内のアクターの機能を明確に文書化することは、どの操作が重大な脆弱性の危険にさらされているかを強調するのに役立ちます。この種のドキュメントは、単体テストを改善し、潜在的な競合を特定するのに役立ち、システムが期待どおりに動作することを保証し、重大なバグにつながるチェック漏れのリスクを最小限に抑えます。また、プロジェクトでは、Web2 世界のリスクがシステム全体に回復不能な損害を与えることを防ぐために、ロールに許可されるアクションが可能な限り制限されていることを確認する必要があります。役割が十分に細分化されていない場合、またはプロトコルが集中型セキュリティ モデルに大きく依存している場合、秘密キーの漏洩は信じられないほどの損害を与える可能性があります。
注意事項
注意事項
弱いアクセス制御の脆弱性を防ぐために、開発者はロールベースのアクセス制御メカニズムを実装する必要があります。契約文書で役割とそれに関連する権限を明確に定義します。実証済み、テスト済みのライブラリを使用して、強力な署名検証を実装します。システム要件やユーザーの役割の変更を考慮して、アクセス制御メカニズムを定期的に確認および更新します。
例
Enzyme Finance は、ガソリン スタンド ネットワークと呼ばれる外部コンポーネントと統合されたときに作成された脆弱性を発見した研究者に報酬を与えました。ガソリン スタンド ネットワークは、dApp が個々のユーザーの代わりに取引コストを支払うことを可能にする中継者の分散型ネットワークです。この支払いプログラムには、中継員が使用した金額を返金する信頼できるフォワーダーの検証が欠けています。動画が好きなら、 Sense Finance の50,000 ドルの報奨金支払いに関する分析を見ることをお勧めします。
参考文献:
lhttps://medium.com/immunefi/88mph-function-initialization-bug-fix-postmortem-c3a2282894d3
lhttps://medium.com/immunefi/mushrooms-finance-logic-error-bug-fix-postmortem-780122821621
l https://medium.com/immunefi/alchemix-access-control-bug-fix-debrief-a13d39b9f2e0
l https://medium.com/immunefi/openzeppelin-bug-fix-postmortem-66d8c89ed166
lhttps://medium.com/immunefi/sense-finance-access-control-issue-bugfix-review-32e0c806b1a0
l https://medium.com/immunefi/enzyme-finance-missing-privilege-check-bugfix-review-ddb5e87b8058
V05:2023反復攻撃/署名改ざん
スマートコントラクトの概要
V05:2023反復攻撃/署名改ざん
スマートコントラクトの概要
暗号化はすべてのスマート コントラクト機能の中心です。プロトコルに実装された暗号化プリミティブは通常、オンチェーンで使用されるものと同じであり、許可のない方法で動作します。ただし、これらを誤って使用すると、予想以上に操作が実行され、経済的損失や誤った契約状態が発生する可能性があります。
説明する
リプレイ攻撃は、攻撃者が有効なトランザクションまたはメッセージをコピーして、スマート コントラクトをだまして操作を複数回実行させるときに発生します。 EVM ベースのチェーンは元の ecrecover にアクセスできるため、スマート コントラクトは、特定のデータが回復アドレスによって検証および署名されていることを検証できます。ただし、このネイティブ関数はいかなる形式のリプレイ保護も実装しません。
通常、リプレイ保護は、署名が使用されるときに増加するノンス (1 回使用される数値) を導入することによって実装されます。ノンスが更新されると、元の署名は再度使用できなくなります。署名の展性とは、署名を無効にすることなく変更する能力を指し、署名を 2 回使用できるようにします。データをエンコードしたり、異なるタイプ間で変換したりする場合、署名のチェック時に値の特定の部分またはビットを無視し、そのすべてを使用してリプレイ攻撃を防ぐ機能を導入することができます。
注意事項
リプレイ攻撃や署名改ざんの脆弱性を防ぐために、開発者は非 CE ベースのトランザクション管理を実装する必要があります。 Nonce により各トランザクションが一意であることが保証され、リプレイ攻撃を防ぐことができます。さらに、署名の整合性や信頼性の検証など、適切な署名検証チェックを実装することも、署名改ざん攻撃の防止に役立ちます。契約の設計には、ワンタイム トークンや一意のトランザクション ID など、操作の偶発的な重複を防ぐメカニズムも含める必要があります。
例
Polygon のDouble-Spendバグは、当時の歴史上最高額のバグであり、前のブロックでの書き込みトランザクションの包括性と一意性を検証するために使用されていた Polygon の WithdrawManager のバグが関係していました。エンコードされた BranchMask メソッドを使用すると、複数の一意のブランチ マスクを同じ出口 ID にエンコードできます。この署名の改ざん可能性により、攻撃者はわずか 10 万ドルを預けて署名を再利用することができ、結果として 2,230 万ドルの損失が発生します。
参考文献:
https://medium.com/immunefi/polygon-double-spend-bug-fix-postmortem-2m-bounty-5a1db09db7f1
https://medium.com/immunefi/hack-analysis-nomad-bridge-august-2022-5aa63d53814a
https://medium.com/immunefi/hack-analysis-binance-bridge-october-2022-2876d39247c1
V06:2023エラー
概要
浮動小数点演算や丸め誤差を不適切に処理すると、財務上の不一致や契約ロジックが悪用される可能性があります。このような脆弱性を回避するには、数値演算を正確に処理する (該当する場合は固定小数点演算を使用する) ことが重要です。通常、これらの脆弱性はパーミッションレス交換プロトコルで発生する可能性があり、標準以外の 10 進数値が予期せぬ結果をもたらす可能性があります。
概要
浮動小数点演算や丸め誤差を不適切に処理すると、財務上の不一致や契約ロジックが悪用される可能性があります。このような脆弱性を回避するには、数値演算を正確に処理する (該当する場合は固定小数点演算を使用する) ことが重要です。通常、これらの脆弱性はパーミッションレス交換プロトコルで発生する可能性があり、標準以外の 10 進数値が予期せぬ結果をもたらす可能性があります。
説明する
丸めエラーは、スマート コントラクトが精度や丸めを考慮せずに浮動小数点演算を含む計算を実行すると発生します。これらのエラーは、財務上の不一致、資金の損失、または契約内で計算された報酬の誤りにつながる可能性があります。スマート コントラクトは、固定小数点演算またはその他のメカニズムを使用して小数計算を正確に処理し、丸め誤差が最小限に抑えられるか排除されるようにする必要があります。
注意事項
丸めエラーを防ぐために、開発者は、正確な数値操作を提供する固定小数点演算またはライブラリを使用する必要があります。固定小数点演算では整数値を使用して分数を表現し、浮動小数点演算の不正確さを回避します。さらに、境界条件やコーナーケースを含む数値演算の徹底的なテストと検証は、潜在的な丸め誤差を特定して解決するのに役立ちます。
例
特に、 DFX Finance は、EURS トークンの非標準 10 進数値 2 によって引き起こされる丸め誤差によって引き起こされる脆弱性を以前に修正していました。すべての資産が USDC とペアになっているため、アシミレーターは DFX Finance の自動マーケット メーカーにとって不可欠です。 AssimilatorV2 コントラクトは、すべての金額を数値、つまりプロトコル全体の計算に使用される基本値に変換する責任を負います。この問題は、ユーザーがカーブ プールの自分の部分を表すカーブ トークンを受け取るにもかかわらず、整数の除算の結果、ユーザーによって転送されたトークンがゼロになる場合に発生します。
参考文献:
l https://medium.com/immunefi/dfx-finance-rounding-error-bugfix-review-17ba5ffb4114
V07:2023 再入可能
概要
イーサリアムにおけるリエントランシーには長い歴史があり、2016 年にはイーサリアムの初期ネットワークに対する最大規模の攻撃の 1 つである「DAO ハック」がこのタイプの脆弱性によって引き起こされました。再入可能により、攻撃者は前の呼び出しが完了する前に脆弱なコントラクトを繰り返し呼び出すことができ、その結果、予期しない状態変化や不正な資金移動が発生します。
説明する
再入可能性の脆弱性は、コントラクトが状態の変更と実行フローを適切に管理せずに、実行中に外部呼び出しを許可している場合に発生します。再入可能により、攻撃者は前の呼び出しが完了する前に脆弱なコントラクトを繰り返し呼び出すことができ、その結果、予期しない状態変化や不正な資金移動が発生します。安全な状態管理パターンを実装し、ミューテックスを適用すると、再入攻撃のリスクが軽減されます。コントラクト内のリエントラントの可能性を特定するのに役立つツールには、 Slither 、 Mythril 、およびPyrometer などがあります。再入可能について詳しくは、この記事「再入可能に関する究極のガイド」を参照してください。
防止
再入可能性の脆弱性を防ぐために、開発者は「Check-Influence-Interact」(CEI) パターンなどのセキュリティ状態管理パターンに従う必要があります。このパターンでは、外部呼び出しが行われる前にすべての状態変更が確実に行われるため、再入攻撃が防止されます。さらに、ミューテックスを実装するか、「 ReentrancyGuard 」パターンを使用すると、再入呼び出しをブロックすることで再入をさらに防止できます。
例
オムニ プロトコルがハッキングされ、そのイーサリアム スマート コントラクトがリエントラント攻撃を受け、140 万ドルを失いました。脆弱なコードは、ERC721 のsafeTransferFrom メソッドを使用し、onERC721Received インターフェイスを実装するスマート コントラクトを呼び出します。このような外部呼び出しは受信者に実行を引き渡し、再入可能性の脆弱性をもたらします。
参考文献:
https://medium.com/immunefi/hack-analysis-omni-protocol-july-2022-2d35091a0109
V08:2023 フロントランニング
概要
フロントランニングは、攻撃者が保留中のトランザクションを観察してからブロックに含めるまでの時間遅延を悪用する手法です。攻撃者は、自分自身のトランザクションを、より高いガス価格での被害者のトランザクションよりも先に配置することで、特定の契約のやり取りの結果を自分の利益になるように操作することができます。分散型取引所、オークション、またはトランザクションの順序が重要なシナリオでは、フロントランニングが懸念事項となります。
説明
フロントランニングは、攻撃者がトランザクションを先制して実行することで有利になる場合、特にブロックに含まれる保留中のトランザクションを知っている場合に発生します。スマート コントラクトの場合、トランザクションの順序が結果に影響を与える状況では、フロントランニングが有害となる可能性があります。たとえば、分散型取引所では、攻撃者は、被害者が特定のトークンを特定の価格で購入しようとする保留中のトランザクションを観察する可能性があります。その後、被害者のトランザクションが実行される前に、自分のトランザクションを迅速に送信して、より高いガス価格でより低い価格で同じトークンを購入できます。このようにして、攻撃者は価格差から利益を得ますが、被害者はその代価を支払います。フロントランニングは、mempool を観察している誰でも実行できますが、ブロックプロデューサー自身が実行することもできます。一部のチェーンにはリスクを軽減するプライベート RPC がありますが、プライベート メンプール内のバリデーターとブロックプロデューサーも誤った信頼仮定を作成する可能性があります。開発者は、プロトコルを保護するための信頼や一貫したインセンティブに部分的に依存する外部の緩和策に頼るのではなく、スマートコントラクトレベルで潜在的な最前線の機会を減らす必要があります。
防止
空振り防止には技術と設計を総合的に考慮する必要があります。いくつかの予防策には、秘密保持またはコミット開示スキームの使用、取引が確認されるまで価格や入札などの機密情報を秘密にするスキームの実装、オフチェーンの注文照合、フラッシュボット（ユーザーが取引をまとめてマイナーに直接送信できるようにする）を使用して最前線で入札される可能性を減らすこと、手数料を最適化して最前線で入札される可能性を減らすことが含まれます。
例
例
フロントラン攻撃はさまざまな DeFi プロトコルで発見されています。 RocketPool と Lido は、両方のベッティング サービスに影響を与える可能性のある脆弱性について通知されました。悪意のあるノードオペレーターは、同じバリデータ bls キーを使用して、事前に準備されたデポジットデータと最低限必要なデポジット値を使用してデポジットを実行することにより、ユーザーのデポジットを盗む可能性があります。
参考文献:
https://medium.com/immunefi/rocketpool-lido-frontrunning-bug-fix-postmortem-e701f26d7971
V09:2023初期化されていないプロキシ サーバー
概要
適切に初期化せずにプロキシ コントラクトを使用すると、初期化されていないストレージ変数が攻撃者によって操作される可能性があるため、脆弱性が発生する可能性があります。安全なプロキシ パターンを実装し、徹底的な初期化チェックを実行することは、初期化されていないコントラクト状態への不正アクセスを防ぐために重要です。初期化されていないプロキシの脆弱性により、これまでに最大 1,000 万ドルの報奨金が支払われています。
説明する
初期化されていないプロキシ コントラクトとは、プロキシ コントラクトの状態変数が使用前に適切に初期化されていないことです。初期化されていないストレージ変数には機密データが含まれたり、重要なコントラクト動作を制御したりする可能性があるため、これによりセキュリティ ホールが発生します。攻撃者は、初期化されていないストレージ変数を操作することでこれらの脆弱性を悪用し、不正アクセスを取得したり、予期しないアクションを実行したりする可能性があります。このリスクを軽減するには、実稼働環境で使用する前にプロキシ コントラクトが適切に初期化されていることを確認する必要があります。
注意事項
初期化されていないプロキシの脆弱性を防ぐために、開発者は、プロキシを展開して使用する前に、プロキシ コントラクトに格納されているすべての変数が適切に初期化されていることを確認する必要があります。これには、機密データ、アクセス制御権限、その他の重要な状態変数の初期化が含まれます。開発者は、プロキシ コントラクト内に包括的な初期化チェックを実装して、必要なすべての変数と依存関係が適切に初期化されていることを確認する必要もあります。開発者は、正しい初期化を二次的に検証するための監視ツールも実装する必要があります。これは、自動化されたスクリプトまたはトランザクション バンドルによってデプロイメント後に呼び出されるコンストラクターまたは初期化関数を通じて実現できます。
例
ワームホールの初期化されていないプロキシの脆弱性レポートには、これまでの歴史の中で最高の報奨金がかけられています。レポートを提出したホワイト ハットには 1,000 万ドルの報奨金が支払われました。 UUPS プロキシ コントラクトを展開する場合、「コンストラクター」は実装内に存在する通常の Solidity 関数です。この実装では、所有者を初期化する initialize() 関数が提供されます。ワームホールは、実装する実装コントラクトを初期化しません。これにより、攻撃者が実装の制御を取得してコントラクトを自己破壊することが可能になり、プロキシ コントラクトが指すロジックが存在しなくなるため、プロキシ コントラクトが実行されなくなります。
参考文献:
https://blog.openzeppelin.com/the-transparent-proxy-pattern
https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades
https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades
https://medium.com/immunefi/harvest-finance-uninitialized-proxies-bug-fix-postmortem-ea5c0f7af96b
https://medium.com/immunefi/wormhole-uninitialized-proxy-bugfix-review-90250c41a43a
V10:2023ガバナンス攻撃 (ガバナンス攻撃)
概要
ガバナンス攻撃とは、分散型プロトコルまたはスマート コントラクト システムのガバナンス メカニズムを操作または悪用することを指します。これらの攻撃は、意思決定プロセス、投票システム、またはガバナンス システムのパラメータ調整を混乱させ、攻撃者がプロトコルから不当な制御や利益を得られるようにすることを目的としています。
説明する
ガバナンス攻撃には、定足数を満たさない提案の実行を許可すること、投票ステップなしで提案の実行を許可すること、または他の参加者の投票を直接操作することなど、さまざまな形があります。これらの攻撃は、プロトコルの分散型の性質を損ない、権力の集中を引き起こしたり、攻撃者に経済的利益をもたらしたりする可能性があります。ガバナンス攻撃は、意思決定権限がトークン所有者間に分散されている分散型自律組織 (DAO) に特に関連します。
注意事項
ガバナンス攻撃を防ぐには、意思決定プロセス、投票メカニズム、関与規則を概説する、強力で明確に定義された透明性のあるガバナンスの枠組みを構築することが不可欠です。安全で改ざん防止された投票システムを実装して、投票の整合性を確保します。これには、セキュリティを強化するための暗号化、ゼロ知識証明、または複数署名スキームの使用が含まれる場合があります。トークンの公平かつ分散的な配布を確保し、少数の団体の手に投票権が集中することを回避します。短期的な操作を阻止するために、トークンの権利確定やロックアップ期間などのメカニズムを検討してください。悪意のある攻撃者が提案を全会一致で可決するのに十分なトークンを取得しないように、ほとんどのガバナンス トークンが異なる取引所に分散していないことを確認します。
例
ガバナンス攻撃の注目すべき例は、許可のない FIAT ステーブルコイン プロトコルBeanstalkに対する攻撃です。ハッカーは、BIP18 と BIP19 という 2 つの Beanstalk 改善提案を提出しました。最初の提案は攻撃者に全額を送金するというもので、2番目の提案は25万ドル相当のBEANトークンをウクライナの公式仮想通貨寄付アドレスに送るというものだった。攻撃者は、Aave、Uniswap、SushiSwap から 10 億ドル以上をフラッシュローンして、緊急ガバナンス施行を発動するのに十分な議決権 (少なくとも 2/3 過半数) を獲得しました。
参考文献:
https://medium.com/immunefi/hack-analysis-beanstalk-governance-攻撃-april-2022-f42788fc821e
結論は
スマート コントラクトが進化し続け、広く採用されるようになるにつれて、開発者と監査人が最新の脆弱性とセキュリティのベスト プラクティスを常に把握しておくことが不可欠です。これらのトップ 10 のスマート コントラクトの脆弱性に対処することで、関係者はスマート コントラクトのセキュリティ体制を強化し、ブロックチェーン ベースのシステム全体の信頼性と信頼性を向上させることができます。
全てのコメント