日経サイエンス2009年9月号にサイドチャネル攻撃についての良いまとめの記事がありました

セキュリティに興味がある皆様、ぜひお読みください。コンピュータネットワーク世界が成立する前の古い時代からのサイドチャネル攻撃の事例など歴史も学べて非常に面白いです。　最新のテクノロジーではどこまで可能なのかについても。　すでに重要インフラについては防御戦が始まっていることについても。

戦争。塹壕。工兵隊が有線を地中に這わせ情報将校が電話で連絡を取り合い戦術をやりとりする。敵方工作員が遠隔から地中に電極を突き刺し通信を傍受する。

オフィスビルに向かいあうもうひとつのビル。スパイはそのビルから超高解像度の望遠鏡でガラス窓越しにあなたの瞳に反射する光の影を盗み出す。あなたはディスプレイをみつめていた…

サイドチャネル攻撃の怖いところは、攻撃を受けている最中でもその痕跡を見出しえないというところにある。ログからの発見などできないのだ、基本的に。

無意識のサイドチャネルアタック

私がパソコンに興味を持って使い始めたときには既にコンピュータゲームは市場が形成されていました。私は趣味が悪くて、流行のゲームよりもオールドスタイルなゲームをよく好んで遊んだものです。視覚にちょっと弱点をかかえているのでテキスト中心のほうがありがたかった、という理由も影響しているかもしれません。
そんな私ですがゲーム専用のコンシューマ機で初期パソコンRPGの傑作であるウィザードリーの復刻版を遊び倒しました。テーブルトークRPGの先輩からもウィザードリーでの戦いのツボについてあれこれ指導を受けたり、古きよきパソコン時代のウィザードリーのマップを入手したりと工夫を重ねたものです。先輩はどうやらマッキントッシュよりも古い時代のパソコンで遊んでいたようですが、（リサ？アップル？）そんな先輩から恐ろしいことを聞いたものです。今から振り返るとそれは立派なサイドチャネル攻撃だったのです。
先輩の話を思い出しますと、初期パソコン版のウィザードリーは8ないし5インチのフロッピーディスクを2枚組み程度？で供給されていたのだったと思います。ウィザードリーは戦闘中心のRPGで10層ある地下迷宮を探索しボスキャラを倒すことが当初の目標なのです。敵モンスターを倒すと運がよければ宝箱が出てきます。この宝箱は、開けてみるまでは何がはいっているかわかりません。敵意ある仕掛けがはいっているかもしれません。毒針などが仕掛けられていれば、下手にあけると被害を受けてしまいます。あるいは別のトラップで麻痺状態になると本当に大変です。そんなわけですから、宝箱を上手に開けたりする職業や、空ける前から中身が何であるかを知るインスペクト技術を持つ職業が、チームの中に必要となってくるわけです。宝箱をうまく処理できれば店で売っていないような優れた武器や防具などもゲットできるため、この魅力には勝てません。とまぁ、ここまでは普通の話です。
さて、先輩は、たとえば、ゲーム上最も強力な武器であり武器店では入手不可能な「カシナートの剣」がはいっている宝箱を、開ける前から認識することができたそうです。どうしてわかるかというと、戦闘終了後に宝箱が出現する直前にフロッピードライブが駆動する際に出す音を聞き分けていたのだそうです。カシナートなどの情報は特定セクタに格納されているようで、そこにアクセスする時には、特別な音を出すのだそうで。それをプレイヤーは耳で聞き分ければよい、ということに。
このとんでもないお話を聞いて当時の私は笑い転げました。すばらしい！　とはいえ、任天堂のゲーム機のカセットでは応用が利かないテクニックでしたから私自身ではそのテクニックの検証ができませんでしたが、いにしえの8インチフロッピーならば、さもありなんと…
サイドチャネル攻撃が実際に身の回りにあったよ、というお話でした。

※余談。ウィザードリーの風変わりなところは、ラスボスを倒してもなお、ゲームが終わらないという点にあります。もはやひたすら自分のパーティの各キャラを育てていくだけなのですが、ラスボスを倒したころには既に、はまっている状態、中毒になっている状態なんですね。武器や防具などのコンプリートを目指すとかも面白いわけです。そうなってはじめて、かの先輩の技が編み出されるわけです。いったいぜんたいどのくらいの数の宝箱を開ければ、めったに出ないカシナートの剣のはいった宝箱のアクセス音を聞き分けられるようになるのかしらん？

大垣さんの本に秘技らしきものが

ええと。大垣さんが書いたウェブアプリのセキュリティについての入門本の130ページあたりを読んでいました。そこにまったく理解できないXSSアタックのベクタが書いてあって、その破壊力は震撼しなくてはいけないぐらいです。って恐れているのは私だけで、既にセキュリティ研究者には常識なのかしらん？

ええと。Aliceが運営しているサイトでは、他者が他のサイトの画像を貼り付けることができます。AliceのページにBobのサイトの画像を、以下のように埋め込むことができるわけです。



<img src="http://bob.tld/gazou.gif" >

このとき、Bobは、任意のJavaScriptを埋め込むことが可能である、やりかたはかくかくしかじか…と大垣さんの本に書いてあったのです。　ただし、ブラウザによって挙動が異なるとのこと。

大垣さんによれば、いくつかある方法の中で簡単なのは次のとおり。　悪意あるJSをテキストにしておいて、gazou.gifという名前でサーバーに保存。HTTPサーバの設定をいじくって拡張子がgifであっても、text/javascriptでサーブしてやればよい。

※くどいようですが。Bobが攻撃者でAliceが被害者です。また、img要素で貼り付けるだけでオッケーのようです。念のため。
※実は大垣さんの本の130ページでは上記のような攻撃者視点でのスッキリした形では書いてありませんでした。私が誤読して解釈しなおしてしまった…ということも充分にありうると思います。そうであるならば大垣さんに大変申し訳ないことをしていると思います。でも、大垣さんの本には以下のように書いてあります。


「リモート画像による」
この場合、リモート画像という言葉の意味を、私はアタッカーのサイトの画像と解釈したのでした。仮に被害者のサイトにアップロードされた偽画像であるとすると、大変に不思議な文脈になるからです。　たとえば、大垣さんによる攻略方法を解釈すると被害者のサーバの設定を変更可能でなければ攻撃が成立しない、大垣さんがあげられていたもうひとつの別攻略方法では、phpで偽画像を出力しつつtext/javascriptでサーブすると書いてあり、これは、攻撃者が既に被害者のサーバにphpスクリプトをアップロードした上実行可能であることを意味している、などです。このような不思議な文脈であるはずはありません。XSS攻撃以前にサーバを乗っ取られているとみなさざるをえないからです。このように、偽画像が被害者のサーバにおかれているということは認められませんから、偽画像は攻撃者のサーバに置かれていると考えざるを得ません。以上により、私は、被害者であるAliceを想定し、攻撃者Bobのサイトに置かれた偽画像を、Aliceのサイトのページにimg要素で埋め込まれた、と解釈したのです。ここで大事なことは、上であげたサンプルコードでも示したように、Aliceのサイトのページに埋め込まれている悪意あるimg要素のhref属性は、http://なスキームで構わない、という点にあります。javascriptな擬似スキームではありませんから、従来私が知っていたようなよくあるXSSベクタとは明らかに異なります。

しょうしょう頭が混乱してきました。大垣さんのあげられた攻撃方法は実にシンプルで強力です。私にとっては、こんな簡単なことを今まで知らなかったということに、我ながらうんざりしたことも確かです。…でも、私は、上の攻撃が成立するような、そんなブラウザの存在を知らないのです。どうしたら良いのでしょう。同書籍のERATTAのページも拝見しましたが、この件についてはあがっていません。はたしてこんなXSSベクタが本当にあるのでしょうか、識者のみなさま、PoCは入りませんから、攻撃が成立するかしないのかだけでも、ぜひぜひご教示ください。IPA/ISECが出しているXSS防御策にも影響が出るかもしれませんしね。

追記：：　上のようになったAliceのページを閲覧直後に、くだんの画像だけをマウス操作で開くことを考えてみましたが、昔のIEでJavaScriptが作動したとしても、そのドメインは攻撃者のBobのサイトのそれでしょう。あんまり意味がありません。・・・referrer取得？でもそれならJSでなくてもいいじゃん…

追記：：　Bobが自分のサイトのページからiframe要素でくだんのAliceのページを呼び出し、そのページにあるBobのサイト上の偽画像が悪さするというストーリーを考えてみましたが、実験するまでもなく、攻撃は不成立であるような気がいたします。　うーん。　もっと不思議な状況セッッテイがあるのかしらん？

HTTPOnlyな謎のcookieがIEに保存されていた件

自室のパソコンだけが知っている自分で作ったサイトのHTTPOnlyなCookieがIEに保存されていました。でもね、そのサーバには、cookieを吐き出すようなスクリプトはひとつもありません、というかサーバサイドで唯一親しみのあるPerlをこれから勉強しようとしている私の実力ではcookieを作れません。(笑
はてー。それならなぜなんだろうとすごく不思議。というか激しく汗。最近遊んでいるJavaScriptでそんなHTTPOnlyなcookie作れると思いませんし。
しばし悩んだのですが、ゴミ箱を探っているうちに判明。cookieを静的HTMLで作っていたのでした。すっかり忘れていたのですがmeta要素で遊んだらしい。HTTPOnlyなcookieをmeta要素で作っていたのですね。なんだか本末転倒。実社会に実例なしのはず。だって、XSSに抵抗しようとするHTTPOnlyなCookieなんでしょ？それをmeta要素で書くってどういうことよ＞自分。
しかもそのことを忘れるってどういうことよ。＞自分。
馬鹿丸出しなので日記にアプするテストでありんす。