従業員が社内のサービスポータルを開き、ナレッジベースを検索し、チケットにファイルを添付するとします。実はこのとき、一度もログインしたことのない第三者が同じポータルにリクエストを送り、記録を取得できてしまうケースがあります。
Bishop Foxは、許可を得たペネトレーションテストの過程で166件のServiceNowインスタンスを対象にこのテストを実施しました。同社はその結果を、使用したGo製ツール「Snowpick」とともに公開しています。
調査対象の31%のインスタンスから何らかの結果が返ってきました。これらのインスタンスは、認証情報を一切持たないセッションに対してレコードそのもの、あるいはレコード件数を返しており、データセット内の組織のおよそ4分の3に該当していました。
「今回確認できたレコード漏えいの露出は、新種のゼロデイ脆弱性ではありません。ServiceNowの公開面にまたがるアクセス制御と設定上の問題です」と、このツールを開発したBishop Foxのアドバーサリアル・オペレーター、Emilio Gallegos氏はHelp Net Securityに語りました。
2つの公開面、2つのルール
ServiceNowは、Service Portalウィジェットとテーブル REST APIという2つの経路を通じてデータを提供します。ウィジェットは/api/now/sp/widget/{widget_id}に存在し、POSTリクエストを受け付け、ナレッジベース検索、カタログページ、チケットフォーム、添付ファイル表示などを処理します。一方、/api/now/table/{table_name}にあるテーブルREST APIは、sys_user、incident、oauth_entityをはじめとするスキーマに直接クエリを実行します。
それぞれの公開面は、独立してアクセス制御を評価します。そのため、ウィジェット側をロックダウンしていても、テーブルクエリにはそのまま応答し続けるインスタンスが存在し得ます。実際、データセット内の2件のインスタンスがこのパターンに該当しており、ウィジェットへの調査は問題なしと出た一方で、REST APIはデータを返していました。
大半の露出は添付ファイルウィジェットが原因
陽性となった調査結果の大半は、チケットに添付されたファイルのメタデータを返す標準ウィジェットticket-attachmentsを通じて得られたものでした。このメタデータに含まれるタイトルや説明文には、オンボーディングガイド、アクセス申請手順、システムの操作方法といった社内プロセスの詳細情報が含まれています。
調査対象全体からは、公開状態にあるナレッジベース記事、インシデントチケットのメタデータ、サービスカタログの項目、部門構成、施設の所在地といった情報が見つかりました。各調査結果あたりのレコード件数は、数十件から数千件にまで及んでいます。
今回のサンプルには認証情報は含まれていませんでした。しかし、ACL(アクセス制御リスト)の設定次第では、同じ公開面からoauth_entityやsys_userにも到達可能です。
ツールの仕組み
Snowpickは、公開ログインページにリクエストを送り、そこでServiceNowが発行するセッショントークンを取得し、後続のAPI呼び出しでそれを再利用します。デフォルトで用意された一連のウィジェットと、あらかじめ組み込まれた26種類のテーブル・フィールドの組み合わせを調査し、さらにインスタンス側にどのウィジェットがインストールされているかを問い合わせて、それらを調査対象リストに追加することも可能です。
カスタムウィジェットについては、この検出ステップが特に重要な意味を持ちます。組織はカスタムウィジェット向けに独自のアクセスルールを設定しますが、そうしたルールはプラットフォーム側のレビューを経ていないためです。
出力結果では、実際にレコードが漏えいしたケースと、件数のみが漏えいする「カウントオラクル」――つまりServiceNowが該当するレコードの存在は確認したものの、レコード自体は一切返さなかったケース――が区別されます。Varonis Threat Labsは、この件数の挙動を悪用したブラインド推論をCVE-2025-3648として記録・公表しています。Snowpickは各調査結果について、報告された合計件数、上限を設けたレコードのサンプル、そしてそのリクエストを再現できるcurlコマンドを保存します。
両刃の剣となるツールの公開
Snowpickは、誰でも自分が所有していないインスタンスに対して実行できてしまいます。Gallegos氏によれば、チームはまずそこから議論を始めたといいます。「私たちが注目した問いは、このツールを公開することで攻撃者の能力が実質的に高まるのか、それとも防御側の可視性が向上するのか、という点でした」。
そもそも、根底にある手法自体はすでに公開されていました。Aaron Costello氏は2023年10月の時点でwidget-simple-listの露出について、セッショントークンの取得手順やテーブルの列挙も含めて詳しく記録しており、その後AppOmniがServiceNowのACLの仕組みに関する分析を発表しています。
公開の判断について、Gallegos氏は次のように述べています。「Snowpickを公開したのは、内部に留めておいても、他人のシステムを勝手に調査しようとする人物の動きを鈍らせることにはならないからです。むしろ、これらのシステムに責任を持つ人々が、インシデントに発展する前に露出を発見し修正する機会を奪ってしまうだけなのです」。
対策
プラットフォーム側のデフォルト設定も、対策の一端を担うことができます。Gallegos氏は、公開ウィジェットやテーブルアクセスに関するガードレールを設けることで最低限の安全水準を引き上げられるとしつつも、ServiceNow自体がカスタマイズを前提として設計されている点を指摘しています。「組織は時間をかけて独自のウィジェット、テーブル、ロール、ACLを追加していきます。そうした組み合わせは、未認証のセッションからアクセスされた場合、想定と異なる挙動を示すことがあります」。
「これは責任共有の問題です。ServiceNow側は安全でないパターンの数を減らすことができますが、顧客側も、公開されている自社のインスタンスを、攻撃者と同じように外部の視点でテストする必要があります」。
修復作業は、チケット、添付ファイル、ナレッジベース、カタログ、リストのデータを返す公開Service Portalウィジェットから着手すべきです。テーブルレベル、フィールドレベル、行レベルのACLについては、別途対応が必要になります。あるウィジェットへの直接アクセスをブロックしていても、そのウィジェットを読み込む別のウィジェットを経由すれば、依然としてアクセス可能な場合があります。
SnowpickはGitHubで無償公開されています。
翻訳元: https://www.helpnetsecurity.com/2026/07/22/servicenow-data-exposure-snowpick-open-source-scanner/
