ハッカーは「第一原則」に立ち返る、カーブ危機は普通の攻撃ではない

原作者: Jaleel、BlockBeats

オリジナル編集者: Jack、BlockBeats

脆弱性悪用事件の発生により、DeFi業界は大混乱に陥った。 DeFi業界の巨人であるCurve Financeが深刻な「攻撃」の標的となり、alETH/msETH/pETHなどの複数のステーブルコインプールが危険にさらされている。不完全な統計によると、この脆弱性悪用事件により、Alchemix、JPEG'd、MetronomeDAO、deBridge、Ellipsis、CRV/ETH のプールで合計 5,200 万米ドルの損失が発生し、市場全体の信頼が大きく揺らぎました。

Vyper 0.2.15、0.2.16、0.3.0 バージョンのリエントリ ロックは無効であり、Vyper 公式ドキュメントのインストール インターフェイスでは間違ったバージョンが推奨されています。 Vyperコンパイラーを使用している他のプロジェクト関係者も、次の被害者にならないよう、自己調査の実施を急いでいる。脆弱性悪用事件の原因が徐々に明らかになり、市場はこの危機が通常のハッカー悪用事件を意味するだけでなく、基礎となるスタック全体の潜在的な巨大リスクがDeFi業界全体に及ぶことを徐々に明らかにしていることに気づきました。

過去と比較すると、前期のハッキング事件の数はますます減少しており、これは市場の繁栄と切り離せないものとなっています。 DeFiの夏とNFTの夏には、今日の市場が非常に縮小しているのに比べて、毎週新しい10億ドル規模の契約が開始されました。同時に、ハッカーがエクスプロイトを発見したり、大規模な攻撃を作成したりできる市場の機会は徐々に縮小しており、これはハッカーが探索するために、より新しい未開発のエントリーポイントを必要としていることを意味します。

「第一原理」に立ち返ったハッカーは、DeFi市場で巨大でおいしい「ケーキ」を食べるための下位レベルのコンパイラーに完璧なエントリーポイントを見つけました。下位レベルのコンパイラーはより「賢い」ハッカーになりました。選択。 BlockBeats は、この事件とそれによって明らかになった関連問題について、スマート コントラクト開発者の Box (@BoxMrChen) と BTX 研究者の Derek (@begas_btxcap) にインタビューしました。

Curve イベントはどのようにして発生しますか?

AaveとLensの創設者であるスタニ（@StaniKulechov）氏はソーシャルメディアでこの事件についての見解を表明し、「これはCurveとDeFiにとって不幸な挫折だ。DeFiは貢献できるオープンスペースではあるが、絶対に正しくする必要がある」と述べた。 」

Curve が被害に遭ったエクスプロイトは、イーサリアム スマート コントラクトに対する最も古く、おそらく最も一般的な攻撃形式の 1 つであるリエントラント攻撃です。再入攻撃により、攻撃者は、その関数に対する前回の呼び出しが完了するのを待たずに、スマート コントラクトの関数を繰り返し呼び出すことができます。このようにして、被害者契約の資金がなくなるまで、抜け穴を利用して資金を引き出し続けることができます。

リエントラントロックと CEI 原則

リエントリー攻撃を説明する簡単な例を挙げてください。銀行には合計 100,000 の現金があります。しかし、この銀行には大きな抜け穴があり、人々がお金を引き出すたびに、銀行員は口座残高をすぐに更新せず、その日の終わりまで待ってチェックして更新します。このとき、誰かがこの抜け穴を発見し、銀行に口座を開設し、最初に1,000元を入金し、次に1,000元を引き出し、5分後に1,000元を引き出しました。銀行は残高をリアルタイムで更新しないため、システムはチェックして更新する前に彼の口座にまだ 1,000 元があると判断します。繰り返しの操作により、ユーザーは最終的に銀行にある現金 10 万ドルをすべて引き出しました。その日の終わりまで、銀行は抜け穴が悪用されたことに気づきませんでした。

リエントランシー攻撃の複雑さは、コントラクト間の相互呼び出しとコントラクト自体の論理の抜け穴を利用し、例外やロールバック機能を意図的にトリガーすることで不正な動作を実現するという事実にあります。攻撃者は契約の論理の抜け穴を繰り返し悪用して資金を盗む可能性があります。リエントリー攻撃を防ぐ対策としては、あらかじめ対象となる特殊なコード内容を設定して保護し、資金の安全性を確保する仕組みが一般的であり、これをリエントリーロックと呼びます。

Solidity は、スマート コントラクト プログラミングに「CEI 原則」 (Check Effects Interactions) を設定し、再入攻撃から機能を十分に保護します。 CEI 原則の内容は次のとおりです。

1. 関数コンポーネントの呼び出し順序は、最初に検査、2 番目に状態変数への影響、最後に外部エンティティとの対話である必要があります。

2. 外部エンティティと対話する前に、すべての状態変数を更新する必要があります。これは「楽観的簿記」と呼ばれるもので、相互作用が実際に起こる前に効果が記録されます。

3. 関数の先頭でチェックを行って、呼び出し側エンティティに関数を呼び出す権限があるかどうかを確認する必要があります。

4. 再入攻撃を防ぐために、外部呼び出しの前に状態変数を更新する必要があります。

5. 信頼できる外部エンティティであっても、制御フローを悪意のある第三者に転送する可能性があるため、CEI パターンに従う必要があります。

ドキュメントによると、CEI 原則は契約の攻撃対象領域を制限し、特に再入攻撃を防止するのに役立ちます。 CEI 原則は、ロジックを変更することなく、主に機能コードの順序で簡単に適用できます。イーサリアムのフォークにつながったDAOの有名なエクスプロイトでも「CEI原則」が無視され、攻撃者は再突入攻撃を達成し、壊滅的な結果を引き起こしました。

しかし、攻撃された Curve プールは、Curve が Vyper コンパイラを使用していたため、この CEI 原則に従っていませんでした。 Vyper コードのコンパイラの脆弱性により、リエントランシー ロックが失敗し、ハッカーのリエントランシー攻撃が成功してしまいます。

Solidity はほとんどの人が知っていますが、Solidity はスマート コントラクトを作成するための唯一の言語ではなく、Solidity に代わる一般的な言語は Vyper です。 Vyper は Solidity ほど強力でも人気でもありませんが、Python に似たコードを Ethereum スマート コントラクト プログラミング言語に変換できるため、Python に精通している開発者にとっては理想的です。

github 情報によると、Vyper の github コード ベースに最初に貢献した開発者は Curve の開発者でもあります。 Curve が Solidity ではなく Vyper を使用する理由を説明するのは難しくありません。

![ハッカーは「第一原則」に立ち返る、Curve 危機は通常の攻撃ではない] (https://img-cdn.gateio.im/resize-social/moments-7f230462a9-a62a0336fd-dd1a6f-1c6801)

Vyper の再入ロックが失敗するのはなぜですか?

では、この攻撃において、Vyper には何が問題なのでしょうか?リエントリーロックが失敗するのはなぜですか?試験がないからでしょうか？ BlockBeats はスマート コントラクト開発者の Box 826.eth (@BoxMrChen) にインタビューしました。彼によると、Vyper リエントラント ロックはユースケースでテストされているとのことです。しかし、失敗の理由は、テスト ケースが結果指向であること、つまりテスト ケースも間違っていることです。

つまり、Vyperのリエントランシーロックが失敗する最大の理由は、テストケースを書いた人が、なぜスロットが不可解に1スキップするのかを考えずに、結果に基づいてテストケースを書いてしまったことです。

![ハッカーは「第一原則」に立ち返る、Curve 危機は通常の攻撃ではない] (https://img-cdn.gateio.im/resize-social/moments-7f230462a9-bc03f536dd-dd1a6f-1c6801)

Box が共有する Vyper コードの次の段落では、問題がはっきりとわかります。ロック名が 2 回目に表示されると、storage_slot の番号が上書きされます。つまり、ret では、最初にロックを取得したスロットは 0 ですが、関数がロックを再度使用すると、ロック用のスロットが 1 つ追加されます。コンパイル後、間違ったスロットが使用されるため、リエントラント ロックが有効になりません。

![ハッカーは「第一原則」に立ち返る、Curve 危機は通常の攻撃ではない] (https://img-cdn.gateio.im/resize-social/moments-7f230462a9-dfdeb7079d-dd1a6f-1c6801)

左が攻撃されたコード、右が修復されたコード

「間違ったテスト結果が予想されますが、もちろんエラーは検証できません。簡単な例を挙げると、今、1+1=2という計算問題をやっているのですが、与えられた標準的な答えは間違っており、1+1=3ということになります。」そして、この問題をしていたクラスメイトが間違った答えを出し、1+1=3と答えましたが、それは事前に与えられた標準的な答えと同じでしたので、プログラムには当然テスト結果が正しいかどうかを判断する方法がありませんでした。間違っています」とボックス氏はBlockBeatsのインタビューで語った。

2年間の絞首刑「ダモクレスの剣」

歴史上初めて記録されたリエントランシー攻撃事件では、WETH Attack の攻撃者はまさにホワイトハッカーであり、開発者にリエントランシー攻撃に注意を払わせるために意図的に攻撃を作成し、より多くのプロジェクトをリエントランシー攻撃の可能性から免れることを目的としています。スマート コントラクトのコンテキストでは、開発者は、保護を実現するために状態変更関数を呼び出すなど、さまざまなトリガー メカニズムを使用する必要があります。このため、開発者は契約を設計する際に起こり得る攻撃シナリオを十分に考慮し、適切な予防措置を講じる必要があります。

Vyper エディターを深く理解するために、BlockBeats は BTX 研究者のデレク (@begas_btxcap) にインタビューしました。彼は、Python に精通した開発者にとって、より快適な UI インターフェイスを備えた Vyper は Solidity よりも理想的な選択肢であると述べました。そしてより速い学習。しかし、どうやら、Vyper エディターのコードの一部のバージョンは、信頼できる第三者による監査を受けていないようです。一部の監査作業も開発者自身が行う場合があります。 「従来の IT 業界ではこのようなことは起こりません。新しい言語が登場すると、抜け穴を探す監査会社が無数に現れるからです。」

言うまでもなく、バグを 2 年間公然と存在させることになります。

Vyper の寄稿者 fubuloubu 氏も次のように述べています: コンパイラーは誰もが思っているほどレビューも監査もされていません。ほとんどのコンパイラには大幅な変更が頻繁に行われるため、監査が不利になります。完全なコードベース監査を行ったとしても、その後バージョンが追加されるにつれて、コードベースは古くなっていきます。コンパイラを監査することは得策ではありません。エンド ユーザーがツールを使用して生成した最終製品 (つまり、生の EVM コード) を監査する方が合理的だからです。

これらはすべて、モチベーションという最後の問題を示しています。とはいえ、コンパイラ、特に古いバージョンの重大なバグを見つけようとする動機は誰にもありません。 fubuloubu氏は以前、ユーザー協賛の報奨金プログラムを追加することでVyperの改善に貢献する提案をしたが、通らなかった。

ハッカーは「第一原則」に立ち返る

これは、プロトコルとプロジェクトの開発者にとってコントラクトセーフな開発実践のもう 1 つの生きた例です。しかし最も重要なことは、Curve 事件は、基礎となるコンパイラのセキュリティが深刻に無視されており、「第一原理」に立ち返ったハッカーが下位コンパイラで完璧な原理を見つけ出したという警告を私たち全員に与えたことです。

その後、Aave と Lens の創設者である Stani (@StaniKulechov) もソーシャル メディアに長い記事を投稿して自身の感情を表現しました: Curve への攻撃は、DeFi のリスクが常に基盤となるスタック、プログラミング言語、EVM 全体に関与していることを意味します、など。これは、特に将来カスタム EVM やアプリケーション チェーンを使用する場合には、より慎重かつ慎重になるよう警告します。

![ハッカーは「第一原則」に立ち返る、Curve 危機は通常の攻撃ではない] (https://img-cdn.gateio.im/resize-social/moments-7f230462a9-f4018e7eac-dd1a6f-1c6801)

下位レベルからの攻撃

コンパイラの脆弱性は、契約ソースコードのロジックを監査するだけでは発見することが困難です。バージョンとバージョンの違いを調査するだけでも大仕事です。スマート コントラクトがコンパイラの脆弱性の影響を受けるかどうかを判断するには、特定のコンパイラ バージョンと特定のコード パターンを組み合わせる必要があります。

「現時点で最良のコンパイラは 2 つだけです。Vyper のコード ベースはより小さく、読みやすく、履歴を分析するための変更が少ないです。これがおそらくハッカーがここから始める理由です。Solidity のコード ベースはもう少し大きいです。」fubuloubu は、次のように述べているとさえ疑っています。この Curve 攻撃には支援を受けたハッカーが関与している可能性があります。「脆弱性を発見するには数週間から数か月かかりますが、投資されたリソースを考慮すると、小規模なグループまたはチームによって実行される可能性があります。」

暗号化業界で最も広く使用されているコンパイル言語として、Solidity のセキュリティに対するユーザーの関心はさらに高まっており、今回、Solidity コンパイラにリエントリーロック失敗の問題が発生した場合、DeFi 業界全体の歴史が大きく崩れる可能性があります。書き換えられること。

Solidity 開発チームが定期的に発行するセキュリティ警告によると、Solidity コンパイラのさまざまなバージョンにセキュリティ上の脆弱性が存在します。

最新のコンパイラ バグは 6 月 26 日に記録され、abi. ミスの使用に関連するセキュリティ レポートを調査した際に記録されました。古いコード ジェネレーターは、割り当て、関数呼び出し、または .selector がアクセスされる条件などの複雑な式を評価しませんでした。これにより、そのような式が実行されないという副作用が発生するため、古いパイプラインでコンパイルされたコントラクトが正しく動作しない可能性があります。

また、Solidity の Github リポジトリには、Solidity コンパイラの既知のセキュリティ関連のバグをリストしたファイルがあることもわかります。このリストはバージョン 0.3.0 まで遡り、このバージョンより前にのみ存在したバグはリストされていません。ここには、別の bugs_by_version.json ファイルがあります。このファイルを使用すると、特定のコンパイラ バージョンがどのバグの影響を受けるかを問い合わせることができます。

幸いなことに、Solidity 言語の広範な適用とイーサリアム財団の支援のおかげで、展開プロセス中にプロジェクトやプロトコルによって多くの既存の問題が指摘されました。したがって、Solidity は Vyper より数段早く修正・改良を完了しており、この点からも Solidity の方が標準化されており、より安全である理由の 1 つとなっています。

Solidity 開発者がより適切にテストできるようにし、同じことが起こらないようにするため。 UnitasProtocol の共同創設者である SunSec (@ 1 nf 0 s 3 cpt) は、Curve 攻撃後に DeFiVulnLabs Solidity セキュリティ テスト ガイドをリリースしました。このガイドでは、脆弱性の説明、シナリオ、防御策、脆弱性コード、緩和策とテスト方法を含む 47 種類の脆弱性をサポートしています。 。

低レベルの攻撃をできるだけ避けるにはどうすればよいでしょうか?

この Curve のインシデントで、Box はすべての開発者に対する啓蒙は次のとおりであると考えています: 技術トレンドに従おうとせず、未熟なソリューションを選択しないこと、テスト ケースを作成せずに独自のコードを承認しないこと (Vyper のいくつかのバージョンには問題があり、テストさえも)ケースが間違っている場合があります); 自分自身のコードを決して承認しないでください; 運命によっては発見されるまでに何年もかかる場合があります; アップグレードしないことは自分自身に対する傲慢であり、他人に対する軽蔑です。

通常、開発者はここで落とし穴など考えず、コンパイルするバージョンを自由に選択するため、バージョン間の違いによってもたらされるリスクを無視する可能性があります。マイナー バージョンのアップグレードでも重大な変更が導入される可能性があり、これは分散型アプリケーションを開発する場合に特に重要です。

この Curve イベントからの開発者への警告は次のとおりです: 新しいバージョンのコンパイラ言語を使用してください。コードベース、アプリケーション、オペレーティング システムを最新の状態に保ち、あらゆる面で独自のセキュリティ防御を構築することが重要です。一般に、古いバージョンに比べて既知のセキュリティ問題は少なくなりますが、新しいバージョンでは新たなセキュリティ問題が発生する可能性があります。もちろん、コミュニティや公式のバージョンアップデートの発表にも間に合うように注意する必要があります。各バージョンによってもたらされる変更を理解し、必要に応じて独自のコード ベースとオペレーティング環境を更新します。これらの手順を実行すると、コンパイラのバグによって引き起こされるセキュリティ インシデントを大幅に減らすことができます。

さらに、コードを完成させるための単体テスト ケース。コンパイラ レベルのエラーのほとんどは、一貫性のないコード実行結果をもたらします。これは、コード レビューを通じてのみ発見するのは困難ですが、テストで発見される可能性があります。コード カバレッジを改善すると、このような問題を回避できます。また、明確な必要性がない限り、インライン アセンブリや多次元配列のエンコードとデコードなどの複雑な言語機能の使用は避けるようにしてください。歴史的に、Solidity 言語の脆弱性のほとんどは、これらの高度な機能に関連していました。開発者は、特に必要がないのに、誇示する目的で実験的な言語機能を使用することは避けるべきです。

プロトコル層とセキュリティ担当者にとって、コード監査を実施する際には、コンパイラのバージョンによって起こり得るリスクを無視することはできません。ハッカーが新たなアイデアを開拓し、将来的には低レベルの脆弱性が悪用される事件がますます増えることが予測されます。同時に、基盤となるインフラストラクチャとして、基盤となるスタック、プログラミング言語、EVM などを監査する必要があります。今後、監査法人の市場はますます大きくなり、白人ゲスト報奨金の市場もますます大きくなるでしょう。 Vyperチームはまた、問題が正式に解決された後、バグ報奨金プログラムの見直しを開始する予定だ。

もちろん、基盤となるインフラストラクチャのリスクについて過度にパニックになる必要はありません。現時点では、コンパイラのバグのほとんどは特定のコード パターンでのみ発生しており、実際の影響はプロジェクトの状況に応じて評価する必要があります。コンパイラのバージョンを定期的にアップグレードし、適切な単体テストを行うと、リスクを防ぐことができます。

参考内容：