Claude、オープンソースコードから493件のセキュリティ問題を発見

Claudeが、25のオープンソースプロジェクトから493件のセキュリティ問題を発見しました。その中には、保護機能が有効に見えるにもかかわらず、ソフトウェアが意図しないアクセスを許してしまうケースも含まれていました。数年にわたってコード内に潜んでいた問題もあります。

Anthropicのこの調査は、セキュリティ設定同士がどのように相互作用するか、そして認証前にどれだけのコードに到達できるかを検証したものです。調査では、警告なしに機能しなくなる保護機能が見つかりました。こうした機能のせいで、ソフトウェアが本来の制限を超えて無防備な状態になっていました。

発見の一つを受け、OpenSSHの開発者は、広く使われているリモートアクセスツールのセキュリティチェックを見直しました。ほかにも、管理者が日常的な設定レビューでは気づけない可能性のある弱点が指摘されています。

設定の競合でセキュリティチェックが無効化

有効なクライアント証明書を必須とするよう設定したサーバーが、証明書なしの接続を受け入れてしまうことがありました。原因は、21年間存在し続けていた設定の競合です。本来は検証を遅延させる設定のはずが、別の設定によって検証そのものが無効になり、管理者に警告も出ませんでした。

Claudeは500万行を超えるコードを解析し、1万7,000件以上の設定オプションを整理しました。そのうち3,842件がセキュリティ機能に関連するものでした。調査では、ソフトウェアがエラーなしに受け付ける設定の組み合わせに起因する問題が、複数見つかっています。

• 94件の無警告で無効化される制御。警告や文書化された挙動がないまま受け付けられた、セキュリティに関わる設定の組み合わせは162件ありました。そのうち94件で、既存の保護機能が無効になりました。
• 68件の不整合な設定。ほかの組み合わせでは、無効にしたはずのログイン経路にアクセスできる状態が残りました。設定の記述順によって、どの制限が優先されるかが決まるケースもありました。
• 4つのプロジェクトで拒否ルールが機能せず。逆引きDNSを無効にすると、サーバーはホスト名ベースの制限を数値のIPアドレスと照合していました。パターンが一致しないため、意図した アクセスルールでは接続を遮断できませんでした。

Anthropicによると、調査にはソフトウェアの実行をトレースする作業も含まれていました。設定上の弱点と疑われるものが、実際のセキュリティチェックに影響するかどうかを評価するためです。

OpenSSHの修正で認証前に到達可能なコードを削減

認証済みユーザー向けに設計された11のプロジェクトで、Claudeはログイン前にアクセスできる不要なコード領域を93件検出しました。

安全なリモートアクセスに広く使われるツールのOpenSSHでは、バージョン10.4に問題がありました。実験的なポスト量子署名のコード約4,500行が、アルゴリズムを無効にしていても、未認証のクライアントから到達できる状態だったのです。サーバーは、署名方式が許可されているかを確認する前に、受信した鍵を解析していました。

開発者はバージョン 10.5で、アルゴリズムのチェックを鍵の解析より前に移しました。しかし、2つの穴が残っていました。クライアントが承認済みのアルゴリズムを申告しながら、別の種類の鍵を送信できたのです。また、証明書の処理では、設定された制限を適用する前に署名が検証される可能性がありました。

バージョン10.6では、パーサー内部に追加のチェックが導入されました。Anthropicの測定では、認証前に到達可能なコードが約20%減少しています。

認証前に到達できるコードを減らせば、攻撃経路を限定できる可能性があります。ただし、到達可能なコードがあること自体は、悪用可能な脆弱性の存在を意味するわけではありません。

セキュリティチームは導入済みの保護機能を検証する必要

リモートアクセスゲートウェイやインターネットに公開されたサービスに頼る企業にとって、Claudeの発見は重要な事実を示しています。承認された設定と、ソフトウェアの実際の挙動との間にはギャップがあるということです。

サーバーに最新のパッチを適用し、制限を正しく文書化していても、設定同士の相互作用によって意図しないアクセスを許す可能性があります。通常のセキュリティレビューでは、この食い違いを検出できないかもしれません。

たとえば、重要なサービスを守るために証明書のみの認証を採用している組織を考えてみましょう。有効な認証情報を持たない状態で接続を試みれば、導入済みの設定でサーバーが制限を実際に適用しているかどうかが分かります。こうした確認を 脆弱性評価に組み込めば、従来のCVEスキャンやパッチ管理台帳では見逃しかねない問題を洗い出せます。

大規模なインフラを管理するセキュリティチームにとっては、 アタックサーフェス管理が役立ちます。外部からアクセスできるシステムのうち、こうした弱点のリスクが最も大きいものを特定できるためです。

AIが出力した発見事項は、影響を受けるソフトウェアのバージョンに照らした検証が引き続き必要です。ただし、公表されたCVEがなくても、露出が確認できれば対策を講じる根拠になります。

自動化された調査によって見落とされていた問題がさらに明らかになれば、セキュリティチームは理論上の弱点と実証可能な露出を区別する必要があります。どの修正を最優先にするかは、悪用可能性の証拠、影響を受ける設定、想定される事業への影響を基準に判断すべきでしょう。

サイバーセキュリティのその他のニュース: AIを活用したセキュリティテストツールが、日本企業を狙ったサイバー攻撃で確認され、悪用への懸念が高まっています。