CSIGの井上です。

この記事は秋のブログ週間連載の第1弾です。

初めに

私の所属するCSIG(CyberSecurityInnovationGroup)は、セキュリティ関連のコンサルティングや実装などを行っています。また、セキュリティスキャナである Vuls やその商用版であるFutureVulsを開発/運営しています。
今回、「秋の読書週間として、読み物成分の多い記事を」という事なので、BlackHatなどでも取り上げられたVulsについて書こうと思います。

私自身、Vulsのコミュニティに関わった関係でFutureと縁ができたので、過去の振り返りになりますね。

※私はVulsの開発を直接している人ではないので、この記事は私の視点での解釈です。
※記載上「実装しました」という書き方をしていますが、実装しているのはプロジェクトオーナの神戸さんや、PullRequestをして頂いたコミッターの方です。
※本記事は他の「秋の読書週間連載」著者と若干毛色が違うため、口に合わない場合は次の記事をお待ちください…

Vulsの歴史

Vulsとは

2016年04月にFuture社の神戸氏によりGithubで公開された、脆弱性スキャナです。ドキュメントなどは、vuls.ioで公開されています。

Vuls自体、色々な団体から評価されています。

• IPAの「脆弱性対策の効果的な進め方 ツール活用編」で、インストールや使い方の解説がされました。
• 一般社団法人 情報処理学会の2019年ソフトウェアジャパンアワードを受賞しました。
• NICTから、Vulsと連動する脆弱性管理プラットフォーム「NIRVANA改弐」がリリースされました。

Vulsがリリースされた事で、脆弱性可視化が楽になった面のありますが、システム管理者の「脆弱性に対する考え方」に影響を与えたと、私は思っています。

• 今までは、「ニュースで報道されたから対応する」「JPCERT/CCが注意喚起を出したから対応する」「CVSS BaseScoreが8.0以上だから対応する」という、内容よりも雰囲気で対応している環境が多い気がします。
• Vulsが出てからは、「脆弱性の影響を見て対応を考える(CVSS Vectorを見る)」「Exploit/PoCが公開された為、対応を早める」「脆弱性のあるパッケージが(ネットワークの)ポートをlistenしているから対応が必要」など、受け身ではない脆弱性対応が広まったと思います。アクティブに脆弱性に対応するには、脆弱性の可視化や情報収集の自動化が必要で、Vulsはそれを助けている、と考えます。

そんなVulsについて、今までどのように進化してきたかを、大雑把にまとめてみました。

Vulsの歴史

2016年04月 - 2016年09月ごろ

Vulsが公開され、初期の口コミでの広まりが起こった時期です。私は2016年06月ごろからVulsに関わり始めたので、最初期の頃は分からないです。

2016年04月04日に、Vulsは初めてリリースされました。初期のVulsは、Red Hat Enterprise linuxは”yum-plugin-security”を、CentOSやその他のOSは”Changelog”をパースして情報源としていました。

Vulsリリース後、当時の各種勉強会で紹介されることが多く、Vulsを利用する人たちも増えてきました。そして、Vulsのslack ¹が作られ、そこで色々な議論が行われるようになりました。海外の方からも意見が来ることがあり、Slackに参加している日本人有志で返答をしたりしていました。

人数も増えて勢いも出てきたのでイベントをやろうということになり、Vuls祭りの第1回が2016年09月に開催されました。最終的には90名程度集まり、JPCERT/CC様のお話もありつつ、どのように利用するかというLTが多数ありました。今考えれば19:00開始で21:20終了(実際には22:00を超えた気がします)という、一般の勉強会よりも長い時間実施するという、かなり熱のあるイベントでした。

振り返ると、初期の拡散力はすごかったと思います。オープンな脆弱性管理/可視化/スキャンツールに対する期待が高く、それにマッチしていたのだと思います。

2016年10月 - 2018年08月

Vuls祭り#1以降、スキャン方法の更新や各種機能の追加が行われました。成熟期ととらえてよいかもしれません。

2016年11月にOWASP Dependency Check ²との連携ができるようになり、OSのパッケージだけではなくアプリケーションのライブラリ検査もできるようになりました。

2017年08月には、OVALスキャンと、Fast/Deepスキャンが実装されました。OVALスキャンは、今までのchengelogやyum-plugin-securityで脆弱性情報を集めるのではなく、各ディストリビューションごとにまとめられたOVAL ³と呼ばれる脆弱性情報をまとめたデータを利用するようになりました。これにより、Changelogのパースより正確な脆弱性情報を取得できるようになりました。また、Fast/Deepスキャンの実装(後にFastRootなどのモードが作られます)により、管理者権限が無くともスキャンができるようになりました。

2017年10月にVuls祭り#3が開催され、この頃から「実運用でVulsをどう使っているか/どう使うのか」という発表がされています。SoftwareDesignで特集が組まれたりしたことで、Vulsというものが認知され、利用が広がってきたことが実感できた時期です。その後スキャン方法の更新などが行われ、2018年08月に、ある程度の人でも安定的に利用できるVuls v0.5.0がリリースされました。それに合わせ、同日、Vuls祭り#4が開催されました。

またこの時期に、商用版のサービスとして FutureVuls ⁴がリリースされています。GitHubで公開されているVulsはスキャンを中心としたものであり、実運用上では「タスク管理機能」や「一覧表示」などが必要になります。自前で何らかの管理の仕組みが必要になるため、商用版としてタスク管理機能等を含んだサービスを提供し始めました。

2018年09月 - 現在

脆弱性スキャンの方向性が固まり、徐々にスキャン範囲を広げていく時期だと思います。

2018年11月に、Exploit/PoC情報があるかを確認できるようになりました。これは、脆弱性トリアージ ⁵の際に「Exploitが公開される=簡単に攻撃ができるようになる」ということで、対応優先度を考慮する際に重要な指標になります。所謂Script kiddieと呼ばれる、他人の作成したExploitを用いて興味本位で攻撃を行うクラッカーが利用してしまう為、攻撃に晒されるリスクが高くなる為です。この情報がVulsのスキャン結果に付与されることで、対応優先度の判断がしやすくなりました。

2019年01月に US-CERT及びJPCERT/CC ⁶の警戒情報が、2019年02月にGithub Security Alertsとの連携、2019年04月にはWordPressの脆弱性スキャン、が可能になりました。

特にGithub Security Alertsについては、今まではOWASP Dependency Checkでしかプログラムのライブラリスキャンはできなかったものが、Github連携をするだけで検出できるようになり、利便性が向上しました。極端な話、プログラムのLockfile(利用しているライブラリ等の依存関係が書かれたファイル)だけをGitHubにアップロードすることで、実機のスキャンの必要が無く脆弱性を診断できるようになったのです。

2019年07月には、脆弱性の残存しているパッケージが利用しているポートやプロセスを表示する機能が実装されました。脆弱性のあるパッケージがどこに影響をしているのか、待ち受けポートやPIDで可視化できるようになりました。例えばlibcの脆弱性が、まわりまわってssh serverで使われている、等が分かるようになります。
脆弱性対策の基本として「利用していないパッケージは導入しない」(不要なものを入れない=管理コスト削減)というのがありますが、脆弱性が残存するパッケージを(少なくとも常駐プロセスとして)使っているのかを確認できるようになりました。

そして、直近ですが2020年10月に、ポートスキャナ機能を実装しました。これはVulsで検出されたポートに対してスキャンを行うものです。通常のポートスキャナは外形検査を含むため、外部から全ポート(若しくは複数の特定のポート)に対してスキャンを実施します。Vulsのポートスキャンは無差別なスキャンを行わず、利用しているポートに対してスキャンを行います。この機能は、Firewallでポートは閉じられているが、実機上ではオープンとなっている、等を認識する点で利用可能だと思います。

このように、続々と新機能が追加されています。これからが成熟期なのかもしれません。

終わりに

簡単ですが、私の視点からVulsの歴史を見てきました。これからも脆弱性対策はますます重要になっていくため、これらのツールを活用して安全に運用していきたいですね。

あと、Vuls祭り、やりたいですね。

尚、商用サービスとして FutureVuls ⁴がありますので、脆弱性対策を検討されているようでしたら 井上までご連絡ください。

それでは、ご安全に。