Claudeを使用してコードの攻撃対象領域を削減する

Claudeを使用してコードの攻撃対象領域を削減する

Chris Rohlf著

過去1年間、私たちはフロンティアAIモデルがセキュリティ脆弱性を発見し、悪用する能力が非常に高いことを示す多くのデータ公開してきました。Firefoxのセキュリティや脆弱性評価に関する研究でその能力を示しました。しかし、未知の脆弱性がどのように悪用されうるかを示すことは、サイバー防御のためにフロンティアAIモデルができることのほんの始まりに過ぎません。この投稿では、自動化された攻撃対象領域の分析と削減に関する初期の研究のいくつかを要約します。これは、到達可能なコードをマッピングし、特定のデプロイメントで必要とされないものを削除またはアクセスを制限するプロセスです。

自動化された攻撃対象領域の分析と削減は、短期間でデプロイされたソフトウェアのセキュリティを大きく向上させることができます。個々の脆弱性を見つけて修正するだけでソフトウェアを保護することは、スケーラビリティが悪いです。たとえクリティカルな脆弱性を修正しても、残りの脆弱性については何もわかりません。対照的に、コードの到達可能性を削減することは、現在悪用されている可能性のあるものを含む、未知の脆弱性の深刻度を低減させることができます。これらの技術はコード内の未知の脆弱性を除去するわけではありませんが、脆弱性に到達することをより困難にし、それによって深刻度を低減させます。コードベースの攻撃対象領域を最小化することは、個々の脆弱性を見つけたり修正したりすることなく、セキュリティを向上させます。

以下では、Claudeを使用して大規模なオープンソースコードベースに攻撃対象領域削減技術を適用して収集したデータの初期段階をプレビューします。私たちの目標は、Claudeが上記の方法を通じてソフトウェアセキュリティを意味のある、そして経済的な方法で向上させることができることを示すことです。具体的には、25のプロジェクト（様々な言語）でClaudeを実行し、493件の問題を発見しました。これらの結果を踏まえ、開発者が自身のコードに同様の技術をどのように適用できるかについて議論します。

コードベースの攻撃対象領域を削減する方法

ソフトウェアは時間の経過とともに複雑化する傾向があり、新しい抽象化レイヤー、新しい依存関係、新しい機能が互いに積み重なっていきます。これはしばしば、元の開発者が意図したとは非常に異なる動作を引き起こします。そして、攻撃者がしばしば成功する大きな理由でもあります：彼らは、コードがどのように機能することを意図または設計したかではなく、実際にどのように動作するかを正確に研究します。

自動化された攻撃対象領域の分析と削減技術は、不要な攻撃対象領域を発見し、そのコードを適切なゲートの後ろに移動させることを目指します。これには、コードを認証前（pre-authentication）から認証後（post-authentication）へ、0クリックから1クリックへ、デフォルトで有効（on-by-default）から明示的なオプトインへ、またはプロトコルの最初のメッセージからセッション状態マシン内のより深い部分へ移動させることが含まれます。一部のコードはこれらの段階の前に到達可能であることが意図されていますが、多くのコードはそうではありません。そして、数千または数百万行のコードにわたるコードの変更に伴う複雑さを考えると、機能の不要な露出はしばしば見過ごされます。

コードの攻撃対象領域を削減するには数多くの方法があります。私たち自身の研究努力では、特に3つの方法に焦点を当てました：

• デフォルト設定。 私たちは、出荷時のデフォルト設定で到達可能でしたが、デフォルト機能のいずれにも使用されることが意図されていなかったコードを特定しました。
• 設定の相互作用。 私たちは、単独では妥当に見えるが、一緒に設定された場合に問題を引き起こすオプションのペアを見つけました（例えば、セキュリティ制御を静かに無効にする、またはコードは到達可能であるにもかかわらず、機能の動作を未定義のままにする）。
• 早期到達可能性。 私たちは、適切なセキュリティ制御（認証など）の前、ユーザーの操作なし、またはプロトコルの状態遷移の前に実行される、セキュリティ上重要で複雑なコードを特定しました。

私たちは、Claudeがこれらの3つの攻撃対象領域の説明をどれだけうまく理解し、大規模で複雑なコードベースで実際の問題を発見できるかを知りたいと思いました。私たちは25のオープンソースプロジェクト（500万行以上のコードを代表）を分析しました。これには、C、C++、Java、PHP、Pythonなどの言語が含まれます。Claudeはこれらのプロジェクト全体で17,000を超える設定オプションのインベントリを作成しました。そのうち、3,842件はセキュリティ関連の制御または機能の設定に関連していました。

私たちの研究の目的のために、これらのオープンソースプロジェクトを3つの広範なカテゴリに分類しました：

• パブリック。 これらのプロジェクトは、到達可能なすべてのユーザーにサービスを提供するため、または識別できない当事者によって作成されたデータを消費するために構築されています。（例：アップストリームの回答を解析するDNSリゾルバ、またはオリジンレスポンスを解析するプロキシ）。
• ゲート付き。 これらのプロジェクトは、認証されたユーザー（パスワード、キー、または証明書を持つユーザー、または登録されたデバイスなど）にサービスを提供することを目的としています。ソフトウェアは依然として任意のクライアントリクエストを許可しますが、ユーザーが認証されるまで機能は利用できません。
• プライベート。 これらは、オペレーター自身のプライベート環境にサービスを提供するために構築およびデプロイされています。この場合、認証レイヤーのような制御を追加することはオプションですが、ソフトウェアの範囲外です。

これらのカテゴリは、私たちの結果を文脈化するのに役立ちます。例えば、パブリックコードベースのかなりの割合がデフォルト設定で到達可能であると予想されます（ユーザー全員にサービスを提供するために設計されているため）が、ゲート付きカテゴリのプロジェクトでは逆になります。

Claudeの発見

Claudeは、上記3つの方法を使用して493件の発見をしました。その結果からいくつかのテーマが際立ちました。

第一に、Claudeは11のゲート付きプロジェクトすべてに意図せず到達可能なコードがあることを発見しました（ただし、このコードはそれらのプロジェクトの総コード行数に対して有意な割合ではありませんでした）。具体的には、Claudeはゲート付きコホートのデフォルト設定で93件の不要な認証前サーフェス、認証前または認証前にコードが実行されたり状態が記録されたりした37箇所、そして管理者が設定した認証前制御を静かに弱めた61の設定の組み合わせを発見しました。これらの問題のいずれも単独で即座に悪用可能ではありませんでしたが、必要以上に大きな攻撃対象領域を作成していました。

［画像］

各技術について、カテゴリ別に発見された問題の内訳。評価した25プロジェクトのうち、10がパブリック、11がゲート付き、4がプライベートでした。ゲート付きコホートは、早期到達可能性に関する多数の発見という点で最も驚くべき結果を含んでいました。

第二に、設定の相互作用の問題を軽減するClaudeの作業は、最も興味深く影響力のある発見（すべてのプロジェクトタイプにわたる）のいくつかを生成しました。Claudeは、エラーや警告なしに受け入れられた162件のセキュリティ上重要な設定の組み合わせを発見しました。これらの組み合わせの期待される動作に関する文書化はありませんでした。それらのうち94件では、組み合わせが静かにセキュリティ制御を無効にしていました。他の68件は、同じセキュリティメカニズムにおける一貫性の問題でした（例：設定で無効になっていると表示されていても、リスナーまたはログインパスは到達可能のままでした。2つの設定が競合し、どちらが優先されるかは設定ファイル内の順序に依存しました。または、管理者が設定した保護が無効なコードが到達可能であるにもかかわらず、何も機能しませんでした）。これらの設定の組み合わせの一部は標準的でないか、めったに使用されないかもしれませんが、管理者がこれらのプロジェクトを設定してデプロイすることを妨げるものは何もありませんでした。

Claudeはまた、4つの無関係なプロジェクトで独立して現れた特定のパターンを発見しました。これは次のように機能しました。管理者は、IPアドレスの代わりに、ホスト名またはワイルドカードパターンを使用してリモートクライアントのアクセスルールを作成しました。クライアントが接続すると、サーバーはそのルールをクライアントのホスト名と比較しました。サーバーがそのホスト名を学習するかどうかは、リバースDNSルックアップを制御する別のオプション（ほとんどのプロジェクトでオフに設定されていました）に依存しました。ルックアップがオフの場合、サーバーはクライアントのIPアドレスのみを持っていました。サーバーは、そのアドレスをプレーンテキストでルールと比較しました。しかし、ホスト名パターンはIPアドレスと一致することはありません。これは、拒否ルールが決して発火せず、リストが失敗オープンになることを意味します。影響を受けたプロジェクトの一部は、ドキュメントでホスト名ルールがDNSルックアップが有効になっていることに依存すると述べていますが、この方法で書かれた拒否リストが失敗オープン動作を持つとは述べていませんでした。

第三に、Claudeはしばしば2つの設定オプションが競合して、静かにセキュリティチェックをドロップしていることを発見しました。あるケースでは、管理者は接続するすべてのクライアントに証明書で身元を証明するように要求できました。別のケースでは、コードはチェックを必要とされるまで遅延させることのみを意図していましたが、実際にはチェックを完全に無効にしていました。したがって、信頼されたクライアントのみを受け入れるように設定されたサーバーは、誰からの接続も受け入れていました。これは、証明書チェックの背後にあるはずだった大量のリクエスト処理コードを、認証されていないクライアントに公開しました。ソフトウェアはデフォルト設定で警告なしに両方の設定オプションを同時に受け入れました。ドキュメントには、証明書要件がドロップされたことについては一切言及されていませんでした。この競合する設定オプションのセットは、21年間ソフトウェアに存在していました。

最後に、Claudeは、デフォルトで認証をオフにしており、管理者がそれをオンにすることを期待しているプロジェクトで問題を発見しました。TLSクライアント証明書を要求するオプションは、プロジェクトのほとんどのネットワークエンドポイントで尊重されていましたが、ごく一部のエンドポイントでは静かに無視されていました（これらは異なる名前空間を持つパスを通じてTLS設定をロードしていました）。これにより、証明書を持たないクライアントでもTLSハンドシェイクを完了し、影響を受けたエンドポイントでセッションを開くことができました。無視された設定については何もログに記録されませんでした。オプションが有効になるかどうかは、管理者が設定で使用する名前空間に依存しました。設定名の1つの形式はすべてのエンドポイントで機能しますが、短い形式（ほとんどの例で使用されている）は影響を受けたエンドポイントではドロップされました。

ケーススタディ：OpenSSH

驚くべきことに、コード全体の割合として測定した場合、Claudeが最も大きな攻撃対象領域の削減を達成したプロジェクトはOpenSSHでした。OpenSSHは、安全なリモートアクセスを提供する高品質なCコードベースです。Claudeは10.4リリース版のSSHデーモンの入力パスをトレースし、デフォルト設定で認証されていないクライアントが到達可能な、ML-DSA-44（ポスト量子署名アルゴリズム）用の約4,500行の新規かつ実験的なコードを発見しました。ML-DSAはデフォルトでは有効になっていませんでしたが、管理者がアルゴリズムを明示的に除外した場合でも、コードは到達可能でした。デーモンはクライアントが送信した任意のキータイプを解析し（証明書の場合は、埋め込まれたCA署名も検証しました）。その後、そのキータイプが許可されているかどうかをチェックしました。この複雑でメモリ安全でないコードが、設定で有効になっていない場合に到達可能であることには、良い理由はありませんでした。ML-DSA-44の4,500行のコードは、デフォルトのsshdにおけるOpenSSH自身の認証前コードの約16%に相当します。私たちはこの問題をパッチと共にOpenSSH開発者に報告しました。10.5リリースでは、チェックが解析の前に行われるようになりました。

次にClaudeは、10.5のチェックにおける2つのギャップを指摘しました。最初のギャップは、クライアントが主張することと、それが送信することとの間の不一致でした。チェックはクライアントが広告したアルゴリズム名を見ましたが、パーサーはキーブロブに埋め込まれたタイプ文字列によって選択されました。クライアントはssh-ed25519を広告し、チェックを通過し、それでも解析されるML-DSAキーを送信することができました。

2番目のギャップは、10.5のチェックにおける証明書にありました。証明書のキータイプはデフォルトで有効になっていました。攻撃者から提供された証明書が与えられると、sshdは埋め込まれたCA公開キーをデシリアライズし、設定を参照する前に、サポートされている任意のアルゴリズムで完全な署名検証を実行しました。ユーザーキー署名パスは、サーバーに接続することを許可された公開キーのリストによって適切にゲートされていましたが、CA署名パスはそうではありませんでした。これにより、バイナリ内のすべての公開キー署名検証器が、キー交換を完了できる任意のクライアントから到達可能になりました。私たちは概念実証を構築し、メンテナーと協力して修正の複数のイテレーションを開発しました。結果として得られた変更は、チェックをパーサー自体の中に配置しました。エンコードされたキータイプと証明書のCA署名アルゴリズムは、対応するデシリアライゼーションまたは署名検証の前に、設定された許可リストと比較されるようになりました。

この修正により、デフォルトビルドで認証されていないクライアントが以前到達可能だったOpenSSHコードの約5分の1が削除されました。そのほとんどは新しいML-DSAコードであり、これはキータイプを偽装したり、許容可能な証明書内にML-DSA CAキーを隠したりするクライアントに対しても到達不可能になりました。許可されたCAアルゴリズムで署名された証明書は引き続き解析および検証されますが、チェックは解析の前に実行されるようになりました。メンテナーは、バージョン10.6でここで説明された変更をリリースしました。

OpenSSHは世界で最も厳密に監査されているコードの一部です。もし不要な到達可能性がそこで生き残るなら、それはどこでも生き残る可能性があります。これは、コードベースの攻撃対象領域を削減することが、多くの重要なコードベース全体で利益をもたらす可能性が高いことを示唆しています。

結論

任意のコードベースに未知の脆弱性がいくつ存在するかを測定することは、おそらく不可能です。そして、攻撃者が十分な時間があれば（特にフロンティアAIモデルを備えている場合）、それらの脆弱性を見つけることができるというデータは豊富にあります。しかし、コード内の不要な攻撃対象領域を削減する防御者は、そのコード内のすべての未知の脆弱性からのリスクを一度に削減します—静かに悪用されている可能性のあるものも含みます。OpenSSHは世界で最も監査されているCコードの一部です。それにもかかわらず、デフォルト設定で攻撃者が到達可能だった可能性のある、約4,500行の実験的な署名解析コードが出荷されていました。

上記で説明した攻撃対象領域削減技術を、再利用可能な単一のClaudeスキルに統合しました。これは、OSS-Scannerへの統合を進めているところです。このスキルは、コードベースに対して3回のパスを実行します。各パスは、前のパスから短いコンテキストを受け取ることを除いて、空のコンテキストウィンドウから新たに開始されます。

最初のパスでは、スキルは、デフォルト設定で到達可能だが、意図された機能のいずれにも使用されていないコードがあるかどうかを確認します。2番目のパスでは、任意の構成で、ハードゲート（認証など）の前、またはプロトコルの状態マシンエントリポイントの前に実行されるコードを確認します。最後に、3番目のパスでは、スキルは、構成のどの組み合わせがセキュリティ制御を静かに無効にするか、またはその有効性を低下させるかを評価します。すべてのパスで、Claudeはコードからのエントリポイントのインベントリを作成し、プログラムの動的なトレースで各発見を確認します。デフォルト設定の発見については、ゲートを設計および実装し、これがプログラムのデフォルト動作に影響を与えないことを保証します。これは、プロジェクト自身のテストスイート（ブラックボックス回帰テストスイートと並行して）をベースラインに対して実行することによって行われます。変更されたビルドが同一の結果を持つことを要求します。非デフォルト設定を変更する可能性のあるゲートは、人間が決定するために脇に置かれます。他の2つのパスについては、設定チェックの順序変更、状態順序を強制するためのガードの追加、または設定ロード時に組み合わせを拒否するといった変更を提案します。この特定のスキルを使用しなくても、ここで概説されている広範な方法論は効果的である可能性が高いと考えています。

この投稿で概説されている技術は、攻撃対象領域削減で可能なことの非常に限定的な側面しか提供していません。例えば、Claudeはランタイムログを分析および比較して、必要な機能のみが有効になっていることを確認することもできます。使用されていないパーサー、レガシープロトコル、およびダッシュボードを無効にすることは、ほとんどコストをかけずにセキュリティリスクを低減させます。

私たちは、組織がClaudeを使用して、依存しているソフトウェアの攻撃対象領域を分析および削減することを検討することを奨励します。これは、開発者が世界がすでに実行しているコードのセキュリティを測定可能に改善するための最も実用的な方法の1つになると予想しています。