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

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