ソフトウェア・インテグリティ

 

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

パッケージ・マネージャーのデータとシグネチャ・ベースのスキャンを使用して、オープンソース・コードの脆弱性を見つける実験をしました。さて、どのような結果になったでしょうか。

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

ただし、それらには違いがあり、他のセキュリティ・ソリューションと同様に、セキュリティ・リスクを検出する効果が重要です。 この記事では、私は、オープンソースの脆弱性の検出、そしてなぜ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要求を介して、任意のコードを実行できるようにします。

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

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

パッケージ・マネージャーの宣言を超えて

パッケージマネージャーのデータが存在し、改竄されていなければ、情報を簡単に取りまとめることができるだけでなくかなり正確になります。 ただし、多くの場合、コンポーネントの完全なリストは提供されません。 その可視性の欠如は、セキュリティ・リスクを高める可能性があります。 これらの結果は、複数のアプローチを組み合わせて、使用中のオープンソース・コンポーネントを完全かつ正確に特定することが不可欠であることを示しています。

私たちは常に脆弱性を特定するための新しい方法を見つけています。 新しいリリースごとに、これらの新しいアプローチを使用して、パンドラの箱にオープンソースの脆弱性が見つからないよう努めています。

この記事の英語版は、2017年7月18日に公開されました。

 

この著者によるその他の情報