Upgrade to Pro — share decks privately, control downloads, hide ads and more …

実際に診断であったゲームの脆弱性

 実際に診断であったゲームの脆弱性

Shibuya.gamesec #2の資料です。

DeNA ではリリース・アップデートするゲームサービスに対して脆弱性診断を行っていま す。今回は過去に行われた脆弱性診断で実際にどのような脆弱性が見つかっているかを紹 介します。 また、そこからゲーム開発・運用時に注意すべき点について考察を行い、実際に DeNA で はどのようなことを行っているかについて紹介をします。

Hyu Ogawa@DeNA

August 26, 2022
Tweet

Other Decks in Technology

Transcript

  1. © DeNA Co.,Ltd. 2 自己紹介
 0 Hyu Ogawa
 - Twitter:

    @__fiord
 - 大学時代にCTFをやっていて、現在DeNA入って2年目 
 - Crypto+Revメイン(?)
 - 最近はfrida等を用いたチートにハマってます。 
 - 発展してHyperDbgをAndroidで動かせないかなぁ...とか。 

  2. © DeNA Co.,Ltd. 5 DeNAでの脆弱性診断について
 1 • サービスの新規リリース・アップデート前に実施 
 ◦

    診断不要と判断されるケースもあり 
 • リリース前に危険な箇所を指摘し、安全な状態にしてリリースしてもらう 
 
 • High/Medium/Low/Info等の4段階で脆弱性を報告 
 • 2018年4月以降、脆弱性診断をJiraで管理するように 
 ◦ Jiraのチケットで一番古いものからの推測で、正確な情報ではありません

  3. © DeNA Co.,Ltd. 7 脆弱性の統計
 
 注意
 • 集計結果は⭕「こういう脆弱性があった」❌「こういう脆弱性が多かった」
 ◦

    アップデート等、同じプロダクトに対して診断を複数回行っている 
 ◦ 同じ脆弱性が見つかった際に、チケットを分けるかはその人次第 
 ◦ 脆弱性をどの程度まとめるかもその人次第 
 • 集計に際しての分類は独断と偏見によります 
 
 1
  4. © DeNA Co.,Ltd. 11 リクエスト改ざんによる脆弱性
 主に以下が該当
 - リクエスト改ざん
 - レスポンス改ざん


    - リクエスト再送・同時送信
 - 脆弱な暗号方式の使用(MIMを想定) 
 - ポリシー満たしているかだけなので詳細は割愛 
 - DDoS
 2
  5. © DeNA Co.,Ltd. 13 リクエスト改ざんの事例1
 High: 不正なアイテムでのガチャの実行 
 • 特定のコインを用いて引けるガチャにて、gacha_idとcoin_idの両方を送信

    
 • coin_idを改ざんすることで他のガチャコインで実行できてしまう 
 mitigation: バリデーション
 • gacha_idとcoin_idのペアは正しいものですか? 
 • リクエスト仕様としてcoin_idが不要な気もします 
 
 2
  6. © DeNA Co.,Ltd. 14 リクエスト改ざんの事例2
 High: リクエスト改ざんによるDoS 
 • プロフィールのアイコン・称号等に存在しないものを指定

    
 →フレンドが不正IDのユーザーを閲覧しようとするとアプリが落ちる 
 mitigation: バリデーション
 • そもそもサーバー側で登録時に存在しないデータを参照しないように 
 • クライアント側で存在しないデータがあってもデフォルト値等で回避する 
 
 2
  7. © DeNA Co.,Ltd. 16 レスポンス改ざんの事例
 Medium: 利用不可能ユニットの再利用 
 • 利用できないユニットが使えてしまう

    
 ◦ レイド・連戦機能などで「過去に編成したユニットの再利用禁止」 
 ◦ 大会などでの「禁止ユニット」
 • ユニットのブラックリスト・ホワイトリストにて改ざん 
 mitigation: バリデーション
 • レスポンス改ざんの結果送られるリクエストは正しい? 
 • パケット改ざんに対する対策を強めましょう 
 
 2
  8. © DeNA Co.,Ltd. 18 リクエスト・レスポンス改ざんの共通対策
 パフォーマンスと相談して暗号化はちゃんとしましょう 
 • 共通鍵暗号方式よりは公開鍵暗号方式の方が望ましい 


    ◦ 秘密鍵が分からないので改ざんが難しくなる 
 ▪ 公開鍵をアプリ改ざんしてproxyを噛ませる形に 
 ◦ RSAでAESの鍵交換するとか
 2
  9. © DeNA Co.,Ltd. 20 リクエスト再送・同時送信
 リクエスト再送
 • Proxyに記録したパケットをもう一度投げる 
 リクエスト同時送信


    • トランザクションロックされていないことを狙って大量に同じパケットを送信 
 
 2
  10. © DeNA Co.,Ltd. 21 リクエスト同時送信・再送の事例
 High: リクエスト同時送信による一回分のアイテム消費で複数回ガチャを引く 
 • トランザクション不備によるもの


    
 
 mitigation: トランザクションの設置 
 • 何らかの方法でロックを取ってあげるとよさそうです。Mutexでもよさそう 
 2
  11. © DeNA Co.,Ltd. 23 DDoSの事例
 Medium: リクエスト毎にリクエストサイズが増大することによるDDoSの可能性 
 • パーティー編成機能にて、変更内容(複数)をリクエストとして送信していた

    
 ◦ ユニットAを枠1に置いて...という情報 
 ◦ 「変更内容の個数に上限が無い」かつ「過去の変更情報も送信」 
 ◦ クライアント側で何度も編成を行うとだんだんリクエストが大きく... 
 mitigation: リクエスト仕様の改訂 
 • 恐らく通信に失敗した可能性を考えて「変更内容」にしている? 
 • どこまで履歴が必要か考え、数の制限を付けるとか 
 2
  12. © DeNA Co.,Ltd. 25 メモリ改ざんによる脆弱性
 • 暗号化でリクエスト改ざん・レスポンス改ざんに耐性がある時に 
 • バトル中など、通信が発生していない箇所にて

    
 apk-meditやGame Guardian、Fridaでも一応出来る
 変数をありえない値にして不正を狙うのが主 
 • UnityだとAnti-Cheat Toolkitとかもあるらしい 
 • 値をそのまま残すと簡単に見つかるので、xorや暗号化で別の値として保持 
 ◦ が、簡単だと検索される、難しくするとパフォーマンスが落ちる 
 • ので検知もおすすめ
 3
  13. © DeNA Co.,Ltd. 26 メモリ改ざんの事例2
 High: ランキング機能におけるスコアチート 
 • スコアの書き換えにより、ランキングを荒らすことが可能

    
 mitigation: メモリ改ざん対策
 • 値を隠してね
 • ランキング上位と同等のスコアとかだと分かりにくい場合も 
 • 監視で理論値以上を弾く運用とか 
 ◦ スコアのみならず、スコア算出に用いている値を送信すると◦ 
 ◦ ゲーム中に現在時点の情報をサーバーに記録、後追い出来ると◎ 
 
 3
  14. © DeNA Co.,Ltd. 29 その他の脆弱性
 アプリ解析
 • UnityでIL2CPPを用いている場合 
 ◦

    global-metadata.datから関数名やシンボル名が復元可能 
 • アセットデータの暗号化不備、セーブデータの改ざん 
 ◦ アセットを抜き出せる→リークにより売上に影響 
 • 重要なログの露出
 ◦ adb logcatとかやっていてパケットの中身をデバッグ出力していたり 
 ◦ エラーログからコード解読のヒントになったり 
 4
  15. © DeNA Co.,Ltd. 30 その他の脆弱性
 • ツールの使用による自動化
 ◦ iPhoneのスイッチコントロールなど 


    • プロセスのKill
 ◦ 特定のタイミングでアプリを落とすことで特定の操作をキャンセル出来る 
 ◦ 1人のPvEゲームで有利に働く場合も 
 • 端末の時間操作
 ◦ オフライン状態で端末の時間を弄る定番のやつ 
 4
  16. © DeNA Co.,Ltd. 32 振り返り
 • ゲームでも基本的にはクライアントを信用してはいけない 
 ◦ 可能な限りサーバー側でもバリデーションを行って欲しい

    
 ◦ 割と見逃しがちな観点は経験な気もします 
 • リクエスト・レスポンス改ざんやメモリ改ざんへの対策はしっかりと 
 ◦ 通信の暗号化・メモリ改ざん検知等 
 
 5