MANABIYA #1のランチセッションに登壇しました

こんにちわ。オルトプラスラボの菊池です。

先日開催されたMANABIYAにて、ランチセッションに登壇させていただきました。

資料はこちらになります。

以下の2種類の攻撃を紹介させていただきました。
  1. ゲームのスコア改ざん
  2. ウォレット(風)アプリの認証迂回

 

ゲームアプリのスコア改ざん

ゲームアプリのスコアの値を大きな値に書き換えてしまうことで、スコアランキング上位に食い込もう!という攻撃です。コンシューマゲームの頃から変わらず行われてきた、いかにもなチート行為ですね。

※ライブハッキングのために作ったゲームです

手法もその頃と大きく変わらず、

  1. メモリアドレスを探して
  2. 書き換える

という2ステップです。ゲームを進めながら値の変化を観察し、書き換えるべきアドレスを探します。アドレスが見つかったら実際にメモリ書き換えを行うわけですが、その際には多くのツールでptraceシステムコールを使うことでしょう。これは防げないものでしょうか?

ptraceを防ぐ

ptraceはデバッグ等の目的のために存在する機能ですが、悪用するとかなりの脅威となりますので、防いでおくに越したことはないでしょう。ptraceは1プロセスにつき1つしか同時にアタッチできませんので、あらかじめ自前のプロセスでアタッチしておくことで、第三者によるアタッチを防ぐことができます。

細かい話をすると、ptrace自体が事前にフックされていて迂回されるようなこともありますが、そこはまぁ永遠のいたちごっこです。100%防ぐことは難しいですが、こういった防御で大事なのは攻撃者にいかに手間をかけさせるか、という点です。できる限りの対策をするに越したことはないでしょう。

 

ウォレットアプリの認証迂回

ウォレット風アプリのPIN認証を、ランタイム改ざんで突破しよう!というデモでした。


手口としては、soファイルインジェクションからのDEX(Javaコード)インジェクション、最終的にはstaticなobjectを置き換えてしまう、というものでした。

Javaコードのインジェクションについては、概要を「ハッキング技法#3: Java APIのフック」で解説しています。この記事や今回のライブハッキングにおいても、objectの置き換えをすることでアプリの動作を改ざんしていますが、直接Javaクラスインスタンスのメソッドを置き換えてしまうような攻撃も可能です。怖いですね。

こちらでもsoファイルインジェクションのためにptraceを利用していますので、上記のptrace対策は有効です。他にも、ROOTED端末での動作を禁止することもアプリへのリスクを抑えるためには有効です。(ただし、ROOTED端末=不正利用者、というわけではありません。そこが悩むところです。)

 

難読化はきちんとしましょう

今回のデモでは、攻撃前にアプリの解析を行い、攻撃方法を検討しました。ソースコードが読みにくいだけでもかなり攻撃の手間は大きくなるでしょう。ptraceもそうですが、いかに手間をかけさせるか、というのは大事なポイントです。「どうせ100%守れないから対策は不要」ということではないのです。

 

DxShieldのご紹介

ライブハッキングの実演後、ハッキングから守るソリューションとしてDxShieldのご紹介をさせていただきました。DxShieldを適用しているアプリでは、メモリ改ざんのためのメモリ検索開始時に以下のようなダイアログをDxShieldが表示し、アプリは終了します。

DxShieldでは、実演したメモリ改ざん検出だけではなく、上述したptrace防止機能、Javaコードの難読化・二重暗号化機能、APIフックの検知遮断機能、アプリ改ざん検知…といった多くの機能を備えています。SDK不要で簡単に使えますので、ぜひ導入をご検討いただければ幸いです。

皆さんのアプリはどのようなハッキング対策をしていますか?
たまには、自分のアプリを攻撃者の目線で見てみると良いかもしれませんね。