何が起きたのか？
12月14日、Ledgerのソフトウェアライブラリの一つであるLedger Connect Kitが、ソフトウェアサプライチェーン攻撃の標的となりました。
この侵害は、公開アクセス権を依然として持っていた元従業員がフィッシング攻撃の被害に遭ったことが発端とされています。この攻撃により、その元従業員のnpm認証情報が漏洩しました。npmとは「Node Package Manager」の略で、オープンソースのソフトウェアライブラリをインポートするためのツールであり、Web開発業界やWeb3において広く使用されています。
この攻撃により、問題のライブラリの悪意あるバージョンが公開されました。このライブラリは、Ethereumエコシステム内の多くのWebアプリにおいて、CDN（コンテンツデリバリーネットワーク）を通じてリアルタイム更新される形式で組み込まれています。その結果、悪意あるコードがそれらのWebアプリに注入されることになりました。
どうすれば防げるのか？LavaMoat。
LavaMoat は、Webアプリケーション開発者が直面するソフトウェアサプライチェーンのセキュリティ問題に対処するために特別に構築されたツール群です。
LavaMoatは、ソフトウェア開発ライフサイクルの3つの異なるポイントでサプライチェーン攻撃に対する保護を提供します：依存関係のインストール時（各種ライブラリをインポートする際）、ビルド時（アプリをインターネット配信用に準備する際）、そしてランタイム時（ビルドされたアプリケーションが実行されている際）です。
LavaMoatが他と一線を画すのは、そのランタイム保護にあります。開発中に使用できる他のツールとして、既知の脆弱性の警告のみを提供するsnyk.ioや、より包括的なコード分析を提供し、専門家が中央データベースに報告するのを待たずに機能するsocket.devなどがあります。これらのスキャンツールは非常に重要な役割を果たしており、socket.devのGitHub Integrationの使用をお勧めします。
しかし、これらのツールはランタイムの保証を提供することができません。 そのため、これらのツールだけでは不十分と考えています。
LavaMoatのセキュリティ保護は、アプリケーションの依存関係に対して指定された権限のみを委譲するという仕組みに基づいています。
どういう意味でしょうか？続きをお読みいただき、LavaMoatの仕組みと使用方法についてより深く理解するために、Devcon 6のトークもご覧ください。
Object Capabilityの基礎
システムにはcapabilities（権限）があると考えることができます。情報の表示、ローカルに保存されたデータの読み取り、サーバーへのWebリクエストやウォレットへのトランザクションリクエストなど他のシステムへのリクエストの実行、そしてこれらの権限を他者に委譲する能力などが含まれます。
権限を委譲する際には、その権限の制限されたバージョンや縮小されたバージョンを提供することができます。これは**attenuation（権限の制限）**として知られています。
これら3つの要素が、object capability セキュリティモデルの基盤を形成しています。このモデルを使用することで、誰が何をする能力を持っているかを把握することができます。
Webアプリケーションのセキュリティ
ブラウザはアプリケーションのサンドボックス化、つまりアプリケーションを分離してコンピューターや他のWebサイトへの干渉を防ぐという点では、ある程度の機能を提供しています。
しかし、Webアプリ開発者がアプリの特定の部分をさらにサンドボックス化するための堅牢な構成要素は提供されていません。そのような機能があれば、アプリの特定のコンポーネントがアプリケーション全体を侵害するのを防ぐことができます。
このため、ライブラリをアプリケーションにインポートする際、実質的にそのライブラリにすべての権限を委譲することになります。さらに複雑なのは、ほとんどのJavaScriptライブラリは自身のコードだけでなく、さまざまな作者によって書かれたライブラリ群も取り込むという事実です。
Ledger攻撃の詳細
@ledger/connect-kit-loaderライブラリは、LedgerがLedger製品との統合に推奨する方法です。このパッケージは、CDNから最新バージョンのライブラリを読み込む薄いラッパーです。
これはアプリが常に最新バージョンのライブラリを持つことを意味しますが、同時に__Ledgerローダーライブラリにウェブアプリの制御を実質的に委譲することになり、そのローダーライブラリはさらにCDN上でホストされているコードに制御を委譲することになります。__
委譲チェーンは次のようにモデル化できます：
Web App → **@ledger/connect-kit-loader** → jsDelivr CDN → npm → Ledger → Ledger元従業員 → 攻撃者
これでも単純化されたものです。jsDelivr CDNなどの一つのコンポーネントを詳しく見ると、サプライチェーンの一部であり攻撃の足がかりとなり得る追加サービスの複雑な絡み合いが見えてきます。
Object Capability Securityによるアプリケーションの保護
前述のとおり、ブラウザ自体はアプリケーションのサブコンポーネントの権限を制限するためのツールをあまり提供していませんが、JavaScriptという言語自体はこの目的に実は適しています。
JavaScriptは、慎重な取り組みにより、コードがアクセスできる範囲を制限するCompartmentsを構築することができます。Compartmentsの実装については、AgoricのHardened Javascriptの取り組みをご覧ください。
MetaMaskの LavaMoat サプライチェーンセキュリティシステムと MetaMask Snaps プラグインシステムは、どちらもConfinement（封じ込め）を実現するためにCompartmentsを基盤として構築されています。
LavaMoatはLedgerのサプライチェーン攻撃を防げたのか？
LavaMoatが攻撃を防げたかどうかを問うのは、テーブルソーの接触時停止機能が崖から飛び降りながらノコギリを持ち続けた場合に役立つかどうかを問うようなものです。答えはイエスで、飛び降りた後も指は手に繋がったままでしょう。
原則として、@ledgerhq/connect-kit-loaderの動作方式は、アプリ開発者に確立されたセキュリティのベストプラクティスの多くを諦めさせることになります。しかし、すべての希望が失われたわけではありません。
LavaMoat（および他のサプライチェーンセキュリティツール）を最大限に活用するには、ローダーにすべての制御を渡すのではなく、@ledgerhq/connect-kitを直接使用することが最善の方法です。
LavaMoatは「event-streamインシデント」とも呼ばれるCopayウォレットハックのような攻撃を軽減するために設計されており、そのような攻撃に対して高い防御力を発揮します。では、LavaMoatはこの異なる種類の攻撃に対してどのように機能するのでしょうか？
残念ながら、答えは昔ながらの「状況による」です。LavaMoatはアプリのランタイムへの統合方法の性質上、ライブラリ開発者ではなくアプリケーション開発者向けのツールです。つまり、一部のWebアプリはLavaMoatで自身を保護できたかもしれませんが、LavaMoatを使用していないアプリケーションは依然として脆弱なままだったということです。
さらに、LavaMoatは開発者が指定したポリシーのみを適用します。安全でないポリシーを指定した場合、LavaMoatはあなたを保護することができません。
LavaMoatを使用したアプリケーションがこの攻撃からどのように保護されたかを見てみましょう。
LavaMoatはポリシーファイルを使用して、依存関係がグローバルプラットフォームAPIの形式でどのような権限を取得すべきかを決定します。これを容易にするために、LavaMoatにパッケージを分析させ、そのパッケージが動作するために必要と思われるものを自動的に判断させることができます。これは静的解析として知られています。
静的解析はコードが何をしようとしているかを理解するための不完全な手段ですが、LavaMoatは静的解析をポリシーファイルの生成を助けるための便宜的な手段としてのみ使用します。ランタイムでのポリシー適用に静的解析は使用しません。生成されたポリシーはその後、開発者によってレビュー、調整、承認されます。
最初の質問に対する一つの答えは：はい、LavaMoatはランタイムで新しいコードを読み込む権限をパッケージが持てないようにすることで、サプライチェーン攻撃からアプリとユーザーを保護することができます。正しく設定されており、過度に強力な権限を要求しない依存関係を使用していれば、保護することができます。
もう一つの答えは：いいえ。@ledgerhq/connect-kit-loaderが正常に動作し、LavaMoatランタイムの外部で任意のコードを実行するスクリプトタグを注入できるようにLavaMoatを設定していた場合、攻撃は依然として成功していたでしょう。 これはLavaMoatの後方互換性とより安全なシステムの間のトレードオフの一部です。LavaMoatは最大限の互換性を持つために非常に柔軟に設計されており、アプリをゼロから書き直すことなく導入することができます。適切なポリシーを設定し、適切な依存関係を選択する責任は依然としてアプリ開発者にあります。LavaMoatはグローバルブラウザAPIを選択的に提供することができますが、一部のグローバルAPIはサードパーティのパッケージに安全に与えるには強力すぎる権限を含んでいます。これらの権限をさらに制限するいくつかの方法を研究中ですが、制御を制限する努力をしないパッケージに対してもそのまま機能するものを作ることは困難です。
LavaMoatの機能の一つであるScuttlingは、@ledgerhq/connect-kit-loaderによって読み込まれた悪意あるパッケージと元のパッケージの両方に干渉します。ScuttlingはLavaMoatサンドボックスの外で実行されるコードの権限へのアクセスを削除します。これにより、最初から安全でない@ledgerhq/connect-kit-loaderの使用が防止され、@ledgerhq/connect-kitを直接使用して更新プロセスを管理するよう促され、アプリで実行されるコードの完全な制御を維持することができます。
LavaMoatは万能薬ではありませんが、そうでなければ何も見えなかったところに制御と可視性をもたらします。LavaMoatはセキュリティ戦略における一つのツールに過ぎません。
明日の攻撃に備えて今すぐできることは以下の通りです：
無料のSocket.dev dependency monitorを追加する（2分）。
リソースを厳密に制御するCSPを追加する（30分）。
AIによる翻訳です。エラーが含まれている可能性があります。常に情報を確認してください。
