Future Tech Blog
フューチャー技術ブログ
Securityカテゴリ

Vulsの歴史

CSIGの井上です。

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

初めに

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

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

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

Vulsの歴史

Vulsとは

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

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

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は、Redhat Enterprise linuxは”yum-plugin-security”を、CentOSやその他のOSは”Changelog”をパースして情報源としていました。

Vulsリリース後、当時の各種勉強会で紹介されることが多く、Vulsを利用する人たちも増えてきました。そして、Vulsのslack 1が作られ、そこで色々な議論が行われるようになりました。海外の方からも意見が来ることがあり、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 2との連携ができるようになり、OSのパッケージだけではなくアプリケーションのライブラリ検査もできるようになりました。

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

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

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

2018年09月 - 現在

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

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

2019年01月に US-CERT及びJPCERT/CC 6の警戒情報が、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 4がありますので、脆弱性対策を検討されているようでしたら 井上までご連絡ください。

それでは、ご安全に。

  1. 1.Vulsのslack。参加はこちらから。初心者的な質問は #newbie、日本語は #vuls-jp などのチャンネルに分かれている。 ↩
  2. 2.OWASP Dependency Check。OWASPが提供しているプロジェクトの一つ。ローカルで実行することで、JavaやRubyなどのアプリケーションを調べ、古いライブラリの存在等を検出するツール。2020年時点では、github上で開発しているプロジェクトであれば、github security alertsでカバーできる為、利用できる場合はgithub側の物を利用することを推奨。 ↩
  3. 3.OVAL:Open Vulnerability and Assessment Language。SCAP(※脚注7）の構成要素の一つで、コンピュータのセキュリティ設定状況を検査するための仕様。これを用いることで、パッケージに残存する脆弱性を特定することが可能。各ベンダごとに用意されている。このOVAL情報を用いない場合、正確な脆弱性検出は不可能と考えられる。一般にCVEとして公開される脆弱性は公開されているプロジェクトの最新版を基にしている。しかしながら各ベンダのパッケージは最新版を使用しておらず、ある程度前のバージョンのものに対してパッチの適用を繰り返している、所謂「バックポート」を行っている。そのため、CVEで公表されたプログラムバージョンと、実際に影響のあるベンダパッケージのバージョンが異なることがあり、CVEで提供される情報だけでは判断がつかない。詳細に話したいがここでは書ききれない為、機会があれば別途公開したい。 ↩
  4. 4.FutureVuls。Vulsを管理しているFuture社が提供している、商用で使えるVuls。Vulsはサーバの脆弱性を可視化するだけだが、チームで脆弱性を管理する機能はない。そのための機能も含めてVulsをSaaSとして提供しているサービス。更新プログラムの適用タスク管理や、トリアージする際に判断しやすい画面などを提供している。 https://vuls.biz/ を参照。私の顔写真も出ている…。 ↩
  5. 5.トリアージ。所謂「患者の重症度に基づいて、治療の優先度を決定して選別を行う」事。脆弱性対応では、より リスクの高い脆弱性 を優先して対応する必要があり、対応優先度の判定という意味で利用される。決して「優先順位の低いものは(面倒だから)対応しない」事を決めるために行うものではない。リスク判定は、一般的には CVSS BaseScoreが高い物(8.0以上)、のような決定がされていることが多い。近年は脆弱性の性質を見て判断するという手法が徐々に広まっており、ネットワークから攻撃が可能か/PoCやExploitは存在するか/攻撃難易度は高いか、等のCVSS Vector情報を利用して判断する組織も増えてきている。CVSS BaseScoreは低くとも自社環境ではリスクが高い、Scoreは高くても自社環境ではリスクは少ない 等があるため、Scoreで判断するのはあまり適切ではない。ここに出てきているCVSS BaseScoreやVectorは、SCAPで利用されている。 ↩
  6. 6.JPCERT/CC(Japan Computer Emergency Response Team Coordination Center)。サイトによると「インターネットを介して発生する侵入やサービス妨害等のコンピュータセキュリティインシデント*1(以下、インシデント) について、日本国内に関するインシデント等の報告の受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討や助言などを、技術的な立場から行なっています。」との事。直接対応する訳ではない部分があるため、コーディネートセンター=CC としており、表記上「/CC」は必要。 ↩
  7. 7.SCAP(Security Content Automation Protocol)。米国で2002年に施工されたFISMA(Federal Information Security Management Act;連邦情報セキュリティマネジメント法)に対応するため、セキュリティ対策を自動化するための標準化として制定された。脆弱性対応でよく利用されるCVE, CPE, CVSS, OVALなどで構成されている。これらの定義により、システムが特定のセキュリティポリシーに合致しているかを迅速に確認/修正できるようになっている。実装としてはOpenSCAPが挙げられる。OpenSCAPのプログラムであるoscapコマンドに、特定のセキュリティポリシーを記載したもの(SSG:SCAP Security Guide。各ディストリビューション毎にパッケージで用意されている)を渡してチェックする。チェック内容は、例えばSSHのタイムアウト時間、必要パスワード文字長、などのconfigのチェックが含まれる。デフォルトで用意されているセキュリティポリシーは強力なものが多く(PCI-DSSやFISMA対応などであり、一般のサーバに適用するには強固すぎるきらいがある)、日本国内ではなかなか利用されていないように見える。こちらも詳細はこの記事には書ききれないので、機会があれば別途公開したい。 ↩