日本スマートフォンセキュリティ協会(JSSEC)は 2017 年 2 月、都内のベルサール神田において、「JSSEC セキュリティフォーラム 2017 スマートフォン/IoT、その先にある ICT社会のセキュリティについて考える」を開催しました。JSSEC では、これまで「スマートフォンのセキュリティ」をテーマに様々な活動を展開しています。今回は「IoT」や「AI」「制御システム」など、スマートフォンから一歩踏み込んだシンポジウムを企画する一方、技術部会のセッションでは、Android周辺のテクニカルな話題を取り上げました。グリー株式会社の開発本部セキュリティ部セキュリティ診断チームでマネージャーを務める山村 憲和氏は、「スマホゲームのセキュリティとWhite box診断のススメ」と題した講演で、ソーシャルゲームに対する攻撃手法のトレンドと、セキュリティの現状について解説しました。
「ラクしてゲームを有利に進める」チート攻撃から守る
インターネットを介してユーザー同士がコミュニケーションを取りながら楽しむソーシャルゲーム。かつてはブラウザベースの作品が中心でしたが、近年はネイティブアプリへとシフトしつつあります。登壇した山村氏が所属するグリーでは、ゲーム事業を手掛けており、これまで様々なゲームアプリを開発してきました。現在、運営するソーシャルゲームのプラットフォームは、約3500万人が利用しているといいます。
講演の冒頭で山村氏は、ゲーム事業者の立場から、ソーシャルゲームに対する攻撃が時代とともに変化してきていることを説明。続けて、「攻撃のトレンドにあわせてセキュリティも変えていく必要がある」と認識を示すとともに、通常のITサービスとソーシャルゲームにおけるセキュリティの違いについて解説しました。
山村氏は、ソーシャルゲームの場合、攻撃者の動機は「ゲームを有利にすること」「ラクをして強くなること」が特徴であると指摘しました。例えば、「レアカードやレアアイテムを手に入れる」「自分のキャラクターを強くする」といったことです。「いわゆる『チート攻撃』と呼ばれるものが、攻撃の大部分を占めます。私たち運営サイドも、日々チート攻撃への対策に頭を抱えているのが現状です」と実情を語りました。
山村氏は、会場のスクリーンに人気ソーシャルゲームの画面を表示し、具体的なチート攻撃の事例を再現しました。画面上で山村氏が操作するキャラクターの攻撃力はずば抜けており、敵を圧倒します。「これがチート攻撃の典型的な例」と山村氏は述べ、「あるユーザーがこのようなチート攻撃を行えば、他のユーザーの楽しみを奪うことにもなりかねない」と悪影響について説明しました。
続けて、山村氏はチート攻撃の変遷を解説しました。山村氏によれば、これまでのチート攻撃は「３つのパターンに分類できる」といいます。
「攻撃パターン１」は、ウェブベースのゲームを対象とした攻撃手法で、いわゆる「ガラケー（フィーチャーフォン）」が主流だった時期に登場しました。ウェブベースのゲームにおいて、端末からサーバに送信されるリクエストを狙う攻撃です。
一方「攻撃パターン２」は、サーバのレスポンスを改ざんする手法です。スマートフォン上で動作するゲームが増えるにつれて広がりました。サーバに送信するリクエストではなく、端末に対するサーバからのレスポンスを改ざんします。
そして現在増えているのが「攻撃パターン３」。端末内に保存されたゲームの内部データなどを直接攻撃します。スマートフォンが高度化し、端末内部での処理も増大しました。そのため端末内部のデータそのものが狙われるようになりました。
ウェブアプリの時代は、サーバへのリクエストデータが狙われた
概要の説明に続き、山村氏は、これら攻撃パターンの特徴について手法の詳細を解説しました。
「攻撃パターン１」は、サーバに対するリクエストを改ざんする攻撃ですが、山村氏は容易に行うことが可能であると指摘します。実際に会場でスマートフォンとパソコンを接続し、攻撃を実演しました。
山村氏はスマートフォンを、ゲームが提供されるネット上のサーバへ直接接続せず、Wi-Fi経由でパソコンに接続させ、サーバとの通信がパソコンを経由するようにしました。
あとはパソコン上へ、通信を仲介し、スマートフォンの代理としてサーバに接続する「プロキシーツール」を導入するだけで、端末とサーバでやりとるされるデータをすべて見ることができます。
プロキシーツールを悪用すれば、通信内容の盗聴はもちろん、サーバに送られるリクエストを簡単に書き換えることも可能です。ゲームの勝敗結果、攻撃力や防御力、アイテムの数などを書き換えるなど、簡単にチート攻撃が行えます。攻撃者は、手間をかけず効率的に、自分のキャラクターを強化できるだけでなく、アイテムも苦労することなく、集められるのです。
「攻撃パターン１」の基本的な対策は、「通信の暗号化」に加えて、「サーバ側でしっかりチェックすること」と山村氏は指摘しました。サーバ側でチェックする際は、3つのポイントがあるといいます。
ポイントのひとつ目は、データの正当性を確認し、想定外のデータがあった場合は排除すること。もし、「プラスの値が来るべきところにマイナスの値が来た場合は、エラーにする」という対処がなされていれば、プロキシーツールでデータが改ざんされていても、チート攻撃を食い止めることができます。
2つめはログの取得です。アイテム利用時などにログを取得しておけば、異常に気がつくことができます。チート攻撃を行ったユーザーのアカウントを停止するといった対処も可能となります。
３つめは、通信の改ざんに対するチェックです。通信するリクエストデータにリクエストデータのハッシュ値を付加し、サーバ側でチェックすれば改ざんの有無を確認できます。
山村氏は「せっかく施した対策も、破ってしまうユーザーがいるでしょう。しかし、簡単にはチート攻撃ができないよう敷居を高くすることは可能です」と、対策の意義を強調しました。
ネイティブアプリが主流になって、攻撃のトレンドはレスポンスデータへの攻撃へ
続いて山村氏は、「攻撃パターン2」として紹介したレスポンスデータの改ざん手法を解説しました。
多くのゲーム事業者が「攻撃パターン１」の対策を実施し。同時にソーシャルゲームのトレンドもウェブベースのゲームから、ネイティブアプリへと移っていきました。そこで台頭したのが「攻撃パターン2」です。
ネイティブアプリでは、攻撃力や防御力などのデータがサーバから送信され、スマートフォンで受信しています。このようなソーシャルゲームのトレンドの変遷に応じて、チート攻撃も「レスポンスデータ」を攻撃する手法へと移っていきました。
「攻撃パターン２」もプロキシーツールを使用しますが、「攻撃パターン１」とは異なり、攻撃力や防御力、スピードなどのデータをサーバから「受信する」タイミングで改ざんします。
例えばサーバが、キャラクターの能力を「攻撃3防御2精神力1速度1」として送信したとしても、攻撃者が受信する前に「攻撃999防御999精神力999速度999」と改ざんすることで、無敵のキャラクターをネイティブアプリ上に作り出すのです。
「攻撃パターン２」の対策について山村氏は、「攻撃パターン1と同様、ハッシュ値による改ざんの検知、通信の暗号化、ログの取得、異常値の監視などの対策が必要です」と述べる一方、「対策を施しても突破されると思っておいたほうがいい」と注意を呼びかけます。
「暗号化したからといって安心できません。暗号化対策を実施しても、共通鍵を見つけ出すユーザーがいます。共通鍵が明らかになれば、暗号化による対策は意味がなくなってしまいます」と山村氏は対策の難しさを語りました。
突破されたときに備える対策が、ログの取得と異常値の検知です。ゲームのログを記録し、常に監視することで、異常な値があった場合はチート攻撃の可能性があると見て、防御することができます。
近年増えたゲーム内部データ改ざん攻撃
ネイティブアプリの時代へ移ってから増えたのが、「攻撃パターン３」の「内部データの改ざん」です。プログラムを解析するリバースエンジニアリングにより、メモリやバイナリデータが改ざんされます。
具体的な事例として山村氏は、サーバへ送信するためにゲームアプリが端末上で生成したリクエストデータを攻撃者が改ざんするケースを挙げました。攻撃者は、スマートフォンのメモリ上にあるデータを直接書き換えるのです。
「攻撃パターン１」では、通信するリクエストデータにハッシュ値を追加することで対策を実施しました。しかし、メモリ上でデータが改ざんされると、「改ざんされたデータ」をもとに「ハッシュ値」が生成されます。そのためデータを受け取ったサーバでは、正しいリクエストとして処理してしまい、改ざんを検知できません。
山村氏は「攻撃者は、リバースエンジニアリングによって、ゲームを完全にコントロールできます。通信の暗号化や改ざん検知は役に立ちません」と指摘。技術的に敷居が高いものの、攻撃ツールがやり取りされており、「大きな課題」であると警鐘を鳴らしました。
「攻撃パターン３」の対策について山村氏は、「安全を保つのは非常に難しく、イタチごっこにならざるを得ません」と語りました。対策を施しても、別の攻撃手法を編み出されるのが実状だといいます。だからこそ「暗号化、ハッシュ値による改ざん検知なども含めて、『できる対策』を漏れなく行うことが重要」と山村氏は強調しました。
また「被害の大きさを見極めた対策も効果的」と山村氏は指摘しました。例えば、ゲーム内の仮想通貨として利用される「コイン」などを狙われた場合、被害も大きくなります。コインの消費に関する処理をスマートフォン上では行わず、サーバ上で実行する仕組みに変えれば影響を受けにくくなります。
White Box診断で開発者と連携を取りながらセキュアなゲームアプリを作る
最後に山村氏は、グリーで行っている脆弱性診断「White box診断」について紹介しました。
「White box診断」では、ソースコードを見て、脆弱性の有無をチェックします。セキュリティ部の診断チームが社内で行う「内製脆弱性診断」と、社外のセキュリティ業者に依頼して行う「外注脆弱性診断」の2種類をメニューとして提供しているそうです。
「White box診断」について山村氏は「ソースコードがすべて見られるので、非常に効率的。ソースコードに問題があれば具体的に開発部門にも指摘でき、組織間の連携も取りやすい」とメリットを挙げました。また、検証時に問題がなくとも、「将来、脆弱性になりかねない点」も発見できることがあると言います。
「グリーではCTOが技術で事業に貢献すると明言しています。White box診断などで開発部門にフィードバックすることで、事業に貢献できます。それは安全なサービスを提供する意味でも、ゲームユーザーにとっても利点となります」と語り、山村氏は講演を締めくくりました。
【編集協力：Security NEXT 企画制作部】