Sterra Security Tech Blog

株式会社ステラセキュリティの公式技術ブログ

しゃぶ葉のテーブルで学ぶMITM 〜届かなかった六穀豚が教えてくれた通信暗号化の大切さ〜

代表の小竹（aka tkmru）です。

先日のしゃぶ葉での出来事です。キッチンから私の席へ運ばれてくるはずの六穀豚が、配膳ロボの移動中にいつの間にか別のテーブルの人に取られていた——

配膳ロボはプログラムされたルートに従って順番にテーブルを巡回するため、私のテーブルにたどり着くまでに他の客席の横をいくつも通過します。そして、ロボには「今まさに皿に手を伸ばしているのが正しい宛先の客か」を確認する手段がありません。

最終的には店員さんに事情を説明し、改めて豚肉を持ってきていただくことで事なきを得ました。通信で言えば「パケットがロストしたので再送してもらった」状態であり、本来は不要だったコスト（追加の調理・配膳）と時間が発生したことになります。

もちろん、通信におけるMITMでより問題になるのは、単に届かないことだけではありません。経路上の第三者が中身を見たり、別の内容にすり替えたりできてしまう点にあります。

これはもちろん実際のセキュリティインシデントではありません。しかし、セキュリティエンジニアの目で見れば、MITM（Man-in-the-Middle：中間者攻撃）を説明する題材になります。本稿では、この身近な出来事を通じて、通信経路における暗号化の必要性と、私たちが業務で日々向き合っている「合意の上でのMITM」について整理していきます。

⚠️ 本稿はしゃぶ葉を題材にした比喩表現です。実在のオペレーションに問題があるという主張ではありません。

事件の構造をネットワーク的に読み解く

今回の事件における登場人物を、ネットワーク通信に対応付けてみます。

しゃぶ葉の世界 ネットワークの世界
キッチン サーバ
客席 クライアント
配膳ロボの巡回経路 ネットワーク経路
皿 パケット
六穀豚（肉そのもの） ペイロード（平文データ）
経路上のテーブルで皿を奪う客 中間者

ポイントは、配膳ロボが複数のテーブルを順に通過する という点です。平文で「剥き出しの肉」を運んでいれば、経路上のどのテーブルの客でも中身を見ることも、持ち去ることも、別の安い肉にすり替えることもできてしまいます。これが、HTTPのような平文通信において、経路上の攻撃者や同一ネットワーク上の攻撃者が盗聴・改ざんできてしまう問題の本質です。

ネットワーク的に言えば、これは暗号化されていない共有メディア（古いハブ接続のLANや、暗号化なしのWi-Fi）上を流れるパケットに近い状況です。実際の攻撃では、ARP SpoofingやDNS Spoofing、悪意あるプロキシなどによって、攻撃者が通信経路に割り込むケースもあります。

MITMとは何か

MITMは、通信する二者の間に攻撃者が割り込み、やり取りを盗聴・改ざん・なりすましする攻撃の総称です。代表的な手法を以下に挙げます。

  • ARP Spoofing: LAN内で「このIPアドレスに対応するMACアドレスは自分」と偽装し、トラフィックを自分に引き込む手法
  • DNS Spoofing / Cache Poisoning: 名前解決結果を偽装し、偽サーバへ誘導する手法
  • Rogue AP（野良アクセスポイント）: 正規のフリーWi-Fiを装い、通信を中継しながら傍受する手法

しゃぶ葉の例で言えば、最も単純なのは「配膳ロボが自分のテーブルの横を通る瞬間に、堂々と皿を取ってしまう」というパターンで、これは暗号化されていない共有ネットワークでの盗聴に相当します。さらに「自分のテーブル番号が正しい宛先だ」と配膳ロボを誤認させればARP Spoofing風、偽の配膳ロボを用意して注文を受け取ってしまえばRogue AP風、といった具合に、さまざまな攻撃パターンに対応付けられます。

なぜ暗号化が必要か

ペイロードを剥き出しのまま運ぶ（= 平文通信）ことには、3つのリスクが伴います。

  1. 盗聴 (Eavesdropping): 経路上の誰でも中身を見ることができる
  2. 改ざん (Tampering): 六穀豚が豚バラ肉にすり替えられても気づけない
  3. なりすまし (Impersonation): そもそも本物のキッチンから来たかどうかが分からない

これらのうち、通信内容の秘匿、改ざん検知、接続先サーバの認証を担保する仕組みがTLS（Transport Layer Security）です。

TLSが提供する2つの「蓋」

暗号化という蓋付きの皿

TLSハンドシェイクで交換された鍵を使い、通信内容を暗号化します。経路上で覗き見られても、中身は意味のないバイト列にしか見えません。また、これらの暗号方式は改ざん検知も兼ねており、途中で内容が書き換えられれば受信側で気付くことができます。

証明書による本人確認

証明書とPKIにより、「この皿を送ってきたのは本物のしゃぶ葉のキッチンか」を検証できます。認証局 (CA) という信頼できる第三者が、キッチンに対して「このキッチンは本物です」と示す身分証を発行しているイメージです。

さらなる防御層

実務では、次の施策が実施されることもあります。

  • HSTS (HTTP Strict Transport Security): 「このお店では必ず蓋付きの皿で運ぶ」とブラウザに強制し、HTTPでの接続にフォールバックさせない
  • Certificate Pinning: 「この身分証を持つキッチン以外は信用しない」と決め、アプリ側で接続先の証明書や公開鍵を固定する

業務における「合意の上でのMITM」— ローカルプロキシを用いた診断

ここまで「MITMは防ぐべき攻撃」として説明してきましたが、MITMは 正当な目的で意図的に実施される 場面もあります。その代表が、脆弱性診断やペネトレーションテストで用いられるローカルプロキシツール（Burp Suiteなど）です。

なぜローカルプロキシを挟むのか

診断では、クライアントとサーバ間のHTTPS通信を詳細に観察・操作する必要があります。具体的には以下のような目的です。

  • リクエスト/レスポンスの構造把握
  • パラメータ改ざんによる認可制御の検証
  • 想定外の値の入力による入力検証不備の検出
  • APIエンドポイントの網羅的な列挙

ただし、TLSで暗号化された通信はそのままでは読めません。そこで使うのが「プロキシ独自のCA証明書をデバイスに信頼させる」という手法です。

証明書インストールによるTLS復号の仕組み

  1. Burp Suite等のプロキシが、独自のルートCA証明書を生成します
  2. そのCA証明書を、診断対象デバイス（PC、スマートフォン）の信頼されたルート証明書ストアにインストールします
  3. プロキシ経由の通信では、プロキシが対象ドメイン用のサーバ証明書をオンザフライで生成します
  4. デバイスは「信頼するCAが署名している」と認識し、プロキシとのTLSを確立します
  5. プロキシは復号後の平文を取得し、必要に応じて内容を確認・変更したうえでサーバへ転送します。サーバとの間では、プロキシが別途TLSを確立します

自分が管理するデバイスに、自分の意思でCAをインストールするため、許可された診断範囲内で実施される正当な通信解析として扱われます。六穀豚で言えば、お店の許可を得て配膳ロボの経路に立ち会わせてもらい、皿の中身をチェックしている、という状態です。

スマホアプリ診断で立ちはだかる壁

スマホアプリの場合、この手法への対策が一歩進んでおり、診断側にもより高度な技術が求められます。

ひとつめの壁が Android Network Security Configです。Android 7.0以降のアプリでは、デフォルトでユーザーが追加したCAを信頼しません。そのため、端末にプロキシのCA証明書を入れただけではHTTPS通信を復号できないケースがあります。

これに対処するため、弊社では apkutil というOSSを公開しています。apkutil は対象APKをデコードし、AndroidManifest.xml に networkSecurityConfig 属性を追加した上で、ユーザCAを信頼する network_security_config.xml を埋め込み、再ビルド・再署名までを一括で行うツールです。これにより、診断対象アプリにプロキシのCA証明書を信頼させ、HTTPS通信の解析が可能な状態に整えられます。

github.com

ふたつめの壁がCertificate Pinningです。アプリ側で正規証明書や公開鍵を固定し、プロキシが生成した代替証明書を拒否する仕組みで、ネットワーク設定の書き換えだけでは突破できません。アプリ自身が証明書検証を行う実装に対しては、ランタイムフックやバイナリにパッチを当てるといった追加の手段が必要になります。Webアプリ診断と比べて、診断のために越えるべきハードルが多い領域だと言えます。

本当のリスクは暗号化のその先に

通信の暗号化は必要条件であって十分条件ではありません。たとえば、暗号化していてもアプリ自体のロジックに認可制御の不備があれば、攻撃者はTLSで保護された通信の中で堂々と他人のデータを持ち去れます。Certificate Pinningを実装しても、クライアント側で無効化するパッチを当てることで迂回される可能性も残ります。 つまり、実装されたロジックによる脆弱性を人の目で探す作業が欠かせません。

おわりに

六穀豚が届かなかった体験は、暗号化の必要性を身をもって教えてくれました。そしてセキュリティエンジニアが脆弱性診断業務で日々行っているのは、プロキシ経由の「合意の上でのMITM」を通じ、攻撃者より先に弱点を見つけ出すことです。

なお弊社ステラセキュリティでは、本稿で紹介したようなプロキシを用いた手動診断に重きを置いた、Webアプリ・スマホアプリ・LLMアプリ・プラットフォームを対象にした脆弱性診断サービスを提供しています。認可制御やビジネスロジック、アーキテクチャ固有の脆弱性までしっかり検証したい方はお気軽にご相談ください。

配送される肉の行方には気を配りつつ、自社サービスに対しては脆弱性診断という形で目を光らせることをおすすめします。