ソースコード診断から一歩踏み込んだ「アプリケーションペネトレーションテスト」とは？

オンラインサービスやアプリケーションの利用が日常の一部となった今、利用者や利用場面が増えるほど、悪意ある攻撃者に狙われやすくなります。潜在的な脆弱性や、仕様・設定の不備が存在すると、その弱点を狙った悪意ある攻撃者によるサイバー攻撃や内部不正行為が発生してしまう可能性があります。

サイバー攻撃や内部不正によって不正ログインや個人情報の漏えいが発生してしまうと、企業イメージの低下やサービス停止になる恐れがあります。そのような被害にあわないためにも、攻撃される可能性のある脆弱性や仕様・設定不備を調査し、修正するなどのセキュリティ対策を実施し、信頼性を向上させることが重要です。

今回は、アプリを悪意のある攻撃者から守るために有効なセキュリティテストの1つである、「アプリケーションペネトレーションテスト」をご紹介します。

ラックのアプリケーションペネトレーションテストの特徴

アプリケーションに対するセキュリティテストと聞くと、多くの方がWebアプリケーション脆弱性診断を思い浮かべるのではないでしょうか。

Webアプリケーション脆弱性診断では、診断対象のWebアプリケーションに対して、「シグネチャ」と呼ばれる特殊な文字列を送信したり、処理を実行したりすることで、その応答結果や動作から脆弱性の有無を判断します。診断はあらかじめ定められた項目に基づき、診断ツールや手動診断などの手段でシグネチャを送信していくことで、脆弱性の有無を網羅的に調査します。

ラックのアプリケーションペネトレーションテストは、Webアプリケーション脆弱性診断とは異なるアプローチで調査を行います。アプローチの特徴は大きく2点あります。

ホワイトボックステストのアプローチを採用

1つ目は、「ホワイトボックステスト」のアプローチをペネトレーションテストに取り入れている点です。

一般的な脆弱性診断は、システムの内部構造は考慮せずに、外部からの攻撃者の視点でシステムにアクセスしてテストを行う「ブラックボックステスト」が一般的です。これに対してアプリケーションペネトレーションテストでは、システムの内部構造を把握した上で実施する「ホワイトボックステスト」を採用しています。

具体的には、お客様から提供いただいた対象アプリケーションのソースコードやドキュメントを基に、システムの内部的な情報を詳細に確認することで、より効率的で精度の高い調査を実施します。ホワイトボックステストのメリットには、ブラックボックステストのみでは検出が難しい複雑な攻撃手法や、セキュリティ上の問題点を検出できることが挙げられます。

また、システム内部の詳細を確認するため、問題の報告だけでなく改善策を具体的に提案することも可能です。

「ホワイトボックステスト」と「攻撃者視点」の検証の組み合わせ

2つ目は、「ホワイトボックステスト」と、「攻撃者視点」の検証を組み合わせることです。アプリケーションペネトレーションテストでは、ソースコードやドキュメントの調査から検出したセキュリティ上の問題点について、「悪意のある攻撃者の目線」で攻撃を実施することで、その問題点が実際に悪用可能なものかどうかを検証します。

ホワイトボックステストと攻撃者視点を組み合わせた検証をブラックボックステストと比較すると、単なるアプリケーションの脆弱性に留まらず、システムの設計や仕様、設定、ソースコードについて品質や開発者の癖などを含めて全方位で深掘りできることが大きな特徴です。内部の詳細を把握して調査を行うため、特定の機能に限定した調査も実施できます。

ブラックボックステストのみでは効果的なテストが難しいアプリケーションや機能についても、このようなアプローチであればテストが可能です。例えば、「特定のタイミングでのみ動作する機能」や「ゲームを長時間プレイしていないと解禁されない機能」などが挙げられます。ブラックボックステストの場合は、そもそもこのような機能の存在に気付くこと自体が困難です。しかし、ホワイトボックステストのアプローチであれば、ソースコード全体を調査することで特定の条件下で発生する挙動を把握し、その上でセキュリティリスクの有無を調査できます。

アプリケーションペネトレーションテストの活用例

アプリケーションペネトレーションテストの「ホワイトボックステスト」×「攻撃者視点」のアプローチを、オンラインゲームにおけるチート可否の調査、クラウド上に構築したアプリケーションの調査、それぞれどのように活用したのか紹介します。

オンラインゲームにおけるチート可否の調査（サーバ×クライアントアプリの例）

「ホワイトボックステスト」×「攻撃者視点」のアプローチが特に有用な例として挙げられるのが、オンラインゲームです。

オンラインゲームの大きな脅威の1つは「チート」です。チートとは、ゲームのプログラムの不正な改造や通信内容の改ざんによって、ゲームに存在する脆弱性や仕様を悪用し、ゲームバランスを崩壊させる行為です。チートには、不正課金による有料アイテムの窃取、アカウントの不正取得、キャラクターのパラメータ改ざんによるゲームバランスの崩壊、チート情報の拡散、RMT（リアルマネートレード：ゲームのアカウントやゲーム内のアイテムなどを現実の通貨で売買する行為）による不正入手アイテムの販売、DoS攻撃によるサービスの妨害などの違法行為があります。

ここでは、架空のゲームを例にとってチート行為やその可否を調査する方法を紹介します。この架空のゲームでは、有償で購入したゲーム内通貨である「虹石」を必要な数だけ消費することで、ゲームで使用できる強いキャラクター、武器、アイテムなどが手に入る「ガチャ」を回せます。

プレイヤーは「虹石」を使って「ガチャ」を引きますが、もし「虹石」を消費せずに「ガチャ」を回せたら......。プレイヤーにとっては大きな魅力になりますが、ゲームの運営側にとってはゲームバランスの崩壊に加え、収益にも影響が発生します。

「ホワイトボックステスト」×「攻撃者視点」のアプローチでチート行為の可否について調査をする場合、お客様より提供いただいたソースコードを目視で確認し、チート行為に悪用される部分を探し出します。

一般的なオンラインゲームは、サーバ側のアプリケーションとクライアント側のアプリケーションによって構成されます。そのため、オンラインゲームを対象とする場合は、サーバ側だけではなく、クライアント側のソースコードも存在するため、両方について調査を行います。

例えば、「ガチャ」を回す操作の場合は、クライアント側から「ガチャ」を回すリクエストが送られ、それを受けてサーバ側ではクライアント側が所持している「虹石」の数を確認し、「ガチャ」を回すために必要な数の「虹石」を持っていることが確認できた時点で「ガチャ」を実行し、「ガチャ」の実行結果を保存する、という処理を行います。ソースコードの中でそれぞれの処理を行っている箇所を目視で確認し、悪用できる恐れがある箇所が無いかを確認します。

この架空のゲームの中では、サーバ側でクライアント側が所持している「虹石」の数を確認する処理の中で排他制御が行われていない可能性があることを確認したと仮定します。ここまでがホワイトボックステストの領域です。

ホワイトボックステストの中で悪用できる恐れがある箇所を検出した場合は、当該箇所のソースコードを書き換え、サーバ側にリクエストを実際に送信します。サーバ側でクライアント側が所持している「虹石」の数を確認する処理の中で排他制御が行われていないと考えられることから、クライアント側の「ガチャ」試行リクエストの送信内容をキャプチャし、同一のタイミングで多重に送信します。実際にサーバ側で排他制御の不備がある場合は、「虹石」の正常な所持数が確認されないまま「ガチャ」を複数回せます。

このように書き換えたリクエストがサーバ側で検証されることなく受け入れられればチート行為、すなわち攻撃に成功したということになります。この部分が攻撃者視点の調査にあたる領域です。

クラウド上に構築したアプリケーションの調査

「ホワイトボックステスト」×「攻撃者視点」のアプローチは、クラウド上に構築したアプリケーションにも応用可能です。クラウド上に構築したアプリケーションについて調査する場合、先述のアプローチでアプリケーションについて調査することに加え、アプリケーションに関連するシステム（サーバ、AWSやMicrosoft Azureなどのクラウドサービス）の設定についても調査できます。

クラウド部分についてのホワイトボックステストでは、クラウドの各種サービスに対する設定を確認し、攻撃に悪用される可能性のある箇所の有無を調査します。ホワイトボックステストの中で悪用できる恐れがある箇所を検出した場合は、実際にクラウド上で動作しているアプリケーションを操作して、問題点が悪用可能なものかどうかを検証します。

ペネトレーションテストと攻撃シナリオ

ペネトレーションテストは「現実的な攻撃シナリオを用いて攻撃者の目的が達成されるかどうかを実証する」テストで、どのような攻撃を行うかを定義する攻撃シナリオが重要です。攻撃シナリオは、主にテストの対象を指す「スコープ」、テストの開始地点を指す「起点」、そしてテストのゴールや目的を指す「目標」から構成されます。アプリケーションペネトレーションテストの場合の攻撃シナリオはどのようになるのでしょうか。

スコープ

まず、テストのスコープはもちろんアプリケーションそのものです。ただし、必要に応じてアプリケーションの土台となっているサーバや各種クラウドサービスなどもスコープに含めてシステム全体をスコープとする場合もあります。システム全体をスコープとすることで、より幅広い視点でセキュリティ上の問題点を洗い出せます。

起点

アプリケーションペネトレーションテストの「起点」について考える際は、テストの開始地点について「どこから？」というよりは、「誰が？」という視点で考えることが重要です。例えば、外部の悪意ある攻撃者によるアプリケーションへの攻撃を想定している場合は、その攻撃者が持ちうる権限を用いて「攻撃者視点」の検証を行います。

一方で、アプリケーションを使用して不正行為や侵害行為をするのは外部の悪意ある攻撃者だけではありません。昨今のセキュリティ対策の中で注目されているキーワードに「内部不正」があります。外部の悪意ある攻撃者と比較して、すでにアプリケーションを利用する権限を持っている内部のユーザなどの内部不正者は、より高位の権限を持っていると考えられます。そのようなユーザによる特権昇格などの内部不正を想定した「内部不正者」視点でのテストも、アプリケーションペネトレーションテストで対応可能です。

目標

「目標」はテストのゴール、つまり攻撃者視点では攻撃者が達成したい目的にあたります。これはアプリケーションの性質や想定しているリスクによって多岐にわたります。報道などでしばしば目にする「機密情報の窃取」は攻撃者の目標の代表格であるほか、先述のオンラインゲームの場合は「ガチャ引き放題」や「無敵状態」などのゲームバランスを崩壊させる行為が攻撃者にとっての目的となりえます。

脆弱性の有無を幅広く調査する脆弱性診断と比較して、アプリケーションペネトレーションテストでは攻撃者が達成可能な攻撃や不正行為を実際に検証することが可能です。テスト後は検出した問題点と合わせて改善策を提案することから、アプリケーションの信頼性の向上やサービス運営の安定化などの効果が期待できます。

おわりに

「すでに脆弱性診断を実施しているが、さらに踏み込んだテストを実施したい」、「クラウドサービスを活用してWebサービスを開発したが、セキュリティ面で不安がある」のような場合、「ホワイトボックステスト」×「攻撃者視点」のアプローチを用いるアプリケーションペネトレーションテストは有用な手段であると言えます。

ソースコード診断では、Windows、macOS、Linux系OSなど、OSを問わずあらゆる言語、プラットフォームの調査が可能です。また、HTTP/HTTPS以外のプロトコルの調査実績もあり、アプリの特性に合わせた検証内容を実施します。アプリケーションのセキュリティ対策についてお悩みなどありましたら、お気軽にラックまでご相談ください。