Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

4,541 views

Published on

11/24にIs Community勉強会にて登壇した時の資料です。

Published in: Engineering
  • Be the first to comment

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. なんでだろ? 業界の人は攻撃が成功するとなぜか皆さん 「刺さる」 と表現している気がします。 アレは一体、なんでなんだろ?w 僕も良く使うけどw https://www.reddit.com/r/pics/comments/61muuz/this_pufferfish _booped_by_a_dolphin/より引用
  25. 25. 情報の交換はすごく重要 僕の場合は知り合いとSlackなどで 情報交換しながら検証しています Strutsのアレ Tomcatのアレ
  26. 26. 4.脆弱性の分析
  27. 27. 正直ここが一番難しい • 3の工程までは環境作るのがちょっとめんど いが、割と簡単にできる • 何故こんな脆弱性が存在するのかの原理分析 は地道に分析していかなければならないため 時間がかかる • 検証対象に関する知識、コードを読む技術、 リバースエンジニアリングの技術などが必要 • 有識者の方が原理に関して詳細な解説を公開 している場合などもあるので、その場合はか なり読み込む • 正直、自分もここら辺のノウハウとかを是非 より深く知りたい
  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!

×