APOP 認証の脆弱性について

今更だけど覚え書きとして書いておく。今週 IPA/ISEC から APOP の脆弱性に関する注意喚起が出た。（4/30 一部訂正）

IPA/ISEC および JVN の解説は簡潔すぎて要領を得ないので，以下のページを参考にするとよい。

注意しなければならないのは，これはあくまでメール（POP）サーバへアクセスする際の認証プロトコルの問題であり，メール本文が盗み見されたり改竄されたりといった問題とは無関係ということだ。っていうか，よく言われるように電子メールは郵便で言えば葉書と同じようなものであり，第三者が本文を覗き見したり改竄することは以前から可能である（たとえ MUA-MTA 間の通信を暗号化しても MTA-MTA 間は平文のまま流通する）。それをリスクと感じるなら PGP/MIME や S/MIME 等でメール本文を署名・暗号化する必要がある。

さて，今回の手法は「Man-in-the-middle 攻撃」と呼ばれるものの一種。ユーザと POP サーバの間に割り込んで（ユーザから見て）サーバになりすます。そうして APOP のやり取りを記録しパスワードの一部を割り出すわけだ。パスワードの一部といっても最大31文字まで割り出せるそうなので，ほとんどの人は完全なパスワードをぶっこ抜かれてしまうのではないだろうか。

何故 APOP が狙われているかというと，おそらく3つポイントがある。

APOP がセキュアな MAC （Message Authentication Code）ではない。
APOP で使われる MD5 （ハッシュ関数の一種）はいくつかの攻略法が発見されていて既に危殆化している。（ハッシュ関数の危殆化の問題については拙文を参照のこと）
アルゴリズムの危殆化が考慮されておらず MD5 以外の選択肢がない。

多くの人は POP 認証を自動化しているはずで，全く気付かないうちにパスワード情報をぶっこ抜かれている可能性もある。この攻撃によってパスワードを知られてしまうことによりメールサーバへの不正アクセスを許してしまうのはもちろんだが（POP 認証と SMTP 認証では同じパスワードになっていることが多いが，そうすると取得したパスワードを使って spam をばら撒くこともできそうだ），そのパスワードを他のサービスでも使っている場合，まとめて侵入を許してしまうことにもなりかねない。これは「Twitterとソーシャルハッキング」で書かれているような話と構図としては同じで，いわゆる「クラスブレイク」が発生している状況である。

ここまでが APOP の脆弱性によって予想される脅威（ハザード）。しかし私たちが知りたいのは脅威ではなくリスクだ。 JVN のレポートによると， CVSS の基本値は 4.0 でそれほど高くない。現状値や環境値は状況によって違うと思うので各自で確かめて欲しいが（一応 JavaScript によるデモがある），そんなに酷い値にはならないと思う。これは Man-in-the-middle 攻撃自体の実現性がそれほど高くないからだと思う（Base Metrics の Access Complexity も high だもんな）。とはいえ放置できるほど軽微でもないので，ユーザやメールサーバの管理者（ISP を含む）は何らかの手を打つ必要がある。

APOP 自体は標準のプロトコルであり，これを変更することはコストがかかりすぎる。 MUA 側でできる手っ取り早い（ただし消極的な）対応としては，送られてくるチャレンジコードをチェックしバイナリ値を含む場合には認証を中断するというものだ。いっそ POP を捨てて IMAP にすれば CRAM-MD5 等の認証プロトコルが使える（CRAM-MD5 では HMAC を使う）。可能であればこういった方法に切り替える手もあるだろう。

IPA/ISEC のレポートでは POP over SSL や Web メールを利用する方法が紹介されている。 SSL/TLS で通信を暗号化した上で認証を行うというわけだ。しかし，個人的な印象では（Web メールはともかく） SSL/TLS をメールサーバにアクセスするためだけに使うには高価すぎる気がする。現在の SSL/TLS は X.509 ベースの PKI を構築している。 X.509 は多対多または1対多での証明には向いているが（例えば Web）， 1対1の証明に使うにはコスト（特にランニングコスト）がかかりすぎる。「APOP終焉で「POP over オレオレSSL」の撲滅運動が可能に」では

「それにしても、上のオレオレ事業者たちは、なぜ普通にサーバ証明書を買わないのだろうか？」

と書かれているが，そんなのは簡単な話で，メールサーバだけのために証明書を調達する（ランニング）コストに比べて，（それによってもたらされる）リスク・ベネフィットのバランスの改善が小さくて見合わないと思っているからだ。 “Beyond Fear” 風に言うなら「トレードオフ」による判断であり，『環境リスク学』風に言うなら「意思決定のためのリスク」評価だ。この辺の状況は電子メールだけじゃなくて Jabber なんかでも同じ。（4/30 訂正あり。文末の追記を参照）

（念のために書いておくが，私はオレオレ証明書を容認しているわけではない。 SSL/TLS が X.509 ベースの PKI で運用されている限り，規模の大小に関わらず，オレオレ証明書を使うことは SSL/TLS の信用モデルを根底から覆す。まぁ “GnuTLS OpenPGP key support” が標準になれば状況も変わるかもしれないが）

しかし，まぁ，これが5年前くらいの話だったらもう少し真剣に考えるところだろうけど，電子メールなんて今ほとんど使わないからなぁ。プライベートなやり取りなら IM や mixi 等の SNS についてるメッセージ機能のほうが手軽で使いやすいし。どうしてもメールのやり取りが必要なら Gmail 使えばいいし。

（4/30 追記）

Twitter で指摘されたのですが，サーバ証明書でワイルドカードが使えることを完全に失念していました。つまりさくらインターネットが提供しているような共用レンタルサーバでもそれほどコストをかけずにサーバ証明書を導入することは可能であるということですね。指摘してくださった方に感謝＆申し訳ないです。