痴耻濒蝉祭り惫辞濒3
- 2. 話の概要 ? Vulsも有名になってきたので、Vulsの立ち位置を再確認した いな、と思いました。 ? 脆弱性対応全体の中での位置づけは？ ? Vulsは、何ができて、何ができないのか？ ? Vulsができない分野は、どうすればいいのか ? どうやったらVulsを活かせるのか ? あたりを話たいと思いました。 ? Vulsを有効に使うため、Vuls以外のツールも使ってほしいよ ? 脆弱性対応が楽になる、という最終目標のために！
- 3. それでは、始めます。
- 4. Vulsで脆弱性対応していますか？ ? そもそも、Vulsはどんな動作をするのでしたっけ？ ? パッケージに残存する脆弱性 を表示する ? より詳細に （CVE番号レベルでの表示） ? 見やすく （動的に画面を構成しながら） ? Vulsで脆弱性が可視化できた！ ? 脆弱性対応は「これ」だけを見ておけばいいかな？
- 6. なぜ駄目なのか ? Vulsが見ているのは、OSのパッケージだけです。 ? ?SSH/SMB/DNS系サーバなら、必要十分、かも。 ? 実運用を考えると、OSパッケージ以外も脆弱性が 多々ある。 ? Apache Struts2は、パッケージには含まれていない？ ? WordPressなども、ダウンロードして使いますよね？ ? ミドルウェアで利用しているライブラリ、気にしています？ ? そもそも、自分で書いたプログラムは安全？ WEB系 という 前提
- 7. 脆弱性が発生/残存する場所 一般的なWEBアプリケーションは以下のように分類 できるはずです。 分類 例 WEBアプリケーション Application.war Index.php WEBアプリケーション ライブラリ/プラグイン Struts2 jQuery Jsp-api.jar WEBアプリケーション フレームワーク Struts2 tomcat OS、パッケージ Apache httpd2 kernel
- 8. 脆弱性が発生/残存する場所 一般的なWEBアプリケーションは以下のように分類 できるはずです。 分類 例 WEBアプリケーション Application.war Index.php WEBアプリケーション ライブラリ/プラグイン Struts2 jQuery Jsp-api.jar WEBアプリケーション フレームワーク Struts2 tomcat OS、パッケージ Apache httpd2 kernel Vulsはここら辺 まで見れる Vulsはここら辺 は見ることができな い
- 9. 脆弱性検知方法とタイミング 脆弱な部分 概要 WEBアプリケーション 自社/自身で作成したWEBアプリケーション （汎用的に使われているものではない＝確認の目が少ない） WEBアプリケーション ライブラリ／プラグイン フレームワークなどで利用するライブラリや、プラグイン WEBアプリケーション フレームワーク OSS等、汎用的に使われているベースとなるシステム （WordPress、Ruby on Rails、Struts、などのもの） OSやミドルウェア層 Windows、Linux、BSDなどのOS および OSで提供されるパッケージ（httpd、bind、mysqlなど）
- 10. 脆弱性検知方法とタイミング 脆弱な部分 概要 WEBアプリケーション 自社/自身で作成したWEBアプリケーション （汎用的に使われているものではない＝確認の目が少ない） WEBアプリケーション ライブラリ／プラグイン フレームワークなどで利用するライブラリや、プラグイン WEBアプリケーション フレームワーク OSS等、汎用的に使われているベースとなるシステム （WordPress、Ruby on Rails、Struts、などのもの） OSやミドルウェア層 Windows、Linux、BSDなどのOS および OSで提供されるパッケージ（httpd、bind、mysqlなど） 自分で確認するしかない 確認する方法が少ない
- 11. 脆弱性検知方法とタイミング 脆弱な部分 検知タイミング 検知方法 WEBアプリケーション 〇 構築時 脆弱性診断サービス （Blackbox/Whitebox） OWASP Zed Application Proxy（ZAP）△/× 運用時 WEBアプリケーション ライブラリ／プラグイン 〇 構築時 脆弱性診断サービス？ Vuls（cpeNames） OWASP Dependency Check△/× 運用時 WEBアプリケーション フレームワーク 〇 構築時 Vuls（cpeNames） Package manager（yum, apt, dpkg …）〇/△ 運用時 OSやミドルウェア層 〇 構築時 Vuls Package manager（yum, apt, dpkg …）〇 運用時
- 12. 脆弱性検知方法とタイミング 脆弱な部分 検知タイミング 検知方法 WEBアプリケーション 〇 構築時 脆弱性診断サービス （Blackbox/Whitebox） OWASP Zed Application Proxy（ZAP） △/ × 運用時 WEBアプリケーション ライブラリ／プラグイン 〇 構築時 脆弱性診断サービス？ Vuls（cpeNames） OWASP Dependency Check △/ × 運用時 WEBアプリケーション フレームワーク 〇 構築時 Vuls（cpeNames） Package manager（yum, apt, dpkg …）〇 /△ 運用時 OSやミドルウェア層 〇 構築時 Vuls Package manager（yum, apt, dpkg …）〇 運用時 Vulsでは無理 Vulsでは無理な場合も Vulsはここが主戦場 VulsではcpeNames使う
- 13. ? Vulsだけでは、すべての脆弱な部分を検知できま せん。 ? ほかのツールを使うことで、隠れた脆弱性を見つ けることができます。 Vulsの次の段階として WEB脆弱性診断などを 始めませんか？
- 14. 脆弱性対策、デモ
- 15. 脆弱なサイトを用意しました ? CentOS7の初期のDVDからサーバを作りました ? 古いパッケージのhttpdによる脆弱性デモ ? WordPressを稼働させています ? WordPressは4.7、WordPressPlguinも脆弱なものを用意 ? Vulsで検知できない脆弱性のデモ ? 自作PHPページも用意しました ? Vulsで検知できない脆弱性を、 OWASP ZAPで検知するデモ
- 16. デモ：一部、準備間に合わず ? すみません、準備時間取れなかったので、 以下のデモは割愛します。 ? Vulsで検知した、古いHTTPDに対する攻撃 ? アップデートで治った ? VuslのcpeNamesで検知した、古いWordPressの脆弱性を ついた攻撃 = REST_API事件 ? アップデートで治った
- 17. デモ：要点 ? WEB脆弱性のデモ ? 反射型XSSができるだけなのでサービスの可用性には影響がない が、ユーザがブラウザ以上で情報を抜かれてしまう。 ? cpeNamesの限界 ? 更新するたびにconfig.toml書き直しになるし、cpeName探すの面 倒 ? 他のツールを使うことも視野に入れる。 ? 脆弱性検査しませんか？ ? 外部業者に出すと高い ? OWASP ZAPと多少の知識があれば、自分でできる！
- 18. デモンストレーション
- 19. どのように対策、検知すべき？ ? Apache HTTPD ? Vulsにて、古いことを確認可能?UPDATE ? WordPress ? VulsのcpeNamesにて、古いことを確認可能?UPDATE ? WordPress Plugin ? Vulsでは、検知不能 ? WordPressのセキュリティ系Pluginでの通知が有効？ ?WP- SITEGUARDとか有用 ? 自作サイト ? 脆弱性検査が別途必要?なるべくフレームワーク使う
- 20. まとめ ? Vulsだけでは、駄目！ ? ほかのツールも使ってみよう(OWASP ZAPなど) ? 連携できるもの(OWASP DependencyCheck)も活用 ? でも、OS側を見るのであれば、Vulsは超便利、使って！ ? 対策は、シフトレフト！ ? アプリ作る時点で、古いライブラリは使わない、など ? 開発時点でしか減らせない脆弱性もある ? 運用段階ではVulsで十分、という形にしたい ? パッケージ配布のもの、cpeNamesで拾えるもの