Recomendados
Mais conteúdo relacionado
Mais de hogehuga
Mais de hogehuga (20)
Último
Último (8)
Vuls祭りvol3
- 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で拾えるもの