顧客に API を提供すると収益は増加しますが、攻撃対象領域も拡大します。企業は、サードパーティのアプリケーションに埋め込むことができる API を提供して、開発を容易にすることができます。たとえば、アプリケーションにソーシャル メディアを埋め込むと、開発チームに多大な負担をかけることなく、顧客が製品について話し合うことができます。ソーシャル メディア企業はトラフィックと可視性を獲得し、顧客はアプリケーションに機能を追加しながら開発を容易にすることができます。 API はマーケティングや収益には有効ですが、API とエンドポイントを追加すると攻撃対象領域が拡大します。API を持つことは管理可能な追加リスクですが、すべてのエンドポイントを厳密に監視して保護する必要があります。ほとんどの管理者は API を監視する必要があることに同意しますが、多数の更新と展開を伴うペースの速いビジネス環境では、API の追跡が困難になり、「ゾンビ API」と呼ばれるサイバーセキュリティ リスクが知らないうちに追加される可能性があります。 ゾンビ API とは何ですか? ゾンビ API とは (簡単に言うと) 忘れ去られ、見過ごされているインフラストラクチャで、使用可能な状態のままですが、組織はその存在に気づいていません。ゾンビ API は小規模または大規模な環境で作成されますが、多くの場合、厳格なプロビジョニングおよびドキュメント化手順が実施されていない状態で IT リソースが構築されている環境で作成されます。変更管理はゾンビ API の状況を回避するのに役立ちますが、特定の重大なエラーを修正するために実行される緊急の展開または構成が発生することもあります。 自動化された環境では、クラウド リソースはアプリケーション コードとともに展開されることがよくあります。その利点は、開発者や運用担当者がハードウェアの展開と手動構成を覚えておく必要がなくなることです。ソフトウェア展開の自動化により、構成ミスによるインシデントが減り、開発者がアプリケーションをサポートするためのリソースのプロビジョニング要求を含めることを忘れるという問題も回避できます。 一部の環境では、開発者に独自のテスト サーバーへのアクセス権が与えられます。開発者が新しいコードをテストできるように、これらのサーバーはパブリック インターネットからアクセスできる場合があります。API テスト サーバーはパブリック インターネットで利用できる場合があり、開発者は公開されなければ検出されないと考えるかもしれません。 ゾンビAPIは、最も厳格な変更管理手順を適用しても、独自のエッジケースを伴うさまざまな方法で作成されます。間違いや誤ったガイダンスから発生するかどうかにかかわらず、ゾンビAPIは これはデータ保護にとって特に危険です。監視がなければ、攻撃者は制限やレート制限なしに何ヶ月もデータを取得できます。脆弱性の調査や悪用は記録されないため、一般的なサイバーセキュリティ分析では異常なトラフィックが管理者に通知されません。 シャドーIT ハッカーはどうやってゾンビ API を見つけるのでしょうか? 状況に応じてゾンビ API が作成される方法は数多くあるのと同様に、ゾンビ API を見つける方法も同じです。ハッカーは、コードのリバース エンジニアリング、オープン ソース リポジトリの確認、または「ファジング」と呼ばれる概念によってエンドポイントを見つけることができます。ファジングは、一般的な API エンドポイント名に対してリクエストを行うスクリプトを作成するタイプの検出です。たとえば、認証に使用される API エンドポイントには、「/login」や「/authenticate」などのエンドポイント名が付けられているのが一般的です。エンドポイントを検出するために、インフラストラクチャに対してさまざまな一般的なエンドポイント名に対してリクエストが行われます。 オープンソース リポジトリからの検出は一般的です。オープンソース リポジトリは、秘密の漏洩に対しても脆弱です。つまり、開発者が秘密鍵、認証資格情報、およびその他のプライベート データへの参照を削除し忘れる可能性があるということです。API エンドポイントへの参照も検出可能であり、脆弱性がないか調査されます。組織がコードで参照されているエンドポイントを認識していない場合、軽減策やレート制限なしで調査される可能性があります。 ゾンビ API は、必ずしもバグ攻撃に対して脆弱というわけではありません。たとえば、SQL インジェクションの脆弱性を悪用すると機密情報のデータ漏洩が発生する可能性がありますが、一部のエンドポイントは脅威に対する耐性を備えて適切にコーディングされています。ゾンビ API の状況では、API は正常に機能する可能性がありますが、制限なくデータを収集するために使用できます。エンドポイントにビジネス ロジック エラーがあり、それが悪用される可能性もありますが、監視がなければ疑わしいアクティビティは検出されません。 ゾンビ API による現実世界のデータ侵害 APIが正常に機能しているが、データを静かに列挙するために使用されている良い例は、 JustDial は、1 億人を超えるユーザーを抱えるインドの大規模なローカル ディレクトリの 1 つです。2019 年に、セキュリティ研究者が JustDial のゾンビ API が監視を実装せずにパブリック インターネットに公開されていることを発見しました。この API は、エンドポイントにリクエストを送信したすべてのユーザーに、名前、メール、携帯電話番号、住所、性別などの情報を返していました。認証は不要で、JustDial はインシデントを捕捉するための監視を行っていませんでした。 JustDial事件 セキュリティ研究者がゾンビ API を検出した後、JustDial はインシデントを修正したと主張しましたが、2020 年に同じ問題が再び検出されました。セキュリティ研究者以外の第三者が関与したかどうかは不明ですが、エンドポイントが監視なしでパブリック インターネットに公開されていたため、JustDial はデータ流出の範囲を評価できません。 もう 1 つの例は、市場で最も優秀な開発者を擁していることで知られるサンフランシスコの大手テクノロジー企業の 1 つ、Facebook です。Facebook は、ゾンビ API のインスタンスを複数経験しています。2016 年に、開発者はサブドメイン (mbasic.beta.facebook.com) を導入して、パスワード リセット機能をテストしました。API の製品版にはレート制限があったため、攻撃者はパスワードをリセットするためにユーザーに送信された 6 桁のパスコードをブルート フォース攻撃で解読できませんでした。ベータ版にはこの制限がなかったため、インターネット接続、帯域幅、および API エンドポイントのバックエンド処理速度によってのみ制限される、数秒以内に 6 桁のパスコードをブルート フォース攻撃で解読できました。 2018年、Facebookは再び この脆弱性は、Facebook の「View As」機能で発見されました。この機能により、ユーザーは自分のプロフィールを他の人と同じように表示できます。この機能の API エンドポイントはロックダウンも監視もされていなかったため、攻撃者は他のユーザーのプロフィールを表示し、アクセス トークンを盗むことができました。アクセス トークンがあれば、攻撃者はユーザーのプロフィールとデータを盗むことができます。Facebook は、4,000 万人のユーザーが影響を受け、9,000 万人のユーザーがアクセス トークンが盗まれないように再認証する必要があったと推定しています。 ゾンビAPI攻撃 2022 年、Travis CI のエンドポイントで、小規模ながら重大なゾンビ API によるデータ侵害が発生しました。Travis CI は、インフラストラクチャとコードのデプロイに使用される自動化ベンダーです。Travis CI の API エンドポイントの 1 つでは認証が不要で、顧客のログ イベントを取得するリクエストが許可されていました。さらに悪いことに、ログはプレーンテキストで保存されていたため、アクセス キーを含むユーザー ログ データを制限なく取得できました。この問題が報告されたとき、Travis CI は、アクセス トークン、キー、クラウド資格情報を含む 7 億 7,000 万件のユーザー ログ レコードが盗まれたと推定しました。 ゾンビ API の検出 理想的には、ソフトウェア開発者はインフラストラクチャの変更を文書化して、変更管理に新しい API エンドポイントが含まれるようにします。その後、運用担当者はエンドポイントを監視エージェントに追加し、これらのエージェントはデータを収集して、サイバーセキュリティおよび分析モニターが疑わしいアクティビティが検出されたときに管理者に通知できるようにします。エンドポイントが文書化されていないと、監視エージェントはエンドポイントを認識しないため、ゾンビ API が発生します。監視を行わないと、分析や管理者アラートなしで、あらゆるリクエストがサーバーに送信されてしまいます。 潜在的なゾンビ API に対処するために、管理者はトラフィックを検出するエージェントをネットワークにインストールすることがよくあります。エージェントはトラフィック データを収集し、サーバーやその他のネットワーク インフラストラクチャ上のオープン接続を検出します。この戦略の問題は、ゾンビ API は、発見されるまでトラフィックやリクエストがないまま休止状態になることが多いことです。開発者、運用担当者、またはインターネット上の第三者によって発見される可能性があります。第三者がエンドポイントを見つけて初めてトラフィックがログに記録されますが、リクエストによってアラートがトリガーされるわけではありません。ゾンビ API は、「ハッキング」や不正なクエリなしで標準的なリクエストを許可します。これが、ゾンビ API がデータ漏洩にとって非常に危険な理由です。 人工知能を使用してゾンビ API を発見する エージェントに頼ってゾンビ API をリアクティブに検出するよりも、人工知能とコードのスキャンを活用する方がよい解決策です。この戦略には 2 つのフェーズがあります。リポジトリ コードをスキャンして内部 API への参照を探すことと、イベント ログを使用して API がリクエストを受信したかどうかを判断することです。 最初のステップは、コードをスキャンして API への参照を探すことです。これらの API は外部または内部の可能性がありますが、このインフラストラクチャは独自のデータに影響を与えるため、内部 API に重点を置く必要があります。参照は、アクティブなリポジトリと非推奨のリポジトリの両方を含む多数のリポジトリに存在する可能性があります。コード内に参照があることに気付いていない場合もありますが、スキャンすると参照が検出され、リストが人工知能 (AI) に送信できるようになります。 次は、イベント ログを取り込んで分析するために使用される大規模言語モデル (LLM) です。イベント ログは、行単位のデータがギガバイトまたはテラバイトになる可能性もあります。イベント ログは、サイバー セキュリティとインフラストラクチャの使用状況の監視に不可欠なため、API をホストするサーバーに設定する必要があります。API エンドポイントがコード内で参照されているが、トラフィック イベントがほとんどまたはまったくない場合は、ゾンビ API である可能性があります。参照と多数のイベント ログがある API は、使用および監視されているため、ゾンビ API とは見なされません。 LLMを使用してすべてのAPIエンドポイント参照の分析を処理するには時間がかかりますが、その結果は、環境内のアクティブなAPIを認識していない管理者を驚かせる可能性があります。例として、 最近、189 個のゾンビ API が見つかり、そのうち 11% が個人識別情報 (PII) にリンクしていました。この発見は、2,063 個のエンドポイントをスキャンし、Domino's Pizza India の環境全体のイベント ログを 2.2 日かけて分析した後に行われました。 ドミノ・ピザ・インドのケーススタディ ゾンビ API を監視する必要がありますか? 答えは「はい」です。ゾンビ API により、顧客データ、内部データ、その他の重要な情報が漏洩する可能性があります。コンプライアンスを遵守した環境では、この見落としにより数百万ドルの罰金が発生する可能性があります。訴訟、ブランドの毀損、収益への影響、その他さまざまな悪影響は、データ侵害につながる監視されていないインフラストラクチャに関連しています。 組織の環境をより良く可視化することは、サイバーセキュリティと迅速なインシデント対応にとって重要です。クラウドにインフラストラクチャを展開する組織が増えるにつれて、ゾンビ API などの未解決の問題がないことを確認することがこれまで以上に重要になります。インフラストラクチャを文書化することは素晴らしい第一歩ですが、一部の API が漏れてしまう可能性があります。コードを継続的にスキャンすると、ゾンビ API を特定するのに役立ちます。ゾンビ API は、無効にしたり、監視エージェントに追加したりできます。インフラストラクチャの可視性が向上すると、機密データが漏洩するリスクが減り、攻撃対象領域が縮小します。
