ServiceNowの脆弱性によりデータ窃取が可能に

JarTee – shutterstock.com

Varonisの研究者は、人気のワークフロー自動化プラットフォームServiceNowに脆弱性があり、機密情報が漏洩することを明らかにしました。セキュリティ専門家が昨年すでにこのソフトウェアの脆弱性をベンダーに報告した後、プラットフォームは密かに修正され、2025年5月に顧客向けのセキュリティアップデートが公開されました。7月8日、ServiceNowは問題の説明とともにCVE番号(CVE-2025-3648)を発表しました。

「ServiceNowのアップデートは、権限の低いユーザーが制限されたデータにアクセスできてしまう脆弱性を修正します」とIDC社長のクロフォード・デル・プレテ氏はCIO.comに語っています。「ServiceNowが扱うデータの性質を考えると、このような状況は常に深刻なリスクを伴います。」

この問題を解決するには、管理者がアクセス制御リスト（ACL）が適切に設定・管理されていることを確認する必要があるとIDCの専門家は強調します。「良い点としては、最近のパッチによりデフォルト設定が『デフォルトで拒否』に変更され、特権のないユーザーによる誤ったアクセスを防ぐようになりました。」

デル・プレテ氏はさらに「ServiceNow環境は（他の多くのシステムと同様に）非常にダイナミックで、ユーザーや権限が頻繁に変化します」と述べ、変更管理の重要性を指摘しています。

Varonisのセキュリティリサーチグループマネージャー、ヨゲブ・マダー氏は、ServiceNow管理者に対し、自分たちの環境のACLを見直し、新しいアクセス制御メカニズムを活用して脆弱性が悪用されないようにすることを推奨しています。

マダー氏によると、そのためには以下が必要です。

• ACLがデータやスクリプト条件のみに依存しておらず、悪用につながる可能性がないこと、
• より強力なアクセス制御を提供する新しいACLメカニズム「Deny else」を使用すること、
• 新しいクエリACLルールを使い、クエリで使用できるオペレーターを制限し、列挙攻撃の試みを抑制すること。

認証済みユーザーでさえ脆弱性を悪用可能

アクセス制御の脆弱性により、認証されていないユーザーだけでなく、認証済みユーザーも特定条件下で本来アクセス権のないデータにクエリを通じてアクセスできてしまいます。この脅威に対処するため、ServiceNowはプラットフォームのXanaduおよびYokohamaバージョンでアクセス制御リストのための追加フレームワークを導入しました。

「この脆弱性は比較的簡単に悪用でき、最小限のテーブルアクセス、例えばインスタンス内の弱いユーザーアカウントや、自己登録した匿名ユーザーでも利用可能で、権限昇格を必要とせず機密データが漏洩する可能性がありました」とVaronisは自社ブログで説明しています。

ServiceNowが2025年5月にパッチを公開するまで、この脆弱性が実際に悪用された事例は報告されていません。

プラットフォームは膨大な機密データを保存可能

クラウドベースのプラットフォームであるServiceNowは、ITサービス管理、IT運用管理、カスタマーサービス管理、人事、ガバナンス、リスク＆コンプライアンス、ヘルスケア、ライフサイエンス、サービス管理など多様な機能を提供します。これにより、プラットフォームは多くの機密性の高い個人情報を保存できます。

Varonisによれば、ServiceNowはほぼすべての情報をテーブルで管理しています。これには、インシデントやリクエスト、インスタンスのプロパティや構成、ユーザーデータ、アプリケーションの認証情報などが含まれます。これらの各要素は対応するテーブルのレコードとして保存されます。

プラットフォームは参照フィールドを使ってテーブル間の関連付けを行い、異なるテーブル間で情報をやり取りできます。例えば、「インシデント」テーブルの参照フィールドが「ユーザー」テーブルの特定ユーザーレコードと紐付いていれば、関連データを複数のテーブルで表示できます。

これらのテーブルへのアクセスは主にアクセス制御リスト（ACL）によって管理され、ユーザーがどのデータにアクセスできるか、どのように操作できるかが定義されています。

Varonisによると、1つのServiceNowインスタンスには数万件のACLルールが含まれることもあります。

ServiceNowのACLルールの主な構成要素は、管理者が保護したいリソース（テーブル、フィールド、レコード）、制御したいアクセスの種類（読み取り、書き込み、作成、削除）、およびルールが適用されるために満たすべき条件です。

アクセスのための4つの条件

各ACLには、ユーザーが特定リソースへのアクセス要件を満たしているかどうかを判断する4つの条件があります：

• 必要なロール：この条件は、特定リソースへのアクセスに必要なロールを定義します。ユーザーがACLに記載されたいずれかのロールを持っていればアクセスが許可されます。
• セキュリティ属性条件：セキュリティ属性を使ってアクセスを判断します。
• データ条件：この条件はデータ自体に関する特定の基準を評価します。例えば、特定のステータスや日付範囲内のレコードへのアクセスを制限する条件を設定できます。
• スクリプト条件：この条件ではカスタムロジックの実行が可能です。管理者はスクリプトを書いて、単純なロールやデータ条件を超えた複雑なセキュリティルールを実装できます。例えば、インスタンスに特定の設定がされている場合や、ユーザーが認証されている場合のみアクセスを許可するスクリプトが書けます。

これら4つのACL条件は、ServiceNowでこの順番で評価されます。

Varonisは、ServiceNowがどのACL条件が満たされなかったかによってアクセスを拒否することを確認しています。最初の2つの条件（「必要なロール」または「セキュリティ属性条件」）のいずれかでアクセスがブロックされた場合、アクセスは拒否されます。

しかし、「データ条件」または「スクリプト条件」が満たされなかった場合、ユーザーにはクエリで返されたレコードの総数が表示されるページが開きます（実際のレコードは表示されません）。サイバー犯罪者はこのアプリケーションのクエリパラメータを使って、列挙によって詳細データを推測できます。さらに悪いことに、攻撃者はこのプロセスを自動化し、列挙用の簡単なスクリプトを書くことで、テーブルから完全なレコードを取得し、HTMLソースから結果を抜き取ることができるとVaronisは指摘しています。

「特別な設定やプラグインは必要ありません」とセキュリティ研究者は強調します。攻撃者は、ServiceNowインスタンス内でテーブルやカラムに部分的なアクセス権を持つユーザーアカウントさえあれば十分です。

新しいACLルールの作成が可能

Varonisは、自己登録したユーザーでさえこの攻撃を利用できると指摘しています。自己登録は、ユーザーが自分でアカウントを作成し、最小限の権限でインスタンスにアクセスできる機能ですが、これも攻撃に利用される可能性があります。

「インスタンスが匿名登録や匿名アクセスを許可することは稀ですが、こうした設定が複数のフォーチュン500企業のServiceNowシステムで見つかっています」とセキュリティ専門家は述べています。

攻撃のリスクがあるのは、「必要なロール」や「セキュリティ属性条件」セクションが空、もしくは広すぎるACLが設定されたテーブルです。「つまり、データ条件やスクリプト条件だけで保護されているテーブルは、攻撃に完全にさらされていることになります」とVaronisは説明しています。

この脆弱性を修正するため、ServiceNowは管理者が実装できる複数の新しいACLルールを作成しました。その一つが「クエリACL」で、ユーザーがテーブルに対して実行できるクエリに制限を加え、レコード取得を制御します。新しいセキュリティデータフィルターは、アサーションに関連するロールやセキュリティ属性に基づいてレコードへのアクセスを制限できます。

ServiceNowはアクセス制御リスト管理のガイドや管理者・開発者向けのアドバイスを提供しています。

「このServiceNowの脆弱性は、確立されたプラットフォームでさえアクセス制御に関する危険な脆弱性が存在しうることを強く示しています。」

「この脆弱性が特に懸念されるのは、その悪用の容易さです」とSaaSセキュリティソリューションベンダーRecoの最高製品責任者ガル・ナカシュ氏は説明します。「権限昇格や高度な技術知識は不要で、誤ったACL設定とクエリフィルターの巧妙な利用だけで深刻なデータ流出が起こり得ます。これは重大なリスクとなり得る低いハードルです。」

「特に医療、金融、政府など規制の厳しい業界の企業にとって、これは警鐘です。アクセス制御リスト（ACL）は最小権限の原則に従って設定されるべきで、ロールやセキュリティ属性は決して空や広すぎる設定にしてはいけません」とSaaS専門家は付け加えます。

ServiceNowの新しいクエリACLやセキュリティデータフィルターは強力な保護を提供しますが、実際に活用・テストされて初めて効果を発揮します。「管理者は、異常なクエリパターンや権限の低いユーザーによるアクセスなどの異常を継続的に監視し、テーブルやロールの権限変更を確認すべきです。」（jm）