ServiceNowがAPI脆弱性を修正、不審なテナント活動の報告を受けて対応

ServiceNowは、新たにパッチが適用された認証不備の脆弱性に関連する活動はセキュリティ研究者によるものだと説明していますが、潜在的な影響範囲については引き続き調査を続けています。

ServiceNowは、影響を受けるインスタンスの認証不要なAPIエンドポイントを通じてデータが漏洩した可能性のある脆弱性を発見・修正したとして、顧客への通知を行っています。

この問題が表面化したのは、顧客が自社環境に関連する不審な活動の報告やServiceNowからのセキュリティ通知について議論し始めたことがきっかけでした。

同社のセキュリティアドバイザリによると、この脆弱性は4月にServiceNowのバグバウンティプログラムを通じて最初に報告され、調査とその後のセキュリティアップデートへとつながりました。ServiceNowによれば、ホスト型の顧客には6月5日にセキュリティアップデート(KB3067321)が適用され、セルフホスト型の展開環境向けにはガイダンス(KB3067372)が発行されています。

この脆弱性は、特定のバージョンと構成で動作するテナントに影響を与えたとみられています。SaaSおよびAIセキュリティ企業AppOmniのCISOであるCory Michal氏は、この問題について「特定の条件が揃った場合に認証なしでアクセス可能となる、インターネットに公開された認証不要のServiceNow APIエンドポイント」が関与していたと述べています。

「実際のところ、エンドポイントのURLとリクエストの構造さえ知っていれば、誰でも事前に認証することなく影響を受けたServiceNowテナントのデータにアクセスできた」とMichal氏は説明しています。

ServiceNowにはITサービスリクエスト、従業員情報、社内のセキュリティデータが保存されていることが多いため、顧客インスタンスへの不正アクセスは企業にとって重大なリスクをもたらす可能性があります。

アドバイザリでは、顧客へのセキュリティ通知で言及された不審な活動は、現時点ではいずれも脆弱性を調査していたセキュリティ研究者によるものと関連付けられると説明されています。

特定リリースのAPIエンドポイントへの影響

ServiceNowのアドバイザリには脆弱性そのものに関する技術的詳細がほとんど記載されていませんが、Redditで問題を議論している顧客の間では、影響を受けたエンドポイントとして「/api/now/related_list_edit/create」が挙げられています。このAPIは特定の状況下において認証なしにクエリを実行できた可能性があり、「requires_authentication = false」という設定でリリースされていたとされています。

同様の議論では、ServiceNowが非公開のセキュリティ通知を通じて顧客に伝えたとされる情報として、影響を受けたのはServiceNowのAustraliaリリースのみだという見解も示されています。これはリリース固有の変更が今回の情報漏洩に関与した可能性を示唆しています。

しかし、問題が単一のリリースに限定されているという見方に対し、顧客側は懐疑的な姿勢を示しました。特定の構成を持つ旧バージョンのリリースにも脆弱性が存在した可能性があると指摘するユーザーが複数いました。

「別のリリースを使っているからといって安全だと思い込まないでください」と、あるユーザーがコメントしています。問題のAPIについてはさらに「これはリリース固有のコード変更ではなく、設定フラグの問題です。自分のインスタンスのScripted REST APIテーブルを確認し、そのチェックボックスが外れているリソース、特に2022年以前から変更されていないものを監査する価値があります」と付け加えています。

研究者か、攻撃者か、それとも両方か

今回のインシデントにおける重要な問いは、影響を受けたServiceNow環境で観測された活動がセキュリティ研究者のみによるものなのか、それとも悪意ある攻撃者もこの脆弱性を悪用した可能性があるのかという点です。

ServiceNowは、確認された不正アクセスはすべて調査目的の行為に起因するものと認定していると述べています。「観測された活動はセキュリティ研究者または独自に調査を行っている顧客によるものと考える根拠がある」とした上で、「ただし、調査は継続中であり、追加の検証が必要な可能性もある」と付け加えました。

Michal氏は、観測されたすべての活動を無害なものと断定する前に慎重を期すよう促しています。

「帰属の判断はそれほど明確ではありません」と同氏は述べています。「この脆弱性の悪用に公に関連付けられているシステムの少なくとも一つは、同様の認証不要なアクセスの弱点を持つ他のSaaSプラットフォームのテナントを標的にしていたようです。研究者による活動が明らかに存在したとはいえ、調査が完了するまでは、観測されたすべての活動が無害な研究目的だったと断言することには慎重であるべきです」

パッチ適用だけでなく、調査も不可欠

ServiceNowは修正とミティゲーションが利用可能だと述べていますが、Michal氏はアップデートの適用はあくまでも最初の一歩に過ぎないと警告しています。

同氏によれば、組織は6月5日のセキュリティアップデートが適用されているか、またはセルフホスト型の展開環境に対して推奨されるミティゲーションが実施されているかを必ず確認する必要があります。それと同様に重要なのが、過去のログを調べて悪用の痕跡を探すことです。

「既知のIoC、影響を受けたAPIエンドポイントへの認証なしリクエスト、テーブルやフィールドへの不審なクエリについて、理想的には少なくとも過去90日分のServiceNowアクセスログおよびトランザクションログを確認してください」と同氏は述べています。「不審な活動が発見された場合は、どのデータにアクセスされたかを特定し、単なるパッチ適用作業ではなくインシデント調査として対処してください」

ServiceNowは、ミティゲーションが適用済みであり、内部調査を継続していることを顧客に伝えています。「現時点の調査によると、一部の顧客インスタンスがこの活動の一環として正常にクエリされたようであり、影響を受けた顧客に対しては専用のサポートケースが作成されています」と同社はアドバイザリに記載しています。

確認済みの研究者IPアドレスからの関連活動については、データの共有・使用・保持の可能性が調査されています。関与した研究者はServiceNowに対し、「テーブルとフィールドに対してクエリを実行したのは、発見内容を検証してバグバウンティレポートを提出する目的のみだった」と伝えたとされています。

翻訳元: https://www.csoonline.com/article/4184082/servicenow-fixes-api-issue-after-reports-of-suspicious-tenant-activity.html

ソース: csoonline.com