CyRC特別レポート：アプリが安全かどうかに 賭けてはいけない

シノプシスのCybersecurity Research Centerは、最も人気の高い10のAndroid用スポーツ・ベッティング・アプリについてセキュリティ分析を行いました。

米国のスーパー・ボウルが近づく中、シノプシスのCybersecurity Research Center（CyRC）は、最も人気のある10のAndroid用スポーツ・ベッティング・アプリをサプライ・チェーンのセキュリティの観点から評価することにしました。Black Duck® Binary Analysis（BDBA）を使用して、これらのアプリで使用されているオープンソース・コンポーネントの調査を行いました。

要約

分析対象の10のアプリは、Google Playストアから合計で2,150万回以上ダウンロードされています。見方を変えると、これらのアプリは、大都市サン・パウロの人口に匹敵するほど多くの人にダウンロードされていることになります。

• アプリあたりのコンポーネントの平均数：125
• アプリあたりの脆弱なコンポーネントの平均数：10
• アプリあたりの脆弱性の平均数：179

活発な開発が行われているにもかかわらず、当社が分析したアプリの多くは、関連する既知の脆弱性を含んでいる古いオープンソース・コンポーネントを使用しています。ソフトウェアの世界では、2～3年というのは長い時間であり、当社が分析したアプリの中には、2010年までさかのぼるオープンソース・コンポーネントもありました。

オープンソース・コンポーネントの既知の脆弱性が、必ずしもアプリから露出するわけではありません。しかし、コンポーネントが古くなり、既知の脆弱性の数が増加すれば、リスクは拡大します。さらに、古くなったコンポーネントは、開発チームがオープンソースの依存関係を管理していないことを示唆するものであり、一般的にセキュリティ管理が適切に行われていないことを示唆している可能性があります。

当社が分析したスポーツ・アプリ・ベッティング・アプリのスコアは、2021年のレポート「コロナ禍における危機的状況」で発表した平均値を大きく下回る、かなり悪い値となりました。このリサーチで、当社は3,335個のアプリを調べ、以下のことが判明しました。

• 脆弱なコンポーネントがあるアプリ：63%（この分析では100%）
• アプリ当たりの脆弱性の平均数：39（この分析では179）

これらのアプリは安全に使用できるのでしょうか？ 開発チームの中には、オープンソースの依存関係をうまく管理しているところもあります。残念ながら、消費者はこれらの状況を把握することはできず、アプリ開発者やアプリ・ストアがセキュリティ・プロセスを改善してくれることを期待するしかありません。当社がこういった分析を行うことができるのであれば、アプリ・ストアもこういった分析を行うことができます。

ソフトウェア・コンポーネントの脆弱性に基準を設定すれば、その基準が低くても、アプリ・ストアで許可されているアプリのセキュリティを向上させることができます。これにより、消費者にとっても、アプリ開発者にとっても、そしてエコシステム全体にとっても、リスクを低減させることができます。

ソフトウェアはどのように作られるか

結果を詳しく分析する前に、ソフトウェアがどのように作られるのかを見てましょう。

ほとんどすべてのソフトウェアは、構成要素にオープンソース・ソフトウェア（OSS）コンポーネントを使用して作成されています。オープンソース・コンポーネントが機能を提供し、開発チームがファーストパーティ・コードを書くことでそれらを「結び付け」ます。オープンソース・コンポーネントはアプリケーションの依存関係です。

また、完全なアプリケーションは通常、いくつかのパーツで構成されています。モバイル・ベッティング・アプリケーションの場合、このモバイル・アプリ自体が1つのパーツです。その他のパーツには、Webアプリケーション、バックエンド・サーバー、データベースなどが含まれます。アプリ、Webアプリケーション、バックエンド・サーバーは、オープンソース・コンポーネントの構成要素の一番上にファーストパーティ・コードを少し載せるというこのパターンに従っています。

オープンソース・コンポーネントを使用することで、開発チームはソフトウェアを迅速に市場に投入することができますが、リスクを最小限に抑えるために、オープンソース・コンポーネントを適切に管理しなくてはなりません。コンポーネント自体に脆弱性があり、それがアプリケーションで露出する可能性があります。

欠落した部分

残念ながら、構造全体はもっと複雑です。各オープンソース・コンポーネントは、それ自体を「他の」オープンソース・コンポーネントで構成することができます。1つのアプリケーションの依存関係は、整然としたリストというよりはネットワークや階層のようなものです。

含まれているソフトウェアが使用するオープンソース・コンポーネントは「依存関係」であり、この依存関係が使用するオープンソース・コンポーネントは「推移的依存関係」です。

Black Duck Binary Analysis（BDBA）について

Black Duck Binary Analysisは、ソフトウェア・コンポジション解析（SCA）ツールです。SCAツールと同様に、BDBAでは、アプリケーションで使用されているオープンソース・コンポーネントを特定し、それらのコンポーネントの既知の脆弱性やソフトウェア・ライセンスをリストします。SCAは、ソフトウェア・サプライ・チェーンのリスクを管理するための重要な要素の一つにすぎません。

ほとんどのSCAツールは、アプリケーションのソース・コードを調べてその依存関係を特定します。必要に応じて、さまざまなマッチング手法が使用されます。ツールは、ソース・コード自体を調べたり、MavenファイルやNPMパッケージ・リストなどのパッケージ・マニフェストを調べたり、既にコンパイルされているコンポーネントのファイル・ハッシュを比較したりします。

依存関係の特定が困難な場合があります。ソフトウェアのビルド・スクリプトは、ビルド中にオープンソース・コンポーネントを取得することがあります。また、コンポーネントは、ソース・コードとして、またはコンパイル済みの実行ファイルや共有ライブラリとして組み込まれている場合があります。

BDBAは実行ファイルを調べる上で特殊であり、ソース・コードを必要としません。このため、BDBAはソース・コードを入手できない商用アプリを調べる際に最適です。さらに、BDBAでは、直接的依存関係と推移的依存関係の両方を簡単に検出します。

方法

当社は、Google Playストアでスポーツ・ベッティング・アプリを検索し、50万回以上ダウンロードされているアプリのリストを作成しました。これにより、11個のアプリのリストができました。その中のあるアプリは、実際のベッティング・アプリというよりはゲームに近いとして、リストから削除しました。残りの10個のアプリについては、APKPureからパッケージ化されたアプリを（APKファイルとして）入手しました。BDBAを使用して、各アプリのAPKファイルを解析しました。

ダウンロードと解析は2回（1回は2022年12月9日、もう1回は2023年1月20日）行いました。

2回の分析の間の42日間に、1つを除くすべてのアプリが少なくとも1つの最新版をリリースしていることから、これらのアプリの開発が活発に行われていることは明らかです。以下の議論は、2023年1月20日に行われた分析に基づくものです。

私たちは意図的に、特定のアプリの名前を挙げずに、結果と分析を示すことにしました。特定のアプリの潜在的な脆弱性を指摘することは無責任であり、攻撃者の注目を潜在的な攻撃ベクトルに集めることにしかならないからです。

このリサーチを発表することで、開発チームにサプライ・チェーンに対する警戒を促し、消費者がソフトウェアやアプリの複雑さを理解できるようになることを願っています。

コンポーネントと脆弱性

10個のアプリはそれぞれ、下のグラフに点として表示されており、検出されたコンポーネントの数とこれらのコンポーネントに含まれる既知の脆弱性の数を示しています。重要なのは、コンポーネントに既知の脆弱性が含まれているからといって、それがアプリで露出したり悪用可能であるとは「限らない」ということです。ただし、既知の脆弱性が多く存在するということは、開発チームがオープンソースの依存関係のセキュリティに注意を払っていないことを示唆している可能性があります。

アプリあたりのコンポーネントの平均数は125であり、既知の脆弱性が存在するコンポーネントは平均10個です。

アプリの権限

アプリのセキュリティを評価するための低精度な方法として、その権限を調べることがあります。それが、驚くべき結果を生み出すことがあります。たとえば、懐中電灯のアプリには、ネットワークやカメラの権限は不要です。

BDBAでは、以下のように、潜在的に危険なアプリの権限を明らかにします。

このカテゴリでは、いくつかの総合的な発見が目立ちました。

• 8個のアプリが、低精度の位置情報と高精度の位置情報へのアクセス権限を要求しています。これは当然のことかもしれません。なぜなら、ベッティング機能をサポートするアプリは、管轄の法律に準拠するためにユーザーの物理的な位置情報を必要とする可能性があるためです。
• 同じ8個のアプリが、カメラへのアクセスも要求しました。
• 4個のアプリが、音声を記録するためのアクセスを要求しました。

カメラへのアクセスや音声の記録といった慎重に扱うべき権限は、アプリの機能のコンテキストを考えれば、理にかなっているかもしれません。それでもなお、注意深いユーザーであれば、アプリが要求する権限やそれが必要な理由について疑ってみる必要があります。

このブログの後半では、（アプリを名指しせずに）5個のアプリのソフトウェア・コンポーネントについて調べ、セキュリティに関する興味深い発見について説明します。

アプリA：近いようで遠い

最初のアプリは、開発チームがアプリの依存関係を最新の状態に保っているように見えますが、1つの重大なミスを犯していました。BDBAの結果のダッシュボードを以下に示します。

上部の概要グラフは、検出された79個のコンポーネントのうちの6個のコンポーネントに既知の脆弱性があることを示しています。概要グラフは、脆弱性の重大度や検出されたコンポーネントのライセンス・タイプの概要も示しています。この分析は既知の脆弱性に焦点を当てていますが、ソフトウェア・ライセンスにもリスクが存在する可能性があります。

BDBAでは、検出されたコンポーネントを脆弱性の数の多い順に並べたリスト（ソフトウェア部品表またはSBOMと呼ばれる）も作成します。色分けされているバーは、重大度別（重大、高、中、低）の脆弱性の数を示しています （最後の3つの列はこの分析には関係ありません）。

sqlite3を除けば、このアプリには欠点がないように見えます。しかし、sqlite3コンポーネントが、この分析結果の90個の既知の脆弱性の原因となっています。問題になっているバージョン（3.6.23）が10代に入ろうとしていることが問題です。13年は、人間にとってはそれ程長い年月ではないかもしれませんが、ソフトウェアの世界では古いといえます。

他の多くのオープンソース・コンポーネントと同様に、sqlite3は、高品質で活発にメンテナンスされているコンポーネントであり、多くのアプリケーションに重要な機能を提供しています。他のソフトウェアと同様に、脆弱性は時間の経過とともに検出され修正されます。最新バージョンのコンポーネントを使用することで、セキュリティの脆弱性やその他のソフトウェア・バグからアプリケーションを保護することができます。

アプリAの開発チームがSBOMの他のコンポーネントに注意を払っていたとしたら、どうして古いバージョンのsqlite3を見落としてしまったのでしょうか？ BDBAで、アップロードされたAPKファイル内のコンポーネントの位置が明らかになります。

sqlite3は、共有ライブラリ（libtdm-5.4-73-jni.so）にパッケージ化されており、アプリのAPKファイル内の別のプロセッサ・アーキテクチャに対応するものです。libtdm-5.4-73-jni.soの起源については把握していません。市販のものか、または別のチームが作成したものである可能性があります。起源がどこであれ、非常に古いバージョンのsqlite3が組み込まれているため、sqlite3がアプリAの推移的依存関係となっています。

つまり、アプリAの開発チームが直接的依存関係を適切に管理しているように見えますが、アプリを複数のセキュリティ脆弱性にさらす可能性がある推移的依存関係を見逃していたのです。

アプリB：推移的依存関係のもう一つの悲しい事例

同じようなことがアプリBでも起こっています。アプリBには120個のコンポーネントがあり、14個のコンポーネントで102個の脆弱性が検出されました。アプリBの推移的依存関係の多くは、SkiaSharp（.NETエコシステム用skia 2Dグラフィックス・コンポーネントの適応）によるものです。

以下のコンポーネントが、アプリB内のlibSkiaSharp.soの中にパッケージ化されています。まとめると、これらの推移的依存関係が、アプリBの102個の脆弱性のうちの89個を占めています。

• expat
• zlib
• libjpeg-turbo
• libwebp
• freetype
• libpng
• skia

検出されたexpatのバージョン（2.1.0）は2017年10月のものです。

さらに詳しく調査したところ、アプリBにはSkiaSharpバージョン1.68.1.1が使用されていることが明らかになりました。.NETパッケージ・リポジトリであるNuGetから取得したSkiaSharpの複数のバージョンの2回目の解析で、リリース日とexpatバージョンが明らかになりました。

アプリBには古いバージョンのSkiaSharpが組み込まれています。古いバージョンのSkiaSharpには、古い推移的依存関係とそれらに関連する既知の脆弱性が大量に含まれています。

アプリC：考え方が甘いと次のようになる

アプリCには特別多くの脆弱性が含まれているわけではありませんが（85個）、SBOMの最も脆弱なコンポーネントを見ただけで、オープンソース・コンポーネントの管理に対して甘い考え方をしていたことがわかります。

3つの最も脆弱なコンポーネントは、かなり古いコンポーネントです。

このような古いコンポーネントを使用していたということは、明らかに、開発チームがSBOMを把握しておらず、コンポーネントを最新の状態に保ち、既知の脆弱性を最小限に抑えるための対策を行っていなかったことを示しています。

アプリD：患者の体内にものを置き忘れる

BDBAでは、SBOMのコンパイルに加え、誤って置き去りにされた可能性がある機密情報についてソフトウェアを調べます。この情報には、クラウド・サービスの認証情報、暗号化された秘密情報、OAuthトークン、パスワードなどがあります。アプリDでは、このカテゴリで興味深い発見がありました。

これは、正規のAmazon Web Services（AWS）キーのように見えます。ただし、このような特定のタイプのキー（接頭辞ASIAが付いている）は短期間使用されるものであり、有効にするにはセッション・トークンも必要です。このアプリをさらに分析したところ、セッション・トークンが不明であり、キーが既に期限切れになっていたことが判明しました。

それでも、このような機密情報をパッケージ化されデプロイされたアプリ内に残しておくことはほぼ確実に誤りであり、アプリDの開発チームは、このような漏洩がないかソース・コードとビルド・パイプラインを見直す必要があります。

アプリE：敬神に次ぐ

最後に、アプリEの例を見てましょう。最初は、既知の脆弱性を持つコンポーネントが3個だけのように見えます。

驚くべきことに、jackson-databindがアプリの71個の脆弱性のうちの69個の原因となっています。SBOMの他のコンポーネントに脆弱性がないことを考慮すると、これはあり得ないことです。

jackson-databindの横にある疑問符は、BDBAがコンポーネントの正確なバージョンを確認できなかったことを示しています。具体的なバージョンがわからない場合、BDBAはどの脆弱性が当てはまるかを判断するためにファイルのタイムスタンプを利用します。

Androidアプリケーションでは、既定のパッケージ・メカニズムが、タイムスタンプ情報を取り除きます。したがって、BDBAは最悪の事態を予測し、コンポーネントに対して記録された脆弱性をすべて有効なものとしてマークします。

アプリEの開発者は、このことに基づいて、最新バージョンのjackson-databindを使用した可能性があるようです。BDBAでは、コンポーネントのバージョンを手動で最新（この時点では2.14.1）のものとして指定することができ、その結果、まっさらなSBOMとなります。

これはいったいどういうことなのでしょうか？

ソフトウェアのリスク評価は困難です。このリサーチでは、最も人気の高い10のAndroidスポーツ・ベッティング・アプリを、オープンソース・コンポーネントのセキュリティの観点から調査しました。これらのアプリケーションの完全なセキュリティ評価には、幅広い範囲の手作業や自動化されたテストが関与します。

消費者にとっての問題は、これらのアプリケーションが安全に使えるかどうかということです。しかしこれは、機械エンジニアのチームに、飛行機の着陸ギアシステムを調べてもらい、その飛行機が乗客にとって安全であると断言してもらうようなものです。

リスクを考える一つの方法として、攻撃者がこれらのアプリケーションを悪用するのがどれほど困難であるか、そしてなぜ悪用したいのかを評価します。つまり、このアプリが何をするものなのか、攻撃者にとって有益な情報を含んでいるのか、このアプリを制御するためにサーバー側のインフラストラクチャを侵害する必要があるのか、またはもっと簡単な方法で制御できるのかを評価するのです。

これらのアプリでSCAを実行することで、開発チームがソフトウェアのサプライチェーンをどのように管理しているかをある程度確認できます。これは結果として、開発組織全体が、バックエンドサーバーおよび他のソフトウェア・コンポーネントを含むシステム全体に、どの程度セキュリティを組み込んでいるかを反映しているのかもしれません。一方、モバイル・アプリのチームとバックエンドサーバーのチームは、文化やセキュアなSDLCの導入レベルがまったく異なっている可能性もあります。

SCAは、セキュアなSDLCの重要な一部に過ぎないのです。すべての段階でセキュリティを含むプロセスを使用することにより、開発チームは回復力があり、安全で、組織と顧客の両方に対するリスクを最小限に抑えるソフトウェアを作り出すことができます。

サプライチェーンのリスク管理に関する詳細はこちら

これらのアプリの分析にご協力いただいたMika Leinonen氏とBogdan Mihaila氏に感謝いたします。