ブログ

FFRI BLOG

CODE BLUE 2016で発表した脆弱性の特性評価と解析で使用したツールの紹介

 今回は、CODE BLUE 2016で発表した、「IoTとしての自動車セキュリティ:リモートサービスのセキュリティ評価とその対策の検討」の補足として、発見した脆弱性の特性(リスク)評価とAndroBugsが検出した脆弱性リスクのある箇所を実際に解析する際に使用したツールについて紹介します。

・CODE BLUE 2016の紹介

 2016年10月20日から21日の2日間、国際情報セキュリティ会議であるCODE BLUE 2016が開催されました。今回は、100件を越える発表の投稿があり、中でも国外からの投稿が非常に多かったそうです。また、事前の参加登録もおよそ800人(昨年度は600人)とCODE BLUEは世界的にも非常に注目されているイベントであるといえます。

・CVSS v3(基本値)による脆弱性の特性(リスク値)評価

 CVSSは「Common Vulnerability Scoring System(共通脆弱性評価システム)」の頭文字を取った略語で、脆弱性の特性を評価し、数値化することで定量的な評価を行う事が出来る手法の1つです。今回は昨年の6月に新たに公開された最新のCVSS v3を使用して脆弱性の評価を行ってみたいと思います。

 CVSS v3の詳細については、FIRSTやIPAのページで公開されているので、ここでは簡単に解説します。まずv2からの大きな変化としては、「脆弱性のあるコンポーネントとその影響範囲に注目した」評価方法に変化しているという点が挙げられます。以下の表はこうした変化の中でも特徴的な、「ユーザ関与レベル(UI)」と「スコープ(S)」の定義です。

表 1 新たに追加された評価項目例(説明文は情報処理推進機構 共通脆弱性評価システムCVSS
v3概説(https://www.ipa.go.jp/security/vuln/CVSSv3.html)より抜粋)

メトリクス 説明 評価値 内容
ユーザ関与レベル(UI) 脆弱性のあるコンポーネントを攻撃する際に必要なユーザ関与レベルを評価します。 不要 ユーザがなにもしなくても脆弱性が攻撃される可能性がある。
リンクのクリック、ファイルの閲覧、設定の変更など、ユーザの動作が必要である。
スコープ(S) 脆弱性のあるコンポーネントへの攻撃による影響範囲を評価します。 変更なし 影響範囲が脆弱性のあるコンポーネントの帰属するオーソリゼーションスコープに留まる。
変更あり 影響範囲が脆弱性のあるコンポーネントの帰属するオーソリゼーションスコープ以外にも広がる可能性がある。 例えば、クロスサイトスクリプティング、リフレクター攻撃に悪用される可能性のある脆弱性など。

 ユーザ関与レベルについては、攻撃を成立させる為にユーザによる操作が必要であるかどうかという観点ですので、非常に分かりやすいかと思いますが、スコープの考え方については「オーソリゼーションスコープ」という概念が登場しているため、少し分かりにくいかも知れません。オーソリゼーションスコープは、「計算機資源に対する管理権限の範囲」と定義されており、脆弱なコンポーネントに対して攻撃が行われたときに、結果として異なる管理権限のコンポーネントにも影響があるかどうかで判断されます。分かりやすい例としては、サンドボックスをバイパス可能な脆弱性や仮想マシンの脆弱性によってゲストOSからホストOSのファイルに干渉できてしまう場合等が該当します。

 実際に CVSS v3を使用して評価した結果は以下の通りとなります。

・脆弱性#1. ユーザ情報を含むHTTP通信

 この脆弱性によって攻撃者は通信データからユーザ情報を得たり、通信を改ざんする事が出来ますが、これによってコンポーネントに直接重大な影響を与える事はありません。

基本値(Base Score) メトリクス 評価
7.3 (重要) 攻撃元区分 (AV) ネットワーク
攻撃条件の複雑さ (AC)
必要な特権レベル (PR) 不要
ユーザ関与レベル (UI) 不要
スコープ (S) 変更なし
機密性への影響 (C)
完全性への影響 (I)
可用性への影響 (A)

・脆弱性#2. サーバー証明書検証不備

 この脆弱性によってアプリ利用者はMITM攻撃を受ける可能性が有ります。アプリと同一のネットワークにアクセス可能な攻撃者は通信データの盗聴や改ざんを行う可能性が有ります。

基本値(Base Score) メトリクス 評価
6.4 (警告) 攻撃元区分 (AV) 隣接
攻撃条件の複雑さ (AC)
必要な特権レベル (PR) 不要
ユーザ関与レベル (UI)
スコープ (S) 変更なし
機密性への影響 (C)
完全性への影響 (I)
可用性への影響 (A)

・Androidアプリの解析で使用したツールの紹介

 Androidアプリの解析を行う前準備として、 主に3つのステップがあります。(図1) 最初のステップであるAPKの入手ですが今回の調査では、国内外の様々なOEMが提供しているアプリを対象としていたため、公式のマーケットプレイスからではなく国外のアプリも入手可能な非公式のマーケットプレイスを利用してアプリを収集しています。

図 1 Androidアプリをリバースエンジニアリングするための3ステップ

 続いて各ステップで使用するツールの一覧を以下に列挙します(各ステップの詳細は補足スライドをご覧下さい)。なお、これらのツールは脆弱性の調査だけでなく、マルウェアの解析などでも同様に利用する事が可能ですが、マルウェア解析に関してはCuckooやViperなどの自動化されたツールが存在しているため、効率化の面においてはそれらの利用を検討するべきでしょう。

ツール名/入手元 説明
adb(Android Debug Bridge)
https://developer.android.com/index.html
デバイスにインストールされているパッケージを探したり、APKをローカルマシンにダウンロード(pull)したりする。また、動的な解析(デバッグ)を行う際にも利用できる。
Apktool
https://ibotpeaches.github.io/Apktool/
APKのアンパック及びリソースファイルやマニフェストファイルのデコード、DEXファイルからsmaliファイルに変換する。
dex2jar
https://github.com/pxb1988/dex2jar
DEXファイルからJARファイルに変換する。
Java Decompiler(JD-GUI)
http://jd.benow.ca/
JARファイルに内包されているclassファイルからjavaにデコンパイルする。

・ソースコードは入手できた!でも次はどうする?

 まずはどこから解析をするか、解析のエントリポイントを探すことになります。色々な方法が考えられますが、より深い解析には勘や経験が依存する場合が有ります(より多くの脆弱性とそれらをエクスプロイトする為の知識が必要。例えば、通信プロトコルの実装ミスを探す場合、プロトコル仕様を理解している必要がある、など)。
 そこで、AndroBugsのような脆弱性スキャナを利用することで、解析のエントリポイントを比較的容易に決定する事が出来ます。加えて、AndroBugsは一般的な脆弱性を検出する為のスキャナであるため、エントリポイントとなる箇所をより効果的に解析出来るように、“Androidセキュア設計・セキュアコーディングガイド”を呼んでおくことをお勧めします。

・まとめ

 発見した脆弱性は基本値を見ると非常に重大な問題であると判断する事が出来ます。その一方で、この値は基本値のみであり、現状値や環境値などの評価指標(メトリクス)を加味する事で対象ソフトウェアの開発やサポートが終了していない限り、一般的にリスク値は時間と共に低下していく傾向に有ります。
 その脆弱性を発見するために行ったAndroidアプリのリバースエンジニアリングは、一般的な脆弱性に限って言えば、多くの情報やツールが世の中には存在しているため、技術的な難易度という点においては比較的容易ということがいえます。ただし、これは逆に攻撃者達や彼らが公開したツールなどを無邪気に使用するスクリプトキディ達にも同じ事がいえるため、セキュア設計・セキュアコーディングは改めて徹底して頂きたいと思います。


関連記事

リサーチ・ペーパー 「IoTとしての自動車とセキュリティ:リモートサービスのセキュリティ評価とその対策の検討 」

Monthly Research 「IoTデバイスのセキュリティの現状」

Monthly Research 「自動車の脆弱性事例とCVSS v3による評価」

pagetop