DeFiセキュリティレッスン:一般的なセキュリティの脆弱性と注意事項

最近、あるセキュリティ専門家が分散型金融のセキュリティに関する内容を共有し、過去1年以上のWeb3業界の重大なセキュリティ事件を振り返り、これらの事件が発生した理由とその回避方法を探り、一般的なスマートコントラクトのセキュリティ脆弱性と予防策をまとめ、プロジェクト側とユーザーに対していくつかのセキュリティに関するアドバイスを提供しました。

一般的な分散型金融の脆弱性の種類には、フラッシュローン、価格操作、関数権限の問題、任意の外部呼び出し、フォールバック関数の問題、ビジネスロジックの脆弱性、秘密鍵の漏洩、再入攻撃などがあります。本稿では、フラッシュローン、価格操作、再入攻撃の3種類に重点を置いて紹介します。

フラッシュローン

フラッシュローン自体は分散型金融の一種の革新ですが、ハッカーがそれを利用する場合、彼らは費用をかけることなくお金を借りることができ、アービトラージのプロセス全体を完了した後に返済します。残りの部分がアービトラージの利益であり、彼らは少量のガス料金を支払うだけで巨額の利益を得ることができます。

一般的な攻撃はしばしばフラッシュローンを伴い、攻撃者はフラッシュローンを通じて大量の資金を借り入れ、価格を操作したり、ビジネスロジックを攻撃したりすることを好みます。開発者は、契約の機能が巨額の資金によって異常になるか、巨額の資金を用いて一回の取引で契約内の複数の関数と相互作用して報酬を得るシナリオを考慮する必要があります。

契約の中でいくつかのトークンの数値が報酬計算に使用されたり、DEXの取引ペアにおけるトークンの数がさまざまな計算に参加するのをよく見かけますが、開発者がこれらの機能を設計する際に、攻撃者がフラッシュローンを利用してこれらの変数を操作できることを考慮していなかったため、契約の資金が盗まれる結果となりました。

過去2年間、フラッシュローンには多くの問題が発生しました。多くの分散型金融プロジェクトは高い利益を見込めるように見えますが、実際にはプロジェクトチームのレベルはまちまちです。例えば、コードは購入されたものである可能性があり、コード自体に脆弱性がなくても、論理的に問題が存在する可能性があります。例えば、あるプロジェクトでは、特定の時間に保有者が持っているトークンの数量に基づいて報酬を発放することがありましたが、攻撃者がフラッシュローンを利用して大量のトークンを購入し、報酬が発放されるときに大部分の報酬が攻撃者に流れてしまいました。さらに、トークンを使って価格を計算するプロジェクトもあり、フラッシュローンを使って価格に影響を与えることができます。プロジェクトチームはこれらの問題に対して警戒を強めるべきです。

価格操作

価格操作の問題はフラッシュローンと密接に関係しており、この問題は主に価格計算時にいくつかのパラメータがユーザーによって制御されることに起因しています。よく見られる問題のタイプは2つあります。

• 一つは、価格を計算する際に第三者のデータを使用しますが、使用方法が不適切またはチェックが欠如しているために、価格が悪意を持って操作されることです。
• 別の種類は、いくつかのアドレスのトークン数を計算変数として使用しているため、これらのアドレスのトークン残高が一時的に増減する可能性があることです。

リエントランシー攻撃

外部コントラクトを呼び出すことの主な危険の一つは、制御フローを引き継ぎ、データに対して予期しない関数呼び出しを行う変更を加えることができるということです。

ユーザーの残高が関数の最後まで0に設定されないため、2回目の(およびそれ以降の)の呼び出しは成功し続け、残高を何度も引き出すことができます。

異なる契約に対して、再入の存在方法は多岐にわたります。契約の異なる関数や複数の異なる契約の関数を組み合わせて、再入攻撃を行うことができます。そのため、再入問題を解決する際には、以下の点に注意する必要があります。

1. 単一の関数の再入問題を防ぐだけではない;
2. エンコードについては、Checks-Effects-Interactions パターンに従います。
3. 時間が検証された再入防止モディファイアを使用する。

実際に最も恐れているのは、同じことを繰り返して行うことであり、必要なものをすべて自分で書かなければならないことです。この業界には多くのベストなセキュリティプラクティスがあり、それを利用すれば良いのです。完全に同じことを繰り返す必要はありません。あなたが車輪を作るとき、それは十分に検証されていない状態であり、そのときに問題が発生する確率は、非常に成熟した、長年の経験を持つものを使用する場合の問題が発生する確率よりも明らかに大きいのです。

Omni Protocolの脆弱性の背後にある話---4人のハッカー間の競争

イーサリアムのmempoolは大量のハッカーに監視され続けており、彼らは絶えず取引を分析し、利益を得るために有利な取引を先に行っています。Omni Protocolの脆弱性を発見した者が提出した攻撃取引は、2人のハッカーによって捕らえられ、彼らはフラッシュボットでの先行取引を利用してOmni Protocolプロトコルから1200 ETHを奪取しましたが、脆弱性を発見した攻撃者はわずか480 ETHしか得られませんでした。この間、別のハッカーがフラッシュボットに提出された先行取引を発見し、その取引がDoodle ERC20トークンを購入する必要があるという特徴を利用して、サンドイッチ攻撃を行い151 ETHの利益を得ました。

バグを発見した人が得られる利益は最も多くはなく、利益を得るのは暗い森の中の他のハンターです。このエコシステムにはハンターが至る所にいます。ハンター同士が互いに獲物になり得るため、攻撃を仕掛けた者であっても、新人であればこのプロジェクトの大部分のお金を持ち去ることはできません。たとえ一度に持ち去る場合でもです。また、多くの人がより高いガス代を支払って取引を優先的に実行し、急いでいる過程でDEXでのトークンの売買が関与する場合、サンドイッチ攻撃を受ける可能性があり、非常に混乱しています。

セキュリティ提案

最後はプロジェクト側と一般参加者への安全に関するアドバイスです。

プロジェクト側の安全に関するヒント

一、契約開発はベストセキュリティプラクティスに従います。

二、契約のアップグレードと一時停止: 多くの攻撃は一度にすべてのコインを移動させるのではなく、複数の取引に分けて実行されます。もし比較的健全な監視メカニズムがあれば、それを発見することができます。発見した後、契約が一時停止できると仮定すれば、損失を効果的に減少させることができます。

三、タイムロックの採用: いくつかのケースのように、タイムロックがある場合、例えば48時間以内に完了する必要があると仮定します。この時、タイムロックの間に多くの人がこの作成者が新しいミントの方法を再更新したことに気づき、誰でも使用できることを監視している人がプロジェクトがハッキングされたことを知ることができます。そして、プロジェクトチームに変更を通知することができます。仮に通知しても誰も気にしない場合でも、少なくとも自分の分のお金を引き出して、自分の利益が損なわれないことを保証することができます。したがって、プロジェクトにタイムロックがない場合、理論的には問題が発生する確率が増加します。

四、安全投資を強化し、完璧な安全システムを確立する: 安全は一点ではなく、一線でもなく、体系的なものです。プロジェクト側として、契約が複数の会社に監査されれば問題ないと思わないでください。結果としてハッカーが秘密鍵を盗んだ場合、たとえそれがマルチシグであっても、複数の秘密鍵をすべて盗まれる可能性があります。あるいは、経済モデルに問題があったり、ビジネスモデルに問題があったりすることもあります......お金が失われる方法は無数にあり、事前に安全リスクを全て回避できるかどうかが重要です。リスクモデリングをできるだけ行い、大部分のリスクを段階的に回避し、残ったリスクは受け入れ可能なリスクであり、許容範囲内にあるべきです。安全と効率は両立することは不可能であり、ある程度の妥協が必要です。しかし、安全を完全に無視し、安全に投資しない場合、攻撃を受けるのは非常に正常なことです。

五、全従業員のセキュリティ意識を高める: セキュリティ意識を高めるためには、特別な技術は必要ありません。Twitterでは多くの人がフィッシングによってNFTを失っているのをよく見かけますが、フィッシングの手口は人間の弱点を利用しているのです。少し注意を払えば、引っかからずに済むかもしれません。Web3という大環境の中では、少しだけ「なぜ？」と問いかけ、少しだけ考えることで、多くの問題を回避できます。

六、内部の悪行を防ぎ、効率を高めながらリスク管理を強化する: いくつかの事例を挙げて説明します。第一に、契約のオーナーはマルチシグではなくシングルシグであり、私鍵を失うとプロジェクト全体が制御されてしまいます。第二に、タイムロックを使用せず、重要な操作の更新がすぐに行われ、誰も知らない状態になり、全体のプロトコル参加者にとって非常に不公平です。さらに内部の悪行についても、内部のセキュリティメカニズムが何の役にも立っていないということです。

ブロックチェーン上のプロトコルは、効率を保証しながら、安全性も一定程度向上させるにはどうすればよいか？特定の人が特定の操作を実行することを指定することができるセキュリティツールがあります。例えば、三分の二のマルチシグを指定することができます。また、特定のアドレスが特定の操作を行うことを許可することもできます。例えば、非常に信頼できるノードに対して安全リスク監視を行うことができます。仮にプロトコルが攻撃を受けていることを発見し、資金が徐々にハッカーのアドレスに移動している場合、その契約自体に一時停止機能があれば、その機能を特定の人に付与することで、彼はその操作を行うことができます。

例えば、DEXのマーケットメイカーに関して、オーナー権限を制限しない場合、オーナーはお金を他のアドレスに移動させることができ、送金先のアドレスを制限し、特定の通貨ペアのみを操作できるように制限し、特定のアドレスにのみお金を引き出せるように設定できます。効率を向上させると同時に、一定の安全性を確保しています。

七、三者の導入の安全性: エコシステムの一環として、プロジェクト側には独自の上下流があります。安全性に関しては「デフォルトで上下流は安全ではない」という原則があります。上流に対しても下流に対しても、検証を行う必要があります。三者に対しては、我々が制御することは非常に難しく、安全リスクのエクスポージャーは実際には非常に大きいため、三者の導入には注意が必要です。契約はオープンソースであり、導入や呼び出しが可能ですが、契約がオープンソースでない場合は絶対に引用してはいけません。なぜなら、内部のロジックが何であるかがわからず、またこの契約そのものがアップグレード可能な契約である可能性があるからです。通常の使用では問題がないかもしれませんが、突然ある日、悪用される契約にアップグレードされるかもしれないということを予測することはできず、これは制御不可能です。

ユーザー/LP はどのようにスマートコントラクトの安全性を判断しますか?

一般のユーザーにとって、私たちはプロジェクトが安全かどうかを判断する際に主に以下の6点を見ます:

一、契約はオープンソースですか: オープンソースでないプロジェクトは絶対に手を出しません。なぜなら、契約に何が書かれているのか全くわからないからです。

二、Ownerはマルチシグを採用していますか？マルチシグは分散型ですか？: マルチシグを使用しない場合、プロジェクトのビジネスロジックや内容を判断できません。一旦セキュリティ事件が発生した場合、ハッカーによるものかどうかを判断できません。たとえマルチシグを採用しても、そのマルチシグが分散型であるかどうかを判断する必要があります。

三、契約の既存の取引状況: 特に市場には多くのフィッシング詐欺プロジェクトが存在し、比較的類似した契約を作成する可能性があります。この場合、契約のデプロイ時間やインタラクション回数などを確認する必要があります。これらは契約が安全かどうかを判断する基準です。

四、契約は代理契約ですか、アップグレード可能ですか、タイムロックはありますか: もし契約が完全にアップグレードできないのであれば、非常に硬直したものになってしまいます。そのため、プロジェクトの契約はアップグレード可能であることをお勧めします。しかし、アップグレードには方法が必要です。アップグレード内容や重要なパラメータの変更がある場合には、タイムロックを設け、ユーザーが実際のアップグレードが有害か有益かを判断するための時間ウィンドウを提供する必要があります。これは公開透明な方法の一つでもあります。

五、契約は複数の機関による監査を受けていますか(監査会社を盲目的に信頼しない), Ownerの権限は過大ではありませんか: まず、一つの監査会社だけを信じてはいけません。なぜなら、異なる監査会社、異なる監査員は、問題を見る角度が異なるからです。もしあるプロジェクトが複数の機関の監査結果を持ち、異なる問題が発見され、プロジェクト側がそれらを修正した場合、単一の監査会社による監査よりも安全です。責任あるプロジェクト側は、複数の監査機関に交差監査を依頼します。

次に、Ownerの権限が過大でないかを確認する必要があります。例えば、一部の貔恘盤プロジェクトでは、Ownerがユーザーの資金を完全に管理できます。トークンの購入が少ない場合は正常に売買できますが、大量に購入した場合、Ownerはすぐに資金をロックして取引できなくすることができます。また、NFTプロジェクトにも同様のことが言えます。正常なプロジェクトでは、Ownerの権限は制御可能であり、これにより危険な操作があまり行われず、操作は時間ロックの方法で行われ、ユーザーに操作内容が通知されます。特に市場が悪い時には、さまざまな詐欺プロジェクトが存在するため、皆さんはOwnerの権限を重要視する必要があります。

六、注意オラクル: 市場の主要なオラクルを使用するプロジェクトは基本的に大きな問題はないが、自前のオラクルを使用する場合や、適当にトークンを担保にして入れることができる場合は注意が必要である。