本投稿の目的
このあと記載する攻撃手法が発生しうるのであれば、
今まで使ってきたいろいろなサイトで機密情報などをアップロードしたりダウンロードしたりするのが少し怖いな、と感じました。
「そんなの前から常識だろ」とか「いや攻撃可能性はほぼないでしょ」等、いろいろとコメントをいただきたいな、と考え投稿します。
忌憚のないコメントをお願いします！
攻撃手法 概要 （1から順に実施）
- あらかじめ、攻撃対象クライアントと、攻撃対象サーバ（サイトのFQDN）を選定（攻撃対象クライアントが example.com へよくアクセスしている等の情報があれば絞りやすい）
- サーバ証明書を簡単に発行してくれる認証局（典型例は、Let's Encrypt）に対し、中間者攻撃を行い、サーバ証明書を入手
- 攻撃対象クライアントに対し、先ほどのサーバ証明書を用いて中間者攻撃を行い、情報窃取・改ざん等の不正行為を行う（サーバ→クライアント、クライアント→サーバのいずれの方向でも可能）
攻撃手法 1. について
- 以下、攻撃対象Let's Encryptを前提に記載する
- まず、サーバ証明書が作られるまでのフローについて
- 前提: Let's Encrypt は、「サーバ証明書発行申請をしてきた者が真正かどうか」をチェックするために、チェックを行い、通れば申請者に証明書を渡している
- 以下、フローの流れ
- 申請者は後のチェックで用いるプロトコル（HTTPやDNS（のTXTレコード）といった手法がある）を選択し、Let's Encryptに伝達
- Let's Encrypt 側は、申請者に対し秘密情報（申請者以外に渡していない情報）を渡す
- 申請者は、先程伝達したプロトコルで秘密情報を開示する（HTTPサーバでファイルを公開する等）
- Let's Encrypt側がチェックし、問題なければ申請者に証明書を渡す
- ここで、攻撃者が「平文であれば攻撃対象サーバになりすまし、中間者攻撃できる」というような状態であるとすると、先ほどのチェックプロセスで平文のプロトコルを選べば、攻撃対象サーバのFQDNに対するサーバ証明書が入手できる
攻撃手法 2. について
- あまり説明は不要と思われるが、先ほど入手したサーバ証明書を使用すれば、攻撃対象クライアントに対してはサーバとして、攻撃対象サーバに対してはクライアントとして、それぞれなりすますことで中間者攻撃が可能
ありうる対策
-
[クライアント側] ユーザがブラウザで機密情報などを扱うサイトを見るときは証明書情報を確認する
- 攻撃者に、ユーザがつないできたあと数分はパケットを素通りさせ、その後なりすましを始める、とかをされると、ユーザとしては気づきにくいので、部分攻撃はできるのではないか
-
[クライアント側] 絶対に信頼できるルート証明書しかインストールしない（プリインストールのものは消す）
- サーバ側になりすますのが困難→攻撃は困難になる
- が、ユーザ側の利便性観点でのデメリットは大きい
- クライアントが、WebAPIのリクエスト側であればこれもよいかも（使用するHTTPクライアントライブラリで、CAを絞れたりすることが多いはず）
-
[サーバ側、クライアント側] クライアント認証を入れ、サーバ側で絶対にできるクライアントしか許可しない
- クライアント側になりすますのが困難→攻撃は困難になる
-
[サーバ側、クライアント側] 素のインターネットを使わない
- 安全なインターネットVPNや、安全な専用線ネットワークとすれば、攻撃は困難になる
-
[サーバ側] （未検討） DNSSEC と [CAA] (https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum?_ga=2.69639056.1856498811.1554972329-1322448050.1554972329) 導入
- CAAはまさにこういう問題に対処するためのもの？
- DNSSECについてよくわかっていないため、未検討扱い
（参考）その他のプロトコル
- SSH: パスワード認証ではなく、公開鍵認証を普通に使っていれば中間者攻撃は不可能
- 正当なクライアント側の公開鍵だけが登録されている前提
- 参考 https://www.gremwell.com/ssh-mitm-public-key-authentication
- IPSec VPN: あまり詳しくないので未検討