kapieciiのブログ

日々学んだことを残しておくためのブログです。このブログはGoogle Analyticsを利用しています。

システム運用者側からみた脆弱性の調査とハンドリングについて

2018/11/24に開催された「大和セキュリティ勉強会:今年話題になった脆弱性を攻撃してみよう! with Vuls」に参加してきました。
脆弱性の概要と対策を調べる方法や、脆弱性を実際に検証してみることの楽しさを体験できたので、ブログに残しておこうと思います。

yamatosecurity.connpass.com

目次

勉強会全体の流れ

  • 脆弱性とは?」という定義の確認からはじまり、「脆弱性が発見された際の調査と対応の例」について話してくれました。
  • ひとしきり情報のインプットが終わった後は、実際の脆弱性であるCVE-2018-11235について、実施に手を動かして調査を行いました。
  • 最後はチームに別れ、vulsを使って既知の脆弱性を見つけ、CTF形式で実際にCVE番号が振られた脆弱性の攻撃を体験しました。

以降は話してもらった内容を簡単に整理したノートです。


脆弱性とは?

悪用できるバグ。
ただし、立場や環境によって脆弱性とみなすかどうか変わります。同じ脆弱性であったとしてもしても、発生するソフトウェアによっては危険度が異なったりします。
ややこしいので今回は「自組織で攻撃されて困るもの」を脆弱性と仮定して話を進めます。

脆弱性に対応するためのシステム運用

迅速なパッチ適用はとても大切です。パッチを適用せずに脆弱性を放置していると情報漏えいなど、大きな被害に発展する可能性があります。
「攻撃者はパッチが公開された2日後くらいから攻撃をしてくる」という観測結果もあるそうです。

継続的に情報を収集し、公開された脆弱性を調査していくことが望ましいですが、人的・時間的制約がある場合も多いです。
そのような場合には、自組織に合わせたルールで脆弱性をフィルタリングし、優先度の高いものから順に調査を実施して対策を行います。

脆弱性のハンドリング

  1. 脆弱性の概要を調査
  2. 脆弱性をフィルタリング
  3. 調査・対策の実施

という流れで対応を進めます。

脆弱性の概要調査

などの情報源を元に、脆弱性の概要を確認します。

脆弱性のフィルタリング

ベンダーページやNVDでは下記のような内容を確認します。

  • Description: 脆弱性の概要。ざっとみることで、どのような脆弱性なのかを知ることができます。
  • Base Score: 値からなんとなく雰囲気を掴みます。ただし、ここだけで判断してはいけません。
  • Attack Vector: 脆弱性をフィルタリングする上でとても大切です。

全ての脆弱性を調査するのは不可能なので、ルールを決めてふるいにかけます。
「Attack Vector」と「Privileges Required」でフィルタリングを行う例を紹介します。

Attack Vector

Attack VectorがP(物理)の場合、攻撃者が物理的にアクセスできている状態です。
物理的にアクセスができるということは機器の破壊や、攻撃用データの追加などができるので、もはや脆弱性がどうとか言っている場合ではありません。

「Attack Vectorの値が、物理/ローカル/隣接の場合は攻撃を受ける可能性が低いと判断し、Attack Vectorがリモートのものに絞って脆弱性の内容を確認する」といったルールを決めることができます。
ただし、この判断基準は所属組織の特性によって変わるので、組織に合わせて適切に設定する必要があります。

Privileges Required

攻撃する際に必要な権限のレベルです。
管理者の権限が無いと攻撃できない場合、「攻撃が発生する」→「攻撃者は管理者?もしくは既に管理権限を持っている?」となり、この場合も脆弱性とか言っている場合ではありません。
ここでも「権限が不要のものだけ対応する」などのふるいにかけることができます。

ふるいにかけて残ったものを調査していきます。

脆弱性の調査・対策

を参照し、攻撃の内容を把握します。

報告者は脆弱性を伝えたくて仕方がないので、詳細に再現方法を説明してくれている場合があります。親切な場合は攻撃に使うファイルを公開してくれていることもあるそうです。
また、報告者のブログ以外にも、redditなどを調べると、日本よりも早いタイミングで脆弱性についての議論が行われている場合もあるそうです。

ソースコードの修正差分や攻撃コードからも、攻撃の原理を理解することができます。
例えば、「特定の記号をフィルタリングしている」という場合には、「特定の記号を使って攻撃を実施できる脆弱性である」ということがわかります。

この段階のゴールは調査そのものではなく、

  • 自分の組織の対応要否を判断できること
  • 「アップデート適用後のシステム再起動が簡単にできない」などの制約がある中で、更新を適用する以外の暫定対応を提示できること

となります。

CVE-2018-11235を実際に攻撃して体験する

CVE-2018-11235を題材に、実際に調査と攻撃を体験しました。

https://nvd.nist.gov/vuln/detail/CVE-2018-11235

CTF

2-3名のチームに別れて、CTFを行いました。
チームごとに現実世界で報告された脆弱性のある環境が与えられ、
「Vulsを使って脆弱性を発見」-->「どのような脆弱性であるか調査し、攻撃を実行」-->「攻撃が成功するとflagゲット」
という内容でした。
苦戦している参加者も多かったですが、講師の方の「全員1つはflagとって帰りましょうね!」という熱い応援を受けて頑張っていました。
私は、講師の方の助言をいただきつつではありましたが、チームメンバーと共にCVE-2018-11235を題材にした問題を解くことができました。

最後に感想など

私は普段、「パッチの適用は大切ですよ」「アップデートを適用できるようにするための運用体制を作りましょう」と言っていました。
しかし、実際のシステム運用の現場では、そうも言ってられない場面もあるはずです。
今回学んだ「もう一歩踏み込んだ調査」をして、「状況に合わせた暫定対応方法」についてアドバイスをできるような、カッコいいエンジニアになりたいと思いました。精進します。
あと、脆弱性の調査と検証は楽しかったので、もっと手を動かしていきたいですね。
ありがとうございました!

kapieciiのブログについてお問い合わせがある場合、下記のフォームからご連絡をお願い致します。
お問い合わせはこちら