netpoyo広報ブログスマートフォン用の表示で見るnetpoyo広報ブログネット文化を探求する同人サークルnetpoyoの広報ブログです。この広告は、90日以上更新していないブログに表示しています。~某プラットフォームの脆弱性に見る構造的問題~まずはこちらのURLをよーく見てほしいです。某ソーシャルゲームのURL↓http://sp.pf.example.com/12008305/?guid=ON&url=http%3A%2F%2F125.6.169.35%2Fxxxxxxxxxx%2Ftutorial%3Fa%3D287979669%26rnd%3D93975868これはスマートフォン向けの某有名ソーシャルゲームサイトでゲームをプレイしている時のURLです。sp.pf.example.comがソーシャルゲームサイト(プラットフォーム)を表し、それ以下はプラットフォームに渡すパラメータになります。確かに、この記事を読まれる方には非エンジニアの方も多いかもしれません。この記事は、筆者が偶然出会った脆弱性(すでに修正済み)について扱い、その危険性について解説するものです。その解説を通じて、どうしてこのような脆弱性が登場するようになったのか、その背景をなるべく誰にでもわかるように語っていきたいと思います。このURLの問題点とは?それでは、上のURLの問題点を、非エンジニアの人にも分かるように、解説を交えながら説明していきましょう。注目するところは1点だけ。ここにurlとかhttpとかいう文字が見えますね。後ろの125.6.169.35はIPアドレスのようです。これを元に戻すとurl=http://125.6.169.35/となり、urlの中にまたurlが入っている入れ子構造になっています。それは、こちらの図を見ると分かります。某サイトのシステム構成図(推測)この図はurl、動作及び他の公開記事を元に推測したシステム構成図です。問題のサイトでは、ユーザーがソーシャルゲームをプレイすると以下の流れでゲーム画面が作成されていると考えられます。ユーザーがプラットフォームにアクセスすると、まずはプロキシと呼ばれるサーバに接続します。プロキシはURLを元にサードパーティ(ゲーム提供者)のサーバにアクセスしますアクセスを元にサードパーティがゲーム画面を作成し、プロキシに返しますプロキシはプラットフォーム共通のメニューとゲーム画面を合成しますプロキシはユーザーに完成したゲーム画面を提供します。サードパーティはプラットフォームAPIを通じて課金情報、決済等を行います。先ほどのhttp://125.6.169.35/は、ゲームを提供している開発会社さんが管理するサーバで、プラットフォーム(sp.pf.example.com)がurlを見てそのサーバにアクセスしていると考えられます。それでは、このhttp://125.6.169.35/を、例えばhttp://netpoyo.jp/とかに変えたらどうなるでしょうか?筆者が確認したところ、「netpoyo.jp」があたかもプラットフォームの1ゲームのように扱われ、そのままユーザーの画面に表示されてしまっていました(現在は修正されています)。危険なのか?今までの説明で、読者はこう思うかも知れません。「で、何が問題なの」、あるいは「ただ、他サイトのゲームが遊べるだけじゃん」と思われるかもしれません。たしかに、他のゲームで遊べるだけならば、ちょっとした2chのスレのネタにしか過ぎないでしょう。「好きなサイトを1ゲームとして扱える」というバグは以下のように悪用される危険性がありました。攻撃者は既存のゲームにそっくりな偽のゲームを用意します。攻撃者はユーザーに対してトラップURLを踏ませます。短縮URL等を使うと効果が高いでしょうトラップURLはプラットフォームのプロキシにアクセスします。プロキシはトラップURLを元に攻撃サーバにアクセスします。攻撃サーバは1で用意した偽のゲームを提供しますプロキシはプラットフォーム共通のメニュー等と偽のゲームを合成し、ユーザーに送信します偽ゲームはユーザーを騙してクレカ情報、パスワードなどを入力を要求します(フィッシング)騙されたユーザーは大事な情報を入力してしまいます(半分は本物ですから、なかなか見抜けないでしょう)筆者はこれは十分危険だったと考えています。実際、フィッシング時にtwitterのOAuth認証も要求すれば効果的にtwitterで拡散する偽ゲームが作れたと考えられます。本物のゲームをコピーして偽ゲームを作れば、偽ゲームとは誰も気付けないでしょう。上記攻撃手順は筆者が実際に確認した、実行可能な危険性です。ここからは、確認した事実を元に推測した危険性についてお話しします。実は、検証時に偽ゲームに注入したJavascriptが動作するとの情報を他の発見者から入手しています。この種の脆弱性は、注入したJavascriptが動作してしまった場合、一般的にアカウント乗っ取りが可能なセッション情報を盗み出せることが多いです。筆者はセッション・ハイジャックは「法的にマズイ可能性アリ」「上記攻撃成立で十分危険である」と判断して検証していません。実際に盗み出せたかどうかは分かりませんが、盗み出せた可能性は高かったのではないかと考えています。アカウント乗っ取りのゲームを操作される危険性が十分にあったと推測されます。専門家に確認したところ、Cookieからセッションキーを抜き出す事自体は問題なかったそうです。セッションが2つあり、抜き出せるセッション情報はあくまでもゲームに使うものであり、プラットフォームのアカウント乗っ取りはできないとの指摘をTwitterで受けました。含む様々な情報をやり取りしているはずです。設計にもよりますが、例えばプロキシからのアクセス情報を鍵として情報をやり取りしていた。この場合、もし仮に攻撃URLを踏んでしまった場合、偽ゲーム提供サーバに鍵が知られてしまい、個人情報、ポイント等の不正使用、ゲームの不正行為などができたのではないかと推測されます。出来たかどうか確実とはいえないので、念のため打ち消し線を引きました)以上の推測も含め、先ほどの攻撃の図を書き足すと、以下のようになります。追記にあわせて、図を差し替えました)まとめると次のようになります。悪意のある偽ゲームを使った攻撃が可能だった(フィッシング等)セッション情報を盗み出してアカウント乗っ取りゲームが操作される可能性が高かったプラットフォームのAPIを使って各種不正行為が出来たかもしれない。短縮URLをトラップとして使え、ユーザーがトラップだと気づく可能性は低い。この問題を解決するためには、以下の方法が考えられます。game=example)。実際にアクセスするURLはプロキシ側で持つ(exampleは127.0.0.1にアクセス等)プロキシが許可するドメイン・IPをホワイトリスト方式で制限するどうやら現在は、2の方法で修正されているようです。言いたいところですが、実はそういうわけには行きません。今までの話は、「サードパーティが提供するゲーム」が「白」であるという前提の話でした。今まで話した危険性は、そっくりそのまま「審査をかいくぐったサードパーティが提供する悪意のあるゲーム」にも当てはまります。当然ながら、どこのプラットフォームも審査は行なっているでしょう。審査の厳しいAppleのiPhoneでも悪意のあるアプリケーションが程度の差はあれ通ってしまっています。同じ事がこれから他のプラットフォーム、モバゲー、グリーやハンゲーなどに絶対に起こらないといえるでしょうか?「実績のある大手メーカさんのゲームだから大丈夫だよ~」と思われる方は、開発は必ずしも大手メーカーではないこと、そして悪意のある人間は一人いれば十分であること、零細大手問わず悪意のある人間は少しは存在する可能性があること、もっと言えば、サードパーティに悪意は無くとも別の悪意のある人物に脆弱性を突かれて乗っ取られる可能性をお忘れなく。以上が筆者に出来る今回の脆弱性の説明です。私たちはこういった脆弱性を避けるためにどうすればよいのでしょうか。(筆者は引っかかりそうですが)。それを考えるために、そもそもなぜ今までのゲームでは見当たらなかった脆弱性がここにきて出てきたのかを考え、さらにその原因を探っていきたいと思います。ゲームと脆弱性そもそも脆弱性とはどういうものなのでしょうか?——実は脆弱性とは「悪用できるバグ」のことでしかありません。引き起こしてしまう”悪性”のバグが「脆弱性」と言われているだけなのです。先ほど挙げた脆弱性も、マリオが通常は壁をすり抜けられないのと同様に、本来ならサードパーティ以外のサーバに接続してはいけないのに、うっかりと抜け穴を作ってしまっているバグなのです。当然ながら、既存のゲームにも「脆弱性」は存在しています。最近少し話題になったものとして、同人ゲームの東方緋想天の脆弱性(JVN#50227837)というものがあります。これは他人のPCの東方緋想天を異常終了させることができるという「脆弱性」でした。ソーシャルゲームでは、「バグを引き起こした時の影響範囲」が既存のゲームとは大きく変わってしまっています。カセットをゲーム機に入れる従来型のゲーム機ゲームでは、酷いバグを起こした所で「ゲームがまともにプレイできない」程度で済みます。最近のゲームは多くの人がネットにつないでやり取りをしています。ソーシャルゲームはゲーム本体を含めて何でもかんでも常時ネットを使用し、更に知り合いとの交流や個人情報や課金・決済情報までもネット上でやり取りしています。悪意のある者がそのバグを利用するのも容易くなっています。従来型のゲームと比べて危険性が構造上どうしても上昇しているのです。終わりに繰り返しますが、脆弱性は「悪性のバグ」です。バグを潰すには、パターン化し、開発者が意識を高めて注意することしか基本的にはないのが現状でしょう。人間はミスをする動物です。筆者もその例外ではありません。ソフトウェアにバグを入れることは、どうしてもあります。それでもなお、現状これ以上に効果的な脆弱性の対策はないように思います。脆弱性について二つほど対策案を上げたいと思います。必要ない情報は扱わない・入力しない方が良い。課金情報などより危険な情報ならなおさらである。事故が起きたとしても大丈夫な形になっているか。比較的安全な手段が利用できないかどうか検討してみよう(クレカよりもPayPalやWebMoney等など)危険性はなるべく少なく、なるべくフェイルセーフに設計、行動しましょう。ちなみに、危険なバグは当然ながらパターン化され、対策は取られ、書籍化等もされているので、調べるようにしましょう。お断りこの記事はすでに修正済みの脆弱性について取り扱っています。現在は記事の通りに攻撃をおこなうことはできません筆者は某プラットフォーム運営会社の人間では無いので、当然ながら内部構造には推測が多分に含まれています。真実と違う点が多く含まれているとおもいます。この脆弱性はIPAには報告しています。筆者はたまたまURLを見た時にきな臭さを感じ、この脆弱性を知りましたが、他に報告されている方がいたため、筆者は報告者ではありません。僕は不細工を可愛くできない。(1)月別アーカイブはてなブログをはじめよう!netpoyoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。