デートアプリをハッキングした経験、そしてセキュリティ研究者への誤った対応

 (alexschapiro.com)
2 ポイント 投稿者 GN⁺ 2025-05-13 | 1件のコメント | WhatsAppで共有
  • Cerca Dating Appは電話番号ベースのログインと露出したAPIが重なり、OTPレスポンスに認証コードが含まれ、個人情報の照会にまでつながり得る危険な状態だった
  • api.cercadating.comはアプリバージョンのヘッダーを付けると、/docs の openapi.json からエンドポイントが露出し、一部のリクエストでは強制マッチングのようなビジネスロジックまで操作できた
  • user/{user_id} は有効なユーザーIDだけで、名前、位置、生年月日、学校、電話番号、メールアドレス、プロフィール状態などの PII を返し、OTP脆弱性と組み合わさるとアカウント乗っ取りにつながり得た
  • アカウントにアクセスした後は、提出済みのユーザーに限りパスポートまたは身分証明書情報、セルフィーURL、私的なメッセージにまでアクセス可能で、確認スクリプトによりユーザー6,117人、ID情報入力者207人、Yale学生と表示されたユーザー19人が見つかった
  • 脆弱性は2025年2月23日にCercaへ報告され、2月24日には通話も行われたが、4月21日の公開時点まで追加の回答やユーザー通知はなく、パッチ適用の有無だけが独立に確認された

報告後に途絶えた対応

  • Cerca Dating Appには、私的なメッセージ、パスポート情報、性的嗜好、その他の個人情報が露出し得るデートアプリのセキュリティ脆弱性があった
  • 脆弱性を発見した後、2025年2月23日にCercaチームへメールで報告し、翌日のビデオ通話で脆弱性、緩和策、フォローアップ対応について議論した
  • Cercaチームは問題の深刻さを認め、責任ある開示に感謝し、脆弱性の修正と影響を受けたユーザーへの通知を約束した
  • その後、3月5日と3月13日に修正およびユーザー通知計画のアップデートを求めたが、2025年4月21日の公開時点まで返答はなかった
  • 公開前に脆弱性がパッチ適用済みであることは独立に確認されており、それを踏まえて公開が行われた

OTPログインから始まったアカウントアクセス

  • アプリは電話番号にコードを送るOTPベースのログインのみを使用していた
  • ネットワークリクエストを確認するため、iPhoneアプリで Charles Proxy を使ってアプリのリクエストを傍受した
  • OTPをトリガーするレスポンス内に、ワンタイムパスワードが直接含まれていた
  • この構造では、ユーザーの電話番号さえ分かればそのアカウントにアクセスできた
  • アカウント所有者の電話番号を見つける別経路が必要になり、APIエンドポイントの探索へつながった

OpenAPIドキュメントで露出したエンドポイント

  • api.cercadating.com に対してディレクトリファザーを使い、パスを列挙した
  • アプリ関連ヘッダーなしでは、サイトのどの部分にもアクセスできなかった
  • Gobuster にそのヘッダーを付けてリクエストすると /docs エンドポイントが見つかり、そこで openapi.json が提供されていた
  • Burp Suiteのmatch-and-replace機能で、アプリバージョンヘッダーとCharles Proxyから抽出したbearer tokenを常に付与するよう設定した
  • 一部の保護されていないエンドポイントはビジネスロジックに影響を与え、2人を強制的にマッチングさせるリクエストも可能だった

ユーザープロフィールと個人情報の露出

  • user/{user_id} エンドポイントは、有効なユーザーIDを受け取ると多様な個人情報を返した
  • レスポンスには次の情報が含まれていた
    • 名前、性別、関心のある性別、都市、緯度・経度
    • 学校メールアドレスと認証状態、業界、職業、生年月日、身長
    • 学校IDと学校名、プロフィール完了の有無
    • 国籍ID認証の有無、モバイル・メール認証の有無
    • プレミアム状態、アカウントの有効・一時停止・オンボーディング状態
    • 電話番号、メールアドレス、ユーザーID、検索残り回数
    • プロフィール画像、マッチング希望条件、ユーザープロンプト、相互連絡先情報、作成・更新時刻、年齢など
  • Pythonスクリプトで有効なユーザーIDを見つけ、ユーザーデータを大量に列挙できた
  • 返された電話番号はOTP脆弱性と組み合わされ、アカウント全体へのアクセスに使われ得た
  • OTPログインなしでもユーザーの個人情報が露出している状態だった

身分証と私的メッセージにまでつながったアクセス

  • national_id_verified フィールドは、パスポートまたは身分証明書情報がシステムに保存されていることを示している
  • 身分証関連のレスポンスには次の情報が含まれていた
    • verification_type: PASSPORT
    • document_number
    • front_side_url
    • back_side_url
    • selfie_url
    • 状態、ID、ユーザーID
  • この情報はログイン済みユーザーにのみ提供されるが、OTP脆弱性により任意のユーザーとしてログインできる状態だった
  • 提出済みのユーザーについては誰のID情報でも見られる構造だったが、実際にはそうしなかったと述べている
  • 潜在的なデート相手との個人メッセージも見られ、提出済みの場合はパスポート情報にまでアクセス可能だった

確認された露出規模

  • 簡単なスクリプトで、情報を取得できるユーザー数、Yaleの学生として登録されたユーザー数、ID情報を入力したユーザー数を集計した
  • スクリプトは有効なユーザーIDを数え、1,000件連続で有効なIDが見つからなければ停止する方式だった
  • この方式は、さらに多くのユーザーがいる可能性を排除するものではない
  • Cercaは最初の週のユーザー数を1万人と発表していた
  • 確認された数値は次の通り
    • ユーザー 6,117人
    • ID情報を入力したユーザー 207人
    • Yaleの学生だと表示したユーザー 19人

個人情報保護の約束と実際のリスク

  • Cercaのプライバシーポリシーは「暗号化およびその他の業界標準の措置でデータを保護する」と述べている
  • 実際の脆弱性の状態と比較すると、この文言は誤解を招くおそれがある
  • 露出対象には性的嗜好、私的なメッセージ、多様な個人情報が含まれ得た
  • 悪意あるユーザーがその情報にアクセスすれば、なりすまし、ストーキング、脅迫といった結果につながり得る
  • デートアプリは機微なデータを扱うため、アプリ公開のスピードよりもユーザーデータのセキュリティが優先されるべきだ

関連記事

1件のコメント

 
GN⁺ 2025-05-13
Hacker Newsのコメント

  • このアプリは、大学生が作ったかなり初期段階のプロジェクトに見える。セキュリティとコミュニケーションの慣行をきちんと守るよう最善を尽くすべきなのは確かだが、似たような問題で大手VCから投資を受けた「大人の会社」でもひどい対応をすることを考えると、あまり厳しく責め立てたいとは思わない。
    https://georgetownvoice.com/2025/04/06/georgetown-students-c...

    • 強く反対する。「何をしているのか分かっていなかったのだから、あまり厳しく判断しないでおこう」というのはおかしい。何をしているのか分かっていないのにリリースまで進めたのなら、情状酌量ではなく、むしろ加重要素に近いと思う。
      運転手が事故で人を死なせたが、実は免許すら持っていなかった、というケースに似ている。
    • 「Cerca」の情報を探していて同じリンクを見たが、2025年4月の記事で、2か月前に作られたアプリを称賛する内容なので、LLMの幻覚みたいなゴミ記事に見える。
      元記事では2月にCercaチームへ連絡したとあるので、リリース日に見つかった欠陥なのか、何かおかしな構造なのだろう。いずれにせよ「2か月前からある脆弱性」であり、「2か月前に学生が作ったアプリ／サービス」でもある。
    • アプリがCerca Applications, LLC名義でリリースされているなら、単に大目に見てよいスクリプトキディ数人なのかどうか、どうやって分かるというのか。
    • この人たちは、たぶん別の専攻を学んだほうがよさそうだ。
    • 一理あるが、それでもこれはひどすぎる。秘密であるべきOTPをレスポンス本文で返さないことは、熟練開発者でも高校生でも常識に近い。
      しかも趣味で作ったものではなく商用製品だ。アプリ内購入として、Cerca App $9.99、Cerca App 3 month $9.99、10 Swipes $2.99、3 Swipes $0.99、5 swipes $1.99、3 Searches $1.99、10 Searches $3.99、5 Searches $2.99が掲載されている。

  • 小さな会社のエンジニアとして、時々自分の個人責任が心配になる。PCIやHIPAAが適用されない非規制業種で運営されている会社は非常に多く、小さな組織ではセキュリティが組織レベルの責務ではなく、単なるエンジニアリング上の関心事に追いやられる。
    プロダクトチームは機能、PMはスケジュール、QAはバグ発見に集中し、セキュリティについて合理的に声を上げる人はめったにいない。エンジニアには、ボードに上がった作業を終える以上のことは期待されない。スケジュールに影響を出さず安全に作れるならよいが、そうでなければPMなどから圧力を受ける。
    「それはどれくらい時間がかかるのか」「実際にそんなことが起きるリスクはどれくらいあるのか」「セキュリティ対応は後でやって、まずはMVPを顧客に出そう」といったことを言われる。従業員としては雇用主に指示された仕事をしているのに、ハッキングやデータ漏えいで会社が訴えられたら、「知っているべきだった」唯一の人物だという理由で、自分が個人的に責任を負うことになるのだろうかと思ってしまう。

    • 厳密に言えば、本物の工学エンジニアではない。安全性を認証する設計図面に署名することもないだろうし、安全でないと証明されても、その責任を負うことはないだろう。
    • LLCや法人であれば、犯罪行為をしたと文書に残していない限り、法人格のベールによって保護される可能性が高い。
      ただし、規模を問わず組織全体でセキュリティ基準が欠けているのは嘆かわしい。良いセキュリティ慣行を保証することより、新機能のリリースが常に優先されているように見える。
    • 個人的には、自分を守れる程度には法律を知り、違法なことには書面で反対し、それを無視しろという指示も書面で承認を取っておきたい。
      ただ、スタートアップで開発者が1人か2人しかいないなら、これすら難しいのは理解できる。合法的なことを追求していないと感じたら、自分なら去ると思う。
    • 小さな組織のエンジニアなら、チームの他のメンバーにこうしたセキュリティリスクを教育し、それを軽減するためのエンジニアリング時間を確保するよう働きかける責任があると思う。
      簡単ではないが、真剣に扱わなければ事業そのものを沈めかねない重要なことだ。
    • 「命令に従っただけ」という抗弁は好きではないが、このような場合なら必ず書面の記録を残すべきだ。
      セキュリティ不足への懸念を提起したメールの記録と、上司が気にするなと返した記録が必要だ。どの地域かは分からないが、一般従業員個人がデータ漏えいについて法的責任を負った事例は知らない。通常、データ漏えいでは誰も実質的な結果を被らず、会社が形式的な罰金だけ払って済むことが多い。

  • 研究者として法的リスクを減らすには、2つ目のアカウントを作るか、友人にプロフィールを作ってもらい、アクセスの同意を得る程度で十分だったはずだ。
    列挙脆弱性を証明するために、実際にデータをスクレイピングする必要はない。自分のIDが12345で、友人が登録して12357を受け取ったなら、任意のユーザーIDを見つけてプロフィールにアクセスできるという証拠として十分だ。
    他の人も言っているように、脆弱性を検証して公開するために、他のユーザーの個人識別情報へそこまで大量にアクセスする必要はない。

    • これは、ほとんどのセキュリティ研究者が無視している標準的で明白な方法だ。
      個人識別情報が保護されることを望みながら、それをスクレイピングして証明するのは不要で偽善的だ。

  • 文章がかなり混乱している。OTPベースのログインで、ワンタイムパスワードのリクエスト応答にOTPがそのまま入っているという部分は説明不足だが、おそらく api.cercadating.com/otp/ のようなAPIで、電話番号を推測すれば、その番号を所有していなくてもOTPコードを受け取れるという意味に見える
    また、連続する1,000個のIDに有効ユーザーがいなければ停止するスクリプトで6,117人、身分証情報を入れていた207人、Yale学生だと主張していた19人を見つけたと言っているが、これがどれほど危険なのか筆者が分かっているのか分からない。実質的には weev が AT&T に侵入した手口に似ていて、彼は刑務所に入った[0]
    より大きな会社で、より大きな漏えいではあったが、セキュリティホールを利用して数千人のデータへ無断アクセスしたと公に自慢することはないと思う。道徳性を判断したいわけではなく、セキュリティ研究者には警告する余地があるべきだと思うが、法律はセキュリティ研究者にかなり不利だ
    [0] https://en.wikipedia.org/wiki/Goatse_Security#AT&T/iPad_emai...

    • 電話番号の推測に触れており、OTPを送るAPI呼び出しが文字通りOTPを返すとされている
    • Auernheimer事件の元の訴状を読んでみると、検察はここにはおそらくないような、広範な故意性の証拠を持っていた
      その事件の被告らは基礎となる個人識別情報を公開したことでも訴えられていたが、ここではそうしたことがあったようには見えない

  • 別のデーティングアプリで似たようなことを経験したが、そちらは結局返答がなかった。創業者の注意を引こうとして、彼のプロフィール文を「連絡してほしい」という文言に変えたら、バックアップを復元していた
    数年後、Instagram広告を見て問題がまだあるか確認してみたところ、まだ残っていた。アプリ-プロキシ-サーバーで簡単に見つけられるAPIエンドポイントさえ知っていれば、誰でも完全な管理者権限を持ち、すべてのメッセージやマッチングなどにアクセスできる構造だった
    もう一度行って再挑戦すべきかと思っている

    • 責任ある開発者らしく、連絡先に脆弱性開示だけして終わりでいいのではないかと思う

  • パスポートや住所のようなセンシティブな情報を受け取る前に、人々が二度考えるよう強制すべきだ。こういうことは単に子どもがアプリを作っただけとして片付けるわけにはいかない

    • パスポートや他の身分証情報は、入力後に公開表示する理由がまったくない。UIに表示するためにAPIでデータを取得する必要があるとしても、パスポート/身分証番号全体を含める必要はなく、少なくとも末尾数桁だけ送るようにマスクできる
      デーティングサイトなら、APIは身分証の状態について verified/not-verified のブール値、あるいは「not-verified」「passport」「drivers-license」のような列挙値を返すだけで十分だ。クライアント/UIに詳細情報を表示する実際の必要はない
      航空会社アプリのように、出入国目的の身分証明書を選ばなければならない場合は例外的により多くの情報を見せることもあり得るが、Unitedアプリのようにパスポート番号の末尾数桁だけを見せればよい。内部APIでもその程度だけを送ってほしい
    • 英国政府はポルノサイトへのアクセスに身分証確認を義務付けようと躍起になっているが、それが自分たちの顔面で爆発する日が楽しみだ
    • 政府が運営する、安全でプライベートな本人確認サービスのようなものがあるべきだ
      あるいは Apple や Google のような「政府っぽい」存在が担ってもよい
    • GDPRを見ればいい
      https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
    • サードパーティの本人確認サービスを使っていなかったのだろうか？普通のアプリはそういう形で処理するものだと思っていた。まさかそうしたサードパーティサービスが、実際の画像のような身分証の原本をアプリにそのまま渡しているわけではないだろう？

  • リクエストAPIの応答でOTPを返すなんてあり得ない。なぜそんなことをしたのだろう？

    • UIに、ユーザーが入力した値が正しいか確認させるためだった可能性がある
      セキュリティを考えなければ、非常にそれらしく明白な解決策ではある。デーティングアプリは必然的に個人識別情報が多く、作るには最も危険な種類のアプリの一つなのに、これはひどい
    • OTPを生成して保存したあと、データベースやキャッシュなどの応答をそのまま返していた可能性がある
      素早い概念実証やMVPでは、時間を節約するために保存モデルをそのままAPI応答として使うことが多いので、見落としやすい
    • データベース費用をなくす簡単な裏技だ
    • HTTPリクエストを1つ減らせて、ユーザー体験も速くなる。嫌う理由がどこにある？
      Pinterestの新APIが出たとき、OAuth連携を使うすべてのアプリにユーザー情報を全部ばらまいていて、2要素認証のシークレットまで含まれていた。報告して報奨金をもらったが、こういうことはもっと分かっているべき大企業のAPIでも起きる
    • OTPは「ワンタイムパスワードをトリガーした応答」で送られていたように見える
      フレームワークのせいである可能性がある。おそらくデータベースに入れるオブジェクトをORMや別の保存システムからそのままシリアライズして、HTTP応答として返す構造だったのだと思う

  • https://yaledailynews.com/blog/2025/04/24/yale-student-expos...
    この件についての別の記事だ

    • 「開発者はベストプラクティスを使うべきだが、それでも十分ではないかもしれない。データを安全に保つことは未解決問題だ」とは、ああそうですか。仕方ないですね

  • 個人識別情報の保存を核廃棄物の保管と同じくらい危険なものにする法律があればいいと思う。漏えいしたら会社はほぼ確実に破産し、責任者は法的リスクにさらされるべきだ
    インセンティブを正しくそろえる最善の方法はこれだと思う。今はユーザー情報を可能な限り多く保存することによるデメリットがほとんどない。データ漏えい？謝罪ツイートを1つ投稿して、そのまま続ければいい

    • 個人識別情報を核廃棄物のように扱おうというのは少し極端だと思う。個人識別情報には、認証や連絡目的のメールアドレスのように比較的無害なデータも含まれる
    • ホワイトカラー刑務所が必要かもしれない
      そうすれば、この問題が受けるに値する注目を得られるようになるかもしれない

  • 「まったく返答がない」のであれば、沈黙が続く場合は90日後に脆弱性を公開すると伝えるタイミングだ

    • それは企業よりも、罪のないユーザーにとってより大きな罰になる
    • ここには脆弱性と呼べるものすらない。単に公然と開け放たれている状態だ
    • そうすると訴訟を起こされ、刑事告発までされかねない道を進むことになる