Let's verify the vulnerability-脆弱性を検証してみよう！-

Let's verify the vulnerability-脆弱性を検証してみよう！-

1. 1. Let‘s verify the vulnerability! -脆弱性を検証してみよう！- @tigerszk 2017/11/24 Is Community勉強会
2. 2. 自己紹介 Shun Suzaki(洲崎 俊) ユーザ企業のセキュリティチームに所属する セキュリティエンジニア Twitter: とある診断員@tigerszk • ISOG-J WG1 • Burp Suite Japan User Group • OWASP JAPAN Promotion Team • IT勉強会「#ssmjp」運営メンバー I‘M A CERTAIN PENTESTER! 公開スライド:http://www.slideshare.net/zaki4649/ Blog:http://tigerszk.hatenablog.com/
3. 3. 脆弱性の検証って？ 公開された脆弱性情報について、 自分で試して詳細を確認してみること CVE 2017-xxxxx CVE 2016-yyyy CVE 2017-zzzzz
4. 4. なぜ脆弱性を検証するのか？
5. 5. 僕が検証する理由 • 単純に面白いし楽しい • たまにマジで感動する • 自分の目で確認することが重要 • 手を動かすことで色々勉強になる • 世の中の役に立つこともある • 自分の業務にも役立つこともある
6. 6. 検証すると色々わかることがある 自分で試さないとわからないことが結構ある 正しい内容を正確に把握したい 攻撃は簡単に成功するの？ どのぐらい危険なの？ 被害を受けそうなものは？ 対策はどうやるの？
7. 7. どうやって検証するのか？
8. 8. こんな流れでやってます アウト プット 脆弱性の 分析 攻撃の 実行 環境構築情報収集
9. 9. 1.情報収集
10. 10. どんな情報を収集するの？ 脆弱性に関する以下のような情報を収集 – 脆弱性の概要 – 攻撃の条件（リモート？ローカル？） – 攻撃の種類（RCE?権限昇格？） – 影響範囲（対象は何か？該当するバージョンなどは？） – 対策方法（現時点で根本対策はあるのか？暫定対策は？） – Exploit（攻撃コード）の有無 これ
11. 11. Exploitは誰が公開する？ • 発見者が検証目的のためPoC (Proof-of- Concept)として公開される • 公開された修正内容や情報を解析され、 作成される • 実際に行われていた攻撃を分析した結果、 脆弱性の存在が判明するようなケースも 【参考】 セキュリティのアレ（35）：脆弱性情報を読み解く際の必須用語、 exploit（エクスプロイト）とは - ＠IT : http://www.atmarkit.co.jp/ait/articles/1610/10/news008.html
12. 12. よくあるパターン セキュリティ技術者・研究者 など誰かが脆弱性を見つける 開発ベンダに報告 Exploit（攻撃コード） が公開される 開発ベンダが パッチなどをリリース 脆弱性の存在が公表される 大体ここらへんで 情報を収集したり 検証する
13. 13. 検証は結構時間との勝負 • 危険な脆弱性であれば、Exploitが公開され てから実際の攻撃が始まるまでの間隔が 非常に短いケースなどは多い • 適切な対応を行うためにも、なるべく 早く正しい情報を把握することが必要 • Exploitを分析することで、対応策の検討、 攻撃の検出、脆弱性の存在検出などの 材料を得ることができる
14. 14. どうやって情報収集するの？ • まあまずとりあえずはググる • TwitterやBlogなど – 自分が知りたい情報などを良く配信してくれる方 などをフォローしておくとよいかも – やっぱり海外の方が情報配信が早い印象 • Githubとかを検索してみる – 修正がでている場合にはコードの中身を diffって確認してみたりする – CVEとかそれっぽいワード検索するといきなり ヒットしたりも • 知り合いと情報交換 – Slack や SNS経由などで情報を交換
15. 15. Exploitが投稿されるサイトなどもチェック • Exploits Database https://www.exploit-db.com/ • cxsecurity https://cxsecurity.com/wlb/
16. 16. 2.環境構築
17. 17. • 収集した情報をもとに、脆弱な環境を構築 – 該当するバージョンは？ – OSなどは限定されているのか？ – 特別な設定や実装などの条件が必要なのか？ • 併せて対策実施後に攻撃が成立しないかを 確認するための準備をしておくと良いかも • OSSとかであれば楽だが、勿論モノによっ ては簡単には用意できないものもある 脆弱な環境を用意
18. 18. 試したいExploitを実行するための環境も 用意しておく必要がある • Pythonで書かれているものが多い印象 • オーバーフローなどメモリ関連の脆弱性では Cが多い • 最近はgoとかで書かれたExploitもたまに見る Exploitコードを動作させる環境も用意
19. 19. • VMWareやVirtualBoxなどをよく使う • スナップショットは必須 • よく使うプラットフォーム環境はあらかじめ 複数環境用意しておくとよいかも • Windowsは業務でならMSDNを用意して もらう、個人だったらmodern.IEとか TechNet Evaluation Centerでしょうがない から頑張る 仮想環境を使うのが良い
20. 20. • 最近は検証用の環境をDockerイメージで 配布しているケースなども多い • ものによっては慣れるとサクッと環境を 構築できるし、切り戻しも楽 Docker使えると便利かもよ？ 【参考】 Dockerを使って、Apache Struts2の脆弱性S2-037のやられ環境を手 軽に作る - DARK MATTER : http://io.cyberdefense.jp/entry/2016/06/22/Docker%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6 %E3%80%81Apache_Struts2%E3%81%AE%E8%84%86%E5%BC%B1%E6%80%A7S2- 037%E3%81%AE%E3%82%84%E3%82%89%E3%82%8C%E7%92%B0%E5%A2%83%E3%82%92%E6% 89%8B%E8%BB%BD%E3%81%AB%E4%BD%9C
21. 21. 検証環境のちょっとした小ネタ あらかじめ複数バージョンのソフトウェアが 動作している環境などを準備していると検証が はかどるかも？ • 僕が調べたApacheバージョン判定の小ネタ – とある診断員の備忘録 : http://tigerszk.hatenablog.com/entry/20 17/09/04/212108 • PHPの全バージョンの挙動をApacheモジュー ルとして試す | 徳丸浩の日記 : https://blog.tokumaru.org/2016/12/mod phpall.html
22. 22. 3.攻撃コードの実行
23. 23. • 準備ができたら、あとは攻撃が成功するのか とにかく試してみる • 脆弱な環境で成功したら、今度は対策を実施 した環境で成功しないかも試してみる • 通常すんなり上手くいかないことが多い – 環境構築が上手く行ってない – Exploitが作成者の環境に依存していて 自分の環境では上手く動かない – そもそもExploitがまともに動かない 環境ができたらあとはやるだけ
24. 24. なんでだろ？ 業界の人は攻撃が成功するとなぜか皆さん 「刺さる」 と表現している気がします。 アレは一体、なんでなんだろ？ｗ 僕も良く使うけどｗ https://www.reddit.com/r/pics/comments/61muuz/this_pufferfish _booped_by_a_dolphin/より引用
25. 25. 情報の交換はすごく重要 僕の場合は知り合いとSlackなどで 情報交換しながら検証しています Strutsのアレ Tomcatのアレ
26. 26. 4.脆弱性の分析
27. 27. 正直ここが一番難しい • ３の工程までは環境作るのがちょっとめんど いが、割と簡単にできる • 何故こんな脆弱性が存在するのかの原理分析 は地道に分析していかなければならないため 時間がかかる • 検証対象に関する知識、コードを読む技術、 リバースエンジニアリングの技術などが必要 • 有識者の方が原理に関して詳細な解説を公開 している場合などもあるので、その場合はか なり読み込む • 正直、自分もここら辺のノウハウとかを是非 より深く知りたい
28. 28. 脆弱性分析のちょっとした小ネタ • デバッガを利用してWebアプリの脆弱性を分析 してみた - とある診断員の備忘録 : http://tigerszk.hatenablog.com/entry/2017/11/17/175839 最近Webアプリでの脆弱性分析のコツを教 えていただいたのでまとめてみました。
29. 29. 試してみた結果をもとに分析 • 調査、検証の結果から、今回の脆弱性に ついて自分なりの分析・評価をする – 収集した情報の通り脆弱性は発現したのか？ – 攻撃が成立する条件どうなのか？ – 攻撃による影響度はどうなのか？ – 公開されている対策は有効だったのか？ – 実際に試して、他に気づいたことはないか？
30. 30. 5.アウトプット
31. 31. 分析した結果を形にしてみる • 社内などに情報を共有する • Twitter、Blogなどで情報を公開する • レポートを作成する • 脆弱性を検出するためのコードを 自分で書いてみる
32. 32. どこまでを公開するか結構悩む • オープンな場で、情報を公開する時 には、どこまで公開すべきなのかと か色々悩む時がある • 情報の収集・共有に関して最近読ん で参考になった – セキュリティ対応組織(SOC/CSIRT)強化に向け た サイバーセキュリティ情報共有の「5W1H」 http://isog-j.org/output/2017/5W1H- Cyber_Threat_Information_Sharing_v1.0.pdf
33. 33. 情報を公開すると意外と反響がある 過去脆弱性検証関連で、自分がBlogなどで公開し てみたら意外と反響があり、ちょっとは役に立っ たようでうれしかった！ • とある診断員によるJoomla!の脆弱性検証まとめ https://togetter.com/li/1041878 • Apache Struts2の脆弱性（CVE-2017-5638） を検証してみた http://tigerszk.hatenablog.com/entry/2017/03/08/063334
34. 34. そのひと手間がもしかしたら 世の中をセキュアにするために 役立つのかもしれない！
35. 35. Let’ Try!