開発者やセキュリティエンジニアの中には、日々セキュリティのニュースサイトや Twitter で自分たちが利用しているソフトウェアに新しい脆弱性が発見されていないか確認している方も多いかと思います。

もし、自分たちが利用しているソフトウェアに脆弱性がありそうだとわかったら次に何をしていますか？

多くの脆弱性には CVE ID が割り当てられているため、その CVE ID を使ってより詳細な情報、正しい情報を調べることと思います。

そして、その際に多くの人が利用するのがアメリカ国立標準技術研究所 NIST が管理する NVD（National Vulnerability Database)のサイトではないでしょうか。

本記事では NVD の情報だけでの脆弱性調査の課題や、より楽に正しい脆弱性情報を収集するための方法について解説します。

※こちらの内容は 2020 年 4 月 22 日に開催された DevSecOps 勉強会 #1 にてお話しした内容と同様のものとなっています。

脆弱性を調査する時のポイント

NVD の調べたい CVE ID のページにアクセスした後、まずはじめに確認するのが「Current Description」の部分になります。
ここでは、以下の 3 点を確認することができます。

• どのソフトウェアの
• どのバージョンに
• どんな影響があるのか

「Current Description」を確認することで自分たちの利用しているソフトウェアにこの脆弱性が該当するのかどうかの判断を行うことができます。

また、「Known Affected Software Configurations」の CPE の情報を確認するとより細かい該当ソフトウェアとバージョンが示されていることもあります。

次に確認するポイントは、CVSS の Base Score や Attack Vector を含む Vector 情報になります。

Base Score で脆弱性の深刻度を確認し、緊急性が高いかどうかの判断材料にしたり、Attack Vector を元にネットワーク経由で攻撃される可能性がないかどうか確認すると良いでしょう。

しかし、修正方法・影響バージョンの調査時に、NVD に書かれている情報だけでは判断できない場合もあります。
その場合は「References to Advisories, Solutions, and Tools」の参考情報を確認し、より詳細な情報を得ることができます。

参考情報を確認

参考情報には以下のような情報があります。

• 脆弱性の PoC（実証コード）の情報 （Exploit Database や発見者のブログなど）
• セキュリティコミュニティサイト（SecurityFocus など）
• メーリングリストでの議論（Apache など）
• Github上の Issue / Commit / PullRequest
• ソフトウェアの提供元サイト

例として CVE-2010-0364 の脆弱性調査・参考情報の確認をしてみたいと思います。

NVD のサイトで「Current Description」を確認することで以下のように該当ソフトウェアとバージョンとどんな脆弱性なのかが確認できます。

• 該当ソフトウェア：VideoLAN VLC Media Player
• 該当バージョン：0.8.6
• 脆弱性情報：execute arbitrary code via an ogg file

次に、「References to Advisories, Solutions, and Tools」の参考情報の中から、例えば「SecurityFocus」の情報を確認します。
SecurityFocus でも以下のような該当のソフトウェアとバージョンを確認することができます。

• 該当ソフトウェア：VideoLAN VLC Media Player
• 該当バージョン：0.6.8

よく注意して見てみると該当するバージョンが SecurityFocus（0.6.8）とNVD（0.8.6）で異なっています。
これはどういうことなのか解説していきます。

NVD と参考情報が合わない理由

USENIX Security 2019 の論文「Towards the Detection of Inconsistencies in Public Security Vulnerability Reports」を参考にこの現象を説明したいと思います。

先ほどの CVE-2010-0364 の別の参考情報（Exploit Databaseなど）で該当バージョンを確認します。

他のどのサイトでも 0.8.6 が脆弱性のあるバージョンだとしているためやはり NVD の情報が正しいようです。

先ほどの論文ではこれは打ち間違え（typo）によるミスだと指摘しています。
では、NVD と参考情報が一致しない場合は常に NVD の情報を信用すればいいのでしょうか。

NVD の脆弱性情報は常に正しいのか？

もうひとつ例として CVE-2006-6516 の脆弱性調査・参考情報の確認をしてみたいと思います。

先ほどと同様に NVD のサイトで「Current Description」を確認すると以下のように該当ソフトウェアとバージョンと脆弱性情報を確認します。

• 該当ソフトウェア：Eye of GNOME
• 該当バージョン：3.16.5, 3.17.x, 3.18.x before 3.18.3, 3.19.x, and 3.20.x before 3.20.4
• 脆弱性情報：denial of service

次に、「References to Advisories, Solutions, and Tools」の参考情報の中から、「Exploit Database」の情報を確認し、PoC を確認したソフトウェア名とバージョンを確認します。

• 確認したソフトウェア名：Eye of GNOME
• 確認したバージョン：3.10.2

今回も Exploit Database（3.10.2）とNVD（3.16.5など）で情報が一致しません。
NVD の情報が正しいのでしょうか。

他の参考情報も確認してみましょう。
packet storm と Security Focus で確認して結果もやはり 3.10.2 が該当バージョンだとわかります。

調査の結果、NVD の情報も完全に正しい情報を提供できていないことがわかりました。

では何故このようなことが起こるのでしょうか。

論文では、NVD は情報がアップデートされてないことがあると指摘されています。
公開当時に 3.10.2 を該当バージョンとしなかった場合、古い情報のままになっていることがあるようです。

最近の CVE でも同様の問題がある

これまでの例では少し古いものをあげていましたが、最近の CVE では改善されているかというとそうでもありません。

2020 年 4 月に発見したものを 2 つ紹介したいと思います。

CVE-2020-7628 では npmのinstall-package というライブラリの脆弱性が 1.1.6 で発生していると書かれています。

しかし、npm や Github で確認するとそもそも 1.1.6 というバージョンはなく、最新バージョンが 0.4.0 となっています。

CVE-2020-7066 では PHP の脆弱性に関して 7.2.9、7.3.16、7.4.34 にて修正されていると書かれていますが、PHP の Change Log では 7.2.29、7.3.16、7.4.4 で修正しているとされているため、2 つのバージョンで情報が食い違っています。

また、NVD が示している 7.4.34 はまだ存在しないバージョンです。
NVD の情報も typo（打ち間違え）によるミスが発生している ように思われます。

※ 2020 / 5 / 15 更新: 2020 / 04 / 30 時点で Current Description、CPE ともに修正されました

このように、正しい脆弱性情報を得るためには色々な情報ソースから情報収集し、どの情報が正しいのか検証することが大切です。

しかし、脆弱性ひとつひとつに多くの時間を掛けて調査することは時間も人手もかかる作業です。
より効率的に情報収集をするためには何をすれば良いのでしょうか。

正しい情報を得るためには

より早く正確な情報を得る手段として脆弱性が報告されているソフトウェアの公式サイトで情報を確認する方法があります。

先ほどの PHP の例では PHP の Change Log を確認することで正確な情報に辿りつくことができました。
しかし、この方法でもいくつか欠点がありますのでご注意ください。

NVD の Reference に公式サイトの脆弱性情報がリンクされていない

PHP の例でも NVD の Reference には公式サイトへのリンクがされていないため、公式の脆弱性が公表されているページまで調査をする必要があります。

脆弱性に関する情報がひとつのページにまとめられているサイトもあれば、Change Log の中に修正した CVE ID が記載されているものなど、多くのパターンがあるので見つけることも容易ではありません。

公式サイトで脆弱性情報を公開していない

公式サイトが必ずしも脆弱性情報を公開しているとは限りません。
また、Github だけで管理されているケースも多くあり、Issue の中で CVE ID が明記されているケースもあまり多くはありません。

ソフトウェアの公式サイトで情報を確認する方法でも時間がかかり、正確な脆弱性情報が見つからないこともあるためベストな方法とは言えません。

脆弱性の正しい情報を得るためのより良い解決策

私が考えるより良い解決策を 2 つ紹介したいと思います。

商用の脆弱性データベースの活用

解決策のひとつとして商用の脆弱性データベースを利用する方法があります。

商用の脆弱性データベースは、セキュリティの専門家が独自に脆弱性を調査した情報が取り込まれているため、より精度が高く、NVD にはない PoC（攻撃コード）の情報や脆弱性への対応方法なども明記されているものもあります。

脆弱性データベースのみの利用では自分たちが利用しているソフトウェアとの突合作業は発生しますが、精度の高い情報は得ることができるでしょう。

脆弱性スキャナ（SCA）の活用

さらに、自分たちの利用しているソフトウェアの突合まで行なってくれるのが脆弱性スキャナ（SCA）です。

無償の脆弱性スキャナでは NVD のデータをそのまま利用しているものもあるため誤検知もありますが、商用の脆弱性スキャナでは自分たちで脆弱性データベースを構築、運用しているケースもあるため、商用の脆弱性データベースと同様に精度の高い情報や NVD にはない付加価値のある情報を得ることもできます。

また、CI / CD に組み込んで利用できるケースもあるため自動で脆弱性の検知を行うことができます。

さいごに

日々の脆弱性ウォッチから正確な調査を行うことは意外と大変な作業です。

脆弱性スキャナなどを活用することでこれらの手間を軽減し、開発サイクルの中で脆弱性の対応を行うことができるようになると良いでしょう。

今回の記事と関連した、CVE や NVD に関する基本的な内容はブログ記事「はじめての方向け CVE 入門 CVEID や MITRE などもまとめて紹介」でも解説しています。

合わせてご活用ください。

yamory では、これらの作業を CI / CD に組み込み自動化することができるサービスを提供しています。
また、間違った脆弱性を見つけた際には NVD へ連絡し、正しい情報が世の中に提供されるように協力しています。

脆弱性調査の自動化ができれば開発者は注力したい開発に専念し、セキュリティ担当者も脆弱性の調査以降の部分に時間を掛けることができるようになると考えています。

yamory によって、少しでも皆様のセキュアな開発をサポートすることができれば幸いです。
ぜひ一度お試しください。