新規発行されたCVEの一覧をいつも目を通しているのだけれども、そういえばxxxは最近登録が無かったっけ？、と探したくなる時が時々あります。そんな時はgo-cve-dictionaryで探せば解決するよ、というエントリ。

事の始まり

作業用に使っているUbuntuで、Elasticsearchとpacketbeatの更新が出ていた。

そういえば最近、cve-newでelasticsearchという文字列を見た気がする。
- もしかして、セキュリティフィックス？
- あのCVE、何だっけなぁ、思い出せないよ

そんなわけで、CVE番号を探し始めた。あと、記憶が正しかったか、も。

go-cve-dictionaryを使う

CVEで文字列を見かけた気がするという事は、サマリか何かに書いてあったはず。
それだったら go-cve-dictionaryの nvds テーブルを探せばいいのでは？

方針

CVEのサマリで見た文字列を探そう

そして、思い出せないアレ（CVE-ID）を見つけてすっきりしよう

当たり前ながら、sqlite3でデータベースにアクセスする。

古いSqlite3を使っている場合、アクセスできない場合があります。
- -walや-shmに対応していないバージョンが該当します。
- sqlite3の新しいものををソースインストールするか、古いOSを捨て去ってください。

vuls@HOSTNAME:~$ sqlite3 cve.sqlite3 
SQLite version 3.11.0 2016-02-15 17:29:24
Enter ".help" for usage hints.
sqlite>

スキーマをざっくり見ると、作成日:created_at, CVE番号：cve_id, サマリ：summary、は存在するようだ

sqlite> .schema nvds
CREATE TABLE "nvds" ("id" integer primary key autoincrement,"created_at" datetime,"updated_at" datetime,"deleted_at" datetime,"cve_detail_id" integer,"cve_id" varchar(255),"summary" varchar(4096),"score" real,"access_vector" varchar(255),"access_complexity" varchar(255),"authentication" varchar(255),"confidentiality_impact" varchar(255),"integrity_impact" varchar(255),"availability_impact" varchar(255),"cwe_id" varchar(255),"published_date" datetime,"last_modified_date" datetime );
CREATE INDEX idx_nvds_deleted_at ON "nvds"(deleted_at) ;
CREATE INDEX idx_nvds_cve_detail_id ON "nvds"(cve_detail_id) ;
sqlite>

適当にselectしてみる。

sqlite> select created_at,cve_id,summary from nvds limit 3;
2017-10-02 11:30:10.628884316+09:00|CVE-1999-0001|ip_input.c in BSD-derived TCP/IP implementations allows remote attackers to cause a denial of service (crash or hang) via crafted packets.
2017-10-02 11:30:10.630703948+09:00|CVE-1999-0002|Buffer overflow in NFS mountd gives root access to remote attackers, mostly in Linux systems.
2017-10-02 11:30:10.631736116+09:00|CVE-1999-0003|Execute commands as root via buffer overflow in Tooltalk database server (rpc.ttdbserverd).
sqlite>

サマリに、対象のソフトウェア等が書いてあるよね。「前に見たかも」と思ったのも、多分ここに書いてあった話だよ。

じゃあ、summaryをlikeすればいいんじゃね。
方針決まった。

探す

対象ソフトウェアは、Elasticsearch。但し、サマリ中でelasticなのかElasticなのかわからんので、lasticsearchで検索しとく。

vuls@HOSTNAME:~$ sqlite3 cve.sqlite3 
SQLite version 3.11.0 2016-02-15 17:29:24
Enter ".help" for usage hints.
sqlite> select created_at, cve_id from nvds where summary like "%lasticsearch%";
2017-10-02 12:12:31.991790102+09:00|CVE-2013-4758
2017-10-02 12:15:50.363058728+09:00|CVE-2014-3120
2017-10-02 12:16:26.985202502+09:00|CVE-2014-4326
2017-10-02 12:17:07.672360323+09:00|CVE-2014-6439
2017-10-02 12:19:23.633626031+09:00|CVE-2015-1427
2017-10-02 12:19:52.939602517+09:00|CVE-2015-3337
2017-10-02 12:20:00.482951281+09:00|CVE-2015-4093
2017-10-02 12:20:00.712335057+09:00|CVE-2015-4152
2017-10-02 12:20:00.778658909+09:00|CVE-2015-4165
2017-10-02 12:20:21.123175479+09:00|CVE-2015-5531
2017-10-02 12:21:04.270948809+09:00|CVE-2015-8131
2017-10-02 12:21:52.702309877+09:00|CVE-2016-1000221
2017-10-02 12:21:57.049457006+09:00|CVE-2016-10362
2017-10-02 12:25:56.433959864+09:00|CVE-2017-8442
2017-12-15 09:26:26.928414027+09:00|CVE-2017-12629
sqlite>

最近裁判されたっぽいのはCVE-2016-1000221のようだけど、うっすら記憶に残っているのは多分直近の物のはず。2017-12-15が存在しているね。たぶんこれでは。

sqlite> select cve_id, summary from nvds where cve_id ="CVE-2017-12629";
CVE-2017-12629|Remote code execution occurs in Apache Solr before 7.1 with Apache Lucene before 7.1 by exploiting XXE in conjunction with use of a Config API add-listener command to reach the RunExecutableListener class. Elasticsearch, although it uses Lucene, is NOT vulnerable to this. Note that the XML external entity expansion vulnerability occurs in the XML Query Parser which is available, by default, for any query request with parameters deftype=xmlparser and can be exploited to upload malicious data to the /upload request handler or as Blind XXE using ftp wrapper in order to read arbitrary local files from the Solr server. Note also that the second vulnerability relates to remote code execution using the RunExecutableListener available on all affected versions of Solr.
sqlite>

確かに文字は存在する。

…が。
Elasticsearch, although it uses Lucene, is NOT vulnerable to this.なのでElasticsearchはLuceneを使用していますが、これには脆弱ではありません。だよ。

という訳で、関係なかった。

答え合わせ

そもそも、「Elasticsearchとpacketbeatのアップデートがあった」とtwitterでつぶやいてたら、Jun Ohtani‏（@johtani）さんから、アップデートだよ、めんしょん頂いてた。

https://www.elastic.co/blog/elastic-stack-6-1-0-released

確認したらやっぱり問題なかったので、気のせいでしたわ。という感じでした。

おしまい。

少しはまじめに。

NVDでCVE情報を全文検索するよりも、ローカルにあるデータを検索したほうがやりやすいですね。
似非リサーチャー以上のスキルをお持ちの方なら、「そういえば少し前に何か出てなかったっけ？」という事はあると思います。相当記憶力が良い方なら思い出せると思いますが、現実のCVE登録数は、記憶に残せるほど甘くはないです。

@cvenew さんのツイートを見てみてください。

本職ではなく、情報だけ収集しているような方には、非常に便利なデータベースだと思いました。

ほんとうに、おわり。