示現舎の全国電話帳アプリについて＋警告

住所でポン（公開電話帳サイト）で有名？になった人が公開している、
全国電話帳 https://play.google.com/store/apps/details?id=info.jigensha.hellopage というアプリは、複数の人が電話帳を送信していると確認しているようだ。

インストールされている人は直ちに削除をおすすめする。

（追記：個人的なまとめ http://causeless.seesaa.net/article/296187376.html でまとめてみた）

ただ、法的に問題があるのかは疑問におもう。作者は最低限周辺法を調べて問題ない、とTwしていて、個人情報保護法や高木先生のような存在を知らないとも思えない。

まずスラドのコメント
http://yro.slashdot.jp/comments.pl?sid=578428&cid=2227099
が指摘していたように、住所でポン！が、単純なNTTの電話帳由来であり、追加情報を加えていない場合、公開しても問題はないと考えられる。

http://www.meti.go.jp/policy/it_policy/privacy/kaisei-guideline.pdf

個人情報データベース等が、以下の要件のすべてに該当する場合は、その個人情報データベース等を構成する個人情報によって識別される特定の個人の数は、上記の「特定の個人の数」には算入しない。

�@個人情報データベース等の全部又は一部が他人の作成によるものであること。
�A氏名、住所・居所、電話番号のみが掲載された個人情報データベース等（例えば、電話帳やカーナビゲーション）であること、又は、不特定かつ多数の者に販売することを目的として発行され、かつ、不特定かつ多数の者により随時に購入することができる又はできた個人情報データベース等（例えば、自治体職員録、弁護士会名簿等）であること。
�B事業者自らが、その個人情報データベース等を事業の用に供するに当たり、新たに個人情報を加えることで特定の個人を増やしたり、他の個人情報を付加したりして、個人情報データベース等そのものを編集・加工していないこと。

の通り、
NTTの提供する電話帳は一般公開の意図で取得された単純なデータベースで、NTTとの契約者が公開を許可した情報に何ら付加情報を加えていないので、ソートやファイル分割は機械的な処理であって、情報が追加されているとはいえず、検索出来る内容も公開されている情報だけで、サーバー内にある秘密情報（たとえば趣味や職業）で検索しているわけでないため、公開されているウェブページからは、ただの電話帳テーブル以上の情報が得られない。

つまり、個人情報取扱事業者にあたらず、公開や電話帳アプリから検索といった利用自体は違法ではない。電話帳や名簿業が問題なく行われていることからもこれは明らか。

次に、全国電話帳アプリは、複数の人が電話帳を送信していると確認しているようだ。
この情報がどのように利用されるかは明示されていないが、電話帳取得権限の警告文でもって、利用者はアプリに収集を許可している。
アプリによって端末内で生成された電話帳データベースを、「ユーザが生成した電話帳」とみなし、それをアプリ提供者に送信・提供している解釈すれば、つまり、全国電話帳アプリが複数データベース横断検索をしているだけなら、法に反しない可能性がある。

ウイルス作成罪側で対処できるかについても、「意図せず」をどこまで広く解釈するかになるが、LINEのように電話帳を公開するアプリや広告ライブラリが（問題視されているといえど）容認されている以上、収集自体を法に問うことも難しいとおもわれる。これは判例が出るまでわからないのではなかろうか？

どこから違法になりうるか

これら情報をマージして公開した場合、個人情報取り扱い事業者となって公開に問題が発生する。しかし、現在のザル法（ザル政令）では、マージしていない個人の電話帳そのものの無断公開は法に問えないと思われる。
たとえば、利用者毎に個別のデータベースとして、とある個人が作成した電話帳、として公開された場合、法に問えない可能性がありそうだ。（よっぽど問題に思えるが）
もしこれが直ちに違法と為るならば、名簿を複数所持しているであろうほとんどの事業者は、マージ可能であるという理由で対象になってしまうが、そんな理由で立件されたという話は聞かない。

これが通れば、公開されたデータをマージして利用する側は個人情報保護法の対象になるが、提供する側の個別のデータは対象外になりうる。

結局のところ、名簿業者が行なっているであろう、データを自分で収集せず購入するなどして多数かき集めて販売し、抽出・マージしての利用は購入した側でご自由に、というスタンスの事業は、個人情報取扱事業に含まれないという抜け穴を明確にしている。

政令を改正するにしても、単にマージ可能なデータを持つ場合合算で5000人、などとしてしまったりすると、小企業や個人事業主（電話帳の一冊くらい持っているだろうから、プラス１人の顧客情報で規制対象になる）にものすごいコスト負担を強いることになってしまう。

続きを読む

SHA-3に選出されたKaccakのスポンジ関数方式

大学の講義で暗号論をかじったくらいの知識で解説してみる。

SHA-3コンペで選出されたKaccakは、旧来の構造とは異なるスポンジ関数という考え方で構築されている。

古い設計のハッシュ関数は、入力圧縮関数、内部状態バッファ、撹拌関数で構成されていた。（丸めやパディングのような雑多な処理は略す）
入力圧縮関数は、撹拌関数の呼び出し回数を減らすため、また前処理として大きな入力ブロックを内部状態サイズ以下に不可逆に縮めるために使われ、
可能な限り撹拌関数の対象となる内部状態サイズ＝必要レジスタ数を小さくして、その分撹拌関数一回あたりの複雑性を高めることで安全性を担保しようとした。

http://sponge.noekeon.org/
一方スポンジ関数方式では、大きな内部状態＝スポンジを用い、複雑な圧縮関数を不要にする。入力は単に、内部状態の一部（例えばKeccakでは1600bit中の1024bit）にXORするような方法で行われる。最後に出力圧縮関数を使う場合もあるが、keccakのように単純な切り出しで十分と考えられているようだ。
この場合、バッファサイズの大きさが増えるが、撹拌関数の複雑性・計算量を無理に増やす必要はないようだ。
非線形な圧縮関数を用いず、撹拌関数と内部状態の余裕分に安全性を担保してもらう形になる。

昔はハードウェアレジスタがとても高価だったため、内部状態を小さくすることは至上命題だったかもしれない。
現在では、ASICや高速な一次キャッシュが十分安価になっているので、内部状態を小さくする利点よりも、高速かつ単純な撹拌関数を利用する利点の方が勝ったということと思われる。非線形性をワード内rotとワード置換のみで実現している点などが評価されたか。

メリット

内部状態の大きさはが出力可能なハッシュサイズを決定するので、内部状態のサイズを切り詰めていた旧来の方式では、内部状態のサイズ自体を変更しなければならず、圧縮・撹拌関数の計算式が出力サイズによって異なった。SHA-256とSHA-512は内部が違う上、計算コストが急激に増えた。

スポンジ関数方式なら将来必要になった時に、同じ撹拌関数を用いて、入出力するブロックサイズを任意に変更できる。例えばkaccakなら仕様上1024bitまでのブロックサイズでそのまま利用でき、出力ビット数もブロックサイズ以上にできる。実質的に計算量は変わらず、原理的には安全性の検証をブロックサイズ毎に行う必要が無く、単純に算出できるものと思われる。
またkeccakは5x5xWord長という可変サイズの内部状態に対してほぼ同じ関数を使える。（rijndaelからAESの256bitブロック固定のように最終的に64bitword固定で規格化されると思うけど。）

もうひとつ利点があり、撹拌関数を都度取り出すことでストリーム暗号に仕立てることが、ほぼ同じ実装だけでIO増加以外の性能劣化なしに可能になる。出力ブロックに対して内部状態が十分大きいなら、内部状態の全体の逆算は困難で、安全である可能性が高い。
独立した暗号化と鍵精製関数を使うよりも、スポンジ関数にsalt+パスワード＋padを入力し、残りは入力ブロックの替りにカウンタを入れて出力ブロックをCTRモード暗号として扱う、といった単純な実装で安全に利用できる可能性がある。SHA-3で規格化されることは無いだろうが、ハッシュと暗号化を統合できるかもしれない。

デメリット
素人に思いつくのはせいぜい必要レジスタ数で実装コストが増えることくらいか。
構造が単純な分懐石も検証もしやすいかもしれない。一般に非線形置換・rotで十分安全と考えられているようなので、単純に性能を犠牲にラウンド数を増やされるかも、程度に思う。

トレードオフ
撹拌関数のラウンド数の他、スポンジ関数の内部状態レジスタにどの程度余裕をもたせるか（一回に出し入れする入出力サイズと、手を加えない残り自由度。図のrとc）で性能が変わる。
余裕を減らしてブロックサイズを大きくすれば計算速度は早くなるが、衝突が発生しやすくなる。（内部状態を推定・制御しやすくなる）

ブロックサイズ1024bit＋576bitで1600bitのバッファ、出力サイズ576bitで、2^-288の衝突耐性がデフォルトのようだ
http://keccak.noekeon.org/tune.html
ブロックを減らせば第二原像の算出可能性が下がるが、撹拌関数の呼び出しが増えるのでrに反比例して性能が下がる。

SHA-3規格化時点でこれも数通りに固定されると思うしそれを使えば安全だろうけれど、自由度が大きいぶん、実装が下手なパラメータを許容するとかやらかしそう。

DNS rebindingを用いた汎用的なルーターパスワードフィッシング手法

前の投稿で書いたものをもう少し汎用的にしてみた。

家庭用ルーター管理画面では多くの場合、
・HTTPSでのサーバー（ルータ）検証ができない
・Hostヘッダチェックを行なっておらずDNS rebindingに脆弱 
・BASIC認証を利用
という前提を満たす事を利用する、汎用的なルータパスワードフィッシング手法を考えてみた。

フィッシングで正しいルーターに紛らわしいドメイン（たとえば192.168.1.1.router.baffalo.tld）で認証してしまうよう誘導しDNS rebinding攻撃に成功すると、認証パスワードを平文あるいは脆弱なMD5ハッシュとして取得できる可能性がある。

Hostヘッダチェックを行うだけで根本的な対策になるので、ルータ製造企業はできるだけ実装して欲しい。

BASIC認証にはブラウザが認証状態キャッシュ（＝一度認証したらしばらくは認証ダイアログを出さずに自動でパスワードを送信する）を実装しているので、DNS rebindingが認証状態が破棄される前に成功すればパスワードを奪取できる。あるいは、フィッシングに脆弱なユーザによって、パスワード自動入力が効いてしまうかもしれない。

フィッシングは一般に紛らわしいドメイン名で攻撃者のサーバにパスワードを送らせる為、攻撃サイトごとに適切な模倣コンテンツの製作が必要だが、この手法では正規のルータにパスワードを送らせて、ブラウザにキャッシュされたパスワードを奪取する、汎用的な攻撃スクリプトが利用できる。

また、正規のルータであるため、ユーザーが攻撃に気づくことが出来るタイミングが、最初にルーターのパスワードを入力する一回のみであり、その後正しくルーターを管理できてしまう点も、フィッシング成功率を高める可能性がある。LAN内は無条件に安全という誤解から、初級者も引っかかるかもしれない。

この攻撃には、フィッシング用に容易したページ（ランディングページ）と、ルータ管理画面ウィンドウ、2つのウィンドウを経由する。
ランディングページでは、ルータのIPをページロード時間などで検出（あるいは決め打ちでもいい）し、ユーザの到達をサーバに通知してから、ルータのIPを指す偽装ドメインにジャンプする。

ランディングページには例えば、オンラインゲームのインストール紹介を模倣し、ルータのポート開放手順の解説などをする、といったシナリオが考えられる。

偽装ドメインは正規のルータを指すので、ユーザがパスワードを覚えていて、偽装ドメインに気づかなければ、認証は正しく行われる。
この間、偽装ドメインのIPは攻撃者のサーバに振り直されている。

時間が経つと、（うまく行けば未熟なユーザーが設定画面での作業に手間取っている間に、）IPアドレスは攻撃者のサーバを指すようになり、パスワード（かMD5ハッシュ）が攻撃者サーバに送信される。

なお、ブラウザがwindow単位のIP pinningをしている場合、ランディングページを残しておいて、定期的に新しいウィンドウを作成する必要がありそう。ただchromeの挙動をみるとタイムアウト式のpinningしかしていないような。

ルータのパスワードは次のrebinding攻撃時のBASIC認証に利用されるかもしれないし、WAN側管理画面が公開されていればそこから完全なアクセスが入手できる。（徳丸先生の昔の記事がヒットした…rebindingマイナー過ぎる…）

前回の記事ではsessionクッキーを使っていれば、と思ったのだが、最近のルータは基本、BASICかDigest認証を利用しているようだった。
IPベースのセッション管理をしているものもあるみたいだけれど、そもLAN内の通信の安全性が前提なので問題無さそう。

（以下追記）
念のため、この手法はWANでも、Hostをチェックせず（IP直打ちで）HTTPでログイン出来るウェブアプリ全てに成立するはず。
流石にそんな阿呆なサービスはもう絶滅していると思うけれど。
自分の書いたアプリはvirtualhostなのでhttpd上でhostチェックされているはずだけれど、一応HTTPS必須化しておいた。

Chrome@win7でrebindingが通る事を金床氏のデモで確認……

フィッシング＋Cookieを利用したルータへのリモートログイン可能性

正規のルーター相手にフィッシングして、cookieで認証情報を抜く手段がありそう。

なお、実行可能な実装を見つけてない＋検証できていないので話半分でお願いします。

オンゲやpaypalフィッシングは周知されてきたと言え、LAN内ルーター相手のフィッシングを想定している人はどれだけ居るだろうか？

kazuho氏がほぼ逆向きの提案（cookie fixで攻撃）をしていたので、もう少し検討してみた。
https://twitter.com/kazuho/status/250402829611712513

Cookie以外にも、成功確率はさらに低そうだが、時間をかけてブラウザのIP pinningさえ回避できれば BASIC認証でも攻撃できそう。（TTL式でないwindow単位pinningならすぐ抜ける？）

家庭用ルータ・モバイルルーターには、管理画面のセッション維持にBASIC認証とcookieを用いているものがあるorあった。手持ちのAtermはBASIC認証とhiddenでのCSRF対策だったが、他社の取扱説明書をみるとcookieを使っていた機種があるらしい。
ぐぐると、モバイルルータの管理画面でCookieを有効にするよう注釈があるPDFがいくつか出てくる。
http://mb.softbank.jp/mb/data_com/product/mobilewifi/101sb/pdf/101sb_userguide_04.pdf

手順
『このオンラインゲームを遊ぶにはルータ192.168.1.1のポート開放が必要』とでも言って、http://192.168.1.1.example.com/に誘導する。
192.168.1.1.example.comは192.168.1.1（推定したルータのデフォルトLANIP）を指している。

ユーザーが認証に成功すると（フィッシング成功時）、cookieが設定されてしまう（ルータ実装の脆弱性）

その後http://192.168.1.1.example.com/ （BASIC認証の場合）あるいはhttp://spy.192.168.1.1.example.com/ （クッキーの場合）を攻撃者サイトのIPを向けさせて、パスワードかセッションクッキーを秘密裏に盗み出す。

これを使えばWAN側管理画面からアクセスすることが可能になる。

前提条件としては、
・ユーザが多少変なドメインでもルータと信じて認証（フィッシング問題）
・WAN側管理画面があってルータの機種が特定しうる
・不正なHTTP Hostヘッダを受け入れる管理画面実装（Atermの去年の機種は通った）
・BASIC認証あるいはCookieベースの管理画面セッション管理実装
・WAN側とセッションや鍵を共有している（わざわざ分離している実装がどれだけあるか疑問）

肝はフィッシング相手のルータは正規のものなのでログインシールの類は意味がなく、かつ手元にあってHTTPSが使えず、不自然なドメイン名に気づかない限りフィッシングと気づかれることが少ない点。特に最近のホームルータはFTPサーバ機能などがあるのでそこそこの価値がある。

……のだが、手近なところで前提条件を全部揃えたものが見つからなかったので、不可能ではないが厳しそう。特定の通信会社の社員など、ある程度絞れていれば狙えるかもしれない。何も考えずメーカ初期パスワードの桁数でブルートフォース試したほうが成功率高そう。

kazuho氏の指摘は逆に、先手を打ってサブドメインからモンスタークッキーを設定し、session fixationを起こす、というものを想定しているようだ。（ただやっぱりhostsファイルでなくDNS側で攻撃できるはず）

回避策
ルータ側でHostヘッダをチェックして、意図しないドメインだったら拒否する。

ただこの対策には問題があり、ルータのメーカ依存機能の一つ、DDNSでルータのWAN管理画面を表示できるようにする機能への対応が難しい。
Hostヘッダのホワイトリストを管理し、DDNSサービス側の変更にリスト更新なりファーム更新なりで追従する必要が出てくる。サポート的に問題となりそう。

共用WiFiルータみたいにhttpフックしてIPアドレスの管理・認証画面に飛ばしてくれるのもあるので、そういった奴は大丈夫そう。

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

『ループバックや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オンリーのサービスであっても、悪意あるアクセスに晒される可能性があることを留意して対策を行うことが必要。

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

（追記）
徳丸先生が纏めているので、twitterなどから来た方はこちらを見ることをオススメします。

http://tumblr.tokumaru.org/post/32194399895/hosts

なお、レアケースとしてリスク増加は有りうるとの指摘が
kazuho氏 http://togetter.com/li/380068
mala氏 https://gist.github.com/3788589
からあり、自分の下記の議論は状況によっては正しく無いことがわかりました。

同じくまとめは http://tumblr.tokumaru.org/post/32357571163/hosts 

を参照してください。
（/追記）

元はしげっち氏 @shigecchi2007 と、デザイアさんさん（？）@ks_desire との会話から
https://twitter.com/shigecchi2007/status/249880380189061120

ブロック目的などで度々編集するhostsファイルに、悪意あるIPが入ると、例えばgoogle.comを攻撃者のサーバIPに向ける、というような場合があるので、注意する必要がある、という話。
ウイルス対策ソフトのブラックリストに間違った情報が入ったら問題が起こる、というのと同じなので、信頼出来ないソフトやhostsファイルを使うな、という趣旨の話でまったくもってそのとおり。

自分のような得体のしれない人間の作ったhostsファイルなんて信頼出来ないから使わない、というのは実に正しい。

そこに、ループバックアドレス 127.0.0.1に書き換えるのも危険、という指摘があった。

https://twitter.com/typex20/status/249891672119443456

これは事実でないと思われたのだが、自分の説明が不十分で伝わらなかったようなのでここでまとめる。

hosts編集には前提としてroot権が必要。

root権
root権があれば、ソケットを開くOSのシステムコール自体をフックして、全ての通信を傍受できる。HTTPSの復号をOSやライブラリに頼る場合、HTTPSも完全かつ隠密裏に傍受できる。証明書チェックをしていなければ、アプリ内実装したHTTPSでも思いのまま。（最悪デバッガ使えばいいんだけど）
攻撃者が端末のrootをとれるのなら、hosts設定などという難しい前提をとらず、いくらでも情報を搾取できる。rootedなデバイスに入れるroot取得アプリは厳選しましょう。というだけ。

hostsファイル自体への悪意IPの挿入
編集にrootが必要。公開されているhostsファイルに、悪意あるIPがリストされれいる可能性があり、得体のしれないhostsは信用しないようにずべきだが、自分で内容を知った上で設定すること自体に問題はない。
なお、昔のwindowsのように、hostsが保護されていなかった時代は、スパイウェアなどが簡単に書き換えできた。winVista以降アクセス制御がまともになってからは現在は正しく保護されている、はず。

そして本題、
loppbackアドレスへの書き換え
well known port =< 1023 をlistenするにはrootが必要なので、http://127.0.0.1/への通信を傍受できるならそもrootでソケットを〜の繰り返し。
リンク先のポート指定で例えばlocalhost:8080にアクセスした場合、通常ユーザ権限のアプリをloopbackにbindすれば傍受可能だが、それはローカルに攻撃専用アプリがインストールされているか酷い脆弱性のあるアプリなので、そちらを削除する方が先。

なぜなら、攻撃者は適当なドメインに127.0.0.1へのAレコードを指定したり、直接http://127.0.0.1/のように指定することでアクセスを強制することが出来るからで、攻撃者はhostsに関係なく実行できてしまう。寧ろhostsで攻撃コードをホストしているドメインへのアクセスを禁止することで若干安全になる。
本来エンドユーザ向けのブラウザはそんなアクセスを禁止すべきかもしれないが、現在の実装としては許されている。（ウェブアプリ開発者といった人にはローカルのウェブサーバで開発するために必要）

UPnPの既知の問題

http://jvn.jp//cert/JVNVU347812/index.html

既に、UPnPが対策不十分のために、外部から操作できる、という問題が発生している。これは192.168.1.1など、ルータのLAN側IPを決め打ちしてアクセスさせ、UPnP実装の脆弱性を突いてポート開放などを行う手口だった。これはブラウザではなく、UPnP実装側の脆弱性として扱われている。
ファイアーウォールソフトなどによっては、このようなLANへのアクセスをブロックしてくれるものもあるかもしれないが、根本的な対策ではない。LAN内の同じファイアウォールを動作させていない他のマシンから、自分やルータにアクセスされた場合、攻撃が回避されうる。

LAN/WAN間や端末内蔵ファイアーウォールで守られたLAN内であろうとも、ブラウザからの悪意あるアクセスを想定した対策は必須、というお話。

#テスト環境に本番由来の個人情報入りデータベースコピーして使うバカは（以下略）

foursquareのclickjacking脆弱性の対応状況 (修正)

このautofill-jacking(仮称)はclick-jackingの亜種（さらにCSRFの亜種）で次のような状況で発生する。

・サービス（特にSNS）のログインパスワードフォームが外部呼び出し可能でiframe内で動作する
・ブラウザがiframe内のパスワードフォームに自動入力する

https://ja.foursquare.com/login

では次の条件で発生する。PC版ChromeとFirefoxで確認している。

・パスワードを保存する
・サードパーティクッキーを有効にする
・ログアウトしている
・フォントがデフォルトのまま
・ユーザーの位置情報取得をfoursquare.comに恒久的に許可

iframeにログインフォームを読み込み、CSSでログインボタンのみを切り出す。透明化してもいいかもしれない。
他のサイトのボタンを偽装できるので、clickjackingは容易である。

この状態で、偽装され埋め込まれたiframeのボタンをクリックしてしまうと、ユーザが意図せずfoursquareにログインさせることが出来る。
foursquareではログインした瞬間から現在地が公開されるので、公開したくない所在地をノートPC経由で漏洩してしまうことがありうる。（修正：mala氏‏ @bulkneets より。御指摘感謝 ）foursquare側に位置情報が伝わってしまう。（自動チェックインできるわけではないので一般公開されるわけではない）
用途はジョークから、ソーシャルハッキングの一部として利用されるかもしれない。その場合GeoIPよりずっと精度の高いリアルタイム情報が得られることになる。

この手の問題は、mala氏‏ @bulkneets に指摘頂いた通り、既にMozillaのBugzillaなどに報告されているものの、それ自体は危険性が無いと見られていたようだ。
しかし、リアルタイム情報発信型SNSにおいては、ログインすること自体が不可逆な情報漏えいを起こしかねない。

この問題をfoursquareに問い合わせたが、応答がない。最初の通知から2週間近く、少なくとも進捗を問い合わせてから丸3日は返信がない。当然というか、対策はなされていない。
自分の英語力の拙さは筆舌に（ｒｙだが、Webアプリ開発者が見れば明らかに意図がわかるサンプルは提示してある。

公開自粛要請のような通知も一切無いため、公開に問題は無いものと判断しここに公開しておく。

念のため、サービス側の対策はログインフォームページにヘッダ X-frame-options: denyを一行入れるだけである。
ユーザー側としては、サードパーティクッキーを無効にすることで対処できる。
ただしこれはあくまでfoursquareの実装依存なので、この対策が無効になったり、似たような脆弱性を持つ他のSNSで同じ対策が可能とは限らないので注意。

続きを読む

さくらのDNSについて、言いたかった事をスライド風にしてみた

さくらのサブドメインハイジャック

http://blog.tokumaru.org/2012/06/sakura-dns-subdomain-hijacking.html

について、いいたかったことをスライド風にしてみた

https://causeless.up.seesaa.net/image/shareddns2.pdf
スライドを更新しました
権威レコード→委任ゾーン（権威レコード＋NS＋グルー）と明確化
コンテンツサーバが必要な情報と不必要な情報をメモ
BINDの設定いくつか

フルいやつ
https://causeless.up.seesaa.net/image/shareddns.pdf

さくらインターネットのドメインハイジャック脆弱性について

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

の前提として、

さくらで他人のドメインのサブドメインを勝手に利用できる脆弱性があった。
http://blog.tokumaru.org/2012/06/sakura-dns-subdomain-hijacking.html
http://www.e-ontap.com/blog/20120614.html
http://jprs.jp/tech/security/2012-06-22-shared-authoritative-dns-server.html
http://www.atmarkit.co.jp/news/201206/22/subdomain.html

自分はさくらの中の人ではないので、外から見える限りの状況で話しています。

さくらの共用DNSは、レンタルサーバやメールなどの各種サービスに付属して、外部ドメイン（いわゆる"独自ドメイン対応レンタルサーバ"の機能）や共用ドメイン（*.sakura.jpなどいくつかサブメインを無料で使える）をホストするため、対応するゾーンとレコードを共用のDNSサーバに設定できるようになっている。

公式の設定方紹介を見るとわかるように、『外部ドメインの登録』と、『サブドメインの登録』がそれぞれ個別のUIで用意されている。

まず外部ドメインexample.jpを登録すると、さくらの共用DNSの中に、example.jp.ゾーンが作られる。当然、必要なSOA/NSが作られる。レンタルサーバならAが、メールサーバならMXも同時に作られるだろう。

さらにサブドメインを登録すると、作ったゾーンにたとえばwww IN A 1.2.3.4のような必要なレコードが作られる。

という動作と考えるのが普通だと思う。少なくとも設定後外から引く限りはそういう動作に見える。

その後、レジストラからexample.jpの委任先をns*.dns.ne.jpというさくらのサーバに設定すると、実際にexample.jpはさくらのDNSの内容通りに利用できるようになる。

ここで第三者がレンタルサーバを契約し、www2.example.jpという外部ドメインを申請した場合。
www2.example.jpをルートとするゾーンは、example.jpのサブゾーンなので、本来勝手にゾーンを作られては困るのだが、さくらはこのチェックをしていなかった。
すなわち、他のユーザが作った登録済みゾーンの中に勝手にサブゾーンを切り分ける権限を、第三者に与えてしまった。

すくなくとも一部のDNS実装は親ゾーン側に適切なNSレコードが設定されていなくてもエラーを吐かずに暗黙にゾーン分割を行うので、www2.example.jpは（そとからみて）正しく委任されたサブゾーンに見える。
よってwww2.example.jpはexample.jpのサブドメインにも関わらず、第三者が勝手に利用できるようになる。

この攻撃には、親ゾーンがさくらの共用DNSに委任されている必要があるので、田中社長の発言によれば少なくとも、委任していなかった6万のドメイン、Aレコードのみ設定していた7000のドメインはこの攻撃の対象外だった。
https://twitter.com/goto_ipv6/status/241712704430170114
対象外だった人たちが、さくらのドメイン登録ポリシー信用していなかったのかは分からないが。

この問題のアドホックな対策は、JPRSも書いている用に、第三者による不正なゾーンの分割が発生する不自然な登録をチェックすることだ。

個人的には、この脆弱性は外部ドメインを受け入れるどのレンタルサーバでも起こりうるし、臆病なら自分でチェックしてみるべきとも思う。
昔広告付き無料サーバを使わせてもらっていた頃、cPanel（共用レンタルサーバのマネージメントソフト群）（かその互換品？〜Panelというのがいくつかある）はこれを考慮しているらしいことをチェックしたことがある。

なお根本的には、http://causeless.seesaa.net/article/289854678.html にかいたように、ドメインの所有者をアカウントと正しく紐つける作業が必要になる。

NSレコードキャッシュポリシー変更によって対応される2つの問題

まず幽霊ドメイン問題
http://netsec.ccert.edu.cn/duanhx/files/2010/12/ghostdomain-2012-02-08-export-with-build.pdf

次の例では親子どちらが権威をもつ？

example.jp.ゾーンにsub.exmaple.jp.のNSレコードがあった
不法行為が判明しsub.exmaple.jp.のNSレコードは削除された

ユーザーがsub.example.jp.をクエリする

example.jp.の権威サーバは、ネガティブレスポンスを権威ありで返すだろう。NSレコードが無いのだから、そこにはこちらが権威を持っている。
一方、
sub.example.jp.の（元）権威サーバは、自身を指すNSレコードのレスポンスを権威有りで返すだろう。当然権威は持っている。

リゾルバはどちらを信用するべきか？
RFCを文字通り読むと、推奨は先にキャッシュに入っていた方、ということになる。
元権威サーバのキャッシュがあると、そのキャッシュは権威ある用に見える古い権威サーバの情報で更新され続ける。つまり、幽霊ドメインになる。
http://jprs.jp/tech/notice/2012-02-17-ghost-domain-names.html
幽霊ドメインをなるべく速く排除するために、BINDほかリゾルバ実装では、サブゾーンルートのNSレコードがサブゾーンのDNSから得たときは、キャッシュのTTLだけ更新しない（ゾーンのルートに対応する"@ IN NS *" なレコードはTTL延長しない）ことで対処しているようだ。　
http://dnsops.jp/bof/20120425/20120425-DNSOPS.jp-BoF_Ghost_Domain_Names_v02.pdf
確かに、その時点でNSレコードの内容を利用することは権威がある以上どうしようもないが、キャッシュすることは強制ではないので、RFCを逸脱せず親ゾーンのTTLを上限にドメインを削除できる。

これは”浸透いうな不浸透問題”＝ネームサーバ移転時の問題と同根でもある

sub.example.jpを消すのではなく、他のDNSサーバに委任する場合、example.jp.の権威サーバは、新しいレスポンスを権威なしで返す。
もし、古い権威サーバの制御ができなくなったら、sub.example.jpの古い権威サーバは古い権威サーバ自身をさす古いNSレコードを権威アリで返す。

同じくRFC推奨に従うと、リゾルバはsub.example.jpの古いDNSからの返答でキャッシュを更新してしまうので、何らかの理由でsub.example.jpにアクセスがあると、何時まで経っても更新されない。＝
浸透いうな不浸透問題。
同様に、サブゾーンから返ってくるNSレコードは無視されるので、TTL切れすると親ゾーンの新しいNSれこーどが読み込める。

親ゾーンを優先するようにRFCが書かれていればこんな問題は起きなかった。ただ論文のスライドの最後にもあるけれど、オーバーヘッドは避けられない。当時はサーバーの処理能力的にそんな事やってられなかった、というのが主要因なんだろう。

ネームサーバ移転は本人のミスで片付くが、幽霊DNSは不法なドメインを削除できないというセキュリティ上の問題として扱われているので、対応が進んでいる、はずなんだけれど実体はだいぶ違うらしい。

（編集）
NSの移転問題を”浸透いうな不浸透問題”にしてみました。