保険料計算機を悪用した保険会社ハッキング事件

 (eaton-works.com)
1 ポイント 投稿者 GN⁺ 2024-01-18 | 1件のコメント | WhatsAppで共有
  • Eicher Motorsの保険料計算機サブドメインでMicrosoft企業クラウド認証情報が露出し、TTIBIのnoreplyメールアカウントへのログインが可能だった
  • 問題のメール送信APIは認証なしでメールを送信でき、サーバーのエラー応答に含まれる送信ログがbase64エンコードされたパスワードを露出していた
  • 露出したアカウントには顧客に送信された65万7,000件のメールと、約25GB規模の保険証券PDF、顧客情報、パスワード再設定リンク、OTPが残っていた
  • そのアカウントには二要素認証がなく、Microsoft企業ディレクトリ、SharePoint、Teamsのような他のクラウドリソースにもアクセス可能だった
  • 脆弱なAPIは報告から2か月以上経って認証を要求するよう修正され、2024年1月27日時点でメールアカウントのパスワードも変更され、もはやログインできない

Eicher保険料計算機から始まったTTIBI侵害

  • Eicher Motorsのシステムを調査していたところ、Toyota Tsusho Insurance Broker India、以下TTIBIのnoreplyeicher@ttibi.co.in Microsoftメールアカウントが露出していた
  • TTIBIは日本のToyota Tsusho Insurance Management Corporation傘下のインドの保険ブローカーで、2008年に設立された
  • Eicher Motorsはインドの自動車メーカーであり、Royal Enfield Motorsのオートバイと、Volvo Groupとの合弁会社であるVE Commercial Vehiclesの商用車を製造している
  • 両社には保険関連の提携があり、TTIBIサイトにはEicher専用サブドメインが存在していた

脆弱性の発見経路

  • MY EICHER Androidアプリを分析していたところ、APIインターフェースのJavaクラスから保険料計算機URLを発見した
  • 保険料計算機Webサイトのソースコードにはクライアント側メール送信メカニズムが含まれていた
  • コードにはBearer Authorizationの使用痕跡があり認証が必要に見えたが、直接APIリクエストを構成すると401 Unauthorizedの代わりにメールが実際に送信された
  • サーバーのエラー応答はメール送信ログも返しており、その中にbase64エンコードされたパスワードが含まれていた

noreplyアカウントに残っていたデータ

  • noreplyeicher@ttibi.co.inは自動メール送信用のnoreplyアカウントだったが、TTIBIでは実際にログイン可能なアカウントだった
  • そのアカウントには顧客に送信したすべてのメール記録が残っていた
    • 合計65万7,000件のメール
    • 約25GB規模
    • 顧客情報
    • 保険証券PDF
    • パスワード再設定リンク
    • OTP
  • OTPやパスワード再設定リンクまで閲覧できたため、顧客の保険アカウント乗っ取りに悪用され得る情報が含まれていた
  • 同じアカウントでMicrosoftクラウドリソースにもアクセス可能だった
    • 企業ディレクトリ
    • SharePoint
    • Teams

脆弱性を拡大させたセキュリティ上の失敗

  • クライアント側メール送信機能

    • クライアントが件名、本文、宛先を制御できるメール送信機能は、悪意あるメール送信に悪用され得る
    • 実在するアカウントから送信されるため、メールレピュテーションの毀損やフィッシングにつながり得る

  • API認証の欠如

    • フロントエンドには認証トークン使用の痕跡があったが、サーバーはトークンを実際には検証していなかった
    • サーバーがトークンを確認していれば、この攻撃を防げた可能性がある

  • 過剰なAPIエラー応答

    • API処理中にエラーが発生した際、クライアントに返す情報が多すぎた
    • この事例ではエラー応答がパスワードを直接露出していた

  • 二要素認証の不在

    • Microsoftアカウントへのログイン時に二要素認証や他のログイン検証プロンプトがなかった
    • 二要素認証があれば、ログイン成功は難しかった可能性がある

  • メール保存

    • アカウントが送受信したメールがすべて保存されており、大量の顧客情報に容易にアクセスできた
    • 保存ポリシーがあれば、顧客データ露出の影響を減らせた可能性がある

対応と現在の状況

  • 2024年1月17日時点では、TTIBIが脆弱性を認識してから5か月以上経っていたが、メールアカウントのパスワードは変更されていなかった
  • 2024年1月27日の更新によれば、メールアカウントのパスワードが変更され、もはやそのアカウントにはログインできない
  • 脆弱なAPIは最終的に認証を要求するよう修正された
  • 異常なMicrosoftログイン警告があったかどうかは確認されておらず、警告があったとしても無視されたか確認されなかった可能性がある

報告タイムライン

  • TTIBIはToyotaのHackerOne脆弱性開示プログラムの対象外だったため、India CERT-Inに報告した
  • 2023年8月7日: CERT-Inに脆弱性の詳細レポートを送付
  • 2023年8月8日: CERT-InがケースIDを発行し、TTIBIに連絡すると回答
  • 2023年9月1日: 進捗状況の更新を要請
  • 2023年9月6日: CERT-InがTTIBIに脆弱性を伝達し、追加の更新を共有すると回答
  • 2023年10月8日: 影響を受けたWebサイトは停止したが、脆弱なAPIは残っていたためCERT-Inに通知
  • 2023年10月11日: CERT-InはTTIBIが脆弱性を修正したと回答したが、確認の結果、脆弱性は依然として残っていた
  • 2023年10月18日: メール送信APIが認証を要求するよう変更され、脆弱性が修正された
  • その後、バグバウンティ報酬の有無を確認するやり取りが続いたが、TTIBIは回答せず、2023年12月22日にケースは終了した

関連記事

1件のコメント

 
GN⁺ 2024-01-18
Hacker Newsのコメント

  • インド人ではないが、Tata系の大手IT企業で働く立場として、あまりに現実味がある
    ここには、安く済ませれば評価されるマネジメント文化、開発者の主体性や自己実現を押さえ込む文化が大きく作用している
    米国でこういうものを見たらすぐ辞めただろうが、彼らには退職すると90日分の給与返還があるので、事実上選択肢がない
    管理職の大半は非技術系の出身なので、聞きたいことだけを聞き、都合の悪い話は聞きたがらない
    同じチームや同じ会社が作った成果だと見るのも間違っているかもしれない。開発者をひどくサイロ化して、API開発者、Office 365開発者、フロントエンド開発者のように細分化し、自分が「認定」されていない領域には触れない
    1億ドル規模のプロジェクト会議でもSendGridの費用をめぐって真剣に争い、結局「SendGrid経験」がないという理由で、ある開発者がOffice 365でできると言い出すようなことになる
    セキュリティチームの予算は「すでに安全であるべきだから」と真っ先に削られ、セキュリティ担当として採用された甥っ子世代の人に話しても、政府や誰かが訴訟を起こすわけではないのに、なぜ面倒なことをするのかという態度になる
    開発者は開発するよう奨励されるのではなく、チケットを処理し、質問するなと教えられる
    インドの優秀な開発者たちと仕事をしているが、これはイノベーション文化ではなく、コールセンターのように扱われる仕事だ。台本から外れず、狭い問題領域にとどまり、失敗さえしなければ勝っている、というやり方だ

    • 90日分の給与返還のようなものは、労働組合と労働権がないときに生じる結果だ
      私たちのところにも近いうちに来るかもしれない

  • 2000年代半ばから後半に相手をしたHonda系の自動車ディーラーが、金融申込書を増加する数値IDで保存していた
    通報はしなかったが、SSN、生年月日、氏名、住所といったニュージャージー州住民の機微情報をいくつも閲覧できた
    当時はバグバウンティが事実上なく、CFAAはあったので通報しなかった
    自分の申込書は削除させたが、脆弱性は新システムに置き換わるまで数年間残っており、その新システムも脆弱そうに見えた
    その後、そのディーラーとは取引しておらず、今でも自動車ディーラーと金融申込書には非常に慎重だ。多少高くても、たいてい別のところで融資を受ける

  • セキュリティ上のミス自体はひどいが、経験のない開発者に理解範囲をはるかに超える仕事を任せた、という形である程度は説明できそうだ
    しかし、いったいどうやって機密性の高い顧客文書をメールアカウントに保存することが承認されたのかは理解できない
    この事業の運営方法を知る責任者が誰もいないということであり、子会社や外注先なら、誰も監査したことがないということでもある
    会社の所有者と、この仕事を任せた側の双方にとって、刑事上の過失に近い行為だ

    • この程度の能力なら、誰かが承認した可能性も低そうだ
      おそらくメールサーバーに送信済みメールの保存機能があり、「noreply」アドレスに実際のアカウントを使うという愚かな判断の副産物として生じた可能性が大きい
    • かなり大きな不動産仲介システムで、すべての送信メールを共有アカウントにBCCして、全員がOutlookに同期しているのを見たことがある
      監査ログ、デバッグツール、データベースバックアップを兼ねていたわけだ
      従業員がすべての顧客情報を新しい職場に持って行っていると分かって、ようやく変更された

  • 「5か月以上たってもTTIBIが脆弱性を知りながらメールアカウントのパスワードを変更していない」のなら、少なくともエラーログからBase64のパスワードは取り除いていることを願う
    もちろんそうしたよね。違う？

  • 影響は文字どおりSharePointとOutlook全体へのアクセスレベルで甚大なのに、経路はクライアント側JavaScriptを見る程度なので、かなり珍しい脆弱性だ
    些細な点を一つ挙げると、スクリーンショットの機微情報はぼかし処理よりも黒塗りで隠す方法のほうがよいと思う。用心して損はない

    • 最近のぼかし機能は、実際の原文をぼかしているのではなく、単にぼやけて見えるようにする処理である可能性が高い

  • 「感謝状」で終わる仕組みのせいで、こうした脆弱性の大半はホワイトハットに報告・公開されず、ハッカーに積極的に悪用される
    顧客の個人情報に関して、一定水準以上のセキュリティ不備による管理責任を会社に問う法的枠組みが必要だ

    • 欧州にはすでにそういうものがあり、名前はGDPRだ

  • インドにはデータ漏洩より大きな問題がある
    その一つが安定した電力供給だ
    インドに十分な電力が行き渡り、ハッキングが主要な心配事になる日を待っている
    毎月10万kmの光ファイバーを敷設し、毎日350か所の5G基地局を建てている

  • 監視用メールエンドポイントが事実上、通信ワーカー／エージェント／ランナーのように設計され、放置されるうちに膨れ上がり続けた点も見るべきだ
    これは、メール使用量を監視しておらず、「なぜこのメールエイリアスは保存コストが他の何倍もかかっているのか？」のような異常な挙動を見つける補完的な仕組みもないということだ
    「noreplyアカウントは顧客に送ったすべての記録を潜在的に持っているため、組織で最も重要なアカウントかもしれない」という言葉が核心だ

  • 「インド全域の有力保険ブローカー」が有能な開発者を雇うお金がないのなら、顧客を危険にさらした複数の深刻な問題を見つけ、責任を持って知らせた人に、少なくともいくらかでも払うべきだ
    だがそうしなかったし、しかも侵害されたメールアカウントのパスワードすらまだリセットしていないという事実が信じられない
    こういう行動をする会社を、どうやって信頼し、何かをまともにやると期待できるのか
    Toyota Tsusho Insurance Broker Indiaは、疫病を避けるように避けるべき会社に見える

    • 同程度の無能さを直接見たことがある
      これは誰かが重要なセキュリティ警告を積極的に無視しているのではなく、何を言われているのか理解していない状態だ
      自分たちが運用している環境や直面している課題を根本的に把握しておらず、あなたが使う専門用語が本人やチームにとって何の意味もないので、ただ消えてほしいと思っている状態だ
      「ややこしいメールを送るのはやめてください。重要な仕事があります」という態度だ
      解決するには組織レベルで首脳部の入れ替えが必要で、IT責任者と彼が手を付けたすべてのものが去らなければならない
    • 代替手段がほとんどない可能性が高く、そもそもその点がこうした問題を生んだ可能性が大きい

  • 問題の一部は、この受信箱を事実上「無料」のSMTPアカウントのように使い、送信メールの費用を払わないようにしたことにある
    SESのようなものを使っていれば、このアカウントの送信済みフォルダー／受信箱にこれほど多くの機微情報はなかったはずだ
    SESは1,000通あたり0.10ドルで非常に安い

    • 技術的にはその通りだが、ここでSESを使う実際のコストはおそらく開発時間だ
      送信したすべてのメールを保存し、非開発者の業務担当者が過去のメッセージを閲覧・検索できるインターフェースを作らなければならない
      この「無料」SMTPアプローチの機能をすべて使っていたのなら、開発と保守のコストはかなり大きい