［パンドラの箱］エクスプロイトが示すパッケージマネージャーの盲点

オープンソース開発が主流になるにつれ、開発者は、増加の一途を辿るアプリケーション開発とセキュリティソリューションから、安全で高品質のソフトウェアを迅速に構築するのを支援する利益を得ることができました。いくつかの新しいオープンソースの脆弱性管理（あるいはソフトウェア・コンポジション解析）ソリューションが登場しました。一見したところ、それらを差別化するものを特定するのは難しい場合があります。 それらはすべて、オープンソースのカタログ化に役立つと主張しており、現在知られている脆弱性に関する情報を示しています。

ただし、それらには違いがあり、他のセキュリティソリューションと同様に、セキュリティリスクを検出する効果が重要です。 この記事では、私は、オープンソースの脆弱性の検出、そしてなぜBlack Duckの精度を最大化するためにそれぞれの長所と短所を組み合わせた方法を採るのかについて説明しようと思います。

オープンソースの発見：正確さの秘訣

使用しているオープンソース・コンポーネントがわからない場合、それらのコンポーネントの脆弱性から身を守ることはできません。 これはとても単純なことです。 したがって、実行中のシステム内のすべてのオープンソースを正確に検出する機能が不可欠なのです。 Black Duckの多要素検出機能は、パッケージマネージャーとファイルスキャンからの情報を組み合わせて使用することで精度を最大化するのです。

パッケージマネージャーの宣言：取っ掛かりとしては良い

パッケージマネージャーは、これらのソフトウェアをビルドする際や、ソフトウェアを展開する際に依存関係を管理するために使用されます。 したがって、パッケージマネージャーの情報は、次の2つの状況において評価することができます。

1. ビルドの仕様： パッケージマネージャーは通常、特定のプログラミング言語用にカスタマイズされています。 パッケージ・マニフェスト・ファイル（たとえば、Maven POMファイル）は、含まれるコンポーネントと、それらを取得する場所（パブリックまたはプライベートリポジトリ）を指定します。
2. ソフトウェアのインストール： この言語非依存の仕組みは、ソフトウェアパッケージ、およびそれらが依存する他のパッケージのインストールを調整します。

パッケージマネージャーのデータが利用できる場合、その情報に簡単にアクセスでき、非常に正確です。 一方、常に利用できるとは限らず、簡単になりすましが可能です。あくまでもBlackDuckがここから処理を始めるというだけのことです。

ファイルシグネチャのスキャン：”隠れた”オープンソースを見つけ出す

パッケージマネージャーから多くの情報を取得できますが、全体像を得られないことがよくあります。ビルド中にすべての依存関係が宣言され、パッケージマネージャーを使用してすべてのソフトウェアがインストールされるわけではないからです。

たとえば、Dockerコンテナは、パッケージマネージャーを完全にバイパスすることでコンポーネントを「非表示」にすることもできます。 典型的なdockerfile（Dockerイメージのビルドファイル）を調べると、次のコマンドでビルドされていることがよくわかります。

make install

以下のエクスプロイトの例が示すように、Make install（yum、rpm、またはdpkg installとは対照的に）はパッケージマネージャーを迂回し、イメージの内容を認識しません。

対照的に、ファイル・シグネチャ・スキャン（ハッシュアルゴリズムを使用してソースファイルとバイナリファイルの一意の「シグネチャ」のセットを計算する）は、ほぼすべてのプログラミング言語または環境で使用でき、コンポーネントをソースとバイナリの両方として認識できます。 シグネチャはそれぞれ、ファイル内の小さなコードスニペットから、データでいっぱいの任意の大きなディレクトリまで、あらゆる場所を表します。 シグネチャスキャンは、ファイルとディレクトリの内容を分析することにより、コードベースに隠れている「宣言されていない」コンポーネントを検出できます。

シグネチャを生成および利用するためのアルゴリズムは複雑なため、場合によっては、曖昧または不正確な結果につながる可能性があります。 曖昧性の解消により、誰かが最初の結果を確認する必要がありましたが、Black Duckの「あいまい一致」ロジックは、さまざまなディレクトリとファイルの属性を調べることにより、このプロセスを自動化および合理化します。

やってみなければ分からない：脆弱性を見つける

パッケージマネージャーを使うやり方は実装が非常に簡単であるため、多くのツールがそのアプローチのみをサポートしているのは当然のことです。 おそらく彼らは、それで十分だと考えているのです。

しかし、私たちは違います。

パッケージマネージャーのデータだけでは十分な脆弱性保護が提供されない理由を示すために、BlackDuckを使用したパッケージマネージャーのみの検出と多要素検出の精度をテストしました。

このテストでは、簡単に入手できる公開されたエクスプロイトを使用しました。 最近、公開されている多くのエクスプロイトには、攻撃するための脆弱なDockerシステムが事前に構築されています。 これらの構築済みシステムは、特定のCVEに対して脆弱になるように設計されています。

私たちのテストのやり方はとても単純です。

1. 両方のやり方で脆弱なDockerイメージをスキャンします。
2. どちらのやり方が関連する脆弱性を見つけるかを確認します。

これらの脆弱性／エクスプロイトシステムの例のうち8つでテストを実行しました。以下のビデオと要約で結果を確認できます。

CVE-2017-5638 (“Equifax”)

コンポーネント：Apache Struts
CVSS v3 スコア：10.0 Critical
エクスプロイト：https://github.com/jrrdev/cve-2017-5638

概要：2.3.32より前のApacheStruts 2 2.3および2.5.10.1より前の2.5.xのJakartaMultipartパーサーは、ファイルアップロードを誤って処理します。これにより、リモートの攻撃者は、2017年3月に野生で悪用されたように、細工されたContent-TypeHTTPヘッダーの「＃cmd =」文字列を介して任意のコマンドを実行できます。

シグネチャスキャン：検知
パッケージマネージャ・スキャン：検知せず

［ビデオを見る］ このエクスプロイトで何ができるか、そしてアプリケーションでどのように見つけることができるかを示します。

CVE-2017-7494 (SambaCry)

コンポーネント：Samba
CVSS v3 スコア：9.8 Critical
エクスプロイト：https://github.com/opsxcq/exploit-CVE-2017-7494

概要：3.5.0以降のすべてのバージョンのSambaは、リモートコード実行の脆弱性があり、悪意のあるクライアントが共有ライブラリを書き込み可能なシェアにアップロードし、サーバーにロードして実行される可能性があります。

シグネチャスキャン：検知
パッケージマネージャ・スキャン：検知せず

CVE-2015-3306

コンポーネント：ProFTPD
CVSS v2 スコア：10.0 HIGH
エクスプロイト：https://github.com/t0kx/exploit-CVE-2015-3306

概要：ProFTPD 1.3.5のmod_copyモジュールを使用すると、リモートの攻撃者は、sitecpfrおよびsitecptoコマンドを介して任意のファイルの読み取りと書き込みが行えます。

シグネチャスキャン：検知
パッケージマネージャ・スキャン：検知せず

CVE-2015-1427

コンポーネント：Elasticsearch
CVSS v2 スコア：7.5 HIGH
エクスプロイト：https://github.com/t0kx/exploit-CVE-2015-1427

概要：1.3.8より前のElasticsearchおよび1.4.3より前の1.4.xのGroovyスクリプトエンジンにより、リモートの攻撃者はサンドボックス保護メカニズムをバイパスし、細工されたスクリプトを介して任意のシェルコマンドを実行できます。

シグネチャスキャン：検知
パッケージマネージャ・スキャン：検知せず

CVE-2016-10033

コンポーネント：PHPMailer
CVSS v3 スコア：9.8 Critical
エクスプロイト：https://github.com/opsxcq/exploit-CVE-2016-10033

概要：バージョン5.2.18以前のPHPMailerには、リモートコード実行（RCE）につながる可能性のある脆弱性があります。PHPMailerのisMailトランスポートのmailSend関数は、Senderプロパティが設定されていない場合、リモートの攻撃者が追加のパラメータをmailコマンドに渡し、その結果、細工されたFromアドレスの\”（バックスラッシュ二重引用符）を介して任意のコードを実行する可能性があります。

シグネチャスキャン：検知
パッケージマネージャ・スキャン：検知せず

CVE-2016-7434

コンポーネント：NTP
CVSS v3 スコア：7.5 High
エクスプロイト：https://github.com/opsxcq/exploit-CVE-2016-7434

概要：4.2.8p9以前のNTPのread_mru_list関数を使用すると、リモートの攻撃者は細工されたmrulistクエリを介してサービス拒否（クラッシュ）を引き起こすことができます。 Ntpdには、アプリケーションをクラッシュのトリガーとなる可能性のあるnullポインタ参照があります。 NTP.orgによれば「ntpdが、細工された悪意のあるパケットを送信するサーバーからのmrulistクエリ要求を許可するように構成されている場合、ntpdは、細工された悪意のあるmrulistクエリパケットを受信するとクラッシュします。」とのこと。

シグネチャスキャン：検知
パッケージマネージャ・スキャン：検知せず

CVE-2016-4977

コンポーネント：Spring Security OAuth
CVSS v3 スコア：8.8 High
エクスプロイト：https://hub.docker.com/r/vulnerables/cve-2016-4977/

概要：Spring Security OAuth 2.0.0〜2.0.9および1.0.0〜1.0.5のホワイト・ラベル・ビューを使用して承認リクエストを処理する場合、response_typeパラメータ値がSpring SpELとして実行され、悪意のあるユーザーが細工したresponse_typeの値を介してリモートコードを実行できます。

シグネチャスキャン：検知
パッケージマネージャ・スキャン：検知せず

CVE-2016-9920

コンポーネント： Roundcube
CVSS v3 スコア： 7.5 High
GitHub リポジトリ： https://github.com/t0kx/exploit-CVE-2016-9920

概要：1.1.7より前のRoundcubeおよび1.2.3より前の1.2.xのsteps / mail / sendmail.incは、SMTPサーバーが構成されておらず、sendmailプログラムが有効になっている場合、sendmailのコマンドライン上でカスタムエンベロープ送信元アドレスの使用を適切に制限しません。 リモート認証されたユーザーが、細工された電子メールメッセージを送信する変更されたHTTP要求を介して、任意のコードを実行できるようにします。

シグネチャスキャン：検知せず*
パッケージマネージャ・スキャン：検知せず

* このケースでは、スキャンによってコンポーネントのいくつかの証拠が検出されましたが、その証拠はレポートのしきい値を下回っていました。 これらのしきい値は、「誤検知」の発生を最小限に抑えるために設定されています。 私たちのチームはスキャンの精度を継続的に確認し、アルゴリズムを調整して、可能な限り最も信頼性の高い結果を提供します。