こんにちは、アドテクスタジオでセキュリティエンジニアをしている岡崎です。

 

皆様、年末年始はゆっくりできましたでしょうか。私は年始に公開された「Meltdown and Spectre」のお陰で年始早々、情報整理に追われてました。

今回は、先日「Meltdown and Spectre」の脆弱性のこともあり、脆弱性情報の見方と脆弱性情報API活用について、書かせていただきます。

 

１，脆弱性情報の見方

エンジニアの方であれば、脆弱性情報を確認する中でCVEやCVSSなどを目にすることが多いと思います。それぞれどのような意味を持ち、どのように見るのかを知っておきましょう。

 

先日あった「Meltdown and Spectre」を例に見ていきましょう。

https://meltdownattack.com/

https://spectreattack.com/

まず、このような脆弱性情報が公開された際、CVEやCVSSは脆弱性情報管理団体により設定されます。

 

CVEとは、「Common Vulnerabilities and Exposures（共通脆弱性識別子）」

多数の情報公開サイト等において、それぞれ独自の識別子によって公開される脆弱性情報の同一性を確認するための判断材料として、世界各国の製品開発企業、セキュリティ関連企業、調整機関や研究者等に広く利用されています。脆弱性情報を公開する際にCVE 番号を表示することにより、脆弱性情報の収集を行っているシステム管理者やユーザーが、脆弱性情報の同一性の判断をより容易に行うことができるようになり、迅速な判断や対応への一助となります。

参考：　https://www.jpcert.or.jp/vh/cna.html

 

CVEは簡単にいいますと、「世界で脆弱性情報に割り振ったユニークID」になります。

命名規則は、「CVE-YYYY-ZZZZ」のようになっており、「YYYY」は発見された年数、ZZZZは一意の番号が付与されています。

＊非営利団体のMITRE社が提供しています。

 

今回の「Meltdown and Spectre」を例にしますと、CVEは以下のようになります。

Meltdownは、「CVE-2017-5754」

Spectreは、「CVE-2017-5753」と「CVE-2017-5715」

＊「Spectre」は２つのCVEを持っていることがわかります。ということは、２つの脆弱性があるようですね。

 

Meltdownの「CVE-2017-5754」情報

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754

 

Spectreの「CVE-2017-5753」情報

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753

 

Spectreの「CVE-2017-5715」 情報

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715

 

上記のページでは、CVEが採番されただけで、詳細な情報は載っていません。

そこで、上記のページにある「Learn more at National Vulnerability Database (NVD)」のリンクをだどります。

 

NVDとは、

NIST（National Institute of Standards and Technology：アメリカ国立標準技術研究所）が管理しているNational Vulnerability Database（NVD：脆弱性情報データベース）です。

ユーザへの通知や発信を強化を目的としているため、脆弱性の詳細情報やCVSSを提供しています。

 

Meltdownの「CVE-2017-5754」の例：

https://nvd.nist.gov/vuln/detail/CVE-2017-5754

 

こちらのページには脆弱性に関する詳細な情報が記載されています。その中でも、CVSSについて注目してみましょう。

 

CVSSとは、

CVSS (Common Vulnerability Scoring System：共通脆弱性評価システム）は、情報システムの脆弱性に対するオープンで汎用的な評価手法であり、ベンダーに依存しない共通の評価方法を提供しています。CVSSを用いると、脆弱性の深刻度を同一の基準の下で定量的に比較できるようになります。

参考：　https://www.ipa.go.jp/security/vuln/CVSS.html

 

簡単に言うと、脆弱性がどのくらい問題なのかを数値化したものになります。

さらのその数値のもとのVectorを確認することで、本脆弱性がどの程度、攻撃しやすく危険なのかを認識することができます。

 

CVSSには、v2とv3があり、項目が少し違います。

CVSSv2は、攻撃対象となるホストやシステムにおいての「脆弱性による深刻度」を評価していましたが、CVSSv3では、仮想化やサンドボックス化などが進んできていることから、コンポーネント単位で評価する手法を取り込んだ仕様となっています。

参考：　

http://jvndb.jvn.jp/nav/jvndbhelp.html

https://www.ipa.go.jp/security/vuln/CVSS.html

https://www.ipa.go.jp/security/vuln/CVSSv3.html

 

CVSSの詳細項目：

[CVSSv2の場合]

攻撃元区分 (AV：Access Vector)

・脆弱性のあるシステムをどこから攻撃可能であるかを評価します。

・ローカル（L） / 隣接（A） / ネットワーク（N）

 

攻撃条件の複雑さ (AC：Access Complexity)

・脆弱性のあるシステムを攻撃する際に必要な条件の複雑さを評価します。

・高（H） / 中（M） / 低（L）

 

攻撃前の認証要否 (Au: Authentication)

・脆弱性を攻撃するために対象システムの認証が必要であるかどうかを評価します。

・複数（M） / 単一（S） / 不要（N）

 

機密性への影響 （情報漏えいの可能性、 C: Confidentiality Impact ）

・脆弱性を攻撃された際に、対象システム内の機密情報が漏えいする可能性を評価します。

・なし（N） / 部分的（P） / 全面的（C）

 

完全性への影響 （情報改ざんの可能性、 I: Integrity Impact ）

・脆弱性を攻撃された際に、対象システム内の情報が改ざんされる可能性を評価します。

・なし（N） / 部分的（P） / 全面的（C）

 

可用性への影響 （業務停止の可能性、 A: Availability Impact ）

・脆弱性を攻撃された際に、対象システム内の業務が遅延・停止する可能性を評価します。

・なし（N） / 部分的（P） / 全面的（C）

 

[CVSSv3の場合]

攻撃元区分(AV：Attack Vector)

・脆弱性のあるコンポーネントをどこから攻撃可能であるかを評価します。

・物理(P) / ローカル(L) / 隣接(A) / ネットワーク(N)

 

攻撃条件の複雑さ (AC：Access Complexity)

・脆弱性のあるコンポーネントを攻撃する際に必要な条件の複雑さを評価します。

・高(H) / 低(L)

 

必要な特権レベル(PR：Privileges Required)

・脆弱性のあるコンポーネントを攻撃する際に必要な特権のレベルを評価します。

・高(H) / 低(L) / 不要(N)

 

ユーザ関与レベル(UI：User Interaction)

・脆弱性のあるコンポーネントを攻撃する際に必要なユーザ関与レベルを評価します。

・要(R) / 不要(N)

 

スコープ(S：Scope)

・脆弱性のあるコンポーネントへの攻撃による影響範囲を評価します。

・変更なし(U) / 変更あり(C)

 

機密性への影響 （情報漏えいの可能性、C: Confidentiality Impact ）

・脆弱性を攻撃された際に、対象とする影響想定範囲の情報が漏えいする可能性を評価します。

・なし(N) / 低(L)  / 高(H)

 

完全性への影響 （情報改ざんの可能性、 I: Integrity Impact ）

・脆弱性を攻撃された際に、対象とする影響想定範囲の情報が改ざんされる可能性を評価します。

・なし(N) / 低(L)  / 高(H)

 

可用性への影響 （業務停止の可能性、 A: Availability Impact ）

・脆弱性を攻撃された際に、対象とする影響想定範囲の業務が遅延・停止する可能性を評価します。

・なし(N) / 低(L)  / 高(H)

 

上記を踏まえて、「Meltdown：　CVE-2017-5754」のCVSSを例に見ていきましょう。

 

Meltdownは、「CVE-2017-5754」の例

https://nvd.nist.gov/vuln/detail/CVE-2017-5754

 

CVSS Severity (version 2.0):

CVSS v2 Base Score:　4.7 MEDIUM

Vector:　(AV:L/AC:M/Au:N/C:C/I:N/A:N) (legend)

Impact Subscore:　6.9

Exploitability Subscore:　3.4

 

CVSS Severity (version 3.0):

CVSS v3 Base Score:　5.6 Medium

Vector:　CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N (legend)

Impact Score:　4.0

Exploitability Score:　1.1

 

これを、Vector別にわかりやすくしてみますと、

[v2の場合]

AV:L　 　ー＞　攻撃元区分：ローカル

AC:M　　ー＞　攻撃条件の複雑さ：中

Au:N　 　ー＞　攻撃前の認証要否：不要

C:C　　　ー＞　機密性への影響 ：全面的

I:N　　　ー＞　完全性への影響：なし

A:N　　　ー＞　可用性への影響：なし

 

[v3の場合]

AV：L　ー＞　攻撃元区分：ローカル

AC：H　ー＞　攻撃条件の複雑さ：高

PR：L　ー＞　必要な特権レベル：低

UI：N　ー＞　ユーザ関与レベル：不要

S：C　ー＞　スコープ： 変更あり

C：H　ー＞　機密性への影響：高

I：N　ー＞　完全性への影響：なし

A：N　ー＞　可用性への影響：なし

 

このようにVector（v2の場合）を確認することにより、

攻撃は「ローカル」でないとできないことや攻撃の複雑さが「中（やや複雑）」であり、「機密性を脅かす」脆弱性ということがわかります。

 

CVSS スコアだけではなく、Vectorも確認することにより脆弱性情報の適切な認識ができ、慌てることなく緊急対応可否の判断ができると思われます。

 

Vectorのポイントとしては前半の「v2の場合：AV・AC・Au」「v3の場合：AV・AC・PR・UI・S」にて攻撃の成功する条件が明記されており、後半の「C・I・A」はその攻撃によりどのような影響があるかになります。

 

このようにCVSSが高いからといって慌てず、Vectorも確認しながら対象システムに合った対応していきましょう。

参考：　https://jvn.jp/nav/jvnhelp.html

 

 

 

２，脆弱性情報APIの活用

最後に脆弱性情報を漏らさずキャッチするために便利なAPIを活用した例を紹介したいと思います。

 

[vulners.com apiの活用]

脆弱性情報の提供サイトの１つに「　https://vulners.com/　」というものがあります。

こちらのサイトがAPIを提供しており、そちらを活用し、ちょっとした通知ツールを作成しました。

 

API：　https://vulners.com/api/v3/

 

POSTやGETのどちらにも対応しており、以下のようにしてリクエストすることにより、該当すると結果がJSONで返ってきます。

 

結果サンプル

 

上記のAPIを利用し、条件に該当したらslackに流れるように致します。

 

流れ図

１，Google SpreadSheetsに開発チームが利用しているソフトウェアを記載。

 

２，Google SpreadSheetsに記載してある情報を元に「vulners.com」APIに問い合わせ、該当情報を検索。

 

３，条件に該当すれば、Slackへ投稿。

 

のような流れになっており、特定の開発チームにしか利用していないニッチなソフトウェアの脆弱性情報をもキャッチすることができます。

 

社内では、主なソフトウェアに関しては社内セキュリティポータルサイトに脆弱性情報は追加・共有されますが、さらに上記のシステムを活用することにより、それぞれの開発チームに合ったソフトウェアの情報を提供することが可能になります。

 

 

３，まとめ

日々多くの脆弱性情報が公開される中、運用しているシステムにどれが該当して、どのような対応が必要かを判断しなければなりません。この機会に改めて、脆弱性情報の見方を覚えましょう。

 

また、脆弱性情報の内容も正確に把握することも重要ですが、その際にCVSSのVector情報も取り入れて、緊急対応可否の判断材料にしていきましょう。