米国の脆弱性データベースをwatchせよ　セキュリティリサーチャーが教える正しい脆弱性調査のやり方

NVDとはなにか

Yoshizawa氏： yamoryのセキュリティリサーチャーのYoshizawaと申します。本日は「NVDは大変便利ですが、はたして本当に信じていいのでしょうか？」というタイトルで発表したいと思います。よろしくお願いします。

はじめに、みなさんは脆弱性ウォッチ、脆弱性モニタリングはされていますでしょうか？　セキュリティの勉強会に参加されている方々なので、脆弱性を気にされている方も多いのではないかなと思いますが、脆弱性を確認する際に日々している方法として、IT・セキュリティメディアを見たり、Twitterを使って情報収集されている方も多いのではないかなと思います。

収集した情報の中で自分たちが使っているソフトウェアに関する脆弱性があれば、自分たちが使っているバージョンでは、そこからどんな影響があるのかを追加で調査することがあると思います。追加で調査する方法としましては、脆弱性にはCVE IDというのが明記されているケースが多くあると思いますので、それで検索してみることが多いかと。

検索してみると、このように一番上にNVDというところの情報が出てくることが多いので、そのNVDの情報を確認してみることもあるのかなと思います。NVDのページはこのようなページですね。このページを見たことがある人もけっこう多いのではないかと思います。

NVDとは何かと言いますと、NISTというアメリカ国立標準技術研究所が管理している脆弱性データベースのことです。先ほど話したCVE IDがCommon Vulnerabilities and Exposuresというもので、日本語だと共通脆弱性識別子と呼ばれるものです。ここでは脆弱性に一意のIDを振ってあげて管理しやすくするためのものだと思ってもらえればと思います。

脆弱性調査のやり方

ここからが本題の話で、実際に脆弱性調査しているとこんな問題にぶつかった人がいるのではないかという話を少ししたいと思います。

例えば自分たちの使っているソフトウェアに脆弱性が見つかって、その脆弱性情報が、例えばCVE-2010-0364だったとします。CVE-2010となっているので2010年にCVE IDが割り振られた少し古い脆弱性の例ですが、そこでCVE IDからNVDの情報を見てみると、このように出てきます。

NVDのCurrent Descriptionの部分では、どんなソフトウェアのどのバージョンに、そしてどんな脆弱性が出ているのかが簡単にまとめられています。今回の例ですとStack-based buffer overflowで、VideoLAN VLC Media Playerの0.8.6にリモートアタッカーから任意のコード実行が起こりそうというのがここからわかるかと思います。

対象のソフトウェアの該当バージョンはここを見てわかる通り、0.8.6です。今回自分たちが使っているバージョンが0.8.6なので、追加でNVDのリファレンスを見てみようと思ったとします。

すぐにバージョンアップで対応できるのであればバージョンアップするだけでこのような追加調査もいらないのですが、やはり簡単にバージョンアップができない環境であったり、そもそも新しいバージョンであったり、パッチがまだ提供されていない場合にはこのように少し調べたいと思うことがあるのかなと思います。

CVEとNVDの情報が合致しない？

こちらがNVDのリファレンス一覧の部分です。今回はリファレンスの中から上から2番目のSecurityFocusのリンクをたどって追加の調査をしてみたいと思います。SecurityFocusはNVDのリファレンスの中で出てくることが多い、セキュリティのポータルサイトです。アクセスしてみますと、スクリーンショットのような情報が得られます。

下のほうにあるVulnerableの部分で脆弱性のあるソフトウェアのバージョンの情報が確認できます。NVDの情報と同じでVideoLANの脆弱性だなというのが確認できますが、こちらを注意してバージョンを確認してみますと、NVDでは0.8.6と言われていたのが、こちらSecurityFocusでは0.6.8と示されています。

意外にあるバージョンの不一致

リファレンスを見て追加で調査した結果、結局どのバージョンに脆弱性があるのかわからなくなっている困った状況になってしまいました。このようなことはほとんどないでしょうと思われるかもしれませんが、もう1つ例を挙げてみたいと思います。

今度はCVE-2016-6855を例に、先ほどと同様にNVDの情報を確認してみます。今回はEye of GNOMEの脆弱性で、Dosなどを引き起こす脆弱性です。NVDでCurrent Descriptionを見ると、この脆弱性が該当するバージョンは、3.16.5などということがわかります。

こちらも先ほどと同様にリファレンスの中からexploit dbの情報を見てみます。exploit dbというのはKali Linuxの環境元であるOffensive Securityが管理している、攻撃コードの収集などをしているサイトです。exploit dbを見てみますと、このようにEye of GNOMEの脆弱性であることがわかります。しかしexploit dbでは3.10.2が該当バージョンになっています。

NVDでは3.10.2については該当と言われていなかったのですが、どの情報が正しいのでしょうか？　このようにNVDが参照しているサイトにもかかわらず、NVDの情報と参照している情報が一致しないというケースがチラホラ見られます。

本日事前の参加者は200名以上ということなのですが、もしかしたらこのようなケースを見たことがあるという方も数名くらいはいるのかなと思っています。もしよろしければYouTube Liveのチャット機能がありますので、こういうケースを見たことあるよという方はコメントを書いていただけるとうれしいです。

打ち間違えに起因する問題

実際このような脆弱性が一致しない問題に関して、セキュリティのトップカンファレンスでこのような論文が発表されています。USENIX Security 2019の『Towards the Detection of Inconsistencies in Public Secrity Vulnerability Reports』という論文で、上記のNVDと外部の参考文献情報が一致しない問題について触れられていました。

今回こちらの情報を参考にしつつ、なぜこのような問題が起こったのか。どうすればこの問題を対処できるのかについて説明していきたいと思います。

先ほどの例の1つ目のSecurityFocusとNVDで少しバージョンが異なるケースは、typo、打ち間違いによりバージョンの食い違いが発生している問題です。すごく単純なミスなのですが、最近のCVEでもこちらのケースはチラホラ見たことがあるものになります。SecurityFocus以外のリファレンスを見てみるとNVDを同じ0.8.6を示しており、SecurityFocusが0.8.6をtypoして0.6.8にしてしまっていることが確認できます。

このケースでNVDではなくて外部のサイトも間違っているケースなのですが、NVDが常に正しくtypoしない情報を掲載しているかといえばそういうわけでもございません。

CVE-2008-1862の場合ですと、ExBB Italiaの0.22に脆弱性があるとなっており、リファレンスに載っているexploit dbでも0.22が書かれているので、こちらは間違いなく0.22で問題ないと思われます。

NVDのページに戻って下のほうにCPEの情報が列挙されているところがあります。CPEというのはCommon Platform Enumerationと呼ばれるもので、ベンダー名、ソフトウェア名、バージョンをフォーマット化して明記したものです。

このCPEの情報を見てみるとcpe:2.3:a、次にexbbというベンダー名、次にexbb_italiaというソフトウェア名です。右のほうを見てみますと、対象のUp to (including)0.2.2までと書かれています。このようにNVDのサイトの中でもCurrent Descriptionでは0.22、CPEでは0.2.2の2つのバージョンで食い違いが起こってしまっていることもあります。

以上のことから、typoによる脆弱性の食い違いが起こっているケースがあり、NVDの情報でもtypoのミスが実際に起こっているケースがあるということがわかります。

更新されないことに起因する問題

次に挙げたEye of GNOMEの例では、情報が更新されていないことでNVDでリファレンスと食い違いが起こっているケースというのがあります。右側のQUICK INFOのNVD Published Dateを見ると2016年になっています。exploit dbが追加された日時をChange Historyの部分で確認をしてみますと、このようにexploit dbは2017年に追加されたリファレンス情報だとわかります。

NVDの情報自体はPublished Dateの下のLast Modifiedを見てもわかる通り日々アップデートされているのですが、Current Descriptionの情報であったりCPEの更新まではされていないケースというのが多くあるために、このような食い違いが起こっているケースがあるようです。

それ以外にもCVE-2018-0852という比較的最近の例を簡単に紹介したいと思います。この脆弱性はMicrosoftのOutlook 2007 SP3などの脆弱性になるんですが、MITREでこの脆弱性を確認してみるとほぼ同じような記述が書かれています。

このMITREというのは何なのかと言いますと、CVEの採番であったりとかCVEの管理をしている組織です。NVDとMITREで内容が同じように見えるんですが、先頭の記述を見てみると、NVDではMicrosoft Outlook 2007 SP3と書かれ、MITREでもMicrosoft Outlook 2007 SP3と書かれています。

しかしNVDのCPEを見てみると、そもそも2007 SP3が書かれていないという状態になっています。やはりこのようにNVDの情報というのは100パーセント正しい、正確な情報を提供しているというわけではないようです。

解決に向けて

ではNVDの情報が間違っているかもと思ったとして、どうやってこの問題を解決すればいいのかについて少し検討してみたいと思います。

1つ目の解決策として考えられるのは、公式サイト、ソフトウェアの提供元のサイトで脆弱性を確認するという方法です。

先ほどのMicrosoftのOutlookの脆弱性であれば、NVDのリファレンスにMicrosoftのSecurity Advisoryがありますので、そこで正しい情報が確認できます。このようにMicrosoft Outlook 2007のService Pack 3のセキュリティアップデートが出ていることが確認できます。

ただ、この方法も完璧な方法ではありません。NVDのリファレンスに公式サイトのリンクが貼られているケースが少ないので、多くの脆弱性では該当するソフトウェアの脆弱性情報が貼られているところを探しにいく手間が発生します。また、そもそも公式サイトにて脆弱性がアナウンスされていないケースも多いので確認することが困難になります。また、何よりも一件一件脆弱性に関してこのように調査をしていく時間がないという人がほとんどではないかなと思います。

商用の脆弱性データベースや脆弱性スキャナを活用する

では次に現実的な解決策としてどのような方法があるのか紹介したいと思います。

1つ目の方法としては商用の脆弱性データベースというのがあるので、そちらを使う方法があると思います。商用である脆弱性データベースは、セキュリティのリサーチャーの方が脆弱性の確認をしていますので、より精度が高い情報が提供されるだけではなく、さらにNVDが脆弱性を公開するよりも早く脆弱性の情報を提供するサービスもあります。

より早く脆弱性の情報が提供されることで、例えば攻撃コードが世の中に出回る前に対応できるようになります。加えて、サービスによって攻撃コードの情報であったり対応方法や軽減策に関する情報の提供など、NVDが提供していない付加価値のある情報を一緒に提供することもあります。

しかし、こちら1つ課題となるのが、自分たちの環境で利用しているソフトウェアと脆弱性データベースの突合作業が必要となることです。その手間が発生してしまいます。

そのためにその次の解決策として、脆弱性スキャナ、SCA、Software Composition Analysisと呼ばれるものを使う方法があります。脆弱性スキャナを使うことで、自分たちが利用しているソフトウェアの検出と脆弱性データベースの突合までできるようになります。無償のものではNVDのCPEに頼ったものもありますが、その場合ですと誤検知をすることがあります。

商用のサービスですと独自に脆弱性データベースを構築し、PoCや対応方法のページなどの付加価値を提供しているところもあります。我々もyamoryという商用の脆弱性スキャナを提供しており、独自に脆弱性データベースを構築し、PoCの収集などもしています。さらにCI/CDに組み込んで利用できるので、開発のライフサイクルの中で脆弱性の検知ができるようになります。

日々の脆弱性ウォッチや脆弱性の調査などの手間がかなり削減できると思います。このように日々の開発サイクルだったり運用の中にセキュリティを組み込むことで、手間をなくしセキュリティを高められるので、我々として目指している世界であるセキュアな開発を促進できると考えています。

まとめとyamoryについて

最後にまとめです。正しい脆弱性情報を収集し見極めることはけっこう大変なことです。NVDの情報が常に正しいわけでもなく、typoや情報が更新されてないケースがあるため、正しい情報を収集するのが大変なことになっています。また、このようなことは最近のNVDでも実際に起こっているのを我々のほうで確認しています。

我々yamoryでは、このような誤った情報を見つけた場合にはNVDに報告し、正しい情報が世の中に共有されるように微力ながら協力しています。

このような問題の解決策としては脆弱性スキャナ、とくに商用のサービスを使ってできるだけ楽に脆弱性対応をすることをおすすめしています。もちろん無償のサービス、OSSでも質が高いものというのはあると思いますが、中には誤検知を引き起こしてしまい、返って手間が掛かってしまうことがあります。

商用の脆弱性スキャナを使うことで正しい情報、それにこうやって付加価値の情報を得られますし、また先ほど申し上げたようにCIに組み込んで自動化、そういうことをすることによって開発者はより開発にフォーカスを当てて、また、セキュリティの担当者もより専門的な部分にフォーカスを当てた業務ができるようになります。

我々としてはyamoryというサービスを通して、このようにセキュアな開発が行えるような環境を提供できればと思っています。

最後に宣伝になるのですが、少しだけ我々が提供していますyamoryというサービスについて簡単に説明させてください。

yamoryは商用の脆弱性スキャナ、SCAです。yamoryを導入することによって先ほどの課題解決であったり、どういったOSSが利用されているのかを把握して脆弱性情報との突合をして、利用している脆弱性情報の提供や開発チームとセキュリティチーム間でのコミュニケーションサポートまでできます。

しかし脆弱性スキャナを入れると、次なる課題に直面されるお客様が多くらっしゃいます。検知される脆弱性が多すぎて運用が回らなくなるというものです。この部分に関してもyamoryではアプローチしています。yamoryではオートトリアージ機能というのを独自でしており、独自の優先付け機能というのを持っています。そうして本当にリスクの高いものを可視化して優先順位付けを自動ですることで、このような問題の解決を図っています。