ServiceNow のデータ漏えい：たった１つのミスコンフィグレーションが原因だった

ServiceNow Data Exposure: A Wake-Up Call for Companies

2023/10/30 TheHackerNews — 今週の初めに ServiceNow が発表したのは、同社のサポートサイト・プラットフォーム内でミスコンフィグレーションが生じていることだ、それにより、機密データへ向けた意図しないアクセスが発生する可能性があるという。ServiceNow を使用している組織にとって、このセキュリティの問題は、企業の機密データの重大な漏えいにつながりかねない重大な懸念事項である。そのため ServiceNow は、この問題を修正するための措置を講じている。

この記事では、ServiceNow で生じたミスコンフィグレーションの問題を徹底的に分析し、それにより企業に深刻な影響を長じた可能性がある理由と、ServiceNow による修正が行われなかった場合に企業が取るべき対策について説明する。(ただし、ServiceNow の修正により、それぞれの企業の危機が回避されたことを再確認すべきだろう)

一言で言えば

ServiceNow は、IT サービス管理／IT 運用管理／IT ビジネス管理を自動化するためのクラウドベースのプラットフォームであり、カスタマーサービス／人事／セキュリティ運用などの各種の領域で使用されている。さらに言えば、ServiceNow におけるインフラの性質／開発プラットフォームとしての拡張性／組織をカバーする機密データや専有データへのセキュアなアクセスにより、ビジネス・クリティカルなアプリケーションの上位に立つと考えられている。

その Simple List は、テーブル内に格納されたデータを取り出し、ダッシュボードで使用するためのインターフェース・ウィジェットである。しかし、Simple List のデフォルト・コンフィグレーションでは、未認証のリモート・ユーザーが、テーブル内のデータにアクセスできてしまう。これらのテーブルには、IT チケット／内部機密ナレッジベース／従業員の詳細情報などの機密データが含まれている。

こうしたミスコンフィグレーションが、実は 2015年の Access Control Lists 導入時から存在していたという。しかし、これまでの間において、結果として報告されたインシデントはなかった。とは言え、最近になって公表されたデータ漏洩調査を考慮すると、未解決の状態を放置する企業は、これまで以上に危険にさらされる可能性がある。

この危険が生じた理由は、たった１つのデフォルト・コンフィグレーションにある。その一方で、アクセス制御／データ漏洩／マルウェア保護などをカバーし、安全性を維持するためのコンフィグレーションは何百もある。 Adaptive Shield などの SSPM (SaaS Security Posture Management ソリューション) を使用している組織の場合は、危険なミスコンフィグレーションを簡単に特定し、それぞれの成否を確認できる。

ServiceNow のミスコンフィグレーションの内側

この問題は ServiceNow のコードの脆弱性ではなく、プラットフォーム内に存在するコンフィグレーションが原因であることを、再確認することが重要である。

この問題は、レコードを読みやすいテーブルに格納する、Simple List という名の Access Control List (ACL) ウィジェットのセキュリティ制御に起因している。これらのテーブルは、複数のソースからの情報を整理する役割を持っているが、デフォルト・コンフィグレーションではパブリック・アクセスが設定されている。

これらのテーブルは ServiceNow の中核であるため、単一のコンフィグレーションの修正では対応が不可能であり、複数のテーブルでの修正が必要である。したがって、アプリケーション内の複数の場所で、 UI ウィジェットと組み合わせて、すべてのテナント全体で問題を解決する必要があったという。さらに問題を複雑にしていたのは、１つのコンフィグレーションを変更するだけで、Simple List テーブルに接続されているワークフローが壊れ、既存のプロセスに大きな支障をきたす可能性があったことだ。

改善ステップ

ServiceNow のナレッジベースである “General Information | Potential Public List Widget Misconfiguration” で公表された、問題の評価と改善策は以下のとおりである：

• Access Control Lists (ACL) が完全に空であることの確認、あるいは、”Public “というロールを含んでいることの確認を行う。
• パブリック・ウィジェットを確認し、ユースケースに合わない “Public” フラグを false に設定する。
• IP アドレス・アクセス制御や適応認証などの、ServiceNow が提供する組み込み制御を使用して、より厳格なアクセス制御手段の使用を検討する。
• ServiceNow Explicit Roles Plugin のインストールを検討する。ServiceNow は、外部ユーザーによる内部データへのアクセスが、このプラグインにより防止されると述べている。つまり、このプラグインを使用するインスタンスは、今回の問題の影響を受けない (このプラグインは、すべての ACL が、少なくとも１つのロール要件を宣言することを保証する)。

上記で推奨される修復手順は、最高のセキュリティを確保するため、再確認する価値がある。したがって、今季の修正後も公開され、ユーザー組織で利用できる。

ServiceNow のデータ漏洩防止の自動化

Adaptive Shield のような、SaaS Security Posture Management (SSPM) ソリューションを使用している組織は、 ServiceNow などの SaaS アプリケーションのコンフィグレーションを可視化し、そこに含まれる問題を修正できる。

リスクの高いコンフィグレーションが存在する場合には、SSPM からセキュリティ・チームに警告が発せられるため、その調整によりデータ漏えいを防ぐことが可能になる。

ServiceNow に限らず、ミスコンフィグレーションが怖いですね。この記事は、SSPM ベンダーである Adaptive Shield が関与しているようですが、同社はミスコンフィグレーションの排除を目的といているようなので、この種の問題を掘り下げることが可能なのでしょう。よろしければ、misconfiguration で検索も、ご利用ください。