ローカルサービスへのブラウザ経由攻撃手段を考えてみた

『ループバックやLAN内ホストでの脆弱性対策について』

http://causeless.seesaa.net/article/293940089.html

を書いた話の続き。

件の人の話し方から、どうやら「ブラウザとローカルサービスの脆弱性」にこだわっているように見えた。
それにhostsファイルは関係ないのは既に書いた通りだが、ループバックアドレス127.0.0.1へのブラウザ経由アクセスが問題になる条件を考えてみた

CSRF攻撃
まず127.0.0.1へのアクセスはフィッシングなりDNSジャッキングなりで誘導した攻撃用ウェブサイトに、http://127.0.0.1/（あるいは適当なドメインに127.0.0.1をAレコード設定）宛の攻撃コードを置けば実現できる。

この攻撃手法で問題になるのは、CSRF対策されておらず、クリックジャッキングに脆弱だったり、アクセス元を認証せずに、機密情報をJSONPで返すような脆弱なローカルサービスだ。
（クリックジャッキングやJSONP用scriptタグを設置すればsameorigin自体は迂回できる。）

例えば、家庭内へのDLNA動画ストリーミング用のウェブサーバアプリやWebDAVサーバで、管理画面もアプリ内ではなくhttp経由のリッチなajax UIを多用していて、JSONPでユーザ名やパスワードや保存されたファイルといった非公開とするべき情報を提供してしまっている場合。
JSONPベースのCSRFが成功すれば、機密が漏洩する。
常識的に考えて、アクセス元がlocalhostであることはチェックしているだろうが、IPベースのフィルタリングに甘えて、パスワードログインなどを実装していなかったり、CSRF対策がなされていなかったりするかもしれない。

#これはWiFiのMACアドレスフィルタリングと同根。予想したり偽装したりできるものを認証に使うことは全く意味が無い。

こういった脆弱なWebサーバアプリケーションがもし存在し、それをローカルで運用していることが分かった場合、この攻撃の対象になりうる。例えば、脆弱なPCがWANに直接接続されていてポートスキャンできるなどの理由で、脆弱なサービスを起動していることがわかれば、該当ホストにDNSインジェクションなりを仕掛けて攻撃ページに誘導し、機密情報を盗み出すことが出来るかもしれない。

攻撃成功には前提として、ブラウザではなくローカルで動いているウェブサーバアプリの脆弱性が必要で、追加でフィッシングなり攻撃サイトへの誘導手段が必須となる。ゼロデイや標的型攻撃の一手段として、全く無価値では無いだろうが、そこまで酷く脆弱なサービスを利用している時点で論外と思う。
広く普及していて、常識的なサポートがあるアプリケーションなら、緊急パッチが出るレベルと考えられる。そんな脆弱性をも考えて、ブラウザを全く使わない、ということは割にあわない。

DoS攻撃・HTTP互換のサービス
前提としてユーザ誘導が必要なのは同じだが、LAN内へのアクセスを大量に起こして自前DOsを起こさせる、あるいはHTTP互換のリクエストでなにか破壊的な動作をするサービスを狙う、といった攻撃はあり得る（これも広義ではCSRFかもしれない）。UPnPのようにHTTP互換サービスへの攻撃手段は実際に発見されている。

いずれも、ウェブブラウザで攻撃コードを読み込んだ場合に生じうる問題として全くあり得ないとは言えないが、ウェブとインターネットの標準的実装の仕様上、ローカルサービス側で脆弱性を潰すべきものだ。

繰り返すが、根本的な対策として、LAN内やloopbackオンリーのサービスであっても、悪意あるアクセスに晒される可能性があることを留意して対策を行うことが必要。