ASV検査、ペネトレテスターの思考を追う：セキュリティ対策の「ある視点」（14）（2/4 ページ）
PCI DSSで定められた脆弱性スキャンテストを行う組織、ASV。彼らの検査手順と考え方をトレースし、セキュリティの意味を再考せよ！
検査、開始！ 脆弱性スキャナ、オン！
さて、いざ検査開始……というわけにはいかない。検査を開始する前に、予定どおりいまから検査を行うという旨のメールを被検査チームに送るのである。開始のネゴが取れたら実際の検査である。この試験は日本時間で午後5時にスタートする。そしてタイムアップは翌日の午後4時、いわば23時間耐久検査となっている。
検査を行う際に初めに行うことは、脆弱性スキャナの実行である。脆弱性スキャナとは、検査の効率化を図るための検査の自動化ソフトウェア（アプライアンスの場合もある）である。脆弱性スキャナにはさまざまなOS、ソフトウェアに対する攻撃手法が収録されており、効率的かつ機械的に、スキャン対象に存在するで「あろう」脆弱性を洗い出し、検査対象の把握を行うのである。
しかし、どんなに優れた脆弱性スキャナでも得手、不得手もあれば、設定内容や解釈の仕方など特有の癖がある。また極論となるが、脆弱性スキャナも結局は自動化されたソフトウェアであるため、検査対象やネットワークの状況によっては、誤検出、非検出も起こり得る。これらを補うためにも、ペネトレーションテストでは、人間の手、つまり手動による検査を組み合わせるのである。
脆弱性スキャナの「うそと沈黙」
脆弱性スキャナの誤検出と非検出について理解していただくためにも、それぞれを簡単に説明しておこう。
誤検出は、“フォールスポジティブ”（False Positive）を日本語に訳したものなのだが、これは検査対象に脆弱性が存在していないにもかかわらず、脆弱性が存在するという誤った報告、極端ないい方をすると“うそ”の報告をすることを指す。検査対象に脆弱性がなければ問題ないのではないかと思われるかもしれないが、そうではない。
自身がその検査対象のサーバ管理者であることを想像してほしい。検査とその報告を受けるということは、報告された脆弱性に対して、なんらかの対応をしなくてはならないはずである。誤検出とは修正する必要のない、というよりは「存在しない問題を修正してください」と報告が行われることだ。システムは安全であるが、誤検出は報告される方にとっては非常に厄介なものである。
また非検出は“フォールスネガティブ”（False Negative）を日本語に訳したものである。誤検出とは逆に、検査対象に脆弱性が存在するにもかかわらず、その脆弱性に関する報告を脆弱性スキャナが報告してこないということを指す。いわば“沈黙”である。脆弱性にも管理者権限が奪取されシステムを乗っ取られるようなこれ以上ないくらいの高危険度のものもあれば、インフォメーションレベルや推奨設定ではないといった軽微といえるものまである。筆者の経験からいわせていただくと、脆弱性スキャナは危険度に関係なく沈黙する場合があると思っていただいていいだろう。
沈黙する理由はなぜだろうか。理由は複数存在する。
- 脆弱性検査パターンの作成が間に合っていない（存在しない）
- 脆弱性検査パターンの精度が低い
- 脆弱性が存在する開放ポートを発見できていない
脆弱性スキャナはその内部にシグネチャに相当するような、脆弱性を検査するパターンを持っている。そのパターンを用い、検査対象との通信を行った際の応答をチェックすることで脆弱性の有無を判定している。ほとんどの検査パターンは、脆弱性の公表後に作成されるため、中にはゼロデイアタックのように攻撃手法が確立しているにもかかわらず、検査パターンが間に合っていないというものが存在する。それが、前述した1.に当たる。
2.は検査パターンが存在するものの、その精度が低いために正確な判断ができず、沈黙という結果を招くものである。脆弱性スキャナのフォローをするわけではないが、世の中には多種多様なシステムが存在する。そのため結果的に、検査パターンの十分なテストができていない状態でリリースされるものがあるのは事実だ。
3.に関しては、脆弱性スキャナのロジックに関係する問題である。脆弱性スキャナのほとんどは効率化のために以下のようなフローでスキャンを行っている。
a.検査対象の稼働確認
b.ポートスキャン
c.OS推測やb.で開放が確認できたオープンポートのプロトコルマッピング
d.b.、c.の結果から最適化された脆弱性スキャン
a.は、いまから脆弱性スキャンを行う検査対象が稼働しているか否かなど、最低限の対象情報の確認を行う。例えば、大きなネットワーク帯の検査を行う場合、ICMPパケットの応答の有無やtcp/80などのウェルノウンポート（well-known port）への通信を確認し、対象の稼働が認められたもののみスキャンするというように利用することがあるのだが、現在はファイアウォールなどによって多くのパケットをブロックしている場合が多いため、筆者が検査を行う場合には、a.の結果は対象の一情報として扱うのみで、そのあとに脆弱性スキャンを行うかどうかの判断には使用していない。
b.は皆さんもご存じだろう。検査対象上でどのようなポートが開放されているのかということの確認である。つまり、脆弱性の存在、侵入の可能性がある入り口を探る第一歩である。ポートスキャンに関しては、筆者が過去に書かせていただいた以下の記事を参考にしてほしい。
【関連記事】
セキュリティ対策の「ある視点」（6）
己を知り、敵を知る――Nmapで見つめ直す自分の姿
http://www.atmarkit.co.jp/fsecurity/rensai/view06/view01.html
c.は、b.の結果を基にして、その開放ポートがどのようなプロトコルであるのかの確認や、対象のOSが何であるかといったような判断、フィンガープリンティング（Finger Printing）が行われる。これにより、後に行う脆弱性スキャンの効率化と精度の向上が行われるのである。
d.からが本番ともいうべきフェイズとなる。c.までで導き出された情報を基に、その情報に応じた脆弱性のチェックを行う通信を検査対象に行うのである。
例えば、tcpの25番がオープンしており、プロトコルがSMTP、アプリケーションがsendmailと判明している場合は、メールの不正中継チェックやバナー情報の確認、sendmailの脆弱性のチェックといったような判明している情報から特化したスキャンを実施するのである。
【関連記事】
セキュリティ対策の「ある視点」（4）
メールサーバ防御でも忘れてはならない「アリの一穴」
http://www.atmarkit.co.jp/fsecurity/rensai/view06/view01.html
以上のフロー、説明を見てご理解いただけたかと思うが、脆弱性スキャナのロジックにおいて、対象上の開放ポートの発見は脆弱性スキャンの中で重要な役割を担っている項目なのである。裏を返すと、このフェイズでポートの開放を見逃してしまうと、後のフェイズすべてに影響が出てしまい、結果的に、対象に存在する脆弱性を発見できない。つまり非検出となってしまうのである。
そんなことがあるのか、と思われる方もいらっしゃるかと思うが、脆弱性スキャナの特性や検査環境によっては、往々にして生じ得る問題である。
余談だが、筆者が過去数々の脆弱性スキャナの検証を行った際には、たびたびtcp/22番（SSH）を見逃し、そのポートに関する脆弱性が一切報告されない脆弱性スキャナが存在したこともあった。
前述したように、脆弱性スキャナには「うそと沈黙」が起こり得る。
話は戻るが、ASV試験では、お客さまから検査結果について質問があった場合には、質問内容に関する回答などの対応をしなければならないとされている。そのため、筆者を含む検査チームは「念のため」手動による検査で、誤検出、非検出を精査するという作業を行った。
ASVの検査中にどのようなことがあったのかということのそのすべてを記すにはあまりにもページ枠が足りない。よって、今回は、どのような非検出を手動でカバーしたのかということを語ろう。
Copyright © ITmedia, Inc. All Rights Reserved.