公開された管理者情報と IoT コマンド：電動スクーター運営会社の完全乗っ取り事例

⚠️ 免責事項

本記事内の企業名、ドメイン、アプリ情報、および個人情報はすべて架空の事例に基づいています。実在する企業や個人とは一切関係ありません。

1. 事案の発端と背景

ある企業が都市内に多数の電動スクーターを投入し、市民が新しい移動手段として活用しました。著者は、このサービス背後で動作する**未確認インターネット接続機器の大規模フロート（車両群）**に警戒感を抱き、以下の調査を開始しました。

• 提供主体の確認：Google で公式ウェブサイト

  electricscootercompany.com.br

  を発見。
• サービス経路の特定：
  • スマホアプリの起動
  • スクーター QR コードの読み取り
  • 利用料の支払い（ロック解除）
  • 走行開始

著者は「ユーザーにとっての理想的な体験」を、裏側の技術実装として詳細に検証しようとしました。

2. ステップ別調査プロセス

ステップ 1：情報収集（Reconnaissance）

公式ドメイン

electricscootercompany.com.br

• 主要ホスト: www, app, api, dev, membros, vouchers, planos, validate, painel
• コンテンツ分析:

  • app

    ,

    membros

    などはアプリストア誘導ページ（実機能なし）。

  • dev

    ：500 エラーが発生するが有用な情報なし。

  • validate

    ：「アカウントが見つかりません」と返すが、受付けパラメータ不明。

発見された重要なアーキテクチャ:

1. マーケティングサイト:

   www.electricscootercompany.com.br

   (WordPress)
2. 公開 API:

   api.electricscootercompany.com.br

   (REST API)
3. 管理パネル:

   painel.electricscootercompany.com.br

   (Angular ベース)

重要な発見: 公式ウェブサイト内には「管理パネル」へのリンクが一切存在しません。しかし、アクセス可能であり、内部構造を解明できる状態でした。

ステップ 2：認証なしでのパネルアクセス試行

管理パネルは生产環境として動作しており、JavaScript チャンク解析から 83 のエンドポイントが発見されました。

• 対象カテゴリ: ユーザー権限、車両・マップ、IoT デバイス、財務データなど。

初期攻撃の失敗（HTTP 401 リターン）:

• 直接ルートへのアクセス：認証ブロックにより拒否。
• 署名なしの管理者 JWT：バックエンドで拒否。
• トークン改ざん：無効化された。
• SQL インジェクション：ログイン画面やレポートエンドポイント（

  php/report.php

  ）から脆弱性は発見できず。
• ファイル公開：

  .git

  ,

  .env

  , ソースマップなどが漏洩していない。

転換点: 認証は機能しているが、アプリ自体が「実在するユーザーアカウント」を狙うべきであることを示唆していた。

ステップ 3：WordPress API を活用した情報取得

WordPress の公開 REST API

wp-json/wp/v2/users

• 取得情報: ユーザー ID 1、公開名「admin」、スラッグ「electricscootercompany」など。

この情報を管理パネルのログインフォームに試行した結果、以下の反応を得ました。

• 既存ユーザー + 不正パスワード：

  Senha inválida

  （無効なパスワード）
• 存在しないユーザー：

  E-mail não encontrado

  （メールアドレスが見つかりません）

結論: このスラッグ名は単なるブログではなく、運用システム内でも有効なアイデンティティであることが確認されました。汎用的な列挙が具体的な攻撃ターゲットに限定されました。

ステップ 4：ブルートフォース攻撃と権限獲得

上記のユーザー名に対し、パスワードの推測（ブルートフォース）を開始しました。

• スローリングなし: 速度制限がかかることがなく、試行錯誤を繰り返せる状態でした。
• 結果: やがて有効なパスワードが見つかり、レベル 1000 の管理者権限を持つトークンを取得しました。

取得したセッション情報の一部:

{
  "data": {
    "PK_Usuario": 2,
    "email": "electricscootercompany",
    "nome": "ElectricScooterCompany",
    "nivel": 1000,      // 管理者ロール
    "fk_empresa_grupo": 1
  }
}

• 有効期間: トークンの有効期限が約 950 日と極めて長く設定されていたため、一度取得すれば数年間利用可能です。

ステップ 5：管理パネルからの機密情報読み取り

有効なセッションを取得後、以前は 401 エラーだったルートが正常に動作し始めました。以下のような広範なデータにアクセスできるようになりました。

• 地理情報: ガレージ・ドックの位置マップ（

  /mapas/__veiculos

  ）、地理的フェンス（

  /fronteiras/__coordenadas

  ）
• ハードウェア管理: IoT デバイスリスト、車両個別詳細、バッテリー残量など。
• ユーザーデータ: 480,000 件以上のアプリ利用者の個人データ。
• 財務・取引: トランザクション履歴、ギフト券バッチ情報など。

レスポンスサイズの例:

• /mapas/__veiculos

  : ~593 KB

• /iots/.../free/true

  : ~1.2 MB（非常に大容量）

ステップ 6：単なる閲覧から「制御」へ

パネルはデータだけでなく、**書き込み操作（PUT リクエスト）**も可能でした。

• 対象: 車両レコード、ユーザーアカウント、ギフト券バッチの編集。
• 機能: テストアカウントへの「無料利用（Free Ride）」フラグの切り替え。
• 車両管理: 数千台のスクーターから任意を検索し、以下の物理コマンドを送信可能。

  • Unlock

    （ロック解除）

  • Lock

    （ロック）

  • Restart IoT

    （IoT モジュール再起動）

IoT コマンド実行例:

POST /iot_sends/
Content-Type: application/json
{"pk_veiculo":699,"comando":"open"}

バックエンドから「コマンド送信済み」との確認メッセージを受け取りました。

物理的な検証:

• 友人を雇い、コマンド実行時に近づくスクーターにライトが点灯し、ロックが解除されたのを撮影で確認。
• QR コードスキャンや支払いなしで乗車可能な状態となりました。

3. 調査における「死胡同（行き止まり）」

すべての攻撃経路が成功したわけではありません。以下は試行錯誤の過程と失敗事例です。

モバイルアプリのインターセプト

• Android アプリ（Flutter/

  libapp.so

  ）からのトラフィックキャプチャに多大な試行が必要でした。
• 特定の組み合わせ（証明書、プロキシ）のみで成功し、API の署名方式を特定しました。しかし、これはパネルへの侵入には直接つながりませんでした。

広範囲なマップクエリの拒否

• 通常は有効なクエリでも、国全体規模の広大すぎるバウンディングボックスを指定すると

  403 Forbidden

  を返すようになり、セッションが破棄されました（粗い異常検知フィルタか、トークン破棄によるもの）。

横断アクセスとインジケータ漏洩

• 他人の移動履歴へのアクセスは不可能（400 エラーや空セットのみ）。
• しかしレスポンスヘッダに

  T_app_usuario_viagem

  や PHP の内部エラーメッセージが漏洩していました。

SQL インジェクションと JWT バイパスの失敗

• クレデンシャル取得前の SQLi 試行、署名なし JWT の改ざん試行はすべて拒否されました。
• 最終的な突破は複雑な脆弱性ではなく、列挙されたユーザー名と推測可能なパスワードによるものでした。

4. 根本原因の分析：連鎖するセキュリティ失敗

本件では「エキゾチックなバグ」よりも、アイデンティティ・認証・権限管理の積み重ねるミスが致命傷となりました。

1. 情報漏洩: WordPress がユーザー情報を公開していた。
2. アカウント発見: 公開名が実システム内でも有効な ID として認識されていた。
3. 弱いパスワード: ブルートフォース耐性（スローリング）がなかったため、強制的にパスワードを推測できた。
4. 高権限付与: 推測したパスワードで取得したトークンが**レベル 1000（管理者）**であった。
5. 長期有効トークン: トークン期間が約 950 日と長すぎて、一度奪えば長期にわたりアクセス可能だった。
6. 過剰な権限付与: 管理パネルから IoT コマンドを直接発射できる機能があった。
7. 二重認証の欠如: IoT コマンド実行前に「もう一度ログインするか」「追加確認」のプロセスが存在しなかった。

結論: パスワードという「開かれた鍵」が、インターネットと物理的なハードウェア（スクーター）の間にある唯一の障壁となっていました。

5. リスクと実務的な影響

単一の管理者アカウントを盗み出された場合、攻撃者は以下を実行可能です。

• 機密情報アクセス: 運用パネル、全車両マップ、地理的フェンス、IoT デバイスリスト、ユーザー個人データ、財務データの閲覧。
• ビジネス操作: ユーザーのステータス変更（無料利用付与）、記録の編集。
• 物理的リスク: 遠隔でスクーターをロック解除し、無断で使用させる。
  • 不正な車両利用による事故リスク。
  • サービスの信頼性低下と法的責任。

6. まとめ

遠隔ロック解除の脆弱性は、複雑な暗号学的欠陥からではなく、最も素朴で明白な攻撃手法によって突破されました。

• 成功要因: 忘れられたサブドメインの存在、公開されたユーザー情報、エラーメッセージからのヒント、スローリングのないブルートフォース。
• 失敗した高度な技術: 偽造 JWT は拒否され、SQLi も機能せず、認証ルートも正常に働いていました。
• 教訓: 物理デバイスの制御権をウェブブラウザ経由で開放している場合、その権限は「推測可能なパスワード」と「適切なセッション管理」だけで守らなければなりません。 第二の防御ライン（MFA や追加確認）が必須です。