macOSでMetaのMessengerの証明書ピンニングをハック

MetaのMessengerの証明書ピンニングを破る（macOS）

• MetaのmacOS向けMessengerアプリケーションは、スタンドアロンのデスクトップアプリケーションであるTexts.comのモデルに似ている。
• Texts.comでMetaプラットフォームのプロジェクトを率いるBatuhan İçözは、ネットワークリクエストを傍受することが最初の重要な段階だと考えた。
• Metaは証明書ピンニングを適用してセキュリティを強化し、MITM（中間者）攻撃によるサーバーリクエストの分析を防いでいる。

証明書ピンニングとは？

• プロキシクライアントを設定する際には、「認証局」を信頼するよう構成する必要がある。
• 認証局が発行した証明書を使って、リクエストに関する情報を傍受して復号できる。
• サービスが証明書ピンニングを実装すると、特定の認証局が発行した証明書だけを受け入れるため、ユーザー側の認証局が発行した証明書は使えなくなる。

基本動作

• 証明書ピンニングを無効化しない限り、すべてのリクエストは「内部エラー」として返され、プロキシソフトウェアには「SSLハンドシェイク失敗」と表示される。
• リクエストがライフサイクルを完了できないため、リクエストに関する情報を推測できない。

望ましい動作

• MITM攻撃を使って、ネットワークデバッグツールでリクエスト、レスポンス、ヘッダーを正常に読み取れるようにする。

可能なアプローチ

• 以前に機能した方法の1つは、バイナリ内のURL文字列を、TLSを実装していない安全でないセルフホストのエンドポイントに変更することだった。
• Fridaのような動的計測ライブラリを使うこともできるが、Messengerは特にフック時にクラッシュしやすい。
• Fridaを使うには複雑なデプロイ手順が伴う。

アプローチ

• MessengerをダウンロードしてApplicationsフォルダに移動した後、HopperにARMバイナリを取り込む。
• Hopperを使うと、バイナリの逆アセンブル、デコンパイル、再コンパイル、デバッグ、可視化ができる。
• 「SSLピンニング検証失敗」のような文字列を探し、修正を最小限に抑えようとする。
• 「Using custom sandbox -> turn off SSL verification」という文字列を見つけ、関連する関数を探して修正する。
• IsUsingSandbox関数が常にtrueを返すように設定して、証明書ピンニングを無効化する。

結果

• 新しい実行ファイルをエクスポートして署名を外した後、元のMessengerバイナリを新しいバイナリに置き換える。
• Messengerを再起動すると、プロキシツールにヘッダー、レスポンス本文、すべてのリクエスト情報が表示される。
• バイナリ97,477,728バイトのうち、わずか4バイトだけを修正してリクエストの傍受に成功した。

デプロイ

• バイナリをコンパイルした後、Batuhanに送る。
• Batuhanは署名証明書を受け取ってインストールし、アプリケーションに署名する。
• 署名が完了すると、自分のシステム上でそのバイナリを使って自分のリクエストを確認できる。

GN⁺の見解

• この記事は、セキュリティ研究者がMetaのMessengerアプリでどのように証明書ピンニングを回避するかについて、興味深い事例を提供している。
• 証明書ピンニングは中間者攻撃を防ぐ重要なセキュリティ機能だが、研究者がこれを回避する方法を見つけることは、セキュリティコミュニティに重要な洞察を与える。
• この技術は、開発者が自分のアプリやサービスのセキュリティを強化するのに役立つ可能性があり、セキュリティ脆弱性の発見と解決にも貢献しうる。
• ただし、このような研究が悪意ある目的に利用される可能性もあるため、研究結果を共有する際には慎重であるべきだ。
• 類似の機能を提供する他のツールとしては、WiresharkやBurp Suiteのようなネットワーク分析ツールがあり、これらはネットワークトラフィックの監視と分析に広く使われている。

[GN⁺]

Hacker Newsの意見

• 法的側面への疑問

  • このような行為の合法性について疑問を持っている。
  • 技術的には DMCA 違反だろうと想定していたが、その前提が間違っている可能性もあるのではと考えている。
  • 法的にどのように可能なのかという疑問を提起している。

• デコンパイルと再コンパイルの試み、そしてその献身

  • 似たような経路を試したが、デコンパイル／編集／再コンパイルの段階で断念した。
  • こうした献身に感嘆し、そこにどれだけの時間を費やしたのか気になっている。
  • 自分は時間制限を決めて、それを守るようにしている。

• 過去の技術の喪失

  • かつての +Orc の時代を思い出している。
  • 不要な分岐を見つけて取り除く方法のような当時の知識の大半は、すでに忘れ去られてしまった。
  • 今は学ぶべき別の技術がはるかに多い。

• Meta の RE 防御に関する観察

  • Meta（特に Messenger）のリバースエンジニアリング（RE）対策がかなり寛容だと指摘している。
  • 本番ビルドで IsUsingSandbox() を取り除くのは簡単だろうと述べている。
  • 高度な難読化技術を使う前の段階でも、こうした防御は容易に回避できるだろうとしている。

• サンドボックスモードでの証明書ピンニング

  • サンドボックスモードでも証明書ピンニングを強制できる方法について言及している。
  • 大学時代に Snapchat のトラフィックを中間者攻撃（MitM）で傍受しようとして失敗した経験を振り返っている。

• ランタイムバイナリチェックサムの有用性

  • ランタイムバイナリチェックサムが改変を複雑にするのに役立ったのではないかと質問している。
  • モバイルアプリで一般的な手順ではないのか、iOS や Android の SDK がこうした機能を提供しているのか疑問を呈している。
  • 最終的な解決策が単にバイナリの数バイトを書き換えることだったため、これを防げたのではないかと考えている。

• プロキシツールの使用に関する質問

  • 記事で使われたプロキシツールについて質問している。
  • そのツールが動作している間、すべてのアプリケーショントラフィックをルーティングするのか気になっている。

• 大企業アプリケーションのセキュリティ

  • 大企業のアプリケーションが完全に難読化されておらず、改変されたバイナリの実行を拒否するような他の保護機能も備えていないのはなぜかと疑問を呈している。

• Meta アプリのトラフィック傍受の可能性

  • Meta アプリのトラフィックを傍受する必要はないと主張している。
  • Meta のバグバウンティ教育ページへのリンクを提示している。

• トラフィック監視の重要性

  • Facebook アプリがマイクを通じてユーザーを監視し、ターゲット広告を表示しているという陰謀論を否定するうえで重要だと強調している。
  • アプリと Facebook サーバー間のトラフィックを監視してそれを反証するのが最も簡単な方法だが、証明書ピンニングがそれを妨げている。
  • 陰謀論を信じる人を説得するのは難しいが、こうした監視が可能であると知っておくことは重要だとしている。