1,000を超える誤設定されたServiceNowエンタープライズインスタンスが、企業の機密情報を含むナレッジベース（KB）記事を外部ユーザーや潜在的な脅威者に公開していることが判明しました。
公開された情報には、個人を特定できる情報（PII）、内部システムの詳細、ユーザー認証情報、本番システムのアクセストークン、その他ナレッジベースのトピックに応じた重要な情報が含まれます。
AppOmniのSaaSセキュリティ・リサーチのチーフであるアーロン・コステロは、設定の問題により、意図せずに企業情報を暴露しているServiceNowのオンライン・インスタンスが1,000以上あることを発見しました。
これは、ServiceNowが2023年にアクセス制御リスト（ACL）の改善を明示的に目的としたアップデートを行ったにもかかわらず、依然として重大な問題である。
公開されたKB記事
ServiceNowは、組織が様々な部門やプロセスにわたるデジタル・ワークフローを管理するために使用するクラウドベースのソフトウェア・プラットフォームです。
ITサービスとITオペレーション管理、人事タスク、顧客サービス管理、セキュリティ・ツールの統合、そしてナレッジ・ベースが統合された完全なソリューションです。
ナレッジ・ベース機能は、組織がハウツー・ガイド、FAQ、その他の社内手順を、閲覧権限のあるユーザー向けに共有できる記事のリポジトリとして機能する。しかし、これらの記事の多くは一般に公開されることを意図していないため、組織に関する機密情報が含まれている可能性がある。
ServiceNowのデータ流出に関するCostelloによる2023年のレポートの後、同社は顧客データへの認証されていないアクセスを防ぐための新しいACLを導入したセキュリティアップデートを展開した。しかしAppOmniによると、ServiceNowのKBのほとんどはACLではなくUser Criteria権限システムを利用しており、アップデートの有用性は低いという。
さらに、顧客情報を公開する公開ウィジェットの中には、2023年のACLアップデートを受けず、認証されていないアクセスを許可し続けているものもある。
このため、Costello氏によると、ServiceNowのパブリック向けウィジェットで誤って設定されたアクセス制御が、認証を必要とせずにKBのデータを照会するために依然として使用される可能性があるという。
AppOmniは、本日発表した新しいレポートの中で、「これらのインスタンスは、影響を受けた組織によって、PII、内部システムの詳細、本番システムのアクティブな認証情報/トークンなど、本質的にセンシティブなものであるとみなされていた」と述べている。
Burp Suiteのようなツールを使って、悪意のある行為者は脆弱なエンドポイントに大量のHTTPリクエストを送り、KBの記事番号をブルートフォースすることができます。
研究者は、ナレッジベースの記事IDはKBXXXXXXXの形式でインクリメンタルであるため、脅威行為者はKB0000001から始まるKB番号を、意図せずに公開されているものを見つけるまでインクリメントすることで、ServiceNowインスタンスをブルートフォースできると説明しています。
AppOmni は、外部アクターが認証なしで ServiceNow インスタンスにアクセスし、HTTP リクエストで使用するトークンを取得し、KB 記事を取得するためにパブリックウィジェットにクエリを発行し、ホストされているすべての記事の ID をブルートフォースできることを示す概念実証攻撃を開発しました。
Source：AppOmni
不正アクセスのブロック
AppOmniは、SecureNowの管理者が適切な「ユーザー基準」（読み取り可能/読み取り不可）を設定し、すべての不正ユーザーをブロックすることで、KB記事を保護することを提案している。
任意のユーザー」や「ゲストユーザー」のような基準では、外部からの任意のアクセスから記事を保護できない構成になってしまいます。
ナレッジベースへのパブリックアクセスが明示的に必要でない場合、管理者はこれをオフにして、記事がインターネット上でアクセスされるのを防ぐべきである。
研究者たちはまた、設定ミスの場合でも不正アクセスからデータを守ることができる、特定のセキュリティ特性を強調している。以下はその例である：
- glide.knowman.block_access_with_no_user_criteria（True）：KB記事にユーザ基準が設定されていない場合、認証済みユーザと未認証ユーザのアクセスを自動的に拒否するようにします。
- glide.knowman.apply_article_read_criteria (True)：たとえKB全体への “Can Contribute “アクセス権を持っていても、個々の記事への明示的な “Can Read “アクセス権をユーザに要求します。
- glide.knowman.show_unpublished (False)：下書きや未公開の記事を表示しないようにします。下書きや未公開の記事には、未審査の機密情報が含まれている可能性があります。
- glide.knowman.section.view_roles.draft（管理者）：下書き状態のKB記事を閲覧できるロールのリストを定義します。
- glide.knowman.section.view_roles.review（管理者）：レビュー状態のKB記事を閲覧できるロールのリストを定義します。
- glide.knowman.section.view_roles.stagesAndRoles (管理者)： カスタム状態のKB記事を閲覧できるロールのリストを定義します。
最後に、新しく作成されたKBの “閲覧不可 “リストにゲストユーザを自動的に追加するServiceNowの既製のルール（OOB）を有効にすることをお勧めします。
Comments