8月3日のBlackhat 2016で発表された、HTTPSのURLが読めるというWPAD/PAC Attack1、なるほどねぇ、と思わせるアタックですな。
HTTPS自身を攻撃するわけじゃなくて、HTTPSのhostに対するproxy resolveの時に、PACファイルを使ってURLの内容をフィルタリングして攻撃者のホストに送るというやり口。
毎回proxy resolveが走るブラウザ（例：Firefox, Chrome）とそうでないブラウザがあって、後者だとあまり攻撃は成功しないが、FirefoxやChromeなどでは効果的。ただし、LANのProxy設定などで、「設定を自動的に検出する」がオンになっていなければならない。でもこれは、企業システムなどでは割りとONになっていることが多いのではないだろうか。
ちなみに、スライドに
- OpenID authentication URLPassword reset URL
というのがあるけど、これは、
- OpenID authentication
- URLPassword reset URL
の間違いかな？OpenID authentication URLPassword reset URLなんてものは無いから。
OAuthのAuthz req/res のqueryは両方共盗られてしまう。つまり、response_type=code * なら codeが、response_type=token * ならばtokenが奪取されて、リアルタイムに攻撃者のサーバに送られてしまいます。
もちろん、ユーザが上記のプロキシ設定自動取得オプションをオフにしていれば大丈夫ですが、これは、OAuth Server/Client側ではいかんともし難いです。できる対策としては、
- S256のPKCE[RFC7636]を使っていれば、このcodeは使いみちが無いので安全。
- Form Post mode を使っていても大丈夫。
- もちろん、Token Binding していれば大丈夫。
といったところですね。
Password Reset URLは、やられてしまいますね。むしろこっちの方が問題ですな。あと、DropboxなどでのURLによるファイル共有もやられます。サーバ側でできる対策としては、ファイル識別子を別途Formで入れさせるとかなんだろうけど、多くの人には使えなくなってしまうだろうことがちょっと悩ましいですね。
脚注
- Kotler, I., Klein, A.: Crippling HTTPS with unholy PAC, https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf