【目次】
1. はじめに
みなさまは脆弱性情報を確認していますか。
新たな脆弱性情報は日々更新されていきます。緊急での対応を迫られる方もいらっしゃるかと思います。アップデートの影響度を検証することも大変手間がかかるのでWAFの導入を検討されたことがあるかと思います。
そこで今回は脆弱性にWAFで対応する流れを説明させていただきます。
2. 大前提
まずは運用面も考慮したセキュアな設計でWebアプリケーションを作成しましょう。脆弱性が発見された際はアップデートを伴うことが多いので、すぐに対応できる体制を計画しておきましょう。
また、正式な対応はベンダー推奨の対応を実施してください。WAFでの対策は緩和策として考えましょう。深刻な脆弱性の場合は、攻撃によりサイトが停止する可能性もあります。早い段階から信頼された機関から公開されている情報を参考にセキュアな状態が保てるように対策しましょう。
上記を理解した上で次に進みます。
3. 攻撃を理解する
脆弱性情報が公開されるとCVE-IDやJVNから始まるVN-JPのIDが割り当てられ
NVDやJVNの脆弱性情報データベースに掲載されるので、その内容を確認し、対応が必要かどうかを判断します。
また、オープンソースであれば、ソースコードの差分や、PoC(Proof of Concept)といわれる実際に検証した結果などが公開されることも多く、得られた情報から総合的に判断し、対策を考えていきます。
WAFでの対策という観点で考えると対象の脆弱性を利用した攻撃がHTTP/HTTPS経由で実行されるものではない可能性があるため、WAFではない別の対策を検討する必要があります。さらに脆弱性情報が出たからといって攻撃にすぐに使えるものとは限らないので情報収集は定期的に行い、具体的な対策を検討することをお勧めします。
では実際にあった脆弱性を元に確認していきましょう。
今回例にあげるのはShellShock(CVE-2014-6271)です。
環境変数の値の関数定義を適切に解析しないため、任意のコマンドを実行される脆弱性です。情報漏洩やデータ改ざん等様々な影響が考えられます。
※当記事は脆弱性の説明ではないので脆弱性の詳細情報は様々な企業や個人から公開されている内容をご確認ください。
CVE
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271
JVN
http://jvn.jp/vu/JVNVU97219505/index.html
IPA
https://www.ipa.go.jp/security/ciadr/vul/20140926-bash.html
公開された以下のPoCでWAFで検知可能な http header の user-agent に攻撃を仕掛けるパターンを検知してみました。
https://github.com/opsxcq/exploit-CVE-2014-6271
4. 条件を設定
脆弱性情報やPoCを確認したところ、以下のような形で値が渡された場合に実行されることが確認できました。
() { :; }; echo; echo; /bin/bash -c 'cat /etc/passwd'
では、この攻撃を実際に検知する Filter を設定していきましょう。
単純にPoCの通り検知しようと思えば、この内容を文字列一致条件に設定するだけです。本脆弱性の重要な部分は環境変数の値の関数定義部分になるので、本来であればその部分に焦点を当てて作成することになります。
今回は上記内容をそのまま検知することを目的に作成していきます。
特定の箇所にスポットを当て以下の3つを選びました。
() {
echo;
/bin/bash
ここで大事なポイントは誤検知を引き起こさないように注意することです。
今回は user-agent に通常使用されないものなので問題なさそうですが、body部分では誤検知を起こしそうです。WAFを使用していると必ず誤検知に遭遇すると思いますが、誤検知を起こす理由はこういった本当は検知すべきなのに通常の処理と判別がつかない場合に起きることになります。
では実際に設定していきましょう condition に設定する内容は以下です。
・type ： String
続いてFilterの設定は各文字列「 () {」「echo;」「/bin/bash」毎に設定していきます。
・Part of the request to filter on ： HeaderでUser-Agent
・Transformation ： Convert to lowercase
・Match type ： Contains
・Value to match ： ”() {“, “echo;”, “/bin/bash”
これで condition の作成は完了です。作成した condition を Rule として設定する手順は過去のブログを参考にしてください。
・AWS WAF で SQL Injection をブロックしてみる
https://www.wafcharm.com/jp/blog/block-sql-injection-jp/
・AWS WAF で URI に特定の文字列が含まれるリクエストをブロックする
https://www.wafcharm.com/jp/blog/block-specific-string-in-uri-jp/
・AWS WAF で特定の IP アドレスからの攻撃をブロックする
https://www.wafcharm.com/jp/blog/aws-waf-block-specific-ip-jp/
5. おわりに
誤検知（過検知）を発生させないよう正確なルールを作成するには様々な知識が必要となります。Webアプリケーションに詳しいセキュリティエンジニアが配置可能な企業ならば、自社で運用していくことは可能ですが、様々な脆弱性に対応し続ける運用をしていくことは困難です。正式な対応については公開された情報からベンダー推奨の対応を実施しましょう。即時でアップデートの対応を行うことが困難な場合は外部のセキュリティ製品の利用も検討してください。