この Red Agent POV では、ビジネスロジックの欠陥に焦点を当て、大手B2BプラットフォームのデータAPIで発見された深刻なペイウォール回避について深掘りします。継続的なミッションの一環として、 Red Agent はパブリックインターネットとお客様の環境を継続的にスキャンし、実際の環境で悪用可能なリスクの発見を支援しています。完全に自律的に動作し、アプリケーションをマッピングし、データの公開メカニズムをリバースエンジニアリングし、クライアント側で制御可能な単一のフラグによって、1クレジットも消費することなく、6億件以上の全プロフィールの連絡先情報を含むプラットフォーム全体のペイウォールで保護されたデータセットが解除されることを確認しました。
ビジネスロジックの欠陥とは何でしょうか？
ほとんどの脆弱性クラスは、インジェクション、オーバーフロー、破損したトークンなど、形式に異常があるものを伴います。しかし、ビジネスロジックの欠陥は異なります。何も壊れておらず、何も問題がないように見えます。リクエストは完全に有効であり、サーバーは要求された通りの動作を正確に行います。しかし欠陥となるのは、そもそもそのリクエストを受け入れるべきではなかったという点です。
これらのバグは、アプリケーションが許可する はず の動作と、 実際 に適用している制御の間のギャップに存在します。
これこそが、従来のツールをすり抜ける理由です。SASTはコードを読み取りますが、何千もの有効なパスのどれがビジネスルールに違反しているかを認識できません。DASTやシグネチャスキャナーは既知の悪質なパターンを探しますが、本来受け入れられるべきではない正規のリクエストにはシグネチャが存在しません。これらの欠陥を見つけるには、アプリケーションの「 意図 」を推論する、つまりシステムが何を保護しようとしているのかを理解し、実際に保護できているかをテストする必要があります。
Red Agentは何を発見したのでしょうか？
Red Agentは、数億件のビジネスメールアドレスと検証済み電話番号を保有するB2Bプラットフォームをスキャンし、無料プランのユーザーが料金を支払うことなく非マスク処理の連絡先データにアクセスできる認可バイパスを発見しました。
このプラットフォームのビジネスモデルは、このデータのアクセス制御に完全に依存しています。ビジネス連絡先の膨大なデータベースを保持し、個々のレコードのマスクを解除して公開するためにユーザーにクレジットを請求し、無料プランのユーザーに対してはマスクされた状態を維持します。しかし、この公開を管理するメカニズムは、APIリクエスト内の単一のパラメータフラグに依存していました。標準インターフェースではクレジットシステムを適用するためにこのフラグを省略していましたが、手動で追加された場合、バックエンドはユーザーの実際の権限を検証することなくこれを受け入れていました。
標準の無料プラン検索にこの単一の値を追加するだけで、制限は完全に回避されました。システムは、完全にマスク解除されたビジネスメール、直通電話番号、および関連する個人のメールアドレスを平文で返しました。その結果、プラットフォームの主な認可および収益化の制御が侵害され、任意の無料アカウントから有料データを大規模に取得できるようになりました。
| What was exposed | Scope |
|---|---|
| Business email addresses | 600M+ contacts |
| Direct phone numbers | 135M+ verified |
| Personal email addresses | ~50% of records, leaked by default |
| Company intelligence | Revenue, headcount, direct lines, addresses |
どのようにしてこのエクスプロイトを発見したのでしょうか？
Red Agentは事前知識ゼロでターゲットにアプローチし、推論ベースのテストを頼りにシステムのメンタルモデルを構築し、動的に適応しました。無料アカウントのみで動作し、エージェントは偵察、仮説生成、エクスプロイトの3つの明確なフェーズを実行しました。
アクセス制御の欠陥をどのように解明したかの概要は以下の通りです：
ステップ1：偵察とバンドル分析
Red Agentは、クライアント側のJavaScript分析を通じてアプリケーションのAPIサーフェスをマッピングすることから開始しました。130MBを超えるフロントエンドコードバンドルを分析することで、プラットフォームの中核となるデータ操作を支える内部プレフィックスを含む、100以上の異なるAPIエンドポイントパスを抽出しました。
発見されたエンドポイントには次のようなものがありました：
POST /api/internal/data/hPeopleSearchPOST /api/internal/data/hPersonLookupPOST /api/internal/data/hUnifiedSearch
ステップ 2: 仮説の生成とスキーマのリバースエンジニアリング
フロントエンドのコードベースに埋め込まれたリクエスト/レスポンスのスキーマを分析する中で、エージェントは特定のパラメーター（例：unmaskContactData）を特定しました。このブーリアンフラグはコード内で参照されていましたが、通常の無料プランの検索フロー中に実際に使用されたり送信されたりすることはありませんでした。UIは常に公開操作の処理をサーバーのクレジットシステムに依存していました。
これがエージェントの核となる仮説の形成につながりました： フロントエンドがこのフラグを認識しているため、バックエンドもこれを受け入れる可能性が高い。サーバーはフラグを適用する前にユーザーの権限を検証するのだろうか、それともクライアントの入力を盲目的に信頼するのだろうか？
ステップ 3: ベースラインの測定
これをテストするため、エージェントは無料プランのアカウントから通常の検索リクエストをキャプチャしてベースラインを確立しました。これにより、標準的な運用中、バックエンドのマスキングが有効であり、意図したとおりに機能していることが確認されました：
{
"firstName": "John",
"lastName": "Smith",
"email": "XXXXX.XXXXXXX@XXXXX.XXX",
"phone": "(XXX)-XXX-XXXX",
"companyName": "[REDACTED] Corp"
}
ステップ 4: パラメーターインジェクションによるエクスプロイト
その後、Red Agentは1か所だけの変更を加えて、まったく同じ検索リクエストを再実行しました "unmaskContactData": true— 発見した公開フラグをJSONペイロードに注入：
curl -s -X POST "https://app.[REDACTED].com/api/internal/data/hPeopleSearch" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <JWT>" \
-d '{
"page": 1,
"rpp": 200,
"fullName": "smith",
"unmaskContactData": true,
"sortBy": "Relevance"
}'仮説どおり、サーバーはユーザーのクレジット残高やプラン権限をチェックすることなくフラグを受け入れました。レスポンスでは、レコードが完全にマスキング解除された状態で返されました：
{
"firstName": "John",
"lastName": "Smith",
"email": "john.smith@example.com",
"phone": "(555) 019-8372",
"companyName": "[REDACTED] Corp",
"isMasked": false
}プラットフォームのセキュリティチームは非常に迅速に対応し、同日中に脆弱性を修復しました。同組織のシニアプロダクトセキュリティアーキテクトは、迅速な解決を次のように認めました：
今朝レポートのトリアージが行われた後、当社のチームは指摘事項を検証し、その後2時間未満で問題を修復することができました。迅速な対応が示しているように、当社はこの種の問題を非常に真剣に受け止めています。
なぜこれが重要なのか
本質的に、この一連の侵害はすべて単一のアーキテクチャ上の過ちに起因しています。それは、バックエンドがクライアントによって管理されている値を信頼したことです。これこそがビジネスロジックの欠陥の決定的な特徴です。不正な形式の入力も、高度なエクスプロイトペイロードも、メモリ破損も存在しませんでした。書かれることのなかった認可チェックの代わりに、「UIがそのフラグを送信することは決してない」という暗黙の前提が存在しただけなのです。
従来のセキュリティツールがこの種のバグの検出に失敗するのは、まさにこれが理由です。自動スキャナーは正規のエンドポイントへの有効なリクエストを正常なトラフィックとして登録し、静的解析（SAST）はコードが正常にコンパイルされ、記述どおりに実行されることを検証しますが、その実行を規定するビジネスルールを評価することはできません。
このような欠陥を発見するには、外部からの視点だけでなく、根本的なビジネスモデルを理解し、アプリケーションが何を保護すべきかを特定し、保護が強制されるのではなく前提とされている可能性がある部分を積極的にテストする必要があります。歴史的に、このレベルの文脈的分析には高度なスキルを持つ人間のペンテスターが必要であり、ほとんどの場合、厳格な時間的制約のもとで動作し、アプリケーションの攻撃対象領域のほんの一部に制限されていました。
自律型AIペンテスティングへの移行により、チームはこのようなビジネスロジックの欠陥を発見しやすくなります。AIエージェントはアプリケーションのエコシステム全体にわたって意図を推論し、動的に仮説を生成・検証し続けることができます。AIを活用した攻撃者から保護するために必要な、人間のチームでは到底再現できないスケールとスピードで動作します。このAI時代において、マシン速度の唯一の防御策は、攻撃者が実行する前に、まったく同じ種類の継続的なAI駆動型攻撃を自社システムに対して配備することです。
重要なポイント
ビジネスロジックの欠陥は盲点であり— それらは 疑わしいペイロード、シグネチャ、不正形式の入力がなく、アプリケーションが拒否すべきであった有効なリクエストが含まれているだけの場合もあります。SAST、DAST、およびシグネチャスキャナーは、構造上これらを検出できません。これらを見つける唯一の方法は、アプリケーションの意図について推論することです。
ビジネスルールの適用をクライアントに委ねてはなりません— ブリーチ（侵害）の全容は、バックエンドがfalseからtrueに切り替えられたフラグをそのまま受け入れたことでした。権利授与、価格設定、アクセスの決定は、インターフェースから送信された内容から推測するのではなく、毎回、レコードごとにサーバー側で強制される必要があります。
AI攻撃者はすでに存在しています— 無料層のアカウントから、自律型エージェントが製品におけるアクセスの収益化手法を推論し、それを支えていた1つの前提条件を見つけ出して覆しました。これらはすべて人間の指示なしに、マシン速度で行われました。フロンティアモデルを持つ攻撃者なら誰でも同じことができます。防衛側にも、内側に向けられた同じ機能が必要です。
Red Agentの成果をさらにご覧になりたいですか？
シリーズのすべての ブログ記事 をお読みになり、Red Agentが発見するリスクの例をさらにご確認ください。お客様の環境でどのような種類のリスクを発見できるかを確認したい場合は、 Red Agent （要ログイン）の詳細をご覧いただくか、当社チームとの ライブデモ をご予約ください。
