目的
脆弱性診断での脆弱性の発見のフローをOWASP BWAを用いて体験する。
ツールを用いた自動検証の後、手動でその脆弱性が実際に起こるかまでを手を動かして体験してみることで、ただ単にツールを使えるレベルからツールを使いこなして真に脆弱性があるかを検証できるスキルに近づく
OWASP BWAとは
やられアプリと呼ばれる、敢えて脆弱に作られたWebアプリケーションが複数入った詰め合わせセットです。 脆弱なため、仮想環境で動かす必要がありますが、その分ホストマシンに影響せず安全に脆弱性をテストすることができます。検証環境
構成
- ホストマシン M2 MacBook Air
- 仮想化ソフトウェア: UTM
仮想マシン
- OWASP BWA 仮想マシン
- Kali Linux 仮想マシン
ツール
- Firefox
- Burp Suite
- OWASP ZAP
準備
-
OWASP BWA仮想マシンを起動し、IPアドレスを確認する。
- 例: 192.168.138.4
-
Kali Linux仮想マシンを起動し、IPアドレスを確認する。
- 例: 192.168.138.5
-
Kali LinuxのFirefoxでOWASP BWAのIPアドレスにアクセスし、OWASP BWAのトップページが表示されることを確認する。
-
OWASP ZAPの証明書をfirefoxに
OWASP ZAPを開き歯車マーク→Network→ServerCertificates→importの順に
適切なフォルダにダウンロード
firefoxでsettings→Privacy& Security→Certificates→View Certificates...→import
先程のファイルをダブルクリック
手順
[ステップ1] 偵察：アプリケーションの「攻撃対象領域」を探る
操作：まず、ツールを起動せず、一人のユーザーとして対象アプリ（例：Juice Shopの検索機能やレビュー機能）を触ってみる。
目的：まず最初にアプリ全体の概要をみることで、どこが攻撃対象となりそうかを洗い出す。
まず、準備にあるトップページを表示
http://{BWA_IP}/
今回はBWAの中でも、peruggiaというアプリを使って演習する。
真ん中あたりのperuggiaのリンクをクリックするか、直接http://{BWA_IP}/peruggiaにアクセス。
peruggia のトップページです。画像ギャラリーとして、アップロードされた写真が一覧表示されています。
次の動作: どのような機能があるか把握するため、まずは画面上部のメニューバーにある「Log in」をクリックしてみましょう
説明: ログインページ (login.php) です。ユーザー名とパスワードの入力フォームがあります。
次の動作: まだアカウントを持っていないため、次のAboutを開きます。
説明: なぜかAboutが編集できます。
次の動作: 最後の方だけタブであるLearnを開きます。
説明: Papersという一覧が表示されたタイトルがリンクになっていそう。
次の動作: タイトルからPaperの詳細リンクを開く。
説明: 真っ白な入力欄があって入力できるが、サブミットは特にない。
次の動作: homeに戻る。
説明: 下の方をみると、写真にコメントと書いたリンクがある。
次の動作: コメント追加欄を開く。
説明: 入力欄がありPOSTできるが、特にCommentsには反映されない。
次の動作: ZAPに戻る。
とりあえず一通りマッピングと入力欄などの怪しい場所の把握ができた
[ステップ2] 自動スキャン：ZAPで「怪しい箇所」を叩く
操作：先程の確認では見逃してしまう部分まで、自動スキャンで全体を検査しつつ実際に攻撃してみる。
目的：手動では試せない膨大な攻撃パターン（ペイロード）をツールに代行させ、効率的に「アタリ」をつける。
先程の操作でhttp://{BWA_IP}/peruggiaがマッピングされているので
http://{BWA_IP}/をクリックして展開し、http://{BWA_IP}/peruggiaをクリックする。
この状態で右クリックしてAttack→ActiveScanwを選びます
そのままStartScanでActiveScanを実行する。
今のままだと全ての技術を対象としてスキャンしていますが、多くの無駄なスキャンが生じています。
このアプリケーションではあまり気にならないかもしれませんが、より大きいアプリを想定してスキャン領域を絞りたいと思います。
もう一度peruggiaを右クリックしてActiveScanを開きます。
今度は以下のShow advanced optionsにチェックを入れます。
すると上部タブが増えるので、その中のTechnologyタブを開きます。
現状全てにチェックがついていると思われます。
このように全ての技術スタックを想定してスキャンしているため無駄が生じて時間がかかっています。
(正しいか)
先にSpiderというツールを使います。
このツールは脆弱性自体を見つけることより、先程手動でやった検査を網羅的に行います。
もう一度peruggiaを右クリックしてからAttack→で今度はSpiderを選択
そのままStart Scan
すると先程と違って一瞬で終わります。
画面下部のタブから、アラートを開きます
Server Leaks Information via...とある２つのアラートに注目します。
これらの情報から、OSがUbuntuで、サーバーはApacheであることや、PHPやpython、perlなどを使っていることがわかりました。
これで対象を絞ることができます。
先程のActive Scanに戻って、以下のように設定し直します。(DBはわからないのでそのまま全部)
再度Strart Scan
少し待つと100%に達した
(途中で%が止まりますが正常です。Time-baseの攻撃等をしていてレスポンスを待っているので進み具合が止まります。)
[ステップ3] 発見と評価：アラートを読み解く
操作：ZAPのアラートタブに「クロスサイトスクリプティング（DOM型と反射型）」のアラートが出ることを確認する。
目的：ZAPが「なぜ」脆弱性だと判断したのか（どんなリクエストを送り、どんなレスポンスが返ってきたか）をZAPの画面で確認する。大まかな評価（例：リスク「高」）が行われることを示す。
アクティブスキャンタブからAlertsタブに切り替えて、一番上のアラートを見てみます。
どのURLで起こるかやRiskの高低、攻撃に試したペイロード、入力方法などがまとまって表示されています。
また下にの方には脆弱性の説明や対策まで乗っています。
次にあるCross Site Scripting (Reflected)も見てみましょう
こちらは(2)とついており、合計2件あるとわかります。
>マークを押すと展開できます。
両方見てみましょう
それぞれURLから
画像での1枚目(DOM Based)と3枚目(Reflectedの2番目)はどちらもlearnタブのpaper詳細画面(ステップ2でタイトルを押したところ)であり、2枚目(Reflectedの1番目)はコメントで発生するとわかる。
また攻撃ペイロードとしても、paperでは単純にScriptタグの挿入によるものに対して、コメントの方ではonMouseOverのイベントハンドラを用いたペイロードとなっている。
そしてこれらの脆弱性の発生源となっているのは、3つともURL Query Stringで共通しているとわかる。
[ステップ4] 手動検証：ツールが「本当」か確かめる（前回の構成案の核心）
操作：ZAPが見つけたペイロードが正しいか手動で確認する。
目的：ツールのアラートを鵜呑みにせず、必ず手動で「再現確認」を行うことの重要性を示す。開発者ツール（コンソール）の使い方もここで解説する。
先程3つに共通して、発生源がURLのqueryであることがわかったので、3つともPSOTリクエストなどを返さず、GETリクエストだけで可能であるとわかった。
一度3つともULRに先程のAlertでのURLをそれぞれ入れてみる。
すると以下のようになった。
Paperの２つは両方とも即座にalertが出た。
よって２つは少なくとも誤検知でないことがわかる。
残りのコメントでのペイロードだが、先程見た通りonMouseOverでのイベントハンドラにて発火するので、正しい部分にマウスカーネルを合わせる必要がある。
どこイベント発火のための場所があるか調べるために、検証で確認する
真正面のformであることがわかったが、特にマウスカーソルを合わせても何も起きない。
つまりアラートだけの情報では実際に起きなかったとわかる。
次のステップではこの報告された脆弱性を手動で検証して実際にこのページに反射型のXSSがあるかを調べる。
[ステップ5] ツールでの箇所を手動で詳しく。
操作：ブラウザの防御を回避する別のペイロード（例：<img src=x onerror=alert(1)>）を使い、手動でポップアップを出すことに成功する。
目的：これが脆弱性の「証拠（Proof of Concept = PoC）」となる。これをもって「脆弱性発見」と確定する。
まずは、何が原因で起こっているか確かめる。
ブラウザのセキュリティ機構などが原因であれば、コンソール等にメッセージが出るはずである。
すると気になるエラーを見つけた。
どうやらただの構文エラーのようだが、関係があるか見てみる。
再度ページをリロードしてみるとエラーは消えた。
その後アラートが出ると想定されている場所にマウスカーソルを合わせると再度エラーが出た。
確実にペイロードによってエラーが起きているとわかる。
もう一度Insoectorを見てみると、以下のようにalert(1);のあとに&postcomment=1が入ってしまっているとわかる。
いくつかこれを解消する方法はあると思われるが、alert(1);以降をコメントアウトする方法でやってみる。
ペイロードとしては onMouseOver=alert(1);からonMouseOver=alert(1);//にする。
最終的にURLのペイロードは以下のようになる
http://192.168.215.2/peruggia/index.php?action=comment&pic_id=+onMouseOver%3Dalert(1)%2F%2F
これをURLに入れたあと、フォームにマウスカーソルを合わせると以下のようにアラートが出た。
これでツールだけでは正確に検証できていなかった脆弱性を検証することができた。
まとめ
まずは脆弱性を、実践的なツールの使い方を用いて検出した。
ただそれだけではどうしても正確に検証できていない部分があることを体験した。
その後、手動で脆弱性を検証することによってより正確に脆弱性を検証することを体験した。
今後
今回は、ツールの誤検知の中でも、アラートが出ているのに脆弱性でないもの(アクティブフォールス)がないか、XSSを用いて一部検証した。
よって今後は
- 他の検知された全部の脆弱性を見る
- 検知されていない脆弱性(ネガティブフォールス)
- 検証した脆弱性のトリアージ
- トリアージした脆弱性のまとめ(レポート)
といったステップで行うのをおすすめします。